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