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. 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. 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 <acee.lin...@gmail.com> wrote: > > > On May 17, 2024, at 17:14, Acee Lindem <acee.lin...@gmail.com> wrote: > > Hi Ketan, Shraddha, > > On May 17, 2024, at 07:22, Ketan Talaulikar <ketant.i...@gmail.com> 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 <shrad...@juniper.net> > 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 <ketant.i...@gmail.com> >> *Sent:* Saturday, April 27, 2024 11:44 AM >> *To:* Shraddha Hegde <shrad...@juniper.net> >> *Cc:* Acee Lindem <acee.lin...@gmail.com>; lsr <lsr@ietf.org>; >> draft-ietf-lsr-flex-algo-bw-...@ietf.org >> *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 <shrad...@juniper.net> >> wrote: >> >> Hi Ketan, >> >> >> >> Thanks for reply. >> >> Pls see inline.. >> >> >> >> >> >> Juniper Business Use Only >> >> *From:* Ketan Talaulikar <ketant.i...@gmail.com> >> *Sent:* Monday, April 8, 2024 2:25 PM >> *To:* Shraddha Hegde <shrad...@juniper.net> >> *Cc:* Acee Lindem <acee.lin...@gmail.com>; lsr <lsr@ietf.org>; >> draft-ietf-lsr-flex-algo-bw-...@ietf.org >> *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 <shrad...@juniper.net> >> wrote: >> >> Hi Ketan, >> >> >> >> Thanks for the review and comments. >> >> Pls see inline for replies. >> >> >> >> >> >> Juniper Business Use Only >> >> *From:* Ketan Talaulikar <ketant.i...@gmail.com> >> *Sent:* Thursday, March 21, 2024 10:07 PM >> *To:* Acee Lindem <acee.lin...@gmail.com> >> *Cc:* lsr <lsr@ietf.org>; draft-ietf-lsr-flex-algo-bw-...@ietf.org >> *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 <acee.lin...@gmail.com> >> 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 >> Lsr@ietf.org >> 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 -- lsr@ietf.org > To unsubscribe send an email to lsr-le...@ietf.org > > > _______________________________________________ > Lsr mailing list -- lsr@ietf.org > To unsubscribe send an email to lsr-le...@ietf.org > > >
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
