January 2010 - nml-wg - lists.ogf.org

Informational Doc on translating NM-WG - NML
by Jeroen van der Ham 19 Apr '10

19 Apr '10

Hello, As some of you know, I've worked several weeks at Internet2 last year. While I was there, we worked on translating between the format the DICE IDC uses and NDL. I've written a report on this, detailling the translation and highlighting some issues that we encountered while implementing the translation. The document can be found at:http://staff.science.uva.nl/~vdham/research/publications/DCN-NDL-Translation.pdf I would like to submit this to the OGF as an informational document. I can do this personally, or from the NML WG. I would prefer the latter, does anyone disagree? Jeroen.

3 5

Definitions of "Adaptation", "AdaptationType" and "AdaptationService"
by Freek Dijkstra 22 Feb '10

22 Feb '10

Hello, As agreed on the last OGF, Jeroen and I have worked on the definitions of Adaptation, Adaptation Function and Adaptation Services. We propose four definitions to describe adaptation between network layers: Definitions: * Layer: A collection of Ports with common Characteristic Information (Characteristic Information is defined in ITU-T G800; we envision sublayers to be a separate layer too, but this is really up to technology-specific extensions). * AdaptationType: Abstract type describing the technology of embedding the data of one layer into the data of another layer. * AdaptationService: Adaptation capability in a topology or node. * Adaptation: Actual data transport function where data of one port is embedded in the data of another port. This can be a configured AdaptationService, or a static component. Properties: * AdaptationType is between two Layers (the client and server Layer) * AdaptationService is between two PortGroups (This is a new concept, see below) * Adaptation is between two Ports (the client and server Port) Context: * Adaptation and AdaptationService are part of a Topology or Node. * Adaptation can not be part of a cross-connect in a SwitchMatrix. * AdaptationService can not be part of a SwitchMatrixService. PortGroup concept: * PortGroup: a collection of zero or more Ports in a Node or a Topology. PortGroups can be used to describe between which Ports an Adaptation can be created from an AdapatationService, or similarly between which Ports a cross-connect can be made in a SwitchMatrix. Unidirectional: The above definitions for AdaptationService and Adaptation are for bidirectional adaptations (adaptation one direction and de-adaptation the other direction). We propose the following terms for unidirectional Adaptation and AdaptationService: * AdaptationSource: Embedding of data from a client port into a server port. ("adaptation") * AdaptationSink: Extraction of data out of a server port into a client port. ("de-adaptation") * AdaptationSourceService: AdaptationSource capability in a topology or node. * AdaptationSinkService: AdaptationSink capability in a topology or node. Regards, Freek and Jeroen

3 5

Soliciting Public Comments on "Network topology descriptions in hybrid networks"
by Freek Dijkstra 15 Feb '10

15 Feb '10

All, Our first deliverable, "Network topology descriptions in hybrid networks", is now soliciting public comments. If you have any comments, or know anyone who like to comment on this document, please do so at http://www.ogf.org/gf/docs/comment.php?id=327. The official public comment period ends Feb 15, 2010. My apologies to Paola Grosso for the very long delay (over a year) between the final editing and this public comments. This was mostly due to negligence and unfamiliarity of procedures on my part. With kind regards, Freek Dijkstra

5 12

Definitions of Topology, Domain and Network
by Jeroen van der Ham 01 Feb '10

01 Feb '10

Hello, As agreed at the last OGF, Inder and I have worked on the definitions of Network, Topology and Domain. - Topology: A connected graph of Network Elements The intended usage of this is to describe the thing that a network provider advertises to others as his network topology that is available for use. - Domain: An unordered collection of Network Elements managed under the same shared policy umbrella. This describes who or what is responsible for the Network Elements. - Network: no definition We had a discussion about the meaning of this term and in the end we had to conclude that is not possible to provide a workable definition for the term 'Network'. The term Network has become so widely used for so many diverse meanings that it is impossible to create a strict definition that everyone can agree on, while still expressing something useful. Inder & Jeroen.

6 13

