Hi All, Thanks for your valuable comments and feedback. We have tried to address most of them in the new version which has been uploaded now.
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-01 Thanks, William From: Tony Li <[email protected]> on behalf of Tony Li <[email protected]> Date: Friday, 5 March 2021 at 10:58 PM To: Shraddha Hegde <[email protected]> Cc: William Britto A J <[email protected]>, [email protected] <[email protected]>, Rajesh M <[email protected]>, DECRAENE Bruno IMT/OLN <[email protected]> Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints [External Email. Be cautious of content] Hi Shraddha, 8) Section 4.2. You write that an implementation "considers cumulative bandwidth of the parallel links while arriving at the metric for the link”. This seems a bit vague. I think you’re trying to say that in interface group mode the bandwidth of an adjacency is the sum of the bandwidths of the individual links. Typically today, if we have L3 parallel links they are encoded as separate adjacencies, complete with unique interface addresses. How does interface group mode work with that? <SH> It continues to work the same way. I mean the topological representation does not change. It is going to be represented as multiple parallel Adjacencies. How the metric is assigned to these links differs in simple mode and interface group mode. In simple mode, single l3 link bandwidth is taken and metric is derived by using either of two modes of metric derivation (reference bw or staircase bandwidth thresholds). In interface group mode, cumulative bandwidth of parallel links is used derive the metric (again either ref bw or staircase method can be used) and same metric is assigned to all parallel links. So just to be very clear: we continue to see multiple, parallel adjacencies advertised. Each of them that has a metric that was computed using the sum of the bandwidths on the parallel links. When one of those links fails, the remainder are then advertised with a revised metric that was computed using the sum of the bandwidths of the remaining links. If this is correct, it would be good to state this very clearly. If you intend something else… please be equally clear. Does each adjacency advertise the same metric based on the total bandwidth of all of the links? <SH> In automatic metric calculation method, each node derives the metric based on advertised maximum link bandwidth . In interface group mode, metric is derived based on cumulative bandwidth of parallel links and same metric is assigned for all parallel links. In automatic metric calculation method, metric is not advertised. I don’t understand your last sentence. Section 4 is all automatic metric calculation. Why would you calculate the metric and then not advertise it using the Bandwidth Metric subTLV? In cases where operators do not want to use this automatic metric derivation, they can advertise bandwidth metric. How this bandwidth metric is assigned, whether same metric on all parallel links or different metric and actual metric value is all upto the operator. When bandwidth metric sub-TLV is advertised on a link, simple mode or interface group mode does not come into play for that link. Bandwidth metric advertisement overrides, automatic metric derivation. I see that I have misunderstood a big chunk of your intent here. Please add more clarifying text. How does a node know whether we are using automatic mode or are being explicit in advertising our metrics? Is it on a per-link basis? Do we default to automatic mode if no bandwidth metric is advertised? Is the metric automatically calculated if no bandwidth metric is advertised? What does a remote node use as a bandwidth the compute the bandwidth of a link? I would assUme that it’s a Maximum Link Bandidth subTLV of the ASLA subTLV. If so, please be explicit. If we are to use the bandwidth metric in a FAD, we need to specify that in the FAD. This implies that we would need a new value (or set of values if we want multiple bandwidth metrics) for the Metric-Type field in the FAD subTLV. I see that you’ve added a specific request for this in section 7.1, but it deserves mentioning somewhere in the text as well. Regards, Tony Juniper Business Use Only
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
