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]> 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]> > Sent: Friday, August 30, 2024 9:59 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Shraddha Hegde <[email protected]>; Ketan Talaulikar > <[email protected]>; lsr <[email protected]>; > [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]> 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]> > Sent: Friday, August 30, 2024 8:34 AM > To: Shraddha Hegde <[email protected]> > Cc: Ketan Talaulikar <[email protected]>; lsr <[email protected]>; > [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]> wrote: > Hi Ketan, > Thanks for the text. Will incorporate in ver-13 > Rgds > Shraddha > Juniper Business Use Only > From: Ketan Talaulikar <[email protected]> > Sent: Wednesday, July 31, 2024 12:01 AM > To: Shraddha Hegde <[email protected]> > Cc: Acee Lindem <[email protected]>; lsr <[email protected]>; > [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]> 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]> > Sent: Tuesday, July 23, 2024 11:29 PM > To: Acee Lindem <[email protected]> > Cc: Shraddha Hegde <[email protected]>; lsr <[email protected]>; > [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]> > wrote: > Hi Acee, > Please check inline below for responses. > On Thu, May 23, 2024 at 1:58 AM Acee Lindem <[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]> 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]> wrote: > On May 17, 2024, at 17:14, Acee Lindem <[email protected]> wrote: > Hi Ketan, Shraddha, > On May 17, 2024, at 07:22, Ketan Talaulikar <[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://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 <[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://www.rfc-editor.org/rfc/rfc9350.html#section-5.2 ... look for > IGP metric type 1 > And then: https://www.rfc-editor.org/rfc/rfc7471#section-4.2 and > https://www.rfc-editor.org/rfc/rfc8920.html#section-14.1 > 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://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-6, > 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]> > Sent: Saturday, April 27, 2024 11:44 AM > To: Shraddha Hegde <[email protected]> > Cc: Acee Lindem <[email protected]>; lsr <[email protected]>; > [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]> wrote: > Hi Ketan, > Thanks for reply. > Pls see inline.. > Juniper Business Use Only > From: Ketan Talaulikar <[email protected]> > Sent: Monday, April 8, 2024 2:25 PM > To: Shraddha Hegde <[email protected]> > Cc: Acee Lindem <[email protected]>; lsr <[email protected]>; > [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]> wrote: > Hi Ketan, > Thanks for the review and comments. > Pls see inline for replies. > Juniper Business Use Only > From: Ketan Talaulikar <[email protected]> > Sent: Thursday, March 21, 2024 10:07 PM > To: Acee Lindem <[email protected]> > Cc: lsr <[email protected]>; [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://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration > 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 > <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://www.rfc-editor.org/rfc/rfc9350.html#section-5.2 ... look for > IGP metric type 1 > And then: https://www.rfc-editor.org/rfc/rfc7471#section-4.2 and > https://www.rfc-editor.org/rfc/rfc8920.html#section-14.1 > 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://www.rfc-editor.org/rfc/rfc9350.html#section-5 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, > 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]> 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] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > 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] > _______________________________________________ > 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] > _______________________________________________ > 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] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
