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.
> On May 21, 2024, at 12:18, Ketan Talaulikar <ketant.i...@gmail.com> 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.” > > 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. 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 <acee.lin...@gmail.com > <mailto:acee.lin...@gmail.com>> wrote: >> >> >>> On May 17, 2024, at 17:14, Acee Lindem <acee.lin...@gmail.com >>> <mailto:acee.lin...@gmail.com>> wrote: >>> >>> Hi Ketan, Shraddha, >>> >>>> On May 17, 2024, at 07:22, Ketan Talaulikar <ketant.i...@gmail.com >>>> <mailto: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 >>>> <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 <mailto:lsr@ietf.org> >>>> To unsubscribe send an email to lsr-le...@ietf.org >>>> <mailto:lsr-le...@ietf.org> >>> >>> _______________________________________________ >>> Lsr mailing list -- lsr@ietf.org <mailto:lsr@ietf.org> >>> To unsubscribe send an email to lsr-le...@ietf.org >>> <mailto: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
