[Nsi-wg] NSI service
Jerry Sobieski
jerry at nordu.net
Wed Sep 7 15:49:59 CDT 2011
Yes- Everyone remember that there has been a lot worked out the last few
days...so please read old email with that in mind... Some of this
stuff is ancient history already:-)
Jerry
On 9/7/11 3:38 PM, John MacAuley wrote:
> Looks like mail is starting to come through the NSI-WG mailing list again.
>
> The decision was made to use HTTP and BASIC authentication with a single fixed account.
>
> John.
>
> ----- Original Message -----
>> From: "John MacAuley"<john.macauley at surfnet.nl>
>> To: "Atsuko Takefusa"<takefusa at acm.org>
>> Cc: "NSI WG"<nsi-wg at ogf.org>
>> Sent: Friday, September 2, 2011 11:54:36 AM
>> Subject: Re: [Nsi-wg] NSI service
>>
>> Can everyone one reply and let me know if they can do https or should
>> we only do http?
>>
>> I think we should use http basic authentication to secure the
>> session. Can everyone allocate a set of accounts on their system
>> for each of the NSA and send the information to the associated NSA
>> prime?
>>
>> Thanks,
>> John
>>
>> Sent from my iPhone
>>
>> On 2011-09-02, at 10:29 AM, Atsuko Takefusa<takefusa at acm.org> wrote:
>>
>>> Hi Jerry, John, and all,
>>>
>>> We will use "urn:ogf:..." values in<requester/providerNSA> and
>>> <stpId>, won't we?
>>> If so, why do we describe the "urn:ogf:..." values in the .owl
>>> file?
>>>
>>>
>>> And I have a question about security.
>>> Which of the followings will we use at Rio?
>>>
>>> #1 http + no authentication
>>> #2 http + basic authentication (single user name& password)
>>> #3 https + basic authentication (single user name& password)
>>> #4 other
>>>
>>> If #2 or #3, what are the user name and password?
>>>
>>> Thanks,
>>>
>>> Atsuko
>>>
>>>
>>> 2011/9/2 Jerry Sobieski<jerry at nordu.net>:
>>>> 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>
>>>> NORDUnet / Nordic Data Grid
>>>> Facility._______________________________________________
>>>> nsi-wg mailing list
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> nsi-wg mailing list
>>>> nsi-wg at ogf.org
>>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>>>
>>>>
>>>
>>>
>>> --
>>> Atsuko Takefusa
>>> Information Technology Research Institute, AIST
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
More information about the nsi-wg
mailing list