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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
