[Nsi-wg] NSI service

Fri Sep 2 07:49:36 CDT 2011

Hey John - question about the requesterNSA/providerNSA fields...see 
comment in line..

On 9/2/11 8:30 AM, John MacAuley wrote:
> Looks like I have some explaining to do.  We forget that not everyone 
> is participating in the NSI weekly meetings and the extra special OGF 
> conference meetings.  Lucky for you, but unfortunately you miss the 
> results of some of the discussions.  The is only one SOAP endpoint in 
> the message and that is in the replyTo field.  We originally didn't 
> have the replyTo field and the endpoints were in the requesterNSA 
> and providerNSA fields, however, there was a push to make these field 
> protocol independent.
>
> I wrote the new topology schema a couple of weeks ago so this is the 
> first time a SOAP endpoint had shown up in the schema.  Mainly for 
> discovering the ProviderNSA endpoint.  This will remove manual 
> provisioning of the endpoint in each NSA. Howeve, now that we have 
> this topology mechanism, we could expand it to hold the Requestor 
> endpoint as well, removing the need for the replyTo field.
>
> Here is what a request should look like based on all the agreements we 
> have reached.  We need to make sure everyone follows this pattern or 
> chaos will prevail :-)
>
> <soapenv:Envelope 
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
> xmlns:int="http://schemas.ogf.org/nsi/2011/07/connection/interface" 
> xmlns:typ="http://schemas.ogf.org/nsi/2011/07/connection/types" 
> xmlns:urn="urn:oasis:names:tc:SAML:2.0:assertion" 
> xmlns:xe="http://www.w3.org/2001/04/xmlenc#" 
> xmlns:xd="http://www.w3.org/2000/09/xmldsig#">
> <soapenv:Header/>
> <soapenv:Body>
> <int:reservationRequest>
> <int:correlationId>*urn:uuid:73d32a9d-fc68-4736-9c24-99abce1aaea3*</int:correlationId>
> <int:replyTo>*http://orval.grid.aau.dk:7080/NSI/services/ConnectionService*</int:replyTo>
> <typ:reservation>
> <requesterNSA>*urn:ogf:network:nsa:Aruba-OpenNSA*</requesterNSA>
> <providerNSA>*urn:ogf:network:NSnetwork:Martinique-DynamicKL*</providerNSA>
Right here ^    Why do you specify an NSA URN in the requesterNSA field 
but specify a Network in the provider NSA field ??    These should both 
be NSA references.  Right?

Also, at SLC, we did not define an "NSA" URN...not that I recall.  Did 
we?    I think what you have will work nicely for now, but I don't think 
it is in the spec. (?)   Therefore, we should put this on the near term 
dicussion list to get group consesnsus.  (we touched only on the Network 
<not equal> NSA issue, but not how that should be done or what the 
mapping supports, etc.)
> <reservation>
> <globalReservationId>*urn:ogf:network:service:**Aruba**:conn-560*</globalReservationId>
> <description>OpenNSA Test Schedule #1</description>
> <connectionId>*urn:uuid:593d9816-0574-471d-b2a9-101e63a5d0f2*</connectionId>
> <serviceParameters>
> <schedule>
> <startTime>2011-10-15T21:32:52+01:00</startTime>
> <endTime>2011-10-15T22:32:52+01:00</endTime>
> </schedule>
> <bandwidth>
> <desired>100</desired>
> </bandwidth>
> </serviceParameters>
> <path>
> <directionality>Bidirectional</directionality>
> <sourceSTP>
> <stpId>*urn:ogf:network:NSnetwork:Martinique:M1*</stpId>
> </sourceSTP>
> <destSTP>
> <stpId>*urn:ogf:network:NSnetwork:Martinique:M4*</stpId>
> </destSTP>
> </path>
> </reservation>
> </typ:reservation>
> </int:reservationRequest>
> </soapenv:Body>
> </soapenv:Envelope>
>
> On 2011-09-02, at 5:45 AM, Henrik Thostrup Jensen wrote:
>
>> On Wed, 31 Aug 2011, John MacAuley wrote:
>>
>>> Yes you can combine them if you need to.  But I think the protocol 
>>> will work without them combined. The csProviderEndpoint value tells 
>>> the RA how to contact the PA for a network.  The RA fills in the 
>>> replyTo field within the SOAP request to tell the PA how to respond 
>>> with the confirmation, failed, or forcedEnd messages.
>>
>> I combine the endpoints in OpenNSA, but as I interpret the protocol, 
>> this is not a requirement at all, and the protocol explicitely 
>> supports different endpoitns for this.
>>
>> It is important to note, that the RA endpoint is only advertised 
>> through the replyTo field (AFAIK), and never in the topology and 
>> requester / provider fields.
>>
>>> Comments?
>>
>> I find that there are way to many addressing schemes. Currently there is:
>>
>> A. NSA provider endpoint advertisted through topology.
>> B. NSA provider and requester endpoint specified in provider/requester
>>   message fields.
>> C. NSA requester endpoint specified in replyTo message field.
>>
>> Which is simply to many IMHO.
>>
>> I think the providerNSA and requesterNSA fields in the message could 
>> be removed entirely without problems (these fields smell alot like 
>> some low level protocol where security is not an issue - which is not 
>> the case for NSI at all).
>>
>> I would also like to see the removal of the replyTo field, such that 
>> an NSA only has one contact point - the one advertised through the 
>> topology.
>>
>>
>>    Best regards, Henrik
>>
>> Henrik Thostrup Jensen <htj at ndgf.org <http://ndgf.org>>
>> NORDUnet / Nordic Data Grid 
>> Facility._______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110902/0e375a1a/attachment-0001.html 