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.