Hi John- On 3/6/13 10:28 PM, John MacAuley wrote:

Peoples,

I was running through the bootstrap procedure with Chin when the question of multiple NSA identifiers per software instance came up. Can someone please explain to me again why we need a one-to-one mapping between NSA (NSA identifier) and Network (Network Identifier)? It seems to be a very arbitrary restriction. I have looked through the existing WSDL definitions and there are no restrictions within it for this imposed rule. In addition, the topology schema could easily have multiple "managing" elements within the NSA object to allow it to reference multiple Network Identifiers, thereby creating a one-to-many relationship. The WSDL does not define the framework or the protocol(s) - it simply defines the primitive interfaces. It does not express their functional meaning or semantics. You need to study the framework and/or protocols to make sure the protocol and framework continue to work properly in the face of the change you propose.

We have a very real network requirement to support multiple network services off of a single NSA software instance. For example, off of one NSA (urn:ogf:network:surfnet.nl <http://surfnet.nl>:2012:nsa) we can support the ETS service (urn:ogf:network:surfnet.nl <http://surfnet.nl>:2012:ets) and an EPL service (urn:ogf:network:surfnet.nl:2012:epl). At the moment, given the current restriction, I would have to have two separate NSA.

Can you describe the "very real network requirements" that cannot use separate NSA IDs for each service instance? You should state the specific issue that is problematic, explain why it causes problems with the exsiting framework and/or protocol as currently defined, or why it prevents or enables important future capability(s). Then explain why/how your solution resolves the issue. Sudden changes to core framework principles are really REALLY dangerous and make real implementors (besides yourself:-) crazy. We need to observe the process of making a proposal, circulating it and presenting and discussing it, giving people time to consider it and the implications it carries with it.

Does anyone have a reason why we can't remove this restriction? I actually think it is viable...with some explicit caveats:

We initially asserted the one-to-one NSA-to-Service Domain relation so that we could identify to which agent we should send a request intended for a particular data plane domain. Implicitly, this also identified the set of policies the RA would encounter to authenticate and authorize the request. And similarly, each PA NSA would implement a set of policy corresponding to the one domain it covered. Simple and easily understood by mortals. And frankly quite easy to implement. If we allow a single NSA to speak for multiple domains, _/we need a means to differentiate the policies associated with each domain covered by that single NSA./_ This is at least one aspect that breaks if we allow it. This could be solved by the "Service identifier" (the service definition type) we adopted in Chicago as part of the Reservation Request. This Service Identifier could be defined to identify local service specific administrative policies that the NSA is to consult for each service under its control - as well as the service specific parameters that are allowed by convention for that type of service. e.g. A request to the NetherLight NSA might allow one of two possible Service Identifiers: the "NetherLight.ets" service, or the "NetherLight.EPL" service. Both service domains would be seen in the topology database and would point to the same NSA object. Both service identifiers would map to the same service type (say, a "p2pcs" service definition) but each has a separate policy associated with it as to whom can use it, or how it chooses paths, who it will peer with on the control plane, etc. Indeed, your example is exactly why I wanted to see the service identifier in the reservation request (I expected we would have multiple services coverd by one NSA.) This may be quite simple if the covered domains are all willing to assume the same policy constraints (begs the question of why have separate domains...but whatever.) ---> So I think the protocol can function appropriately with one NSA covering multiple domains *IF* we clearly define the Service Identifier to identify and differentiate policy by service domain. I.e. the Service Identifier specifies which service the request pertains to. Another concern is the resulting service tree... Allowing a single NSA to serve multiple domains does not imply that these domains are disjoint or of different types or that they comprise a single uber-domain. A single NSA may cover a set of NSI service domains [data planes] that may or may not be interconnected at the data plane. We need to make sure that a request received by the "megaNSA" and which is segmented across any of those covered domains, that the megaNSA strictly adheres to NSI protocol and constructs a service tree reflecting each individual NSI domain segment. I.e. if the megaNSA gets a request that it segments to transit multiple of its own covered domains - this request must be treated as if each domain had its own separate NSA. _/The result is an /__/inter-domain multi-segment NSI service tree,/__/and not a single intra-domain segment./_ The resulting service tree will point to the same NSA at different nodes, but the associated children requests will have differing service constraints and are subject to different policies for each child segment. As each domain is thus able to maintain separate policy, these children segments and any subsequent operations upon them must be individually authorized according to the NSI rules for inter-domain primitives and policies at each domain boundary- regardless that a single NSA is performing these function(s). To do otherwise abrogates inter-domain security architecture and will pose a deployment issue and will confuse many aspects of service tree processing. (Note - if the various domains agree to a single covering policy, this is ok, but the megaNSA breaks protocol if NSI transit domains are not authorized appropriately and reflected in the construction of the service tree.) ---> If a "mega NSA" _/rigorously /_follows NSI protocol for inter-domain path segmentation/tree construction/primitive authorization, even and especially when the path transits one or more covered domains, then, IMO, I think it is fine for an NSA to cover multiple domains. THis is essentially saying as long as the advertised NSI domains continue to be treated as separate NSI domains, one NSA may be allowed to act as the protocol entity for service requests. What is the implication of a NSA which covers multiple domains treating transit requests across those domains as a single intra-domain segment? First, one would ask if this is treated as intra-domain, then why differentiate the domains in the first place? If the domains are disjoint without any data plane peering between the covered domains, then all transit segments will necessarilly be single domain segments and the tree will build in conformance with existing NSI practice. If a single segment is created that crosses multiple interconnected covered NSI domains, then the megaNSA is in fact an aggregator - and so strictly speaking, each covered domain should have its own PA-Only NSA...at least logically ... but how do we indicate this if both the aggregator and the leaf node NSA are the same NSA object in the topology? This implies then that a megaNSA can not be an aggregator, that it must be PA Only for each/every domain it covers. (THis is a softer issue - the delineation of Agg from PA-Only may not be really necessary...) THis is an issue that needs some group discussion and resolution - but I don't think is structural or would prevent a megaNSA. ---> So we should discuss the implications further of how a megaNSA is expected to function within the NSI framework. This is not simply a WSDL issue but deals with the protocol and framework semantics. It seems that if we [for v2] allow megaNSA's, but require that multi-domain transit segmentations are reflected in the service tree in the existing manner, then we can go with it. We need to discuss federations and such for v3 and this issue will again come up in that discussion - so in v3 we may be able to ease some aspects further. I want to make sure we clearly understand that a single NSI implementation (e.g. DRAC, or OpenNSA or OSCARs etc) may be coded so that a single implementation instance - say the Nordunet OpenNSA instance or the StarLight OpenNSA instance - could be acting as multiple NSAs. If an implementation can do this is solely an implementation issue. The NSI spec does not prevent this. For example, if OpenNSA was coded to support it, the Nordunet OpenNSA instance could be configured to act as the NorthernLight NSA *and* the SUnet NSA, and possibly many other NSAs as well. Each "NSA" would have its own object in the global Topology database and its own separate NSA identifier...but would end up mapping to a single OpenNSA instance running on a server in Copenhagen. (This would be indicated by the csProviderEndpoint(s) found in the topology database.) This one OpenNSA instance would recognize protocol messages intended for any of the configured NSAs and process them as if they were separate NSI protocol entities. How this is accomplished internally is an implementation issue. But the global NSI framework still sees two separate [logical] NSAs. Likewise, an NSA covering multiple domains would be very similar. Only difference would be that an NSI software implementation and each NSA instance running one of those implementations must be configurable to recognize their respective domains and NSA ids, and treat the NSI protocol requests in the same fashion as would separate NSAs covering each domain. In this way we maintain the semantics and overall scalability of the framework and protocols, while at the same time allowing additional flexibility in some aspects of the implementations and deployments and service domain crafting. Thanks all! See you all soon in Charlottesville! Jerry

Thank you, John

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg