[Nsi-wg] Topology Abstract sent to Terena

[Jeroen van der Ham]

TL;DR version below
> *First*, NSI is technology agnostic. 
> *Second* Our CS Reservation semantic is a simple Point-to-Point connection request.

> *Third*, the issue of *representation* of large sets of STPs is not difficult, and it is not a scaling issue.
> Further, we still need to indicate SDP peerings with this enumerated STP object.
> *Fourth*, Jeroen properly points out that PathFinding (PF) and Topology are intimately related.


> <tirade>
> With respect to VLAN swapping...   Inability to swap VLANs is essentially saying your NSI network cannot cross connect - ever - certain STPs.   If you cannot *ever* cross connect certain STPs, there is no service!      I might as well advertise STPs that point to bananas -  I will never be able crossconnect them either but who cares?  Advertising capabilities that can never be met is a Bad Thing. It injects false and misleading topological information - it could be considered malicious(!)



On 10 Dec 2011, at 18:32, Jerry Sobieski wrote:

> Hi all-
> 
> I am responding to some of the issues Jeroen states in his abstract, but please take these as ciritique of the issues - not JvdH:-)     And then a brief tirade at the end:-)
> 
> *First*, NSI is technology agnostic.   This is NSI's real value and uniqueness.    We need to start our thinking from this first principle.    NSI is not a VLAN technology and does not owe VLANs any allegiance.    When anyone uses a particular technology as a justification for NSI requirements, we are in fact instituting those technology specifics into NSI - the discussion in Jeroens abstract breaks that agnostic.  We should *always* start with the minimal abstract notions of a "Connection" and "Network" and "Endpoints" and use those notions to define NSI --- And let the hardware technologies map their technology to the NSI model...not the other way around.    NSI has to work across any/many technologies - some with vlans, or labels, many without, some that can stack labels arbitrarilly deep, or anything else - and in an environment that considers autonomy and security as prime requirements as well.   We can do this in the abstract and technology agnostic - we do not need to revert back to conventional thinking and models of protocols mapped to specific hardware technologies.
> 
> *Second*, and with due credit to Jeroen - his fascination with labels IMO actually points out something really more important:  Our CS Reservation semantic is a simple Point-to-Point connection request.  A single STP as an origination point, and a single STP as a destination point.  This semantic works - and works quite well largely due to its simplicity.  But it can be slow if we need to implement it across oceanic latencies without much topological state information.
> 
> What Jeroen is fixated on is actually described as "/Point-to-Any-Point/" semantics in the literature.  Point-to-any-point says "I want a connection from point A to any point in the set {X, Y, or Z}."  If the set of endpoints happens to include 4000 STPs, the exhaustive search issue becomes simpler - STP selection (i.e. vlanid) can be done locally where the local NSA has visibility to the state information and is orders of magnitude faster access.  Further, this approach (P2AP) maintains the strict abstractions of the existing STP and NSI Topology model.   So I think we need to seriously consider the P2AP semantic for CS in v2.0.   And might as well consider if P2MP is needed at this time as well.
> 
> *Third*, the issue of *representation* of large sets of STPs is not difficult, and it is not a scaling issue.  We can have a zillion STPs at the edge of a NSI Network and we can represent those zillion STPs with a single topological STP object.  We can call it an _/"enumerated" STP/_ object or something similar, but it essentially allows us to describe those zillion abstract STPs in a very concise and compact manner.   I would also point out that this enumerated STP object is implemented almost exactly the same as Jeroen's proposal for representing labels, e.g. with a ranging attribute - the key difference being that it retains the STP as the endpoint - a very important abstraction we should not change.
> 
> This is important to reiterate: this enumerated STP may look and feel like VLAN IDs or even more generalized labels, _/but they are *not *labels/_ - these are simply Service Termination Points, objects that *reference* topological locations, described in a concise manner.   These are not numeric labels, or vlanids. _/They are treated exactly like STPs are now/._  Visibility to the physical attributes of an STP is [still] at the discretion and control of the network that owns that STP.  A network may in fact map these enumerated STPs to VLANs internally in the network.  Thats fine and a local decision.  And this does not preclude some external agent from linking to that internal information in the topology to determine if these are VLANIDs (for instance) or something else.   But it does require the local network conciously advertising more internal information than just the boundary STPs.   And lack of advertising such physical information will not prevent PF from working effectively (given a P2AP semantic.)
> 
> Further, we still need to indicate SDP peerings with this enumerated STP object.  And similarly the two peering networks will need to coordinate on these inter-domain peerings before setting them up or advertising them, and just like other border protocols, both networks need to agree on these edge point configurations.   So the semantics for the "corresponding" SDP is simply extending the same semantics of the classic singleton SDP.   For example:    If enumSTP "A:M" is defined as "aa", ..., "az", and enumSTP "B:foo" from 1,2,3,...,26, then the corresponding SDPs would be (A:Maa,B:foo1), (A:Mab,B:foo2), (A:Mac,B:foo3),..., (A:Maz, B:foo26).   We can discuss the specifics of the compact syntax, but the key points take away is that a) we define the "enumerated" STP object  in a concise form, and b) the define a "corresponding" SDP semantic likewise. These enumerated STPs do not affect the rest of the abstract NSI connection service model.     I think this, combined with P2AP, is a good compromise to the STP/label discussion in which both aspects win - we can represent thousands of connection endpoints easily and can map easily where labels are present in the physical, representation is compact, and we maintain the strict STP abstraction; And the P2AP it represents a big step forward on the exhaustive search issue.   Win win win, and win.
> 
> *Fourth*, Jeroen properly points out that PathFinding (PF) and Topology are intimately related.  We can not address the topology issues without considering PF.   So IMO our first step here is to get clarity about what we mean by "Path", what we mean by "Path Finding", what are the subtle differences between "Path Selection", "Path Allocation", "Path Reservation", etc.   These are very important nuances IMO, and we should have clarity on these as we pursue the Topo/PF issues.   And we need to consider these in a *purely* abstract context.
> 
> 
> Finally, with a brief foray into hardware specifics...
> 
> <tirade>
> With respect to VLAN swapping...   Inability to swap VLANs is essentially saying your NSI network cannot cross connect - ever - certain STPs.   If you cannot *ever* cross connect certain STPs, there is no service!      I might as well advertise STPs that point to bananas -  I will never be able crossconnect them either but who cares?  Advertising capabilities that can never be met is a Bad Thing. It injects false and misleading topological information - it could be considered malicious(!)
> 
> If STPs cannot be cross connected, then they are not part of the same _/network/_ - that is what the "network" part of /network service/ means.   ITS NOT A NETWORK SERVICE IF IT CAN NOT EVER ESTABLISH A NETWORK CONNECTION BETWEEN ITS ENDPOINTS !
> 
> These capabilities are easily represented _/properly/_ within the existing NSI topology model.  Its more verbose than some folks expected, but that is simple esthetics.   Its _/not/_ a flaw of the model, its a lazy network administrator who does not want to truthfully advertise several distinct network services.   And because they are lazy, they cause agents in other networks enormous delays and excess wasted computational cycles, and wasted bandwidth to discover that the service they advertised is fake.  By dissing the notion of vlan planes and insisting that all VLANs needed to be part of the same single NSI network, you hide important topology information...And then everyone whines about not being able to see it.   DUH!
> 
> For instance, if in the SC topology we defined individual VLAN planes for each non-swapping network, the pathfinders would have worked perfectly.   But no one wanted to do this "ooooh, its too many lines of data!...its not what I expected...oooh..oooh...too much xml"...and so they got all wrapped around the axle whining about how hard this was.
> BS.  Its simple.
> 
> If there is a mechanism to accomplish something, and you don't want to use it, its not a flaw in the system.   If we do not like the verbosity of the current representation, i.e. if we don't think we want to replicate 20 vlan planes, there are ways to make the representation more compact and concise.   We can devise a more sophisticated means of describing the data - we do not need to change the abstractions.
> 
> But don't dis it because it takes more XML and then claim it doesn't work.   IT WORKS JUST FINE!
> 
> There are many ways to be more concise in the representation (i.e. the OWL/RDF), but they get syntactically more involved.   We need to recognize that this is part of the problem that Topology and pathfinding has had for decades:  The more information and generality you wish to provide in the topology in order to make better pathfinders, the more complex the topology representation becomes.   And the harder it becomes to keep it current.   The generalized representation of these network capabilities is non-trivial and can and will generate large data sets.   Get over it.   You are not personnally going to process these data sets for a large network.  And you are not likely to build them by hand either - tools/NSAs/NRMs will spit out the topology files and import them back in.   All the data representation is used for is to exchange the information.   You don't need to be able to read it personally.
> 
> </tirade>
> 
> OK...breathe in, breathe out,...go to my happy place,....I am better now..
> 
> :-)
> Thanks!
> Jerry