Roman Łapacz wrote:

...

1. The resulting topology file has three layers: - NML topology - dtox NSNetwork - dtox NSA I really like the clear distinction between the data plane (NML) and control plane (dtox/NSI). However, I wonder if we should move this to two layers, perhaps merging dtox:NSNetwork and nml:topology.

I'm not sure of this distinction if nml:bidirectionalport is STP (I have a problem with this: dtox:hasSTP in dtox:NSNetwork points at nml:bidirectionalport; moving from dtox to nml domain does not look right to me in this case).

I agree that this looks strange, and should be fixed. But before we can fix it, we should decide if the above three concepts are truly distinct and should remain as-is, or perhaps should be merged somehow. My hope is that we can merge NML:topology with dtox:NSNetwork, but for that to decide, at least I need a better understanding what a NSNetwork represents. If I'm correct, a NSNetwork represents the abstracted transport capability of some data plane (typically under control by a given NSA). I think that NML:Topology is able to represent that. However, it should be said that a NML:Topology can also represent a non-abstracted data plane. In my mind, that's not an issue, but I like to hear input from others.

All elements in the example belong to NSI abstraction (links are SDPs, ports STPs; except VCard part). To me distinction is between NSI topology (represented by STP, SDP, NSNetwork, NSA) and internal domain topology which is hidden under mapTo relation.

What do you mean with a mapTo relation? A mapping from an abstracted to an actual topology? One of the discussions we should have tomorrow is if NML is capable of describing abstracted topologies or not. I personally think it can; I also think it should: NML about exchanging topology data, and there are substantial benefits in only exchanging abstracted topologies over exchanging the actual topology implementation. Regards, Freek

Jerry Sobieski wrote:

Exactly. I view a topology as [initially] an abstract domain that comprises a comprehensive but finite switching function between points at its boundary. We can map those points to co-registered points in another topology that expresses some other aspects - perhaps geolocation, or internal connectivity, or policy-based capabilities, or a combination thereof. A perfect example would be a simple abstract topology announced publicly that mapsTo a much more detailed internal physical topology that the local network wishes to manage itself. The NSA is the agent that speaks to other NSAs inter-domain (at whatever domain level we are at) and translates as necessary to local agents that do the dirty work internally.

It is important IMO that NML be recursive and abstract in this manner as well as able to capture physical hdw engineering trappings. It looks like it is very close to being able to do this.

