Hi Ketan, All, Thanks for confirming - I also had concluded that it was resolved when you guys converged on the text.
Thanks, Acee > On Sep 27, 2024, at 12:16, Ketan Talaulikar <[email protected]> wrote: > > Hi Acee/All, > > There was no passive debate intended and the discussion on usage for TE was > settled. That text section was about ASLA and hence suggested ASLA specs. > > I think we are good here and the doc has already been sent to IESG as well. > > Thanks, > Ketan > > > On Mon, Sep 2, 2024 at 4:56 PM Acee Lindem <[email protected] > <mailto:[email protected]>> wrote: >> Hi Shraddha, >> >>> On Sep 1, 2024, at 23:43, Shraddha Hegde >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Acee, >>> >>> >>> Are we still debating whether generic metric is applicable to OSPF TE LSAs. >>> I thought we had closed on the topic and the code points taken a while ago. >> >> Yes - there is “passive” debate in that Ketan’s suggested text doesn’t >> include the OSPF TE LSAs. >> >> I thought it was resolved as well. >> >> Thanks, >> Acee >> >> >>> >>> OR >>> >>> Are you suggesting to qualify the RFC 3630 and RFC 5305 with TE >>> applications as below? >>> >>> " >>> The usage of a generic metric by an individual application is subject to >>> the same rules that apply to other link attributes as defined in [RFC9479] >>> [RFC9492] [RFC9350] and to TE applications as defined in [RFC3630] >>> [RFC5305]" >> >> >> >>> >>> Rgds >>> Shraddha >>> >>> >>> Juniper Business Use Only >>> -----Original Message----- >>> From: Acee Lindem <[email protected] <mailto:[email protected]>> >>> Sent: Saturday, August 31, 2024 12:31 AM >>> To: Les Ginsberg (ginsberg) <[email protected] >>> <mailto:[email protected]>> >>> Cc: Shraddha Hegde <[email protected] <mailto:[email protected]>>; >>> Ketan Talaulikar <[email protected] <mailto:[email protected]>>; >>> lsr <[email protected] <mailto:[email protected]>>; >>> [email protected] >>> <mailto:[email protected]> >>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: >>> Bandwidth, Delay, Metrics and Constraints" - >>> draft-ietf-lsr-flex-algo-bw-con-07 >>> >>> [External Email. Be cautious of content] >>> >>> >>> Les - >>> As document shepherd, I'm trying to advance the document by facilitating >>> discussion of the pro and cons of generic metric applicability to OSPF TE >>> LSAs. >>> I don't feel that strongly one way or another (as long as TE LSAs are not >>> used for non-TE applications). Hence, my input to the WG is to dispense >>> with the passive proposal of competing text and discuss the remaining >>> generic metric question - "To TE or not to TE." >>> >>> Acee >>> >>>> On Aug 30, 2024, at 1:24 PM, Les Ginsberg (ginsberg) >>>> <[email protected] <mailto:[email protected]>> >>>> wrote: >>>> >>>> Acee – >>>> The references to RFC 3630 (and RFC 5305) are not new (though some >>>> editorial changes were made). >>>> I for one would appreciate it more if you could provide input rather >>>> solicit it. >>>> Les >>>> From: Acee Lindem <[email protected] <mailto:[email protected]>> >>>> Sent: Friday, August 30, 2024 9:59 AM >>>> To: Les Ginsberg (ginsberg) <[email protected] >>>> <mailto:[email protected]>> >>>> Cc: Shraddha Hegde <[email protected] <mailto:[email protected]>>; >>>> Ketan Talaulikar >>>> <[email protected] <mailto:[email protected]>>; lsr <[email protected] >>>> <mailto:[email protected]>>; >>>> [email protected] >>>> <mailto:[email protected]> >>>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: >>>> Bandwidth, Delay, Metrics and Constraints" - >>>> draft-ietf-lsr-flex-algo-bw-con-07 >>>> What I’m trying to do is solicit direct discussion on the generic metric >>>> applicability in the OSPF TE LSAs rather than further alternate text >>>> proposals. >>>> Thanks, >>>> Acee >>>> >>>> >>>> On Aug 30, 2024, at 11:53, Les Ginsberg (ginsberg) >>>> <[email protected] <mailto:[email protected]>> >>>> wrote: >>>> I think the problematic text is in Section 2 final paragraph: >>>> It now reads: >>>> “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 as defined in [RFC3630], >>>> [RFC5305], [RFC9479], [RFC9492] and [RFC9350].” >>>> What was suggested was: >>>> “The usage of a generic metric by an individual application is subject to >>>> the same rules that apply to other link attributes as defined in [RFC9479] >>>> [RFC9492] [RFC9350].” >>>> The problem with the revised text is that the paragraph is specifically >>>> talking about ASLA use cases, but the set of RFCs referenced includes >>>> documents which have nothing to do with ASLA. >>>> I would suggest that the draft be revised to follow Ketan’s original >>>> suggestion. >>>> Les >>>> From: Acee Lindem <[email protected] <mailto:[email protected]>> >>>> Sent: Friday, August 30, 2024 8:34 AM >>>> To: Shraddha Hegde <[email protected] >>>> <mailto:[email protected]>> >>>> Cc: Ketan Talaulikar <[email protected] >>>> <mailto:[email protected]>>; lsr <[email protected] <mailto:[email protected]>>; >>>> [email protected] >>>> <mailto:[email protected]> >>>> Subject: [Lsr] Re: Working Group Last Call for "Flexible Algorithms: >>>> Bandwidth, Delay, Metrics and Constraints" - >>>> draft-ietf-lsr-flex-algo-bw-con-07 >>>> Hi Shraddha, Ketan, >>>> I see the new text also includes RFC 3630 and RFC 5305 generic metric >>>> applicability. Does everyone agree on this? If not, we should discuss the >>>> pros and cons. >>>> Thanks, >>>> Acee >>>> >>>> >>>> >>>> On Aug 30, 2024, at 01:20, Shraddha Hegde >>>> <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi Ketan, >>>> Thanks for the text. Will incorporate in ver-13 Rgds Shraddha >>>> Juniper Business Use Only >>>> From: Ketan Talaulikar <[email protected] >>>> <mailto:[email protected]>> >>>> Sent: Wednesday, July 31, 2024 12:01 AM >>>> To: Shraddha Hegde <[email protected] <mailto:[email protected]>> >>>> Cc: Acee Lindem <[email protected] <mailto:[email protected]>>; >>>> lsr <[email protected] <mailto:[email protected]>>; >>>> [email protected] >>>> <mailto:[email protected]> >>>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: >>>> Bandwidth, Delay, Metrics and Constraints" - >>>> draft-ietf-lsr-flex-algo-bw-con-07 >>>> [External Email. Be cautious of content] Hi Shraddha, After >>>> discussing further on this topic during the IETF with some WG members, I >>>> see that most of this is covered by existing RFCs and we only need to >>>> reference them. Please find below the suggested text changes that also fix >>>> some other issues that I found during the closer review of the LSAs. >>>> Section 2 >>>> OLD >>>> 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. >>>> NEW >>>> The usage of a generic metric by an individual application is subject to >>>> the same rules that apply to other link attributes as defined in [RFC9479] >>>> [RFC9492] [RFC9350]. >>>> [Rationale: This change references existing specifications for >>>> alignment.] Section 2.2 OLD >>>> • sub-TLV of the OSPF Link TLV of OSPF extended Link LSA [RFC7684]. >>>> • sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630]. >>>> • sub-TLV of the Router-Link TLV in the E-Router-LSA in OSPFv3 >>>> [RFC8362]. >>>> • sub-sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV >>>> [RFC9492]. >>>> NEW >>>> • sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630]. >>>> • sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA [RFC5392]. >>>> • sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA [RFC5329]. >>>> • sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA [RFC5392]. >>>> • sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV >>>> [RFC9492] of the OSPFv2 Extended Link TLV [RFC7684]. >>>> • sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV >>>> [RFC9492] of the OSPFv3 Router-Link TLV [RFC8362]. >>>> [Rationale: There is no application using advertisements as top-level >>>> sub-TLVs (i.e., outside ASLA) in the OSPFv2 Extended Link TLV or the >>>> OSPFv3 Router Link TLV – therefore we need to remove them. Added the >>>> OSPFv3 LSA for RSVP-TE and also for Inter-AS TE links as done for ISIS. >>>> Clarified for the ASLA advertisements in OSPFv2 and v3 separately. >>>> Finally, using alphabetical bullets to make it easier to reference in >>>> further text (same may help for ISIS section as well).] Section 2.2 OLD >>>> The Generic Metric sub-TLV MAY be advertised multiple times. For a >>>> particular metric type, the Generic Metric sub-TLV MUST be advertised only >>>> once for a link when advertised in the OSPF Link TLV of Extended Link LSA, >>>> the Link TLV of TE LSA and the sub-TLV of the Router-Link TLV in the >>>> E-Router-LSA Router-Link TLV in OSPFv3. When Generic Metric sub-TLV is >>>> advertised as sub-sub-TLV of ASLA, it MUST be advertised only once >>>> per-application for a link. If there are multiple Generic Metric sub-TLVs >>>> advertised for a link for the same metric type in a received LSA, the >>>> first instance MUST be used and the subsequent instances MUST be ignored. >>>> NEW >>>> The Generic Metric sub-TLV MAY be advertised multiple times. For a >>>> particular metric type, the Generic Metric sub-TLV MUST be advertised only >>>> once for a link when advertised as (a) through (d) above. When Generic >>>> metric sub-TLV is advertised in ASLA, each metric type MUST be advertised >>>> only once per-application for a link. If there are multiple Generic Metric >>>> sub-TLVs advertised for a link for the same metric type (and same >>>> application in case of ASLA) in one or more received LSAs, advertisement >>>> in the lowest numbered LSA MUST be used and the subsequent instances MUST >>>> be ignored. >>>> [Rationale: Alignment with ISIS text.] >>>> Thanks, >>>> Ketan >>>> On Wed, Jul 24, 2024 at 9:20 PM Shraddha Hegde <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi Ketan, >>>> Here is the proposed text >>>> “Generic Metric is a link attribute appears in various TLVs as >>>> described in the beginning of this section. >>>> For Flex-algorithm purposes the use of Generic Metric sub-TLV is >>>> governed by the rules defined in sec 12 of <xref target ='RFC9350'/>. >>>> For applications such as RSVP-TE when used in packet networks and in >>>> GMPLS , Generic Metric is used from TE Link TLV of the OSPF TE LSA <xref >>>> target ='RFC3630'/> >>>> as described in sec 4 of <xref target ='RFC9492'/>. >>>> For applications such as SR Policy <xref target ='RFC9652'/>, Generic >>>> metric >>>> may be used from TE Link TLV of the OSPF TE LSA <xref target ='RFC3630'/> >>>> as specified in sec 12.1 of <xref target ='RFC9492'/>” >>>> Let me know if that works for you. >>>> Rgds >>>> Shraddha >>>> Juniper Business Use Only >>>> From: Ketan Talaulikar <[email protected] >>>> <mailto:[email protected]>> >>>> Sent: Tuesday, July 23, 2024 11:29 PM >>>> To: Acee Lindem <[email protected] <mailto:[email protected]>> >>>> Cc: Shraddha Hegde <[email protected] <mailto:[email protected]>>; >>>> lsr <[email protected] <mailto:[email protected]>>; >>>> [email protected] >>>> <mailto:[email protected]> >>>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: >>>> Bandwidth, Delay, Metrics and Constraints" - >>>> draft-ietf-lsr-flex-algo-bw-con-07 >>>> [External Email. Be cautious of content] Hello Shraddha/Authors, >>>> Checking to see if we can conclude on the text to be added/updated to >>>> cover the advertisement and usage for applications other than FlexAlgo >>>> like RSVP-TE and SR Policy. >>>> Thanks, >>>> Ketan >>>> On Mon, May 27, 2024 at 8:27 AM Ketan Talaulikar <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi Acee, >>>> Please check inline below for responses. >>>> On Thu, May 23, 2024 at 1:58 AM Acee Lindem <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Ketan, >>>> First of all, the have been early allocations for over almost 2 years now >>>> and it isn’t very timely to object at the end of WG last call. However, I >>>> think your concerns can easily be satisfied. >>>> KT> It is only at WGLC that the authors have indicated that the draft is >>>> "complete" and therefore the WGLC seems the time for me to object that it >>>> isn't complete? I agree that my concerns can be easily satisfied with >>>> additional text - I've shared the suggestions for the same as well. >>>> On May 21, 2024, at 12:18, Ketan Talaulikar <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi Acee, >>>> You seem to have misunderstood my concern. I am not asking for >>>> specification of the RSVP-TE CSPF algorithm/computation using Generic >>>> Metric. >>>> Let me clarify my objections. There are 3 ways in which Generic Metric can >>>> be advertised for OSPFv2 as stated in this draft: >>>> 1) As a sub-TLV of the ASLA sub-TLV in the OSPFv2 Extended Link LSA : For >>>> FlexAlgo usage this is the one and only one way to advertise Generic >>>> Metric in OSPFv2 (note there is no L-bit in OSPF for ASLA). RFC 9492 >>>> (ASLA) allows for this to be used for other applications beyond FlexAlgo. >>>> I would like this draft to clarify if it is defining Generic Metric use >>>> for any application other than FlexAlgo under ASLA - see further in my >>>> email. >>>> 2) As a top-level sub-TLV of the OSPFv2 Extended Link TLV in the OSPFv2 >>>> Extended Link LSA : This document is making allocation in this namespace >>>> but that is not an issue since the namespace is shared with ASLA. However, >>>> the draft needs to clarify that it is not defining Generic Metric use for >>>> any application when advertised this way as it is not used in base OSPF >>>> route calculation. >>>> So, basically 1 and 2 are the same and equates to “Generic metric usage >>>> for applications other than flex algorithm is out of scope. Future >>>> documents may describe usage.” >>>> KT> Sure, that was the "easy" option that I had initially suggested. >>>> However, Shraddha mentioned that she is aware of ongoing/existing >>>> implementations and that is why I am instead suggesting that we add some >>>> text to cover those other applications. I don't think it should be very >>>> difficult to incorporate. >>>> 3) As a sub-TLV of the Link TLV in the OSPFv2 TE Opaque LSA : This >>>> document is making an allocation in this namespace but not indicating any >>>> application usage. If the intention is to use this advertisement for >>>> RSVP-TE CSPF, then there is no issue since this is allowed per RFC 9492 >>>> Section 12.3.4. However, the draft must explicitly state that this is the >>>> only way to use it for RSVP-TE application. >>>> I’m looking at RFC 9492 Section 12.1 - why couldn’t the generic metric be >>>> used for the other referenced applications - LFA and SR policy if usage is >>>> described in a future document? Similar to above. >>>> KT> For SR Policy, it is certainly possible. For LFA, I am not sure at >>>> this point other than within FlexAlgo. I would rather prefer that we add >>>> small sections in the current draft that cover RSVP-TE and SR Policy at >>>> least (as suggested). I can provide the text if the authors are OK with >>>> this proposal. >>>> Thanks, >>>> Ketan >>>> Shraddha - can you provide these application scoping statements? >>>> Thanks, >>>> Acee >>>> Now, in addition to the above, there is the SR Policy CSPF computation >>>> application (very similar to RSVP-TE) as well and this draft does not >>>> clarify how Generic Metric is to be advertised for that application. Per >>>> RFC9492, it should be as (1) and not as (2) or (3). >>>> Without this clarification, we are in for interop issues for all >>>> applications other than FlexAlgo. >>>> Finally, the list of points that I shared earlier on this thread is not >>>> about the actual CSPF computation algo, but more about the semantics of >>>> the advertisement itself. >>>> I hope this clarifies why this draft is currently underspecified for >>>> Generic Metric TLV usage for all applications other than FlexAlgo. >>>> Thanks, >>>> Ketan >>>> On Sat, May 18, 2024 at 4:19 AM Acee Lindem <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> On May 17, 2024, at 17:14, Acee Lindem <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi Ketan, Shraddha, >>>> On May 17, 2024, at 07:22, Ketan Talaulikar <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi Shraddha, >>>> Thanks for your response. I believe we now have only one open discussion >>>> point and hence I am top posting my suggestions. >>>> If the authors wish to cover the Generic Metric TLV usage in TE Opaque >>>> LSAs in this document then we will need more text/specification than "All >>>> traditional TE applications like CSPF/RSVP make use of link-attributes >>>> from TE-LSA." >>>> Since the new Generic Metric code point is in this registry - >>>> https://urldefense.com/v3/__https://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml*subtlv2__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1rSq38o1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6FGeDTJ1g$ >>>> I don’t the issue with it being used for TE applications currently >>>> making use of the TE Opaque LSA - we’re still using the OSPF TE Opaque LSA >>>> for traditional TE. Right? >>>> Some suggestions which can be incorporated in a separate section that is >>>> titled "Use of Generic Metric for RSVP-TE": >>>> - specify that Generic Metric TLV usage in TE Opaque LSAs is limited >>>> to RSVP-TE use >>>> - specify the differences for use of bandwidth metric for RSVP-TE; I >>>> assume it is a constant metric value itself since we don't have FAD to >>>> determine the b/w metric >>>> - flex algo prunes links w/o the specific metric advertisements; will it >>>> be the same for RSVP-TE CSPF? >>>> - cover backward compatibility aspects (e.g., what if the computation >>>> needs to optimize on a particular metric and a set of routers/links don't >>>> carry that metric value) I hope this gives an idea of the details >>>> necessary if this document is attempting to cover use of generic metric >>>> for not just flex algo but other applications. If there were any other >>>> applications/usage in mind, it would be good to clarify that explicitly. >>>> We have many different LSAs in OSPF resulting in potential interop issues >>>> if the specifications are not clear. >>>> Perhaps, it should be stated that usage will be specified in future >>>> documents. This could included in the -13 version with Peter’s comments. >>>> On second thought, since RSVP signals the complete path, the TE path >>>> computation typically has not be standardized and I don’t think this is >>>> required. We can move forward with the -13 version with Peter’s comments. >>>> Thanks, >>>> Acee >>>> Thanks, >>>> Acee >>>> Thanks, >>>> Ketan >>>> On Thu, May 16, 2024 at 2:56 PM Shraddha Hegde <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi Ketan, >>>> Snipping to open points >>>> 2) This comment is specific to OSPF given the encoding differences it >>>> has with ISIS. Section 2.2 allows for Generic Metric TLV to be used in too >>>> many places without clear specification of what it is used for - this is a >>>> potential pitfall for interop issues. RFC9492 provides helpful directions >>>> for us here. >>>> a) This draft specifies FlexAlgo extensions, it is natural that Generic >>>> Metric be advertised under ASLA TLV. No issues here. >>>> b) This draft does not specify anything about use of generic metric in >>>> base OSPF and as a reminder there is nothing like L-bit in OSPF encoding. >>>> Therefore, it does not make sense to advertise Generic Metric outside of >>>> ASLA and under the OSPFv2 Extended Link TLV or OSPFv3 Router Link TLV. >>>> c) This draft does not specify anything about use of generic metric with >>>> RSVP-TE/GMPLS. Therefore, it does not make sense to advertise Generic >>>> Metric in the TE Opaque LSAs. >>>> We can have specific documents that introduce (b) or (c) when there is a >>>> proper specification. >>>> <SH> Generic metric is a link attribute and can be used by other >>>> applications apart from Flex-algo. >>>> I don’t see a reason to not take code-points under other applicable LSAs. >>>> KT> I disagree on this one. There is a reason why what is proposed in the >>>> draft for ISIS is OK - due to the L-bit in ASLA, we need codepoints both >>>> under ASLA and at the top level for FlexAlgo. There is no L-bit in OSPF >>>> and therefore this does not apply. The code-points can be allocated when >>>> the behavior is specified for those other LSAs and applications (beyond >>>> FlexAlgo) in OSPF. We should not set the precedent for allocating >>>> code-points for TLVs without any defined use or behavior. >>>> <SH2> Early code points are taken and implementations underway for other >>>> applications. >>>> “Implementations MUST support sending and receiving generic metric >>>> sub-TLV in ASLA encodings as well as in the TLV 22/extended link >>>> LSA/TE-LSAs. >>>> The usage of a generic metric by an individual application is subject >>>> to the same rules that apply to other link attributes defined in >>>> respective standards.” >>>> The above text clarifies the use of generic metric by individual >>>> application. >>>> KT2> I am not sure this is sufficient. Let us take an example. How is the >>>> Generic Metric TLV received in OSPFv2 TE Opaque LSA handled and what is it >>>> used for? >>>> <SH3> The text in the draft says the applications that make use of link >>>> attributes from TE LSA will also use generic metric from TE-LSA. All >>>> traditional TE applications like CSPF/RSVP make use of link-attributes >>>> from TE-LSA. I don’t see the need to say anything beyond what has already >>>> been said in the draft. >>>> The Min Unidirectional Link Delay as advertised by sub-sub-TLV 12 of ASLA >>>> sub-TLV [RFC8920], 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], 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://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9350.htm >>>> l*section-5.2__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1r >>>> Sq38o1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6Fb0HOfOg$ ... look for IGP >>>> metric type 1 And then: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7471*sec >>>> tion-4.2__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1rSq38o >>>> 1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6GnElBzCw$ and >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8920.htm >>>> l*section-14.1__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1 >>>> rSq38o1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6FRzXEUMw$ >>>> 12 Unidirectional Link Delay Y [RFC9492] >>>> 13 Min/Max Unidirectional Link Delay Y [RFC9492] <SH3> Ok I got it. >>>> Will fix in -12 version >>>> 7) Regarding >>>> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*section-6__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1rSq38o1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6GV3tj5Xw$ >>>> , it seems like we want to retain a numbering ordering of rules/sequence >>>> for flex-algo as extension documents are introduced. Am I correct? If so, >>>> then this document should formally "update" RFC9350 since it is changing >>>> the "set of rules/sequence" for FlexAlgo computations. Further such >>>> extensions will also need to keep updating the base spec similarly. I >>>> would suggest that a full set of rules that is a union of what is in >>>> RFC9350 and rules added by this draft are maintained in an Appendix >>>> section. Other documents in the future can similarly maintain the latest >>>> set of rules. >>>> <SH> This draft is adding 2 new rules at the end of existing rules. Its >>>> not modifying or changing the order. >>>> I don’t see what value it is going to add by repeating the set of rules in >>>> Appendix. >>>> KT> What happens when another FlexAlgo document adds more rules? What >>>> happens when some FlexAlgo document wants to insert rules in the middle of >>>> existing ones instead of appending at the end? My point is that if there >>>> is a desire to establish a "live" set of rules in specific orders, then we >>>> need to leave a trail of document "updates" on the base FlexAlgo that one >>>> can refer to know how these "live set of rules" are getting "updated" by >>>> this and future documents. I am thinking of this on lines similar to an >>>> update for an FSM. >>>> <SH2> It’s a matter of choice. For ex RFC 8029 >>>> Has so many updates to the Rules but each update only lists the >>>> changes. >>>> KT2> I am not sure I follow and it would help if you can perhaps give an >>>> example. >>>> I am fine with whatever WG decides to do. >>>> I want to hear if anyone in WG has an opinion on adding >>>> Appendix. >>>> KT2> Sure. My point is that this seems like an ordered set of rules that >>>> are being updated by multiple documents (more to come). How does one keep >>>> track of the "current" set of rules without some trail or each new(er) >>>> document capturing the "latest" set? >>>> <SH3> I don’t see any other opinions on mailing list. Will add appendix in >>>> -12 with full set of rules. >>>> Rgds >>>> Shraddha >>>> Juniper Business Use Only >>>> From: Ketan Talaulikar <[email protected] >>>> <mailto:[email protected]>> >>>> Sent: Saturday, April 27, 2024 11:44 AM >>>> To: Shraddha Hegde <[email protected] <mailto:[email protected]>> >>>> Cc: Acee Lindem <[email protected] <mailto:[email protected]>>; >>>> lsr <[email protected] <mailto:[email protected]>>; >>>> [email protected] >>>> <mailto:[email protected]> >>>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: >>>> Bandwidth, Delay, Metrics and Constraints" - >>>> draft-ietf-lsr-flex-algo-bw-con-07 >>>> [External Email. Be cautious of content] Hi Shraddha, Please check >>>> inline below with KT2. >>>> On Mon, Apr 15, 2024 at 12:16 PM Shraddha Hegde <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi Ketan, >>>> Thanks for reply. >>>> Pls see inline.. >>>> Juniper Business Use Only >>>> From: Ketan Talaulikar <[email protected] >>>> <mailto:[email protected]>> >>>> Sent: Monday, April 8, 2024 2:25 PM >>>> To: Shraddha Hegde <[email protected] <mailto:[email protected]>> >>>> Cc: Acee Lindem <[email protected] <mailto:[email protected]>>; >>>> lsr <[email protected] <mailto:[email protected]>>; >>>> [email protected] >>>> <mailto:[email protected]> >>>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: >>>> Bandwidth, Delay, Metrics and Constraints" - >>>> draft-ietf-lsr-flex-algo-bw-con-07 >>>> [External Email. Be cautious of content] Hi Shraddha, Thanks for >>>> your responses. Please check inline below for clarifications with KT. >>>> On Thu, Apr 4, 2024 at 9:49 AM Shraddha Hegde <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi Ketan, >>>> Thanks for the review and comments. >>>> Pls see inline for replies. >>>> Juniper Business Use Only >>>> From: Ketan Talaulikar <[email protected] >>>> <mailto:[email protected]>> >>>> Sent: Thursday, March 21, 2024 10:07 PM >>>> To: Acee Lindem <[email protected] <mailto:[email protected]>> >>>> Cc: lsr <[email protected] <mailto:[email protected]>>; >>>> [email protected] >>>> <mailto:[email protected]> >>>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: >>>> Bandwidth, Delay, Metrics and Constraints" - >>>> draft-ietf-lsr-flex-algo-bw-con-07 >>>> [External Email. Be cautious of content] Hi All, I have reviewed >>>> this document and believe it needs some further work before publication. >>>> I am sharing my comments below: >>>> 1) There is the following text in sec 2.1 and 2.2 for Generic Metric. >>>> A metric value of 0xFFFFFF is considered as maximum link metric and a link >>>> having this metric value MUST NOT be used during Flex-algorithm >>>> calculations [RFC9350]. 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://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1rSq38o1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6FSgkt6Sw$ >>>> 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://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!C97xg51a >>>> Rs4Qmr-9zJwV-vVuuijMIG0ko-sq1rSq38o1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6 >>>> HkMAY7ww$ >>>> <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], 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], 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://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9350.htm >>>> l*section-5.2__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1r >>>> Sq38o1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6Fb0HOfOg$ ... look for IGP >>>> metric type 1 And then: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7471*sec >>>> tion-4.2__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1rSq38o >>>> 1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6GnElBzCw$ and >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8920.htm >>>> l*section-14.1__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1 >>>> rSq38o1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6FRzXEUMw$ >>>> 12 Unidirectional Link Delay Y [RFC9492] >>>> 13 Min/Max Unidirectional Link Delay Y [RFC9492] >>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9350.html*section-5__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1rSq38o1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6EA172HPw$ >>>> 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://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*section-6__;Iw!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1rSq38o1QPxRN2LCDuwaokekq2DrWukyCtb3iBDfI6GV3tj5Xw$ >>>> , it seems like we want to retain a numbering ordering of rules/sequence >>>> for flex-algo as extension documents are introduced. Am I correct? If so, >>>> then this document should formally "update" RFC9350 since it is changing >>>> the "set of rules/sequence" for FlexAlgo computations. Further such >>>> extensions will also need to keep updating the base spec similarly. I >>>> would suggest that a full set of rules that is a union of what is in >>>> RFC9350 and rules added by this draft are maintained in an Appendix >>>> section. Other documents in the future can similarly maintain the latest >>>> set of rules. >>>> <SH> This draft is adding 2 new rules at the end of existing rules. Its >>>> not modifying or changing the order. >>>> I don’t see what value it is going to add by repeating the set of rules in >>>> Appendix. >>>> KT> What happens when another FlexAlgo document adds more rules? What >>>> happens when some FlexAlgo document wants to insert rules in the middle of >>>> existing ones instead of appending at the end? My point is that if there >>>> is a desire to establish a "live" set of rules in specific orders, then we >>>> need to leave a trail of document "updates" on the base FlexAlgo that one >>>> can refer to know how these "live set of rules" are getting "updated" by >>>> this and future documents. I am thinking of this on lines similar to an >>>> update for an FSM. >>>> <SH2> It’s a matter of choice. For ex RFC 8029 >>>> Has so many updates to the Rules but each update only lists the >>>> changes. >>>> KT2> I am not sure I follow and it would help if you can perhaps give an >>>> example. >>>> I am fine with whatever WG decides to do. >>>> I want to hear if anyone in WG has an opinion on adding >>>> Appendix. >>>> KT2> Sure. My point is that this seems like an ordered set of rules that >>>> are being updated by multiple documents (more to come). How does one keep >>>> track of the "current" set of rules without some trail or each new(er) >>>> document capturing the "latest" set? >>>> Thanks, >>>> Ketan >>>> Thanks, >>>> Ketan >>>> 8) Please fix idnits warnings - some are related to obsolete references >>>> while others are related to formatting. There are also some >>>> spelling/grammar errors. >>>> <SH> ok >>>> Thanks, >>>> Ketan >>>> On Tue, Feb 20, 2024 at 3:56 AM Acee Lindem <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> This starts the Working Group Last call for >>>> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm >>>> enhancements described in the document have been implemented. >>>> >>>> Please send your support or objection to this before March 5th, 2024. >>>> >>>> Thanks, >>>> Acee >>>> _______________________________________________ >>>> Lsr mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ >>>> _;!!NEt6yMaO-gk!C97xg51aRs4Qmr-9zJwV-vVuuijMIG0ko-sq1rSq38o1QPxRN2LCDu >>>> waokekq2DrWukyCtb3iBDfI6H6Mq4QsA$ >>>> _______________________________________________ >>>> Lsr mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >>>> _______________________________________________ >>>> Lsr mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >>>> _______________________________________________ >>>> Lsr mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >>>> _______________________________________________ >>>> Lsr mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >>>> _______________________________________________ >>>> Lsr mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >>>> _______________________________________________ >>>> Lsr mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >>> >>> >>> >>> _______________________________________________ >>> Lsr mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
