[Nsi-wg] Question about NSA identifier

[Jerry Sobieski]

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 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/20130310/271dd128/attachment-0001.html>