NML is partly capable of defining recursive topologies. * It does not dictate till what level a topology should be abstracted, and is designed to make this irrelevant (I recommend to give figure 7 of ITU-T G.800 a good stare: "Example of recursive partitioning") * NML does not yet define how to tie topologies of different abstraction together, other than that all ports at the edge of a the more abstract topology will also be ports at the edge of the less abstract topology, and should (in my view) get the same identifier. A 'mapTo' relation may be a possibility. We played with the concept of virtualisation during OGF 23 in Barcelona (see https://forge.ogf.org/sf/go/doc15482), which does this for nodes (both partitioning a physical node into smaller logical nodes as well as grouping nodes into something that we now call a "topology"). The discussion was resolved by making all concepts: both node and topology abstract. Thinking about it, if nodes in NML are also abstract, perhaps both concepts (topology and node) are the same, only on different levels of abstraction. I like to hear from nml-wg participants: - if they think that NML should be capable of defining a topology at different layers of abstraction - how these different descriptions should be tied together. Should we define a relation between them? For the NSI participants I'm interested in hearing if you think that only NML should define different levels of abstraction, or if you also expect NSNetwork to have different levels of abstraction, and if an NSA have different levels of abstraction. (I presume both have, given that NSA supports a tree-like request structure, where a top-NSA can delegate requests for path provisioning to other NSA). Regards, Freek

Roman Łapacz wrote:

...

I like to hear from nml-wg participants: - if they think that NML should be capable of defining a topology at different layers of abstraction

Yes but I would make this more general and say - just different layers. They could be abstractions or tech layers (I'm thinking that layers may be also a good solution to control publishing information by configuring somehow that only some layers can be distributed, others not; a single abstraction could be split into more layers because of some reasons; it would be up to the implementation)

Network layers indeed abstract the underlying complexity, but I presume that there is also a need to abstract a single-layer network. Hence, I propose to treat these two as different tasks for now (if we can integrate them later in the same concept, that would be great). I like to spend some time before next OGF to look into VLAN and layer abstraction; if someone else would like to take up the topology abstraction (if only single layer abstraction), that would be awesome.

...

- how these different descriptions should be tied together. Should we define a relation between them?

I think so. The work on examples will help to progress.

Agreed. I will dot this down as a work item. That can be either one of Jerry's suggested examples, or just some artificial example. Freek

W dniu 2012-02-22 10:52, Freek Dijkstra pisze:

...

Hi all,

I've tried to NML-ify the AutoGOLE topology. I did in RDF/XML because that is probably readable by both OWL and XML folks.

Below are the steps I took in detail, along with intermediate results (which may help in understanding the differences).

The main changes are: - made ports and link unidirectional, per NML specs. - use explicit link object to describe the SDP (NML has no connectedTo concept) - change the urn:ogf:network identifiers to a valid syntax, the ones currently in AutoGOLE use are not valid according to proposed standard nor previous use in either GLIF or perfSONAR community.

The file AutoGOLE-Topo-2012-02-22.rdf gives the result so far.

Notes:

1. The resulting topology file has three layers: - NML topology - dtox NSNetwork - dtox NSA I really like the clear distinction between the data plane (NML) and control plane (dtox/NSI). However, I wonder if we should move this to two layers, perhaps merging dtox:NSNetwork and nml:topology.

I'm not sure of this distinction if nml:bidirectionalport is STP (I have a problem with this: dtox:hasSTP in dtox:NSNetwork points at nml:bidirectionalport; moving from dtox to nml domain does not look right to me in this case). All elements in the example belong to NSI abstraction (links are SDPs, ports STPs; except VCard part). To me distinction is between NSI topology (represented by STP, SDP, NSNetwork, NSA) and internal domain topology which is hidden under mapTo relation. Yes. But first things first. This was/is a good exercise as we see

Hi Roman e al- In general, I think the NMLification of the NSI topology is quite good. I do not mind the unidirectional aspects myself as I believe these are necessary for NSI (ultimately) anyway. And as presented in Freek's example seem to be perfectly consistent with the current NSI model. (FYI- I have asked that unidirectional connections be a topic for NSI V2.0. The vcard issue is not on the critical path for NSI, so I am not too worried about that. Freek's suggestions seem fine to me. There is some concern about using the "port" term itself as it is just so overloaded that it creates confusion. But that said, I think the logical nature of the NML "port" construct as it represents STPs is consistent with NSI semantics. I think the bidirectional nature of NSI STPs will relax soon as well to be unidirectional STPs. STPs identify specific locations where a connection can be terminated (or originated). And really, a unidirectional flow of data is the atomic element of a "connection" and is in fact how actual switching fabrics are actually constructed, so this fits best (IMO). Binding arbitrary switch fabric input and output interfaces into a single "transmit/receive Port" on a box is purely an engineering practice (indeed - many optical equipment explicitly separate the transmit and receive paths to be configured independently by the transport engineers..) Bi-directional Connections are [should be IMO] a compositional service feature. (see comments further down.) There is no innate requirement that a "NSI Connection" be bi-directional. Nor is it required that the forward and reverse components be congruent or symmetric. Thus, I believe the basic coin of the realm should be a unidirectional topological construct as well. I understand why Freek translated STPs to be the bidirectional ports - this is how the current NSI topology uses them. But I would concur that what we really want is a unidirectional concept of a domain edge interface (STP or port) that identifies uniquely the termini for service instances with an "orientation" - in or out relative to the domain. some other comments below... On 2/22/12 9:19 AM, Roman Łapacz wrote: that the NSI topology can indeed be represented semantically in the NML format. This is a great first step. Now, as you suggest, there is this issue of "resolution" - the ability to define internal topology in finer resolution - still as NSI concepts or as NRM technology specific constructs. IMO, we should be able to recursively define more internal detailed NSI constructs until the domain is ready to map the NSI constructs to the tuple that the internal NRM will recognize. It is not strictly required that the "mapsTo" relation point to physical or technology specific information. The mapsTo could map to a more detailed NSI topology internal to a domain (think of a "federation" NSI domains). I do believe at some level the mapsTo should reference a topological object or tuple that is physical or a string that the local NRM can interpret to indicate where the NSI Connection should be terminated. Topo X1. Perhaps a next exercise would be to stipulate a simple exemplar network with a single physical switch. Lets take NetherLight domain as example. The expressed NSI/NML Topology should be such that we can ascribe a simple any-to-any switching function to NetherLight...from any ingress STP to any egress STP. Topo X2a & X2b. The next topology would be to enhance TopoX1 with the specification of an ethernet switch as Netherlight switching core. For X2a, assume the switch can do VLAN re-write and so the any-to-any switching capability is maintained. For X2b, assume the ethernet switch is a crufty old conventional switch that cannot swap VLAN IDs and so the any-to-any switching function is reduced to ingress port/STP(i) can switch to output port/STP(j) iff i=j. TopoX3. In this topo, provide an example we switch to NorthernLight. Show how NorthernLight could present a single NSI domain but has NSI "sub-domains" in NYC and CPH. (This is likely a real scenario...) Assume the switching functions are any-to-any for all ports/STPs. Consider the naming scope carefully.

btw. I'm still thinking that we don't need nml:bidirectionalport in NML :) We could use port with "bidirectional" relation.

I agree. What is a "bidirectional port"? It is really two ports bound together for purposes of ... what? Indeed - Freek bound NSI STPs together as bidirectional ports...you didn't have any information that said these ports were even on the same switch or of the same technology! (:-) Be careful about what your assumptions are. NSI STPs deliberately hide technology specifics - don't be fooled by the STP names:-) There were no MapsTo relations that pointed to physical descriptions, so you all made some assumptions that were not necessarily valid. A true "bidirectional port" would be a port on which data is sent in both directions simultaneously...which is in fact possible in the photonic realm. So perhaps the "bidirectional port" grouping needs some further consideration? Also... simply calling an in and out port a "bidirectional port" does not prevent those unidirectional components from linking to completely different far ends... Jerry

