Hello, I want to clarify a bit on NSI services - currently when generating sources from the NSI wsdls we get two services (RA and PA) and each one has its own url. I try to combine them together so they will be accessible under a single url, suitable for csProviderEndpoint. Br michal
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. Jerry will have a stroke, but this would allow an RA-only entity to not need to be in the topology file. If we want to remove the requirement for the replyTo field and force all RA addresses into the topology file then we could do that. We would then do a lookup for the NSA csRequesterEndpoint in topology before sending a confirmation. Comments? John. On 2011-08-31, at 10:35 AM, Michał Balcerkiewicz wrote:
Hello,
I want to clarify a bit on NSI services – currently when generating sources from the NSI wsdls we get two services (RA and PA) and each one has its own url. I try to combine them together so they will be accessible under a single url, suitable for csProviderEndpoint.
Br michal _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Ok ... comments in line: On 8/31/11 10:53 AM, 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. Jerry will have a stroke, but this would allow an RA-only entity to not need to be in the topology file. The csProviderEndpoint tells the local NSA how to contact the NSA represented by the NSA object. Period. No RA or PA qualifications or constraints. - NSA to NSA. The roles of the NSA in any particular request should not affect the address used to send or receive a message. It affects which fields the NSA IDs go into, but it does not affect where a message is sent if its going to a particular NSA. One NSA, one address.
The confrimation response is an NSI CS protocol message - it does not rely on the reply going back to the same SOAP Endpoint that issued some other message. For example: It would be perfectly fine within the CS protocol to *change* the NSA contact information associated with an NSA bewtteen the Request and ensueing Response. The NSI layer would still function just fine - it would find the NSA addess for the appropriate NSA and queue a Confirmation. But the MTL would break this if the MTL is expecting to send the message back to where it came from. This is just broken John and should not be even considered. Likewise, I could restart and issue the confirmation after a local restart ...the SOAP environment would be destroyed and the MTL would not know how to deliver the message. In NSI, each message is processed by the MTL independent of every other NSI message. Period. We've gone over this before. It is ok to acknowledge receipt of a message between two MTLs in order to assure delivery - this is fine within the SOAP environment. But you cannot link upper Layer NSI CS messages to SOAP constraucts or dependencies.... No.
If we want to remove the requirement for the replyTo field and force all RA addresses into the topology file then we could do that. We would then do a lookup for the NSA csRequesterEndpoint in topology before sending a confirmation.
This is much better. But still not clear why we care or need this...? The PA NSA receives a Request() message...once the MTL has finished processing it the message is passed up to the NSI layer for processing. The NSI layer looks at the msg type and says to itself "Self, this is a primitive *request* that I just *received*, therefore I am the NSA in the PA-NSAID, and the request came from the NSA in the RA-NSAID field. The NSI layer will never need see the SOAP Endpoint or any other SOAP fields...and shouldn't. It only sees the NSI message header and learns its role from that....right? What I suggest is the following: I think there is some confusion about the RA and PA _/roles/_ getting in the way of /_Source and Destination NSA_/s in the message header. Maybe the msg header field names are chosen poorly. But without changing the roles of the corresponding NSAs, or the semantics of the messages/primitives, we could rename the message header fields to "SourceNSA" and "DestNSA". The message mechanics be a bit clearer if the message header fields were clearly meant as message delivery fields rather than NSI functional roles. Not faulting anyone on this...but would it not work better? Their respective roles as RA and PA will still be obvious from the message type and direction (e.g. a "send" "Request" msg puts the PA's NSAID in the destNSA field and the RA's NSAID in the SourceNSA field,, The NSA issueing the Response msg will place the RA's NSAID in the destNSA field, and the PA's NSAID in the sourceNSA field. This way, the MTL always sends messages based soley on the DestNSA field of the NSI message. No confusion, and it requires almost no knowledge of the NSI layer primitives. The MTL still needs to know the *address* of the destNSA. So a lookup is still required by someone....The MTL could a) require NSI layer provide the address as a Send() parameter, or b) the MTL could find the NSAID in the topology database itself and grab the contact info, or c) we define another service to look up this information. I suggest "b" - at least for Rio as we are pretty much there now. But "a" would be an easy and perhaps purer alternative since it means the MTL needs no topology access. Jerry
Comments?
John.
On 2011-08-31, at 10:35 AM, Michał Balcerkiewicz wrote:
Hello, I want to clarify a bit on NSI services – currently when generating sources from the NSI wsdls we get two services (RA and PA) and each one has its own url. I try to combine them together so they will be accessible under a single url, suitable for csProviderEndpoint. Br michal _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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.
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> <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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST
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@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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST
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@surfnet.nl> To: "Atsuko Takefusa" <takefusa@acm.org> Cc: "NSI WG" <nsi-wg@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@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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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@surfnet.nl> To: "Atsuko Takefusa"<takefusa@acm.org> Cc: "NSI WG"<nsi-wg@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@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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
On Fri, 2 Sep 2011, 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.
One of the key ideas with a standard is that one is supposed to be able to implement it without having overheard some decision on how to represent something in a phone meeting :-).
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 :-)
Thanks for providing an example, it is highly needed. I have a few comments, but we should definitely wait to after Rio with modifying anything.
<int:correlationId>urn:uuid:73d32a9d-fc68-4736-9c24-99abce1aaea3</int:correlationId>
This is not a UUID (correlationId is a uuidType). It is a URI/URN, which happens to by a UUID. Also there is a slew of ways to represent UUIDs. I do not see the reason for forcing the usage of UUIDs. Given the constraints I would have choosen UUIDs myself, but forcing a specific technology into the spec. seems a bit silly. A string would do fine as type.
<requesterNSA>urn:ogf:network:nsa:Aruba-OpenNSA</requesterNSA> <providerNSA>urn:ogf:network:NSnetwork:Martinique-DynamicKL</providerNSA> <globalReservationId>urn:ogf:network:service:Aruba:conn-560</globalReservationId> <connectionId>urn:uuid:593d9816-0574-471d-b2a9-101e63a5d0f2</connectionId>
Are we just using URNs because it is possible? I have a hard time seeing what value they add here? (they do not provide a global namespace). Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
On 2011-09-05, at 6:48 AM, Henrik Thostrup Jensen wrote:
On Fri, 2 Sep 2011, 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.
One of the key ideas with a standard is that one is supposed to be able to implement it without having overheard some decision on how to represent something in a phone meeting :-).
True, but one could also read the documentation which states "correlationId - An identifier provided by the requesting NSA used to correlate to an asynchronous response from the responder. It is recommended that a Universally Unique Identifier (UUID) URN as per IETF RFC 4122 be used as a globally unique value." :-) I wanted to make sure the value was as unique as possible so designers could have certainty when coding that people would not but stuff like "corrid-1" in the 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 :-)
Thanks for providing an example, it is highly needed.
I have a few comments, but we should definitely wait to after Rio with modifying anything.
<int:correlationId>urn:uuid:73d32a9d-fc68-4736-9c24-99abce1aaea3</int:correlationId>
This is not a UUID (correlationId is a uuidType). It is a URI/URN, which happens to by a UUID. Also there is a slew of ways to represent UUIDs. I do not see the reason for forcing the usage of UUIDs. Given the constraints I would have choosen UUIDs myself, but forcing a specific technology into the spec. seems a bit silly. A string would do fine as type.
This comment I do not understand. We are using names spaces throughout the specification to provide context to a field. For example, the STP, NSA, and global reservation Id all use them so why not be consistent throughout the message? In addition, we have forced specific formats and naming standards on all the fields. UUID happens to be a globally accepted standard for generating unique identifiers, We needed one, so why not use the standard everyone else in the computer industry uses :-)
<requesterNSA>urn:ogf:network:nsa:Aruba-OpenNSA</requesterNSA> <providerNSA>urn:ogf:network:NSnetwork:Martinique-DynamicKL</providerNSA> <globalReservationId>urn:ogf:network:service:Aruba:conn-560</globalReservationId> <connectionId>urn:uuid:593d9816-0574-471d-b2a9-101e63a5d0f2</connectionId>
Are we just using URNs because it is possible? I have a hard time seeing what value they add here? (they do not provide a global namespace).
Is your main issue that I prefixed the UUID with "urn:uuid" or are you fundamentally against enforcement of a unique identifier in the field?
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
Hi John On Mon, 5 Sep 2011, John MacAuley wrote:
On Fri, 2 Sep 2011, John MacAuley wrote:
True, but one could also read the documentation which states "correlationId - An identifier provided by the requesting NSA used to correlate to an asynchronous response from the responder. It is recommended that a Universally Unique Identifier (UUID) URN as per IETF RFC 4122 be used as a globally unique value." :-)
OK, I actually missed the URN part.
This is not a UUID (correlationId is a uuidType). It is a URI/URN, which happens to by a UUID. Also there is a slew of ways to represent UUIDs. I do not see the reason for forcing the usage of UUIDs. Given the constraints I would have choosen UUIDs myself, but forcing a specific technology into the spec. seems a bit silly. A string would do fine as type.
This comment I do not understand.
UUID: 5c731826-d7ba-11e0-b36f-00144f20a8d2 URN: urn:uuid:5c731826-d7ba-11e0-b36f-00144f20a8d2
We are using names spaces throughout the specification to provide context to a field. For example, the STP, NSA, and global reservation Id all use them so why not be consistent throughout the message? In addition, we have forced specific formats and naming standards on all the fields.
The question is "why", not "why not". I simply do not see what value the URNs provides, besides "Hey, I know URNs, we should use them".
UUID happens to be a globally accepted standard for generating unique identifiers, We needed one, so why not use the standard everyone else in the computer industry uses :-)
I do not mind UUIDs, I've used them before and will probably use them again. But technology tends to change a lot, and in some years there might be something else. Put the restriction for generating ids there, but keep there spec. free from specific technologies in any way possible. The UUID can be in an appendix with implementation recommendations.
Are we just using URNs because it is possible? I have a hard time seeing what value they add here? (they do not provide a global namespace).
Is your main issue that I prefixed the UUID with "urn:uuid" or are you fundamentally against enforcement of a unique identifier in the field?
The issue is that URN just adds a prefix here. They do nothing to ensure uniqueness, as a field must explicitely begin with "urn:ogf...". The last part is the implementation name, which is the only place there is a real difference, and despite us using URNs we still have to ensure uniqueness there. As I see it, it is a solution to a problem we do not have. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
participants (5)
-
Atsuko Takefusa -
Henrik Thostrup Jensen -
Jerry Sobieski -
John MacAuley -
Michał Balcerkiewicz