Acee - As regards my comments, Shraddha is correct. I explicitly stated this back on April 26:
<snip> Acee – I left it up to Shraddha to introduce the I-bit or not – she has chosen not to do so. I believe all of my comments have been addressed to my satisfaction – sorry if it appeared that I left this issue unresolved. Les <end snip> Les > -----Original Message----- > From: Shraddha Hegde > Sent: Thursday, May 16, 2024 1:55 AM > To: Acee Lindem > Cc: Shraddha Hegde ; Ketan Talaulikar ; lsr ; draft-ietf-lsr-flex-algo-bw- > c...@ietf.org; Les Ginsberg (ginsberg) > Subject: RE: [Lsr] Working Group Last Call for "Flexible Algorithms: > Bandwidth, > Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07 > > Acee, > > I believe Les and I have agreed to the text that I added and his comments are > closed. > Les, let me know if you don't agree. > > I don't agree with Ketan's comment on removing code points from OSPF TE > opaque LSAs. > Early code points are already taken and implementations underway. If he can > elaborate his concern > With having generic metric in opaque LSA > We can see what details need to be added in the draft. > > I got some more comments from Peter. Will publish -12 soon. > > > Rgds > Shraddha > > > > > Juniper Business Use Only > -----Original Message----- > From: Acee Lindem <acee.lin...@gmail.com> > Sent: Friday, May 10, 2024 12:29 AM > To: Acee Lindem <acee.lin...@gmail.com> > Cc: Shraddha Hegde <shraddha=40juniper....@dmarc.ietf.org>; Ketan > Talaulikar <ketant.i...@gmail.com>; lsr <lsr@ietf.org>; > draft-ietf-lsr-flex-algo- > bw-...@ietf.org; Les Ginsberg (ginsberg) <ginsb...@cisco.com> > 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] > > > Any update? > > Thanks, > Acee > > > On Apr 26, 2024, at 11:53 AM, Acee Lindem <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> wrote: > >> > >> Hi Ketan, > >> Thanks for reply. > >> Pls see inline.. > >> > >> Juniper Business Use Only > >> From: Ketan Talaulikar <ketant.i...@gmail.com> > >> Sent: Monday, April 8, 2024 2:25 PM > >> To: Shraddha Hegde <shrad...@juniper.net> > >> Cc: Acee Lindem <acee.lin...@gmail.com>; lsr <lsr@ietf.org>; > >> 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> 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> > >> Sent: Thursday, March 21, 2024 10:07 PM > >> To: Acee Lindem <acee.lin...@gmail.com> > >> Cc: lsr <lsr@ietf.org>; 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]. 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!BeudAtZGk7-XssYqte2dyPuiegf- > oXoroaYsXYyIEJLEdZf1Bh4Jn5Mopid4VlitSAJoWvYiC0bPAdcSDIhyKQ$ 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://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-iet > >> f-lsr-flex-algo-bw-con-08.html*section-3.2.2__;Iw!!NEt6yMaO-gk!BeudAt > >> ZGk7-XssYqte2dyPuiegf- > oXoroaYsXYyIEJLEdZf1Bh4Jn5Mopid4VlitSAJoWvYiC0b > >> PAdftNfDjHQ$ > >> <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. 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://urldefense.com/v3/__https://www.rfc- > editor.org/rfc/rfc9350.html*section-5__;Iw!!NEt6yMaO-gk!BeudAtZGk7- > XssYqte2dyPuiegf- > oXoroaYsXYyIEJLEdZf1Bh4Jn5Mopid4VlitSAJoWvYiC0bPAdfXkvmp9A$ > 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!BeudAtZGk7- > XssYqte2dyPuiegf- > oXoroaYsXYyIEJLEdZf1Bh4Jn5Mopid4VlitSAJoWvYiC0bPAdezMO9Now$ , 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> > 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 > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > >> __;!!NEt6yMaO-gk!BeudAtZGk7-XssYqte2dyPuiegf- > oXoroaYsXYyIEJLEdZf1Bh4J > >> n5Mopid4VlitSAJoWvYiC0bPAdfJo6SZLw$ > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > >> __;!!NEt6yMaO-gk!BeudAtZGk7-XssYqte2dyPuiegf- > oXoroaYsXYyIEJLEdZf1Bh4J > >> n5Mopid4VlitSAJoWvYiC0bPAdfJo6SZLw$ > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > > _;!!NEt6yMaO-gk!BeudAtZGk7-XssYqte2dyPuiegf- > oXoroaYsXYyIEJLEdZf1Bh4Jn5Mopid4VlitSAJoWvYiC0bPAdfJo6SZLw$ > _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
