[Nsi-wg] Do we allow one NSA (by URL) to act for multiple networks?

[Jerry Sobieski]

Hi John-

I looked at your slides multiple times to clarify my thinking...

I agree with slides 5, 6, and 7.   With a small qualification on slide 6 
that says the protocol endpoint must also implement a message transport 
layer function to inspect the destination NSA and decide how to forward 
the message to reach the intended NSA.   So, strictly speaking, the 
protocol endpoint is not *just* NSI protocol endpoint , but a network 
transport function as well.   NEvertheless, the message transport is 
still based upon NSA ID.

However, ...

In slide 3 bullet 4 you state that NSA ID is the only value that should 
be used to address NSI messages to their destination.  This is correct - 
its conformant to the NSI Framework that states that NSAs are the 
protocol speakers.   THus messages are directed between NSAs only.

However, in slide 4 bullet 5 you break this rule.   You assert that each 
NSA function (presumably each protcol or even each primitive of each 
protocol) can have a separate endpoint...  While underlying transport 
might support this - it is not conformant to the NSI framework that says 
messaging is transported between NSAs [only]. From the NSI perspective, 
an NSA may have multiple endpoints as long as they are all functionally 
equivalent.   If the endpoints are not equivalent, i.e. they do not map 
to the same NSA, then they *by definition* constitute different NSAs.  
Thus if my NSI protocol needs to send a message to a specific NSA I 
should address the message to the intended NSA.  If the destination 
supports multiple protocols or has different protocl endpoints for each 
protcol or primitive, then the *destination NSA* is responsible for 
determining how to process the message content.     If you have 
different endpoints for differnet primitives, there is no way to 
indicate which endpoints correspond to which protocol speaker except via 
NSA ID.   Thus each protocol speaker (NSA) only sends messages to other 
protocol speakers (other NSAs) - not to the specific primitive endpoints.

This means your slide 8 and slide 9 are incorrect.   As those functions 
are *not* associated with the same NSA(s) behind the protocol endpoints. 
   In Slide 8, each different protocol end point constitutes a different 
NSA.  And in slide 9, if the protocol endpoints are not equivalent in 
terms of the NSA functions they serve, then you need to treat them as 
separate NSAs.   (It is ok to separate the protcols onto separate NSA - 
it should not break the protocols, but that do not reside in the same 
NSA if there are separate and unique destinations for each.)

I think it is important to understand the subtle differences you are 
making.  The sending NSA designates message destination by NSA ID. The 
sending NSA should not be required to differentiate each protocol 
primitive on every remote NSA.   Its unnecessary.  In your NSA if you 
want each primitive to have a separate endpoint - then write your NSA to 
distribute the messages accordingly - but this is transparent to all 
remote NSAs sending you a message.    From the NSI perspective - each 
NSA simply sends messages to other NSAs. Period.

A couple other points:  First, In regards to protocol mappings to NSA 
IDs, the physical network they represent or speak for is IMO immaterial 
to the message transport addressing - these are separate issues.  
Message transport has to do solely with delivering messages between 
NSAs, and has no direct relationship to the data plane an NSA may or may 
not represent.    Indeed, it may be that the Network ID may only need be 
associated with an NSA for the CS protocol - its not clear that, say, a 
NSI Topology Service needs to be associated with a particular data plane 
at all...it could simply serve topology information about any/all 
networks...  A TS would need a NSA ID, but maybe not a NSI Network ID.  
(I think this was the outcome of our discussion last March about 
NSA-NSnetwork mappings)

Second, There is no intrinsic requirement for two protocols to be 
associated with a single NSA ID.   If/when two protocols are part of the 
same NSA, it only means that NSA is able to distinguish all the messages 
from one another and that the services coexist on the same NSA.  I think 
this is best, but it is not required.    THere is no inherent linkage 
between different protocols due to the agent that runs them.   I.e. 
NSI-CS does not *need* to be the same NSA as the NSI-TS.     There could 
good reasons for separating protocols to separate agents.  However(!) - 
this should also not be interpretted to mean that two disjoint and 
independent protocol agents can claim to be the same NSA yet require 
different endpoints for different services.   THis can lead to some 
erroneous operation as sending agents may need to interact with both 
services but cannot distinguish which endpoint to use since they both 
claim to be the same NSA.

Finally:  What exactly does the "Discovery Service" do? (:-) Initially 
it was to tell us what version of NSI an NSA was running.   DS was not 
part of v1.   Is there a [draft] document that describes the Discovery 
Service?  Do we have group clarity on what the DS is supposed to do?    
I admit that I am very confused about what it has evolved into - or 
ought to do - or ought not be doing - or how it does it...
(Thanks.)

I hope this was lucid...
Jerry


On 1/31/13 8:28 AM, John MacAuley wrote:
> I had a funny feeling someone was going to bring this up :-)
>
> You are correct in that we do need to distinguish between services, however, the NSA is not distinguished by the service endpoint.  A requester NSA can determine the protocol endpoint for a specific service and for a specific NSA through the Discovery Service.  If there are multiple NSA off of a common protocol endpoint, then the provider NSA element is used to determine the target NSA for that endpoint.  If the endpoint supports multiple services, then the service operation contained in the message will identify the specific service being targeted.
>
> Does that address your concerns?  I wanted to make sure we clearly state that the providerNSA value should be the only value used to identify the NSA.  Would you like me to add the specific statement about how a shared endpoint should behave?
>
> Thanks,
> John
>
> On 2013-01-31, at 4:20 AM, Jeroen van der Ham <vdham at uva.nl> wrote:
>
>> On 30 Jan 2013, at 23:10, Jerry Sobieski <jerry at nordu.net> wrote:
>>
>>> --- Slide 4 last bullet:   If each NSI Service (e.g. Discovery Svc, Connection Svc, Topo Svc, etc)  is allowed to have different underlying messaging layer endpoints, (e.g. different SOAP endpoints) then the NSI messages cannot be delivered with *only* the NSA IDs (Slide 3 bullet 4).    Delivery will be dependent upon both the destination NSA ID *AND* the NSI service.    I.e. The destination NSI Service must also be known in order to differentiate and select the appropriate protocol (SOAP) end point.
>> No. The messages for the different services are different, thus it is very easy to differentiate between them.
>>
>> Jeroen.
>>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg