[Nsi-wg] NSI service

[Jerry Sobieski]

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 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/20110831/61f43da8/attachment.html