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