[Nml-wg] Example topology of Automated GOLE

[Jerry Sobieski]

On 2/15/12 8:24 AM, Roman Łapacz wrote:
> W dniu 2012-02-15 14:12, Jerry Sobieski pisze:
>> I am very nervous about this - we deliberatly did *NOT* use "port" in 
>> NSI because of the overloaded connotation. The Service Termination 
>> Point in NSI is *not* a port. ...not in the physical sense.   So we 
>> need to understand what a NML "port" represents.
>
> port in the nml-nsi namespace is not physical. This is an abstraction 
> and represents STP. We could introduce new element nml-nsi:stp but is 
> it really necessary?
>
Ah, ok...the abstraction is good.  (Thanks both Roman and Freek in 
explaining this.)   This was much of my concern.    But lets discuss 
tomorrow in more detail as there are still some other aspects of NML 
"ports" we need to understand/reconcile.

Some further background on NSI notions:

In NSI, the STP is indeed an interface at the edge of a network service 
domain - it identifies uniquely where user data enters or exits a 
service domain.   The STPs associated with a network service define the 
boundary of that NSI service domain.    STPs "mapTo" an internally 
defined tuple that represents the internal specifics associated with 
that Service Termination Point.   For instance, an STP 
"NorthernLight:ams-80" would mapTo <switch, mx80-CPH>, <blade, 0>, 
<port, 2>, <vlan, 1780>.   This entire tuple is the internal topological 
information represented by that STP.   (Note- the internal tuple 
specification is a local network internal issue relevant to the specific 
infrastructure or software being used.)

Inter-domain peering between two networks is expressed via a Service 
Demarcation Point "SDP".   An SDP pairs two corresponding STPs - one in 
each network.   SDPs indicate adjacencies between NSI network services, 
and differentiate the paths that exist between two networks (or that 
originate or terminate at a network.)   SDPs are *not* physical links 
(circuits, fibers, etc) between networks - SDPs are /relations/ that 
identify a common topological interface between two domains - i.e. the 
two STPs that are part of an SDP represent the *same* topological 
location - albeit from different name spaces and with different internal 
mapsTo info.  For example, an SDP might look like this: < 
NorthernLight:ams-80, NetherLight:cph-80 >   In the OWL topology, this 
SDP would be expressed as NorthernLight:ams-80 "connectsTo" 
NetherLight:cph-80.   Thus it is found in an NorthernLight:ams-80 STP 
object.  A similar SDP would be defined in the NetherLight domain.   
These STP names are just strings, but they "mapTo" the internal physical 
details of the terminus, and they "connectTo" the corresponding STP in 
another network.   (Note:  NSI is developing an "enumeration" construct 
that will allow a compact SDP representation of large groups of peering 
STPs...e.g. where two networks terminate a physical link that carries 
large number of VLAN IDs. perhaps we can discuss this too at the NML 
call thursday.?)

If an STP does not have a corresponding STP in another NSI network - for 
example where the remote side is an end host that does not participate 
in NSI - there is just no "connectsTo" relation, i.e no SDP.   In our 
AutoGOLE topology, these are how we represent the perfSonar nodes.

Note that these STPs and SDPs are expressly technology agnostic.  The 
physical details are held internally to each network NSA in the "mapsTo" 
relation and the internal topology DB.    I think what we nee to now do 
with NML and NSI is that we want to express these NSI topological 
constructs and the NML constructs using a common form (the NML 
representation is what we currently believe to be the right approach), 
without breaking the semantics that NSI requires to remain secure and 
autonomous.  At the same time, we want to enable a network announce much 
more topology if they wish - We'd like both of these aspects to be a 
well integrated common representational model that syntactically 
functions smoothly together.  Thus a NSA would announce the NSI service 
domain (presumably using an NML representation), and if they wish, they 
can include more details of internal structure using further - perhaps 
more technology specific -  NML constructs.   Ideally, all of this 
announcement would be a common structure syntactically, and hopefully 
semantically as well.   This would simplify implementations - 
partcularly in furture virtual worlds...   But we *must* maintain the 
NSI topological model of STPs and SDPs and Networks and NSAs etc (though 
we might elect to rename them within the NML context)  So I think our 
task is to figure out how to dovetail these NSI semantics and the NML 
semantics so that processes can traverse between the two smoothly and 
hopefully imperceptibly.

I look forward to the discussion tomorrow!
Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120215/06cfd664/attachment-0001.html>