L.S., In the current version of the NML specification, as presented today at the GLIF/OGF meeting, I noticed that there is no provision for assigning metrics to links or ports. To support pathfinding in NSI (which uses NML for its topology description), it would be very useful to include attributes for such metrics. Without any such information, intercontinental links are just as likely to be used in an NSI path as local links, which would be a waste of scarce international bandwidth. At first glance, I would suggest adding attributes such as length, weight (preference) and bandwidth - as NML is extensible, should such extensions be coordinated by the NML-WG, or extensions that NSI themselves could create? Given the basic nature of these attributes, it would probably be best to have them centrally registered, to prevent multiple, incompatible versions (Length in m or km? Bandwidth in b/s or Mb/s?) from occurring. Regards, Paul Boven.
W dniu 2013-06-06 16:51, Paul Boven pisze:
L.S.,
Hi Paul, all,
In the current version of the NML specification, as presented today at the GLIF/OGF meeting, I noticed that there is no provision for assigning metrics to links or ports. To support pathfinding in NSI (which uses NML for its topology description), it would be very useful to include attributes for such metrics. Without any such information, intercontinental links are just as likely to be used in an NSI path as local links, which would be a waste of scarce international bandwidth.
At first glance, I would suggest adding attributes such as length, weight (preference) and bandwidth - as NML is extensible, should such extensions be coordinated by the NML-WG, or extensions that NSI themselves could create? Given the basic nature of these attributes, it would probably be best to have them centrally registered, to prevent multiple, incompatible versions (Length in m or km? Bandwidth in b/s or Mb/s?) from occurring.
I think NML should only focus on topology description but your proposal could be considered by the NM WG. The current NML could be used by NM. Kind regards, Roman
Regards, Paul Boven. _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
On 06-06-2013 16:51, Paul Boven wrote:
[...] At first glance, I would suggest adding attributes such as length, weight (preference) and bandwidth - as NML is extensible, should such extensions be coordinated by the NML-WG, or extensions that NSI themselves could create? Given the basic nature of these attributes, it would probably be best to have them centrally registered, to prevent multiple, incompatible versions (Length in m or km? Bandwidth in b/s or Mb/s?) from occurring.
I would like to see delay (in ms), (maximum) capacity of Links, and (maximum) capacity and MTU of ports. The problem with capacity is that it is highly non-trivial for the main technology in use today, Ethernet. Two notes: * Maximum achievable bandwidth of a channel (VLAN) depends on frame size and interframe gap, and header size. (Most technologies define bandwidth of the payload; to avoid these issues, Ethernet defines the bandwidth of the underlying medium) * Ethernet does not work with a achievable bandwidth, but instead defines Committed Information Rate (CIR), Excess Information Rate (EIR), Committed Burst Size (CBS), and Excess Burst Size (EBS). For this reason, the proposal to make generic definitions was rejected at OGF35, and it was suggested to define technology-specific definition for each technology. I agree that the above issues are irrelevant for a "rough estimate" as you need. My fear is that we introduce a "rough estimate", an application may later use it to check if it is possible to fit a data flow within a pipe (thus is the bandwidth of the data flow is smaller than the capacity of the pipe). GMPLS is doing this. For reference, see http://tools.ietf.org/html/rfc6003#section-4.1 for how GMPLS defined the bandwidth. I personally think it is way too complex. Maybe we have to pick, and make some "experimental" parameter: * Do you want a parameter that describes the capacity of the data flow including or excluding the header? * For Ethernet, do you want a parameter that defines the CIR or PIR (=CIR+EIR), or do you prefer two (or four) parameters? Freek
Hey Freek, On Jun 6, 2013, at 11:45 AM, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
On 06-06-2013 16:51, Paul Boven wrote:
[...] At first glance, I would suggest adding attributes such as length, weight (preference) and bandwidth - as NML is extensible, should such extensions be coordinated by the NML-WG, or extensions that NSI themselves could create? Given the basic nature of these attributes, it would probably be best to have them centrally registered, to prevent multiple, incompatible versions (Length in m or km? Bandwidth in b/s or Mb/s?) from occurring.
I would like to see delay (in ms), (maximum) capacity of Links, and (maximum) capacity and MTU of ports.
The problem with capacity is that it is highly non-trivial for the main technology in use today, Ethernet. Two notes: * Maximum achievable bandwidth of a channel (VLAN) depends on frame size and interframe gap, and header size. (Most technologies define bandwidth of the payload; to avoid these issues, Ethernet defines the bandwidth of the underlying medium) * Ethernet does not work with a achievable bandwidth, but instead defines Committed Information Rate (CIR), Excess Information Rate (EIR), Committed Burst Size (CBS), and Excess Burst Size (EBS).
For this reason, the proposal to make generic definitions was rejected at OGF35, and it was suggested to define technology-specific definition for each technology.
I agree that the above issues are irrelevant for a "rough estimate" as you need. My fear is that we introduce a "rough estimate", an application may later use it to check if it is possible to fit a data flow within a pipe (thus is the bandwidth of the data flow is smaller than the capacity of the pipe). GMPLS is doing this.
For reference, see http://tools.ietf.org/html/rfc6003#section-4.1 for how GMPLS defined the bandwidth. I personally think it is way too complex.
Maybe we have to pick, and make some "experimental" parameter: * Do you want a parameter that describes the capacity of the data flow including or excluding the header? * For Ethernet, do you want a parameter that defines the CIR or PIR (=CIR+EIR), or do you prefer two (or four) parameters?
Similar to your bandwidth example above, 'delay' has a highly screwing meaning depending on the link (e.g. if an end-to-end link covers 3 physical links and 2 switches, what is its delay? does that include any latency added by the switches? is it average, minimum, or maximum delay?). For bandwidth, in general, I think if folks are really expecting that 9Gbps really means they can send 9000000000 bits of traffic on the link with no issues, they're going to be in for a rude awakening anyway, and it won't much matter with that 9Gbps includes headers or not. I think if we can come up with some reasonable defaults that roughly account for what most people are expecting, that's probably fine. If folks find that definition of delay, or bandwidth, or whatever, is not to their liking, they can create a new parameter. The other big thing to think about is how people are going to populate this field. It doesn't matter if the documentation says "this must include headers", or "this must not include headers", because people will likely put in what they think should be in there, and there's not really a good way to say "that's not what i right" unless you have very in-depth knowledge of their network. Cheers, Aaron
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
ESnet/Internet2 Focused Technical Workshop Network Issues for Life Sciences Research July 17 - 18, 2013, Berkeley CA http://events.internet2.edu/2013/ftw-life-sciences/
Guys, I had a discussion on this topic with Freek and he asked if I would repeat it in an e-mail to the group. I am going to explain how OpenDRAC does this, but I in no way say this is the correct way to do it. It just happens to be how we originally did it inside of Nortel. OpenDRAC has two routing metrics called "cost" and "metric2". There are historical reasons for the naming I will not get into, but it boils down to two attributes the customer can used for routing. The routing algorithm in OpenDRAC is a modified dijkstra's configurable to minimize based on hops, cost, or metric2. We support routing on a single value at a time. We do not care what values are placed in the metrics, we just use them when asked to route minimize on a specific one. The network administrator can configure any value they deem useful, and we have customers do some interesting things with these values. For example, we had one customer configure the majority of links at a cost of 1, and certain historically high congestion links a higher value so they were only chosen when no other valid paths existed. This had the result of diverting dynamically routed circuits from these core links. Other obvious uses are for modelling link delay is this is a critical attribute for minimization. SURFnet has also assigned huge values to links when they temporarily want to block a route from being used. OpenDRAC also supported diverse routing based on node and SRLG values. We supported a simple model where an administrator could assign a set of integers to a link representing the shared risk. When asked to route a protected path, or asked to route one path diverse from a second path, we would exclude all nodes and resources with SRLG values from the first path before path computation. We did not support route optimization for two path simultaneously. We routed one path then the second. This could result in blocking of potential protection paths, but simplified our implementation. John On 2013-06-06, at 10:09 PM, Aaron Brown <aaron@internet2.edu> wrote:
Hey Freek,
On Jun 6, 2013, at 11:45 AM, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
On 06-06-2013 16:51, Paul Boven wrote:
[...] At first glance, I would suggest adding attributes such as length, weight (preference) and bandwidth - as NML is extensible, should such extensions be coordinated by the NML-WG, or extensions that NSI themselves could create? Given the basic nature of these attributes, it would probably be best to have them centrally registered, to prevent multiple, incompatible versions (Length in m or km? Bandwidth in b/s or Mb/s?) from occurring.
I would like to see delay (in ms), (maximum) capacity of Links, and (maximum) capacity and MTU of ports.
The problem with capacity is that it is highly non-trivial for the main technology in use today, Ethernet. Two notes: * Maximum achievable bandwidth of a channel (VLAN) depends on frame size and interframe gap, and header size. (Most technologies define bandwidth of the payload; to avoid these issues, Ethernet defines the bandwidth of the underlying medium) * Ethernet does not work with a achievable bandwidth, but instead defines Committed Information Rate (CIR), Excess Information Rate (EIR), Committed Burst Size (CBS), and Excess Burst Size (EBS).
For this reason, the proposal to make generic definitions was rejected at OGF35, and it was suggested to define technology-specific definition for each technology.
I agree that the above issues are irrelevant for a "rough estimate" as you need. My fear is that we introduce a "rough estimate", an application may later use it to check if it is possible to fit a data flow within a pipe (thus is the bandwidth of the data flow is smaller than the capacity of the pipe). GMPLS is doing this.
For reference, see http://tools.ietf.org/html/rfc6003#section-4.1 for how GMPLS defined the bandwidth. I personally think it is way too complex.
Maybe we have to pick, and make some "experimental" parameter: * Do you want a parameter that describes the capacity of the data flow including or excluding the header? * For Ethernet, do you want a parameter that defines the CIR or PIR (=CIR+EIR), or do you prefer two (or four) parameters?
Similar to your bandwidth example above, 'delay' has a highly screwing meaning depending on the link (e.g. if an end-to-end link covers 3 physical links and 2 switches, what is its delay? does that include any latency added by the switches? is it average, minimum, or maximum delay?). For bandwidth, in general, I think if folks are really expecting that 9Gbps really means they can send 9000000000 bits of traffic on the link with no issues, they're going to be in for a rude awakening anyway, and it won't much matter with that 9Gbps includes headers or not.
I think if we can come up with some reasonable defaults that roughly account for what most people are expecting, that's probably fine. If folks find that definition of delay, or bandwidth, or whatever, is not to their liking, they can create a new parameter. The other big thing to think about is how people are going to populate this field. It doesn't matter if the documentation says "this must include headers", or "this must not include headers", because people will likely put in what they think should be in there, and there's not really a good way to say "that's not what i right" unless you have very in-depth knowledge of their network.
Cheers, Aaron
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
ESnet/Internet2 Focused Technical Workshop Network Issues for Life Sciences Research July 17 - 18, 2013, Berkeley CA http://events.internet2.edu/2013/ftw-life-sciences/
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Hi Freek, everyone, On 06/06/2013 05:45 PM, Freek Dijkstra wrote:
The problem with capacity is that it is highly non-trivial for the main technology in use today, Ethernet. Two notes: * Maximum achievable bandwidth of a channel (VLAN) depends on frame size and interframe gap, and header size. (Most technologies define bandwidth of the payload; to avoid these issues, Ethernet defines the bandwidth of the underlying medium) * Ethernet does not work with a achievable bandwidth, but instead defines Committed Information Rate (CIR), Excess Information Rate (EIR), Committed Burst Size (CBS), and Excess Burst Size (EBS).
While I understand that this is a complex issue, we do need a single definition of bandwidth for NSI to properly function end-to-end. Otherwise, we end up with end-users having to 'fudge' their requests to make sure that it fits with any possible underlying technology. So in this context, payload capacity is the only metric that makes sense. I will bring up this issue in the NSI-WG as well, the current draft of the NSI v2.0 spec does not give any precise definition of 'bandwidth'.
Maybe we have to pick, and make some "experimental" parameter: * Do you want a parameter that describes the capacity of the data flow including or excluding the header? * For Ethernet, do you want a parameter that defines the CIR or PIR (=CIR+EIR), or do you prefer two (or four) parameters?
As my goal here is to do reliable pathfinding, I think we should have a single, technology agnostic metric that will tell me whether a link can theoretically support my request, or not. NSI has no notion of CIR/EIR/PIR, so presumably their use of 'bandwidth' matches closes to the CIR parameter for Ethernet. Regards, Paul Boven. -- Paul Boven <boven@jive.nl> +31 (0)521-596547 Unix/Linux/Networking specialist Joint Institute for VLBI in Europe - www.jive.nl VLBI - It's a fringe science
participants (5)
-
Aaron Brown -
Freek Dijkstra -
John MacAuley -
Paul Boven -
Roman Łapacz