Do we allow one NSA (by URL) to act for multiple networks?
Peoples, I pulled together a few slides to capture the discussion and illustrated the possible deployment models. John.
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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On 30 Jan 2013, at 23:10, Jerry Sobieski <jerry@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.
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@uva.nl> wrote:
On 30 Jan 2013, at 23:10, Jerry Sobieski <jerry@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.
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@uva.nl> wrote:
On 30 Jan 2013, at 23:10, Jerry Sobieski <jerry@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (3)
-
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley