[Nsi-wg] Topology Abstract sent to Terena

[Jerry Sobieski]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20111210/3c814de8/attachment-0001.html