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