Re: [Nml-wg] Definitions of "Adaptation", "AdaptationType" and "AdaptationService"
by Jeroen van der Ham 29 Jan '10

29 Jan '10

On 28/01/2010 21:16, John Vollbrecht wrote: > Thanks Jeroen - > > I include Freek -- perhaps this should go the the list? > > additional questions below -- > > On Jan 28, 2010, at 4:58 AM, Jeroen van der Ham wrote: > >> On 27/01/2010 18:52, John Vollbrecht wrote: >>>> * AdaptationType: Abstract type describing the technology of embedding >>>> the data of one layer into the data of another layer. >>>> * AdaptationService: Adaptation capability in a topology or node. >> > >>> I would think this could happen in a port, or at least be specific to >>> a port. Is that possible? >> >> The AdaptationService is indeed specific to a port, as we define >> later. However, often in a Node there are a group of ports with the >> same AdaptationService, i.e. the capability of adapting one layer into >> another. >> We feel that without loss of generality you can state that an >> AdaptationService exists between a group of (logical) ports, and >> another group of (logical) ports, instead of specifying this for each >> of the ports individually. >> > this seems fine -- I tend to think that a generic connection at some > level (e.g. ethernet) might be carried internally in a provider as > VLAN/Ethernet and perhaps delivered as ethernet/ MPLS for example. In > that case the generic connection is adapted to VLAN/ MPLS, then to > ethernet/MPLS. So adaptation is at a port, not between them. The idea is that the adaptation takes place in a physical port, but we model it using two logical ports. > >>> When a link with multiple labeled sub-links connects to a port with >>> multiple labeled subports on a node -- >>> What is the way that labeled links are concatenated to labeled ports >>> -- is that cross connect? If not, what is it? >> >> Labeled links are directly associated with labeled (logical) ports. >> >> Multiplexing and Demultiplexing could then be necessary to describe >> this properly, cross-connect and all. However, we haven't defined that >> yet. >> > so there is a port on a node. but if a topology edge is the end of a > link, what is that called? do the ends of links have names? I have > started thinking they should have names (like ITU, they have ports > perhaps), and where two ports connect is a point. > > I understand this is not defined yet - and of course this is the basic > thing that a lot so NSI is concerned with. Which is ok -- just need to > be clear. I am not sure yet whether Link-ends will have names. We currently have Link objects, describing unidirectional links, with a source and a sink relation, so names for the ends may not be necessary. Jeroen.

1 0

Scope op NML
by Freek Dijkstra 21 Jan '10

21 Jan '10

Hi all, I'm cross-posting to NMC. Please reply to NML. The NML is currently defining a few subtopics for network description: domain/topology; adaptation/layer; and identifiers. What is not covered yet is the description of cross connects. My question to the group: to what extend do we want to define cross connect details in NML as well? If we're going to do that, we will bump into problems on labels (VLAN, timeslot, wavelength, ...), multi-cast, broadcast, backup/protected cross-connects, etc. I these details are required. Now we can either dive into this topic as well or leave it up to other standards. In particular, I was wondering if it would be useful to look at NETMOD [1], and have the following scopes: * NETMOD: focus on configuration in a device. * NML: focus on topology between devices and domains. * NM/NMC: focus on monitoring information. So link status, packet loss, bit error rate, etc. are in scope of NM; cross connects are in scope of NETMOD; link description is in scope of NML. The advantage of relying on other work is that we avoid duplicate work, and NML is more likely to be picked up elsewhere. The disadvantage is that it requires more work to cooperate. I suspect problems for topics which overlap. For example, identifiers in NETMOD and NML are different; path description (needed for NSI) relies on both link and cross connect descriptions; I have some doubt that adaptations and/or capabilities are clearly described in NETMOD, so we should either push that group or add that in NML after all. So what's your opinion? I like to speed up the NML, and wondered if we can gain speed by a bit more focus. Regards, Freek Dijkstra (with my co-chair hat off) [1] FYI: NETCONF is a replacement protocol for SNMP. While NETCONF describes the protocol, NETMOD describes the data model. NETMOD is still in development in the IETF.

2 1