[Nml-wg] recursive topologies

[Jason Zurawski]

Hi Freek/All;

As with any proposal to this group, I would expect that those pushing 
the idea (yourself and Jerry) can provide some examples for everyone to 
see.  These examples should show highlight the similarities and 
differences between the current working schema that has been in use for 
some time, and this new approach that is aiming to please a single 
constituency of the NML schema.  It is not really possible to evaluate 
the concepts until these are provided.

Thanks;

-jason

On 3/4/12 7:55 AM, thus spake Freek Dijkstra:
> 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