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. Thanks, Acee > > Thanks, > Ketan > > > On Thu, May 16, 2024 at 2:56 PM Shraddha Hegde <shrad...@juniper.net > <mailto: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 >> <mailto:ketant.i...@gmail.com>> >> Sent: Saturday, April 27, 2024 11:44 AM >> To: Shraddha Hegde <shrad...@juniper.net <mailto:shrad...@juniper.net>> >> Cc: Acee Lindem <acee.lin...@gmail.com <mailto:acee.lin...@gmail.com>>; lsr >> <lsr@ietf.org <mailto:lsr@ietf.org>>; >> draft-ietf-lsr-flex-algo-bw-...@ietf.org >> <mailto: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 >> <mailto:shrad...@juniper.net>> wrote: >> >> Hi Ketan, >> >> >> >> Thanks for reply. >> >> Pls see inline.. >> >> >> >> >> >> Juniper Business Use Only >> >> From: Ketan Talaulikar <ketant.i...@gmail.com >> <mailto:ketant.i...@gmail.com>> >> Sent: Monday, April 8, 2024 2:25 PM >> To: Shraddha Hegde <shrad...@juniper.net <mailto:shrad...@juniper.net>> >> Cc: Acee Lindem <acee.lin...@gmail.com <mailto:acee.lin...@gmail.com>>; lsr >> <lsr@ietf.org <mailto:lsr@ietf.org>>; >> draft-ietf-lsr-flex-algo-bw-...@ietf.org >> <mailto: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 >> <mailto: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 >> <mailto:ketant.i...@gmail.com>> >> Sent: Thursday, March 21, 2024 10:07 PM >> To: Acee Lindem <acee.lin...@gmail.com <mailto:acee.lin...@gmail.com>> >> Cc: lsr <lsr@ietf.org <mailto:lsr@ietf.org>>; >> draft-ietf-lsr-flex-algo-bw-...@ietf.org >> <mailto: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 >> <mailto: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 <mailto: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
