[Nml-wg] Example topology of Automated GOLE

[Roman Łapacz]

W dniu 2012-02-15 15:56, Jerry Sobieski pisze:
>
> 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.?)

I was thinking about this grouping. To better understand the problem 
I've created an example presenting simple solution. I wasn't involved in 
the NSI discussion on this so that piece of xml may be far away from 
that what you want. But your comments let me see your ideas of solving this.

Cheers,
Roman


>
> 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/20120216/617a2a98/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vlans_in_one_stp_example_v1.xml
Type: text/xml
Size: 2647 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120216/617a2a98/attachment-0001.xml>