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
Hi, On 4 Mar 2012, at 13:55, Freek Dijkstra wrote:
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
I agree with this idea, and the option of defining aliases. This makes for a more stable inter-domain topology. I would suggest that we allow abstracted topologies to contain some hints regarding internal availability.
2. Hierarchical identifiers
No thanks.
3. Updates and Versioning
In the Automated GOLE experiments I've found that being able to see a version of the topology used would be a nice feature. Currently the demo still uses a centralized topology, so knowing the used version is more important. Still, knowing when your neighbor last updated their topology can help debugging issues. So I think it would be a nice feature to have, although not necessarily something that we'd include in the schema itself though. Jeroen.
Hi,
On 4 Mar 2012, at 13:55, Freek Dijkstra wrote:
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 I agree with this idea, and the option of defining aliases. This makes for a more stable inter-domain topology. I would suggest that we allow abstracted topologies to contain some hints regarding internal availability. I don't mind doing something like this as long as it is an optional announcement by the local network. Thus a network can announce what
Hi guys- Thanks for writing this up Freek. Comments in line... On 3/5/12 4:18 AM, Jeroen van der Ham wrote: they are comfortable announcing. And an external path finder agent can gather as much topology as they can acquire. I think some of the internal availability announcements become less important if we modified the Reservation Request to more acurately reflect the desired constraints - in particular to loosen the endpoint speciications to allow some selection criteria on a set of available endpoints. But this latter approach is an issue for NSI, not really NML.
2. Hierarchical identifiers No thanks. Hmm...why that reaction? :-)
I am on the fence on this. I don't think we implemented URNs well in the current RDF/OWL topology. The global nature seems awkward... I just think we probably did not leverage the namespaces of the URNs effectively.
3. Updates and Versioning In the Automated GOLE experiments I've found that being able to see a version of the topology used would be a nice feature. Currently the demo still uses a centralized topology, so knowing the used version is more important. Still, knowing when your neighbor last updated their topology can help debugging issues. So I think it would be a nice feature to have, although not necessarily something that we'd include in the schema itself though.
I concur that we need to transition the topology management to the networks/GOLEs themselves as soon as we can - this is the right thing to do. But to do that, we should also have a well considered plan for how we expect NSAs to construct their world views - and have all NSA developers implement this as part of the transition. There is no urgent rush - better to think it though first. I would vote for the basic approach that each NSA builds a world view from direct neighbors and then they announce their world view, rather than each domain simply announcing only their own local topology. I think the world view approach will scale better. Thoughts? The version timestamp is useful I think when we move to the distributed mechanism. If you want to suggest a RDF predicate, I can add it into the present topology. I think the idea was that we could use timestamps to date each nested block of information...so that merging them could be done based on block timestamp rather than a more complex parser analysis. J
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
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
Jason Zurawski wrote:
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.
See Jerry's email of http://www.ogf.org/pipermail/nml-wg/2012-March/000848.html (the attachment, slides 4-7). I'll see to create a few RDF or XML examples if that helps understanding the concept.
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.
As for examples on the Lifetime and version attributes I'll make some examples (we decided on Lifetime object at OGF 26, and it has been in the schema since but it seem we never made examples with it). Freek
Hi Freek/All; On 3/5/12 7:13 AM, thus spake Freek Dijkstra:
Jason Zurawski wrote:
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.
See Jerry's email of http://www.ogf.org/pipermail/nml-wg/2012-March/000848.html (the attachment, slides 4-7).
I'll see to create a few RDF or XML examples if that helps understanding the concept.
This is what I was looking for specifically.
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.
As for examples on the Lifetime and version attributes I'll make some examples (we decided on Lifetime object at OGF 26, and it has been in the schema since but it seem we never made examples with it).
Perhaps Aaron can respond with some use cases for how this is used in OSCARS and Circuit Monitoring. Thanks; -jason
participants (4)
-
Freek Dijkstra -
Jason Zurawski -
Jeroen van der Ham -
Jerry Sobieski