Hi Ketan, Shraddha, > On Apr 27, 2024, at 02:16, Ketan Talaulikar <ketant.i...@gmail.com> wrote: > > Hi Acee, > > I've responded to the thread with Shraddha. There are still 3 issues open - > (1) an error with TLV reference, (2) a codepoint allocation being done > without specification, and (3) regarding the updates to FlexAlgo rules. > > You have asked me about (2). There is no issue with Generic Metric codepoint > allocation as a sub-TLV for OSPFv2 Extended Link TLV (which also includes as > a sub-TLV of ASLA TLV) - its use for FlexAlgo is fully specified in this > document. My objection is to allocation for OSPFv2 TE Opaque LSA without any > specification being done on how it is used. I am just asking to leave that > out to a document that actually specifies the usage and let this draft > progress towards publication.
I agree - this should be removed for the OSPFv2 TE Opaque LSA. Shraddha - can you remove this - at least until usage is specified in a separate document. Thanks, Acee > > Hope that clarifies. > > Thanks, > Ketan > > On Fri, Apr 26, 2024 at 9:23 PM Acee Lindem <acee.lin...@gmail.com > <mailto:acee.lin...@gmail.com>> wrote: >> Hi Ketan, Shraddha and Les, >> >> >> I’m trying to conclude this thread and send this document to the AD. I’ve >> read the Emails but I must admit I don’t understand all the arguments. >> >> >> Ketan - if we have the generic-metric in IS-IS, why wouldn’t define it in >> OSPF as well? If you cannot provide a compelling argument, I ‘m going to >> request publication of the document send it to the actual LSR AD. >> >> Shraddha - I see that you included similar text in section 4.3.1 to address >> Les’s comment. I guess the example referring to Flex algo 128/129 is not >> needed. >> >> Les - I’m sure what the I-bit but I don’t see that adding it at this >> juncture is a good idea unless the described protocol enhancements don’t >> work without it. >> >> Thanks, >> Acee >> >> >> >>> On Apr 15, 2024, at 02:46, Shraddha Hegde >>> <shraddha=40juniper....@dmarc.ietf.org >>> <mailto:40juniper....@dmarc.ietf.org>> 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. >>> >>> >>> >>> 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. >>> >>> >>> >>> >>> >>> 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. >>> >>> >>> >>> >>> >>> 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. >>> >>> I am fine with whatever WG decides to do. >>> >>> I want to hear if anyone in WG has an opinion on adding >>> Appendix. >>> >>> >>> >>> 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> >>> https://www.ietf.org/mailman/listinfo/lsr >> > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
