[Nsi-wg] NSI service

Fri Sep 2 08:21:21 CDT 2011

Ok good.   I agree with what you did...it makes sense to me.  And you 
and I had discussed the NSA topo object.   We just need to bring this to 
the group when we do a Rio post-mortem (:-).

I recall that we decided that the NSA and the Network were separately 
addressable entities - one was an active agent, and one just represented 
an administrative/infrastructure domain.  Each network has exactly one 
NSA, and each NSA manages exactly one network.   (This does not preclude 
things like federated structures in the future, but feds require some 
topological considerations that we have not broached yet.)

Thanks!
Jerry

On 9/2/11 9:00 AM, John MacAuley wrote:
> You are correct - copy and paste issue.  It should be 
> *urn:ogf:network:nsa:Martinique-DynamicKL.*
>
> I can't remember if we decided to use the network to define the NSA, 
> but in the topology we need to uniquely name the NSA and it can't 
> conflict with the network name.  I made the leap of faith that we 
> should then use this NSA name in the NSA fields.
>
> John.
>
> On 2011-09-02, at 8:49 AM, Jerry Sobieski wrote:
>
>> 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/ca1722aa/attachment-0001.html 