Hi Shraddha, Please check inline below with KT2
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Shraddha Hegde Sent: 27 May 2021 18:31 To: Tony Li <tony...@tony.li>; Ketan Talaulikar (ketant) <ket...@cisco.com> Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02 Snipped.. 5. 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>, 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxHHnJfE7$>? 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxAEMtKzf$> The Maximum Link Bandwidth as advertised by the sub-sub- TLV 23 of ASLA [RFC 8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMntRW1t$>] 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$> Maximum link bandwidth is an application-independent attribute of the link that is defined in [RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMwurpJX$>]. 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. <shraddha> As per RFC 8920, Maximum Link Bandwidth cannot be advertised in ASLA. Will update the text to reflect Maximum Link Bandwidth sub-TLV in Extended Link TLV of Extended Link opaque LSA. [KT2] Thanks. For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that different values for different applications is not allowed. Maximum Link bandwidth is also allowed with all bits set to zero in SABM/UDABM or each individual application bit set for all applications making use of ASLA. [KT2] Yes, you are correct. The RFC8919 does not mandate or require Max Link Bandwidth to be signaled within ASLA (at least that was my reading). If so, perhaps it is better to not require that in this document - just keep in the base. Would that not work? And if it were advertised in the ASLA (as RFC8919 allows it), then perhaps a reference to the RFC8919 will be important on how it is to be done - basically exactly what you described above. Thanks, Ketan RFC 8919 sec 4.2.1 " Maximum link bandwidth is an application-independent attribute of the link. When advertised using the Application-Specific Link Attributes sub-TLV, multiple values for the same link MUST NOT be advertised. This can be accomplished most efficiently by having a single advertisement for a given link where the Application Identifier Bit Mask identifies all the applications that are making use of the value for that link." 1. Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric. <shraddha> As long as we have fixed length generic metric, there won't be any changes to FAPM. We'll add a section to clarify about FAPM Juniper Business Use Only From: Tony Li <tony1ath...@gmail.com<mailto:tony1ath...@gmail.com>> On Behalf Of Tony Li Sent: Wednesday, May 26, 2021 10:10 PM To: Ketan Jivan Talaulikar <ket...@cisco.com<mailto:ket...@cisco.com>> Cc: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02 [External Email. Be cautious of content] Hi Ketan, 1. 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. 1. 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>, 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxHHnJfE7$>? 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxAEMtKzf$> The Maximum Link Bandwidth as advertised by the sub-sub- TLV 23 of ASLA [RFC 8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMntRW1t$>] 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$> Maximum link bandwidth is an application-independent attribute of the link that is defined in [RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMwurpJX$>]. 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. 1. 2. 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
