Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Tony Li <[e-mail]>]

Hi Ketan,

> Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, I do see MAX METRIC being referred to as 4,261,412,864.
>  
>  
> Because I’m a lazy sod.
>  
> It’s far easier to detect metric overflow on three byte values than four byte values. True, four byte is not impossible, but it’s just quick and easy with three byte values.  Adding a fourth byte would add range to the metric space, but in practice, this seemed like it was not really relevant. Most areas are not a very high diameter and the need for detailed metric distinctions has not been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and that seems to work.
> [KT] The Generic Metric is by definition something that will get extended in the future and we don’t know what use-cases might arise. It doesn’t seem right to follow in the steps of an administratively assigned metric type like the TE metric. Therefore, I suggest to make it variable.


Thank you for the suggestion. I don’t think anyone has suggested a variable length metric before.  A variable length metric is difficult to implement as if the length exceeds your processors word size, you need to resort to long integer software emulation packages. These are a huge performance penalty.


> [KT] Regarding metric overflow, I think it would be better to leave it to implementations on how to deal with it. A guidance similar to below (from draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does not cause interop issues. Theoretically, it is something that is independent of the size of the metric.
>  
>    During the route computation, it is possible for the Flex-Algorithm
>    specific metric to exceed the maximum value that can be stored in an
>    unsigned 32-bit variable.  In such scenarios, the value MUST be
>    considered to be of value 4,294,967,295 during the computation and
>    advertised as such.


In fact, we are not specifying how implementations deal with it.


> 
> For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7 <https://datatracker.ietf.org/doc/html/rfc8920#section-7>, in case of ISIS also, it is not really appropriate for use within ASLA -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1 <https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1>?
>  
>  
> I’m sorry, I don’t understand this comment.
> [KT] In https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1 <https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1>
>  
> The Maximum Link Bandwidth as advertised by the sub-sub-
>    TLV 23 of ASLA [RFC 8920 <https://datatracker.ietf.org/doc/html/rfc8920>] MUST be compared against the Minimum
>    bandwidth advertised in FAEMB sub-TLV.
>  
> And in the https://datatracker.ietf.org/doc/html/rfc8920#section-7 <https://datatracker.ietf.org/doc/html/rfc8920#section-7>
>  
> Maximum link bandwidth is an application-independent attribute of the
>    link that is defined in [RFC3630 <https://datatracker.ietf.org/doc/html/rfc3630>].  Because it is an application-
>    independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.
>  
> Somewhat similar for ISIS as well.


I’m sorry, I’m still not understanding your comment. Are you objecting because we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested this, updating the other two protocols.


>  
> Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric.
>  
>  
> Nor this one.
> [KT] Generic Metric is used for the links. When we get to the computation of inter-area or external routes, we will need to get into FAPM. The draft at a minimum should discuss the applicability of the Generic Metric and its use as FAPM. Now, if we do make the Generic Metric size variable (as suggested above), then we will likely need a new TLV for a variable size FAPM equivalent?


We would need a new TLV regardless of the metric size as the FAPM TLV only carries the default metric. We are not proposing that TLV at this time. That’s future work.


Tony