Hello Shraddha/Authors, Checking to see if we can conclude on the text to be added/updated to cover the advertisement and usage for applications other than FlexAlgo like RSVP-TE and SR Policy.
Thanks, Ketan On Mon, May 27, 2024 at 8:27 AM Ketan Talaulikar <[email protected]> wrote: > Hi Acee, > > Please check inline below for responses. > > > On Thu, May 23, 2024 at 1:58 AM Acee Lindem <[email protected]> wrote: > >> Ketan, >> >> First of all, the have been early allocations for over almost 2 years now >> and it isn’t very timely to object at the end of WG last call. However, I >> think your concerns can easily be satisfied. >> > > KT> It is only at WGLC that the authors have indicated that the draft is > "complete" and therefore the WGLC seems the time for me to object that it > isn't complete? I agree that my concerns can be easily satisfied with > additional text - I've shared the suggestions for the same as well. > > >> >> On May 21, 2024, at 12:18, Ketan Talaulikar <[email protected]> >> wrote: >> >> Hi Acee, >> >> You seem to have misunderstood my concern. I am not asking for >> specification of the RSVP-TE CSPF algorithm/computation using Generic >> Metric. >> >> Let me clarify my objections. There are 3 ways in which Generic Metric >> can be advertised for OSPFv2 as stated in this draft: >> >> 1) As a sub-TLV of the ASLA sub-TLV in the OSPFv2 Extended Link LSA : For >> FlexAlgo usage this is the one and only one way to advertise Generic Metric >> in OSPFv2 (note there is no L-bit in OSPF for ASLA). RFC 9492 (ASLA) allows >> for this to be used for other applications beyond FlexAlgo. I would like >> this draft to clarify if it is defining Generic Metric use for any >> application other than FlexAlgo under ASLA - see further in my email. >> >> 2) As a top-level sub-TLV of the OSPFv2 Extended Link TLV in the OSPFv2 >> Extended Link LSA : This document is making allocation in this namespace >> but that is not an issue since the namespace is shared with ASLA. However, >> the draft needs to clarify that it is not defining Generic Metric use for >> any application when advertised this way as it is not used in base OSPF >> route calculation. >> >> >> So, basically 1 and 2 are the same and equates to “Generic metric usage >> for applications other than flex algorithm is out of scope. Future >> documents may describe usage.” >> > > KT> Sure, that was the "easy" option that I had initially suggested. > However, Shraddha mentioned that she is aware of ongoing/existing > implementations and that is why I am instead suggesting that we add some > text to cover those other applications. I don't think it should be very > difficult to incorporate. > > >> >> >> 3) As a sub-TLV of the Link TLV in the OSPFv2 TE Opaque LSA : This >> document is making an allocation in this namespace but not indicating any >> application usage. If the intention is to use this advertisement for >> RSVP-TE CSPF, then there is no issue since this is allowed per RFC 9492 >> Section 12.3.4. However, the draft must explicitly state that this is the >> only way to use it for RSVP-TE application. >> >> >> I’m looking at RFC 9492 Section 12.1 - why couldn’t the generic metric be >> used for the other referenced applications - LFA and SR policy if usage is >> described in a future document? Similar to above. >> > > KT> For SR Policy, it is certainly possible. For LFA, I am not sure at > this point other than within FlexAlgo. I would rather prefer that we add > small sections in the current draft that cover RSVP-TE and SR Policy at > least (as suggested). I can provide the text if the authors are OK with > this proposal. > > Thanks, > Ketan > > >> >> Shraddha - can you provide these application scoping statements? >> >> Thanks, >> Acee >> >> >> >> Now, in addition to the above, there is the SR Policy CSPF computation >> application (very similar to RSVP-TE) as well and this draft does not >> clarify how Generic Metric is to be advertised for that application. Per >> RFC9492, it should be as (1) and not as (2) or (3). >> >> Without this clarification, we are in for interop issues for all >> applications other than FlexAlgo. >> >> Finally, the list of points that I shared earlier on this thread is not >> about the actual CSPF computation algo, but more about the semantics of the >> advertisement itself. >> >> I hope this clarifies why this draft is currently underspecified for >> Generic Metric TLV usage for all applications other than FlexAlgo. >> >> Thanks, >> Ketan >> >> On Sat, May 18, 2024 at 4:19 AM Acee Lindem <[email protected]> >> wrote: >> >>> >>> >>> On May 17, 2024, at 17:14, Acee Lindem <[email protected]> wrote: >>> >>> Hi Ketan, Shraddha, >>> >>> On May 17, 2024, at 07:22, Ketan Talaulikar <[email protected]> >>> wrote: >>> >>> Hi Shraddha, >>> >>> Thanks for your response. I believe we now have only one open discussion >>> point and hence I am top posting my suggestions. >>> >>> If the authors wish to cover the Generic Metric TLV usage in TE Opaque >>> LSAs in this document then we will need more text/specification than "All >>> traditional TE applications like CSPF/RSVP make use of link-attributes from >>> TE-LSA." >>> >>> >>> Since the new Generic Metric code point is in this registry - >>> https://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#subtlv2 >>> I >>> don’t the issue with it being used for TE applications currently making use >>> of the TE Opaque LSA - we’re still using the OSPF TE Opaque LSA for >>> traditional TE. Right? >>> >>> >>> >>> Some suggestions which can be incorporated in a separate section that is >>> titled "Use of Generic Metric for RSVP-TE": >>> - specify that Generic Metric TLV usage in TE Opaque LSAs is limited to >>> RSVP-TE use >>> - specify the differences for use of bandwidth metric for RSVP-TE; I >>> assume it is a constant metric value itself since we don't have FAD to >>> determine the b/w metric >>> - flex algo prunes links w/o the specific metric advertisements; will it >>> be the same for RSVP-TE CSPF? >>> - cover backward compatibility aspects (e.g., what if the computation >>> needs to optimize on a particular metric and a set of routers/links don't >>> carry that metric value) >>> >>> I hope this gives an idea of the details necessary if this document is >>> attempting to cover use of generic metric for not just flex algo but other >>> applications. If there were any other applications/usage in mind, it would >>> be good to clarify that explicitly. We have many different LSAs in OSPF >>> resulting in potential interop issues if the specifications are not clear. >>> >>> >>> Perhaps, it should be stated that usage will be specified in future >>> documents. This could included in the -13 version with Peter’s comments. >>> >>> >>> On second thought, since RSVP signals the complete path, the TE path >>> computation typically has not be standardized and I don’t think this is >>> required. We can move forward with the -13 version with Peter’s comments. >>> >>> Thanks, >>> Acee >>> >>> >>> >>> >>> >>> >>> Thanks, >>> Acee >>> >>> >>> >>> >>> >>> Thanks, >>> Ketan >>> >>> >>> On Thu, May 16, 2024 at 2:56 PM Shraddha Hegde <[email protected]> >>> wrote: >>> >>>> Hi Ketan, >>>> >>>> >>>> >>>> Snipping to open points >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2) This comment is specific to OSPF given the encoding differences it >>>> has with ISIS. Section 2.2 allows for Generic Metric TLV to be used in too >>>> many places without clear specification of what it is used for - this is a >>>> potential pitfall for interop issues. RFC9492 provides helpful directions >>>> for us here. >>>> >>>> a) This draft specifies FlexAlgo extensions, it is natural that Generic >>>> Metric be advertised under ASLA TLV. No issues here. >>>> >>>> b) This draft does not specify anything about use of generic metric in >>>> base OSPF and as a reminder there is nothing like L-bit in OSPF encoding. >>>> Therefore, it does not make sense to advertise Generic Metric outside of >>>> ASLA and under the OSPFv2 Extended Link TLV or OSPFv3 Router Link TLV. >>>> >>>> c) This draft does not specify anything about use of generic metric >>>> with RSVP-TE/GMPLS. Therefore, it does not make sense to advertise Generic >>>> Metric in the TE Opaque LSAs. >>>> >>>> We can have specific documents that introduce (b) or (c) when there is >>>> a proper specification. >>>> >>>> <SH> Generic metric is a link attribute and can be used by other >>>> applications apart from Flex-algo. >>>> >>>> I don’t see a reason to not take code-points under other applicable >>>> LSAs. >>>> >>>> >>>> >>>> KT> I disagree on this one. There is a reason why what is proposed in >>>> the draft for ISIS is OK - due to the L-bit in ASLA, we need codepoints >>>> both under ASLA and at the top level for FlexAlgo. There is no L-bit in >>>> OSPF and therefore this does not apply. The code-points can be allocated >>>> when the behavior is specified for those other LSAs and applications >>>> (beyond FlexAlgo) in OSPF. We should not set the precedent for allocating >>>> code-points for TLVs without any defined use or behavior. >>>> >>>> >>>> >>>> <SH2> Early code points are taken and implementations underway for >>>> other applications. >>>> >>>> >>>> >>>> “Implementations MUST support sending and receiving generic metric >>>> >>>> sub-TLV in ASLA encodings as well as in the TLV 22/extended link >>>> LSA/TE-LSAs. >>>> >>>> The usage of a generic metric by an individual application is subject >>>> to the same >>>> >>>> rules that apply to other link attributes defined in respective >>>> standards.” >>>> >>>> >>>> >>>> The above text clarifies the use of generic metric by individual >>>> application. >>>> >>>> >>>> >>>> KT2> I am not sure this is sufficient. Let us take an example. How is >>>> the Generic Metric TLV received in OSPFv2 TE Opaque LSA handled and what is >>>> it used for? >>>> >>>> >>>> >>>> <SH3> The text in the draft says the applications that make use of link >>>> attributes from TE LSA will also use generic metric from TE-LSA. All >>>> traditional TE applications like CSPF/RSVP make use of link-attributes from >>>> TE-LSA. I don’t see the need to say anything beyond what has already been >>>> said in the draft. >>>> >>>> >>>> >>>> The Min Unidirectional Link Delay as advertised by *sub-sub-TLV 12* of >>>> ASLA sub-TLV [RFC8920 >>>> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC8920__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmun5uDKc7A$>], >>>> MUST be compared against the Maximum delay advertised in the FAEMD sub-TLV. >>>> >>>> <SH> changed to “The Unidirectional Link Delay as advertised by >>>> *sub-sub-TLV >>>> 12”* >>>> >>>> >>>> >>>> KT> Perhaps my comment was not clear. The following text would be more >>>> accurate: >>>> >>>> >>>> >>>> The Min Delay value advertised via the Min/Max Unidirectional Link >>>> Delay sub-TLV [RFC7471] of the ASLA sub-TLV [RFC8920 >>>> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC8920__;Iw!!NEt6yMaO-gk!HoQCxz15c5OoUVXjpmPpCU0N94Ex0cMuET6hFT8l6FE_kNkB58lpI-LSmXBUJvY4IdViL2mzTjVwvp4nyibk3A$>], >>>> MUST be compared against the Maximum delay advertised in the FAEMD sub-TLV. >>>> >>>> <SH2> I think there is a misunderstanding here. You are proposing to >>>> use sub-tlv 13 where as the text in the draft clearly proposes to use >>>> sub-tlv 12. This probably justifies why it is important to specify sub-tlv >>>> number >>>> >>>> And not just name. >>>> >>>> >>>> >>>> KT2> Well, that is what I am also trying to point out ... that the >>>> draft is wrong :-) The one to use is 13 - please check below and let me >>>> know if I am missing something. I also urge you to stick to using OSPF >>>> conventions of using TLV names as opposed to the ISIS convention of using >>>> TLV numbers. >>>> >>>> >>>> >>>> Refer: https://www.rfc-editor.org/rfc/rfc9350.html#section-5.2 >>>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*section-5.2__;Iw!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvQO78JKxQ$> >>>> ... look for IGP metric type 1 >>>> >>>> And then: https://www.rfc-editor.org/rfc/rfc7471#section-4.2 >>>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7471*section-4.2__;Iw!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvSIQb9eeQ$> >>>> and https://www.rfc-editor.org/rfc/rfc8920.html#section-14.1 >>>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8920.html*section-14.1__;Iw!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvRWLiM03A$> >>>> >>>> 12 >>>> >>>> Unidirectional Link Delay >>>> >>>> Y >>>> >>>> [RFC9492 >>>> <https://urldefense.com/v3/__https:/www.iana.org/go/rfc9492__;!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvT7cfK2pA$> >>>> ] >>>> >>>> 13 >>>> >>>> Min/Max Unidirectional Link Delay >>>> >>>> Y >>>> >>>> [RFC9492 >>>> <https://urldefense.com/v3/__https:/www.iana.org/go/rfc9492__;!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvT7cfK2pA$> >>>> ] >>>> >>>> >>>> >>>> <SH3> Ok I got it. Will fix in -12 version >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 7) Regarding >>>> https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-6 >>>> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*section-6__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumnzxX7UA$>, >>>> it seems like we want to retain a numbering ordering of rules/sequence for >>>> flex-algo as extension documents are introduced. Am I correct? If so, then >>>> this document should formally "update" RFC9350 since it is changing the >>>> "set of rules/sequence" for FlexAlgo computations. Further such extensions >>>> will also need to keep updating the base spec similarly. I would suggest >>>> that a full set of rules that is a union of what is in RFC9350 and rules >>>> added by this draft are maintained in an Appendix section. Other documents >>>> in the future can similarly maintain the latest set of rules. >>>> >>>> <SH> This draft is adding 2 new rules at the end of existing rules. Its >>>> not modifying or changing the order. >>>> >>>> I don’t see what value it is going to add by repeating the set of rules >>>> in Appendix. >>>> >>>> >>>> >>>> KT> What happens when another FlexAlgo document adds more rules? What >>>> happens when some FlexAlgo document wants to insert rules in the middle of >>>> existing ones instead of appending at the end? My point is that if there is >>>> a desire to establish a "live" set of rules in specific orders, then we >>>> need to leave a trail of document "updates" on the base FlexAlgo that one >>>> can refer to know how these "live set of rules" are getting "updated" by >>>> this and future documents. I am thinking of this on lines similar to an >>>> update for an FSM. >>>> >>>> <SH2> It’s a matter of choice. For ex RFC 8029 >>>> >>>> Has so many updates to the Rules but each update only lists >>>> the changes. >>>> >>>> >>>> >>>> KT2> I am not sure I follow and it would help if you can perhaps give >>>> an example. >>>> >>>> >>>> >>>> I am fine with whatever WG decides to do. >>>> >>>> I want to hear if anyone in WG has an opinion on adding >>>> Appendix. >>>> >>>> >>>> >>>> KT2> Sure. My point is that this seems like an ordered set of rules >>>> that are being updated by multiple documents (more to come). How does one >>>> keep track of the "current" set of rules without some trail or each new(er) >>>> document capturing the "latest" set? >>>> >>>> <SH3> I don’t see any other opinions on mailing list. Will add appendix >>>> in -12 with full set of rules. >>>> >>>> >>>> >>>> Rgds >>>> >>>> Shraddha >>>> >>>> >>>> >>>> Juniper Business Use Only >>>> >>>> *From:* Ketan Talaulikar <[email protected]> >>>> *Sent:* Saturday, April 27, 2024 11:44 AM >>>> *To:* Shraddha Hegde <[email protected]> >>>> *Cc:* Acee Lindem <[email protected]>; lsr <[email protected]>; >>>> [email protected] >>>> *Subject:* Re: [Lsr] Working Group Last Call for "Flexible Algorithms: >>>> Bandwidth, Delay, Metrics and Constraints" - >>>> draft-ietf-lsr-flex-algo-bw-con-07 >>>> >>>> >>>> >>>> *[External Email. Be cautious of content]* >>>> >>>> >>>> >>>> Hi Shraddha, >>>> >>>> >>>> >>>> Please check inline below with KT2. >>>> >>>> >>>> >>>> On Mon, Apr 15, 2024 at 12:16 PM Shraddha Hegde <[email protected]> >>>> wrote: >>>> >>>> Hi Ketan, >>>> >>>> >>>> >>>> Thanks for reply. >>>> >>>> Pls see inline.. >>>> >>>> >>>> >>>> >>>> >>>> Juniper Business Use Only >>>> >>>> *From:* Ketan Talaulikar <[email protected]> >>>> *Sent:* Monday, April 8, 2024 2:25 PM >>>> *To:* Shraddha Hegde <[email protected]> >>>> *Cc:* Acee Lindem <[email protected]>; lsr <[email protected]>; >>>> [email protected] >>>> *Subject:* Re: [Lsr] Working Group Last Call for "Flexible Algorithms: >>>> Bandwidth, Delay, Metrics and Constraints" - >>>> draft-ietf-lsr-flex-algo-bw-con-07 >>>> >>>> >>>> >>>> *[External Email. Be cautious of content]* >>>> >>>> >>>> >>>> Hi Shraddha, >>>> >>>> >>>> >>>> Thanks for your responses. Please check inline below for clarifications >>>> with KT. >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Apr 4, 2024 at 9:49 AM Shraddha Hegde <[email protected]> >>>> wrote: >>>> >>>> Hi Ketan, >>>> >>>> >>>> >>>> Thanks for the review and comments. >>>> >>>> Pls see inline for replies. >>>> >>>> >>>> >>>> >>>> >>>> Juniper Business Use Only >>>> >>>> *From:* Ketan Talaulikar <[email protected]> >>>> *Sent:* Thursday, March 21, 2024 10:07 PM >>>> *To:* Acee Lindem <[email protected]> >>>> *Cc:* lsr <[email protected]>; [email protected] >>>> *Subject:* Re: [Lsr] Working Group Last Call for "Flexible Algorithms: >>>> Bandwidth, Delay, Metrics and Constraints" - >>>> draft-ietf-lsr-flex-algo-bw-con-07 >>>> >>>> >>>> >>>> *[External Email. Be cautious of content]* >>>> >>>> >>>> >>>> Hi All, >>>> >>>> >>>> >>>> I have reviewed this document and believe it needs some further work >>>> before publication. >>>> >>>> >>>> >>>> I am sharing my comments below: >>>> >>>> >>>> >>>> 1) There is the following text in sec 2.1 and 2.2 for Generic Metric. >>>> >>>> >>>> >>>> A metric value of 0xFFFFFF is considered as maximum link metric and a >>>> link having this metric value MUST NOT be used during Flex-algorithm >>>> calculations [RFC9350 >>>> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC9350__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmuk-veyTXw$>]. >>>> The link with maximum generic metric value is not available for the use of >>>> Flexible Algorithms but is availble for other use cases. >>>> >>>> >>>> >>>> I believe the FlexAlgo reference here is to >>>> https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration >>>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumv0_0Zeg$> >>>> >>>> >>>> >>>> >>>> But the above text does not align with the RFC9350. If a link is to be >>>> made unavailable for FlexAlgos operating with a specific Generic Metric, >>>> then the way to do that is to omit that specific Generic Metric TLV from >>>> the ASLA for flex-algo application. The same would apply for other >>>> applications - just omit the metric. Why do we need a special >>>> MAX-LINK-METRIC value for generic metric given that it is a new thing we >>>> are introducing? >>>> >>>> >>>> >>>> <SH> I see what you are saying. Text is updated as below for ISIS and >>>> similar for OSPF. >>>> >>>> “A metric value of >>>> >>>> 0xFFFFFF is considered as maximum link metric and a link having >>>> >>>> this metric value MUST be used during Flex-algorithm calculations >>>> >>>> as a last resort link as described in sec 15.3 of RFC[9350] >>>> >>>> >>>> >>>> KT> Thanks - that works. Perhaps also clarify that to make the link >>>> unusable by FlexAlgo using that generic metric, the advertisement of the >>>> particular generic metric can be skipped. >>>> >>>> <SH2> ok >>>> >>>> >>>> >>>> >>>> >>>> 2) This comment is specific to OSPF given the encoding differences it >>>> has with ISIS. Section 2.2 allows for Generic Metric TLV to be used in too >>>> many places without clear specification of what it is used for - this is a >>>> potential pitfall for interop issues. RFC9492 provides helpful directions >>>> for us here. >>>> >>>> a) This draft specifies FlexAlgo extensions, it is natural that Generic >>>> Metric be advertised under ASLA TLV. No issues here. >>>> >>>> b) This draft does not specify anything about use of generic metric in >>>> base OSPF and as a reminder there is nothing like L-bit in OSPF encoding. >>>> Therefore, it does not make sense to advertise Generic Metric outside of >>>> ASLA and under the OSPFv2 Extended Link TLV or OSPFv3 Router Link TLV. >>>> >>>> c) This draft does not specify anything about use of generic metric >>>> with RSVP-TE/GMPLS. Therefore, it does not make sense to advertise Generic >>>> Metric in the TE Opaque LSAs. >>>> >>>> We can have specific documents that introduce (b) or (c) when there is >>>> a proper specification. >>>> >>>> <SH> Generic metric is a link attribute and can be used by other >>>> applications apart from Flex-algo. >>>> >>>> I don’t see a reason to not take code-points under other applicable >>>> LSAs. >>>> >>>> >>>> >>>> KT> I disagree on this one. There is a reason why what is proposed in >>>> the draft for ISIS is OK - due to the L-bit in ASLA, we need codepoints >>>> both under ASLA and at the top level for FlexAlgo. There is no L-bit in >>>> OSPF and therefore this does not apply. The code-points can be allocated >>>> when the behavior is specified for those other LSAs and applications >>>> (beyond FlexAlgo) in OSPF. We should not set the precedent for allocating >>>> code-points for TLVs without any defined use or behavior. >>>> >>>> >>>> >>>> <SH2> Early code points are taken and implementations underway for >>>> other applications. >>>> >>>> >>>> >>>> “Implementations MUST support sending and receiving generic metric >>>> >>>> sub-TLV in ASLA encodings as well as in the TLV 22/extended link >>>> LSA/TE-LSAs. >>>> >>>> The usage of a generic metric by an individual application is subject >>>> to the same >>>> >>>> rules that apply to other link attributes defined in respective >>>> standards.” >>>> >>>> >>>> >>>> The above text clarifies the use of generic metric by individual >>>> application. >>>> >>>> >>>> >>>> KT2> I am not sure this is sufficient. Let us take an example. How is >>>> the Generic Metric TLV received in OSPFv2 TE Opaque LSA handled and what is >>>> it used for? >>>> >>>> >>>> >>>> >>>> >>>> 3) Please introduce a reserved field to pad the OSPF FAEMD sub-TLV to a >>>> 4 octet boundary as is the convention in OSPF - >>>> https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-3.2.2 >>>> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*section-3.2.2__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmunYcymQgw$> >>>> >>>> <SH> OK >>>> >>>> >>>> >>>> KT> Thanks. >>>> >>>> >>>> >>>> >>>> >>>> 4) In section 3.2.2 there is the following text for OSPF. Could you >>>> please use the TLV/sub-TLV name? OSPF folks are not good at remembering >>>> numbers ;-) >>>> >>>> >>>> >>>> The Min Unidirectional Link Delay as advertised by *sub-sub-TLV 12* of >>>> ASLA sub-TLV [RFC8920 >>>> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC8920__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmun5uDKc7A$>], >>>> MUST be compared against the Maximum delay advertised in the FAEMD sub-TLV. >>>> >>>> <SH> changed to “The Unidirectional Link Delay as advertised by >>>> *sub-sub-TLV >>>> 12”* >>>> >>>> >>>> >>>> KT> Perhaps my comment was not clear. The following text would be more >>>> accurate: >>>> >>>> >>>> >>>> The Min Delay value advertised via the Min/Max Unidirectional Link >>>> Delay sub-TLV [RFC7471] of the ASLA sub-TLV [RFC8920 >>>> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC8920__;Iw!!NEt6yMaO-gk!HoQCxz15c5OoUVXjpmPpCU0N94Ex0cMuET6hFT8l6FE_kNkB58lpI-LSmXBUJvY4IdViL2mzTjVwvp4nyibk3A$>], >>>> MUST be compared against the Maximum delay advertised in the FAEMD sub-TLV. >>>> >>>> <SH2> I think there is a misunderstanding here. You are proposing to >>>> use sub-tlv 13 where as the text in the draft clearly proposes to use >>>> sub-tlv 12. This probably justifies why it is important to specify sub-tlv >>>> number >>>> >>>> And not just name. >>>> >>>> >>>> >>>> KT2> Well, that is what I am also trying to point out ... that the >>>> draft is wrong :-) The one to use is 13 - please check below and let me >>>> know if I am missing something. I also urge you to stick to using OSPF >>>> conventions of using TLV names as opposed to the ISIS convention of using >>>> TLV numbers. >>>> >>>> >>>> >>>> Refer: https://www.rfc-editor.org/rfc/rfc9350.html#section-5.2 >>>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*section-5.2__;Iw!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvQO78JKxQ$> >>>> ... look for IGP metric type 1 >>>> >>>> And then: https://www.rfc-editor.org/rfc/rfc7471#section-4.2 >>>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7471*section-4.2__;Iw!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvSIQb9eeQ$> >>>> and https://www.rfc-editor.org/rfc/rfc8920.html#section-14.1 >>>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8920.html*section-14.1__;Iw!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvRWLiM03A$> >>>> >>>> 12 >>>> >>>> Unidirectional Link Delay >>>> >>>> Y >>>> >>>> [RFC9492 >>>> <https://urldefense.com/v3/__https:/www.iana.org/go/rfc9492__;!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvT7cfK2pA$> >>>> ] >>>> >>>> 13 >>>> >>>> Min/Max Unidirectional Link Delay >>>> >>>> Y >>>> >>>> [RFC9492 >>>> <https://urldefense.com/v3/__https:/www.iana.org/go/rfc9492__;!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvT7cfK2pA$> >>>> ] >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 5) Do we want to call out that the reference bandwidth approach >>>> requires a router to compute and maintain a per link per algo bandwidth >>>> metric for every link in that algo topology. It may not be very obvious to >>>> some. >>>> >>>> <SH> updated as below >>>> >>>> “Advertising >>>> >>>> the reference bandwidth in the FAD constraints allows the metric >>>> >>>> computation to be done on every node for each link. >>>> >>>> The metric is computed using reference bandwidth and the advertised >>>> link bandwidth. >>>> >>>> Centralized control of this >>>> >>>> reference bandwidth simplifies management in the case that the >>>> >>>> reference bandwidth changes” >>>> >>>> >>>> >>>> KT> The above text is not really needed IMHO. My point was more about >>>> the implementation detail - for the flexalgo computation, we need to >>>> maintain this info on a per link per algo topology basis in the link-state >>>> data store used for path computation. I will leave it to the authors if >>>> this is needed or is obviously clear to implementers. >>>> >>>> <SH2> I don’t see the need to add implementation specific details. >>>> >>>> >>>> >>>> KT2> OK - I leave it to you. >>>> >>>> >>>> >>>> >>>> >>>> 6) There are a lot of procedures which are common to both OSPF and ISIS >>>> and are repeated in each section instead of a common section. It would be >>>> easier (and avoid errors) if there was some consolidation. >>>> https://www.rfc-editor.org/rfc/rfc9350.html#section-5 >>>> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*section-5__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumpoQRYAA$> >>>> provides a good reference for such an organization of text. >>>> >>>> <SH> There is repetition in some cases but its not much so it seems to >>>> me leaving it as is for clarity may be better. >>>> >>>> >>>> >>>> KT> This is an editorial comment so I leave it to the authors. My >>>> concern is that great care/diligence is required through the rest of the >>>> publication process to ensure that when anything is changed or updated for >>>> one IGP, it is done appropriately for the other as well - it may be >>>> copy/paste case when the change is IGP agnostic but may need careful >>>> consideration when related to the specific IGP mechanics. >>>> >>>> >>>> >>>> >>>> >>>> 7) Regarding >>>> https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-6 >>>> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*section-6__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumnzxX7UA$>, >>>> it seems like we want to retain a numbering ordering of rules/sequence for >>>> flex-algo as extension documents are introduced. Am I correct? If so, then >>>> this document should formally "update" RFC9350 since it is changing the >>>> "set of rules/sequence" for FlexAlgo computations. Further such extensions >>>> will also need to keep updating the base spec similarly. I would suggest >>>> that a full set of rules that is a union of what is in RFC9350 and rules >>>> added by this draft are maintained in an Appendix section. Other documents >>>> in the future can similarly maintain the latest set of rules. >>>> >>>> <SH> This draft is adding 2 new rules at the end of existing rules. Its >>>> not modifying or changing the order. >>>> >>>> I don’t see what value it is going to add by repeating the set of rules >>>> in Appendix. >>>> >>>> >>>> >>>> KT> What happens when another FlexAlgo document adds more rules? What >>>> happens when some FlexAlgo document wants to insert rules in the middle of >>>> existing ones instead of appending at the end? My point is that if there is >>>> a desire to establish a "live" set of rules in specific orders, then we >>>> need to leave a trail of document "updates" on the base FlexAlgo that one >>>> can refer to know how these "live set of rules" are getting "updated" by >>>> this and future documents. I am thinking of this on lines similar to an >>>> update for an FSM. >>>> >>>> <SH2> It’s a matter of choice. For ex RFC 8029 >>>> >>>> Has so many updates to the Rules but each update only lists >>>> the changes. >>>> >>>> >>>> >>>> KT2> I am not sure I follow and it would help if you can perhaps give >>>> an example. >>>> >>>> >>>> >>>> I am fine with whatever WG decides to do. >>>> >>>> I want to hear if anyone in WG has an opinion on adding >>>> Appendix. >>>> >>>> >>>> >>>> KT2> Sure. My point is that this seems like an ordered set of rules >>>> that are being updated by multiple documents (more to come). How does one >>>> keep track of the "current" set of rules without some trail or each new(er) >>>> document capturing the "latest" set? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Ketan >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Ketan >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 8) Please fix idnits warnings - some are related to obsolete references >>>> while others are related to formatting. There are also some >>>> spelling/grammar errors. >>>> >>>> <SH> ok >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Ketan >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Feb 20, 2024 at 3:56 AM Acee Lindem <[email protected]> >>>> wrote: >>>> >>>> >>>> This starts the Working Group Last call for >>>> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm >>>> enhancements described in the document have been implemented. >>>> >>>> Please send your support or objection to this before March 5th, 2024. >>>> >>>> Thanks, >>>> Acee >>>> _______________________________________________ >>>> Lsr mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lsr >>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmukG-EHJRw$> >>>> >>>> _______________________________________________ >>> Lsr mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> >>> _______________________________________________ >>> Lsr mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> >>> _______________________________________________ >> Lsr mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> >>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
