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

[Jerry Sobieski]

Hi John-

I thought your slides were good.   They provide a clear separation of 
the NSI architectural aspects from the implementation of those aspects.  
This is very good IMHO :-)

However - there is one aspect I don't think works as you suggest:

--- 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.

Thus delivery of a message cannot be done solely on the basis of NSA 
IDs.   In order to retain the one-to-one relationship of NSAs to 
networks, we need to have a single "NSI destination" for messages (e.g. 
NSA ID) for all services destined for or associated with a particular 
NSA or network.    To do as you propose in Slide 4 ties all the NSI 
layer to a particular messaging layer technology.   (The simplest 
example of this is that even different SOAP versions can screw the NSI 
messaging.  This is bad.)

I suggest the following:
We deliver messages between NSAs based solely on the NSA ID.   A single 
NSA may have one or more underlying messaging layer addresses (e.g. 
multiple SOAP endpoints) that are _/functionally equivalent/_ as far as 
message delivery is concerned.   We add a a Service Identifier to the 
NSI header - *AND* we require that the NSA inspect the Service ID and 
route the message internally to the proper service entity.

There are several twists on this theme, but they all boil down to the 
same thing: The sending NSA needing to differentiate messages by both 
destination NSA ID and destination Service in order to determine where 
to send it.

I think it is important to separate those issues that are NSI related 
(e.g. NSAs, NSI Service routing, Connection ID routing etc) from those 
issues over which NSI has no control (HTTP/SOAP/TCP/SSL/etc., firewalls 
and NATs)   We push these other uncontrolled transport protocol issues 
into a Message Transport Layer that is only dependent upon the NSAID, 
and everything else above it is dealt with by NSI specifications.   But 
the MTL does not need to know about different NSI Services or Connection 
IDs or anything else - just the NSA ID.

I am building a PPT on a proposed MTL for next week.   I think this will 
make this clearer.   But I like everything you proposed except the 
separate NSI service end points.

Thoughts?

Jerry


On 1/29/13 10:07 PM, John MacAuley wrote:
> Peoples,
>
> I pulled together a few slides to capture the discussion and illustrated the possible deployment models.
>
> John.
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20130130/868c467f/attachment.html>