Roman

...

2. The dtox:hasSTP relation now points to a nml:bidirectionalport. NML defines a similar "hasPort" relation between a nml:Topology and nml:Port. (and there is some discussion to differentiate between hasOutboundPort and hasInboundPort). If dtox:NSNetwork and nml:topology are merged, I recommend to use these relations. 3. Yet unclear how exactly to tie Ethernet specifics to the examples, it seems prudent to use labels and the subnetwork concept as discussed in the NML-WG in Lyon (see subversion: https://forge.ogf.org/svn/repos/nml-examples/20110922/other_examples/configu...; you need a gridforge login. Drop me a line if you can't access it.)

Regards, Freek Dijkstra

List of steps I took:

Source: AutoGOLE-Topo-2012-01-25.owl

Removed owl:NamedIndividual Removed schema definitions (owl:Ontology, owl:AnnotationProperty, etc.) Removed Position comments (used by auto-gole.appspot.com) Removed unnecessary comments

Result: AutoGOLE-Topo-2012-01-25.rdf

Changed dtox:lat, dtox:long and dtox:Location to geo84:lat, geo84:long and geo84:SpatialThing Corrected label of Netherlight location from Copenhagen to Amsterdam (geo84 was OK)

Changed dtox:STP to nml:bidirectionalport Grouped ports of a single network in a nml:topology Commented dtox:connectedTo, since this is not valid NML Added rdfs:label to all NSA and all locations Changed admin contact from string to vCard

Result: AutoGOLE-Topo-2012-02-20.rdf

Change urn:ogf:network identifiers to valid syntax (urn:ogf:network:<FQDN>:<date>:<opaque>) Make all bidirectional ports unidirectional Explicitly defined NML links, with sources and sinks

Result: AutoGOLE-Topo-2012-02-22.rdf

Possible future direction:

Merge NML:topology with dtox:NSNetwork Remove the dtox:managedBy property, as there is already an inverse relation dtox:managing to find the correct dtox:NSA Added switch matrix to each NML topology Define switching capabilities for each topology. use nml:hasPort instead of dtox:hasSTP

Result: (the-AutoGOLE-future-is-yet-to-be-written.rdf)

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg