March 2012 - nml-wg - lists.ogf.org

recursive topologies
by Freek Dijkstra 05 Mar '12

05 Mar '12

Hi all, Last Friday Jerry and I had a short conversation. Jerry's idea is to define recursive topologies, as he described in his slides to the list. He convinced me that this is a great concept, as it allows for simple topology abstraction. While I wholeheartedly support the idea, I like to describe the concept before giving a concrete proposal for changing the NML schema. 1. Connecting the (sub)topologies 2. Hierarchical identifiers 3. Updates and Versioning Feedback is highly appreciated. 1. Connecting the (sub)topologies We certainly need a relationship between two topologies, describing that one topology contains one or more subtopologies. In my view, this is a one to many relation. In addition, we need to describe how the ingress and egress ports of a subtopology connect to the larger topology. As a first step, this means that a topology can have (externally published) ingress and egress ports, much like a Node. If we don't specifically allow this already, we should. Secondly, we need to define how these ingress and egress ports are connected to the rest of the internal topology. I see three options: (a) ensure that these external published ports have the same identifier as a node (or subtopology) within the topology. This is a rigid 'relation'. (b) define a NML:Link to relate them to other network elements. That would be a link on the "inside" of Port. We already have something similar since we describe cross-connects as NML:Links too. It is verbose (again) and I like to see an implementation to make sure software doesn't mix up the "external" and "internal" link of a Port, but it probably just works. (c) define some 'alias' to map the externally published port to a port in the internal network. This is what Jerry suggested, and has the benefit that is less verbose than the previous option, but does allow networks to change their internal topology without changing the Port identifiers published to the rest of the world. The drawback is that we need to defined yet another relation (from port to port). I have no strong preference. If asked, I would pick option (c). 2. Hierarchical identifiers Jerry not only proposed to define hierarchical topologies, but also hierarchical identifiers. E.g. A port X in subtopology C, which is part of the topology of domain B, which is part of the global topology A should be name C.B.A.X. The big advantage is that it a hierarchical namespace make routing a lot easier and scalable -- just by looking at the name, you know where a port is located. The downside is that it make the hierarchy very rigid. For example, if domain B and domain E decide to create a federation, F, the name would change to C.F.B.A.X. Name changes are bad, in my opinion. Also, it is different from what we already agreed upon. I think hierarchical topologies are good, but hierarchical names are not. I rather see some split between naming and routing. Suggestion are welcome. Perhaps we can demand in path finding protocol that a request should be accompanied by a topology hierarchy, to aid path finding, even though it is unnecessary to identify the port (since that is already unique). 3. Updates and Versioning One of Jerry's arguments for hierarchical topologies is the ability to change the sctructure of a subtopology, without affecting the higher (more abstracted) topology. Since the higher topology is not changes, it would not be needed to send updates for the larger topology to peer networks. That would make things more scalable. Regards, Freek

4 5

Versioning
by Freek Dijkstra 05 Mar '12

05 Mar '12

Each NML object has a "Lifetime" attribute which specifies -well- when an NML object is valid. I see two problem with that, namely that it is often not known in advance when the lifetime of an object terminate, and that describing the lifetime of each object is not very efficient. Jerry's idea about versioning and topology updates made me reconsider the current proposal. Jerry's idea is to simply change a whole topology description (or subtopology description) when it is changed. This seems more useful than to change the lifetime of each individual network object. Hence I propose to get rid of the Lifetime object and replace it with a version attribute, which is a timestamp. The version attribute should be used for topologies (or for any network object if the WG prefers). The meaning of the version attribute is that the topology with the latest timestamp (before now -- see below) describes the current active topology. This is much like the version string in DNS SOA records. A topology can be end-of-life'd by describing the topology without any ingress or egress Ports, and giving it a new timestamp. One of the great features of the "Lifetime" attribute is that it would allow description of future topologies, and hence advance reservations. This is why the "before now" in the above description comes in. It would allow one to describe a topology with a timestamp that lies in the future. The meaning would be that that topology would not be valid until that time is reached, hence allowing the description of future topologies as well. This seems much easier than the current proposal, and just as flexible. Can we decide to replace Lifetime with version? Regards, Freek

2 1

security considerations
by Jeroen van der Ham 02 Mar '12

02 Mar '12

Hi all, I'm proposing the following security considerations: There are important security concerns associated with the generation and distribution of network topology information. For example, ISPs frequently consider network topologies to be proprietary. We do not address these concerns in this document, but implementers are encouraged to consider the security implications of generating and distributing network topology information. I'd like to commit it to the repository, but svn repos are down at the moment :( Jeroen.

3 3

NSI topology proposal
by Jerry Sobieski 01 Mar '12

01 Mar '12

Hi guys- Here are some slides presenting a general concept of how I think we can a) provide a more comprehensive NSI topology model that provides more internal structure, and b) gracefully dovetails with existing NML dataplane constructs. Look at the constructs and the concept, we can adjust the syntax appropriately. I am at the OnVector workshop and present shortly after the call, so I may not be able to stay on today's call very long. Thanks! Jerry

2 2

Notes for March 1 call
by Jeroen van der Ham 01 Mar '12

01 Mar '12

Notes for NML call 23 February ============================== Attendance: Aaron Brown (I2), Freek Dijkstra (SARA), Jeroen van der Ham (UvA), Jerry Sobieski (Nordunet) Excused: Jason Zurawski, Chin Guok 1. Action items from previous call: ---------------------------------- * Jeroen to go through document and set up action points * Jeroen to check the Security considerations of NM * Freek to write use case on bidirectional and unidirectional links: single fiber with two wavelengths in different directions. * Jerry to write use case on bidirectional and unidirectional links * Jerry to write usecase on NORDUnet being a geographical segregated network (NY and CPH), with possible restrictions between the two locations/networks * Jerry to write this down federated and sub-NSA as a use case. * Freek and Jerry look at the exact definition of NML:Topology and NSI Network, and see if they can sync their definition 2. Current schema document status --------------------------------- Jeroen has gone through the document and distilled some new action points: - Introduction needs some updating and extension - Schema figure must be moved to front and checked against current definitions (Jeroen) - "at layer" relation must be examined, there currently is no Layer object. (Freek) - Identifiers section needs to be fixed, and needs its own introduction (Jeroen) - Examples is work in progress - Security considerations: The ones from NM are pretty short and basically say that descriptions may be sensitive. Implementers should be careful with distribution. We don't want to add much more than that. 3. Other action Items --------------------- - Freek and Jeroen will prepare a presentation for the NSI session at OGF34 - Freek's use case action still stands - Freek will contact Jason about possibly switching NMC and NML calls. 4. Discussion on aliases ------------------------ We had a short discussion on whether NSI descriptions and physical topology descriptions are different things. One is something like a service, the other is the actual instantiation of it. This is similar to identifiers for books, stories, translations and physical books. Freek remembers that libraries have a solution for identifiers on those things, he will try to get a link to that and post it. Jerry and Freek will discuss his slides, we can then discuss them in the next call on March 8th. Action items: ============= * Freek to write use case on bidirectional and unidirectional links: single fiber with two wavelengths in different directions. * Jerry to write use case on bidirectional and unidirectional links * Jerry to write usecase on NORDUnet being a geographical segregated network (NY and CPH), with possible restrictions between the two locations/networks * Jerry to write this down federated and sub-NSA as a use case. * Freek and Jerry look at the exact definition of NML:Topology and NSI Network, and see if they can sync their definition * Jeroen to move schema figure and check definitions * Freek to check "at layer" relation and "Layer" object * Jeroen to fix the identifiers section * Jeroen to write the security considerations section * Freek to provide link on book identifiers

1 0