[Nml-wg] recursive topologies

[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