Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
Ron - Dealing simply with the language in the RFCs, both RFCs discuss the problems the RFCs are aimed at solving in the Introduction. Those problems are not specific to the set of link attributes defined at the time of writing the RFCs. Which is why the Introduction concludes with: "...as evolution of use cases for link attributes can be expected to continue in the years to come, this document defines a solution that is easily extensible to the introduction of new applications and new use cases." Which is exactly what is being introduced in draft-ietf-lsr-flex-algo-bw-con. There is then the more important question as to why new attributes - and Generic Metric specifically - should NOT follow the ASLA model. The same issues discussed in the RFCs that motivated the ASLA solution certainly apply to Generic Metric. This has been made clear by others in their responses to this thread - and each of the arguments Shraddha has made have been countered by responses in this thread. The substance of what is being discussed here is not (and should not be) whether there is a violation of the "letter of the law" - but whether there is a behavioral aspect of the new attribute that makes ASLA unsuitable. On that point I think clear and cogent arguments have been made that ASLA is appropriate and necessary. If the WG feels that more explicit language is needed to prevent such debates in the future, I am happy to work on an Errata - but that isn’t the substance of this discussion and I would much prefer that any future posts on this thread focus on the substantive issues. We can address improving the RFC language separately. Les > -Original Message- > From: Ron Bonica > Sent: Thursday, July 22, 2021 9:13 PM > To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) > ; Shraddha Hegde ; > gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; > lsr@ietf.org > Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > > Les, > > Please, let us avoid discussion of whether my message is disingenuous. As > Acee will agree, discussion of my internal motivations and moral deficiencies > is beyond the scope of the LSR WG. > > Now, let us address my point and your counter points. My point was that > draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919. Nothing more, > nothing less. > > In your counterpoint #1, you point out tension between draft-ietf-lsr-flex- > algo-bw-con and draft-ietf-lsr-flex-algo. While this point deserves > discussion, > it is orthogonal to my point. It is entirely possible that both of the > following > statements are true: > > - draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919 > - there is tension between draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr- > flex-algo > > In your counterpoint #2, you talk about the "clear intent" of RFC 8919. > Section 6.1 of RFC 8919 reduces that intent to a few very clear normative > statements. Draft-ietf-lsr-flex-algo-bw-con does not violate any of those > normative statements. Therefore, it does not violate RFC 8919. > > You may say: > > - Section 6.1 should have included more prohibitions > - The authors had additional prohibitions in mind when they wrote the draft, > but failed to add them to Section 6.1 > > That's all fine, but the community agreed only to the words on the page, not > the authors larger intent. > > > Ron > > > > > > Juniper Business Use Only > > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: Thursday, July 22, 2021 2:49 PM > To: Ron Bonica ; Acee Lindem (acee) > ; Shraddha Hegde ; > gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; > lsr@ietf.org > Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > > [External Email. Be cautious of content] > > > Ron - > > With respect, it is hard to read your email without feeling that it is > disingenuous. > > But, let's cover the relevant points nonetheless. > > Point #1: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- > ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj- > YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$ > states: > > " Link attribute advertisements that are to be used during Flex- >Algorithm calculation MUST use the Application-Specific Link >Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..." > > As the new generic-metric is intended for use by flex-algo it needs to > conform to this normative statement. > > Point #2: > > RFC 8919 and 8920 were written to address ambiguities associated with the > use of multiple applications. > The Introduction sections of both documents discuss this in some detail. > > The clear intent is to make use of ASLA going forward - not to restrict ASLA > on
Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
Ron I agree the way the RFC 8919 and 8920 are written it is more of an intent by the authors based on normative language as you have stated and not violating the specification. I think it does sound like that future attributes developed the authors kept it open to developers be application independent and not a MUST normative language for ASLA unfortunately it seems created a loophole, however I am not sure why it was written that way as it defeats the goal and purpose of RFC 8919 and RFC 8920. Kind Regards Gyan On Fri, Jul 23, 2021 at 12:13 AM Ron Bonica wrote: > Les, > > Please, let us avoid discussion of whether my message is disingenuous. As > Acee will agree, discussion of my internal motivations and moral > deficiencies is beyond the scope of the LSR WG. > > Now, let us address my point and your counter points. My point was that > draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919. Nothing more, > nothing less. > > In your counterpoint #1, you point out tension between > draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo. While this > point deserves discussion, it is orthogonal to my point. It is entirely > possible that both of the following statements are true: > > - draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919 > - there is tension between draft-ietf-lsr-flex-algo-bw-con and > draft-ietf-lsr-flex-algo > > In your counterpoint #2, you talk about the "clear intent" of RFC 8919. > Section 6.1 of RFC 8919 reduces that intent to a few very clear normative > statements. Draft-ietf-lsr-flex-algo-bw-con does not violate any of those > normative statements. Therefore, it does not violate RFC 8919. > > You may say: > > - Section 6.1 should have included more prohibitions > - The authors had additional prohibitions in mind when they wrote the > draft, but failed to add them to Section 6.1 > > That's all fine, but the community agreed only to the words on the page, > not the authors larger intent. > > > Ron > > > > > > Juniper Business Use Only > > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: Thursday, July 22, 2021 2:49 PM > To: Ron Bonica ; Acee Lindem (acee) ; > Shraddha Hegde ; gregory.mir...@ztetx.com; Peter > Psenak (ppsenak) ; lsr@ietf.org > Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > > [External Email. Be cautious of content] > > > Ron - > > With respect, it is hard to read your email without feeling that it is > disingenuous. > > But, let's cover the relevant points nonetheless. > > Point #1: > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$ > states: > > " Link attribute advertisements that are to be used during Flex- >Algorithm calculation MUST use the Application-Specific Link >Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..." > > As the new generic-metric is intended for use by flex-algo it needs to > conform to this normative statement. > > Point #2: > > RFC 8919 and 8920 were written to address ambiguities associated with the > use of multiple applications. > The Introduction sections of both documents discuss this in some detail. > > The clear intent is to make use of ASLA going forward - not to restrict > ASLA only to the set of link attributes defined at the time of the writing > of the RFCs. Failure to do so would reintroduce the same set of issues that > RFC 8919/8920 were written to address. > Your attempt to infer that because Generic-Metric was not defined at the > time that RFC 8919/8920 were written that the RFCs don’t apply to it makes > no sense. > ASLA is in fact a revision to the link attribute architecture and is meant > to be used going forward. > > The more appropriate question to ask is why we need to define a legacy > style sub-TLV for new link attributes? Ketan has made this point in his > post on this thread and I have sympathy with his position. > > We do understand that legacy applications such as RSVP-TE may continue to > be deployed in networks for some time to come. It is not reasonable to > expect that legacy application implementations will be updated to use ASLA, > which is why I do not object to defining a legacy style encoding for > Generic Metric if folks believe that legacy applications may be enhanced to > support new link attributes. > > I strongly disagree with your interpretation that ASLA is limited only to > the code points defined in RFC 8919/8920. > >Les > > > > -Original Message- > > From: Ron Bonica > > Sent: Thursday, July 22, 2021 10:28 AM > > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > > ; Shraddha Hegde ; > > gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; > > lsr@ietf.org > > Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org > > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-
Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts
I support the adoption of both drafts as a co-author. I’m not aware of any IPR that applies to these drafts. Thanks, Yingzhen > On Jul 22, 2021, at 3:48 AM, Christian Hopps wrote: > > > Hi Folks, > > This begins a 3 week WG Adoption Call for the following related YANG drafts: > > https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ > https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ > > Please indicate your support or objections by August 12th, 2021 > > Authors, please respond to the list indicating whether you are aware of any > IPR that applies to these drafts. > > Thanks, > Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
Les, Please, let us avoid discussion of whether my message is disingenuous. As Acee will agree, discussion of my internal motivations and moral deficiencies is beyond the scope of the LSR WG. Now, let us address my point and your counter points. My point was that draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919. Nothing more, nothing less. In your counterpoint #1, you point out tension between draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo. While this point deserves discussion, it is orthogonal to my point. It is entirely possible that both of the following statements are true: - draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919 - there is tension between draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo In your counterpoint #2, you talk about the "clear intent" of RFC 8919. Section 6.1 of RFC 8919 reduces that intent to a few very clear normative statements. Draft-ietf-lsr-flex-algo-bw-con does not violate any of those normative statements. Therefore, it does not violate RFC 8919. You may say: - Section 6.1 should have included more prohibitions - The authors had additional prohibitions in mind when they wrote the draft, but failed to add them to Section 6.1 That's all fine, but the community agreed only to the words on the page, not the authors larger intent. Ron Juniper Business Use Only -Original Message- From: Les Ginsberg (ginsberg) Sent: Thursday, July 22, 2021 2:49 PM To: Ron Bonica ; Acee Lindem (acee) ; Shraddha Hegde ; gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; lsr@ietf.org Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt [External Email. Be cautious of content] Ron - With respect, it is hard to read your email without feeling that it is disingenuous. But, let's cover the relevant points nonetheless. Point #1: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$ states: " Link attribute advertisements that are to be used during Flex- Algorithm calculation MUST use the Application-Specific Link Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..." As the new generic-metric is intended for use by flex-algo it needs to conform to this normative statement. Point #2: RFC 8919 and 8920 were written to address ambiguities associated with the use of multiple applications. The Introduction sections of both documents discuss this in some detail. The clear intent is to make use of ASLA going forward - not to restrict ASLA only to the set of link attributes defined at the time of the writing of the RFCs. Failure to do so would reintroduce the same set of issues that RFC 8919/8920 were written to address. Your attempt to infer that because Generic-Metric was not defined at the time that RFC 8919/8920 were written that the RFCs don’t apply to it makes no sense. ASLA is in fact a revision to the link attribute architecture and is meant to be used going forward. The more appropriate question to ask is why we need to define a legacy style sub-TLV for new link attributes? Ketan has made this point in his post on this thread and I have sympathy with his position. We do understand that legacy applications such as RSVP-TE may continue to be deployed in networks for some time to come. It is not reasonable to expect that legacy application implementations will be updated to use ASLA, which is why I do not object to defining a legacy style encoding for Generic Metric if folks believe that legacy applications may be enhanced to support new link attributes. I strongly disagree with your interpretation that ASLA is limited only to the code points defined in RFC 8919/8920. Les > -Original Message- > From: Ron Bonica > Sent: Thursday, July 22, 2021 10:28 AM > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > ; Shraddha Hegde ; > gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; > lsr@ietf.org > Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > > Acee, > > I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919. > > Section 6.1 of RFC 8919 says: > > " New applications that future documents define to make use of the >advertisements defined in this document MUST NOT make use of legacy >advertisements. This simplifies deployment of new applications by >eliminating the need to support multiple ways to advertise attributes >for the new applications." > > Section 3 of RFC 8919 defines legacy advertisements. The definition of > legacy advertisements does not include new attributes such as generic > metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not
Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts
Hi, all, I support the adoption of these two drafts. As a co-author of IS-IS SRv6 draft(https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/), I am not aware any IPR that applies to this draft. Best Regards, Qiufang Ma -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Thursday, July 22, 2021 6:48 PM To: lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts Hi Folks, This begins a 3 week WG Adoption Call for the following related YANG drafts: https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ Please indicate your support or objections by August 12th, 2021 Authors, please respond to the list indicating whether you are aware of any IPR that applies to these drafts. Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts
I am not aware of any IPR related to the draft. Best Regards, zhibo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Thursday, July 22, 2021 6:48 PM To: lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts Hi Folks, This begins a 3 week WG Adoption Call for the following related YANG drafts: https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ Please indicate your support or objections by August 12th, 2021 Authors, please respond to the list indicating whether you are aware of any IPR that applies to these drafts. Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts
I support the adoption of these two documents. Best regards, Jie > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps > Sent: Thursday, July 22, 2021 6:48 PM > To: lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org > Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts > > > Hi Folks, > > This begins a 3 week WG Adoption Call for the following related YANG drafts: > > https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ > https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ > > Please indicate your support or objections by August 12th, 2021 > > Authors, please respond to the list indicating whether you are aware of any > IPR > that applies to these drafts. > > Thanks, > Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts
Support adoption of these 2 documents as a co-author. And I'm not aware of any IPR that applies to the drafts Best Xuesong -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Thursday, July 22, 2021 6:48 PM To: lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts Hi Folks, This begins a 3 week WG Adoption Call for the following related YANG drafts: https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ Please indicate your support or objections by August 12th, 2021 Authors, please respond to the list indicating whether you are aware of any IPR that applies to these drafts. Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
As stated nicely by Les, the goal and intent of RFC 8919 and 8920 as stated clearly was meant to fix a ambiguities related to cases where multiple applications RSVP-TE, SR, Flex Algo making use of link attributes by creating ASLA for a list of link attributes sub-tlv’s that existed at time of writing the document, however moving forward that all new link attributes defined MUST now be advertised using ASLA sub tlv. By not doing do you are perpetuating the problem all over again. The chairs and other in the WG would like to draw a line in the sand that any new link attribute MUST be advertised using ASLA SUB-TLV encoding. RFC 8919 -Last paragraph in the introduction This document defines extensions that address these issues. Also, as evolution of use cases for link attributes can be expected to continue in the years to come, this document defines a solution that is easily extensible to the introduction of new applications and new use cases. RFC 8920- Last paragraph in the introduction This document defines extensions that address these issues. Also, as evolution of use cases for link attributes can be expected to continue in the years to come, this document defines a solution that is easily extensible for the introduction of new applications and new use cases. The key is the extensibility of RFC 8919 and RFC 8920 for all future link attributes and not just the ones defined when the draft was written. Kind Regards Gyan On Thu, Jul 22, 2021 at 2:49 PM Les Ginsberg (ginsberg) wrote: > Ron - > > With respect, it is hard to read your email without feeling that it is > disingenuous. > > But, let's cover the relevant points nonetheless. > > Point #1: > > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17#section-12 > states: > > " Link attribute advertisements that are to be used during Flex- >Algorithm calculation MUST use the Application-Specific Link >Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..." > > As the new generic-metric is intended for use by flex-algo it needs to > conform to this normative statement. > > Point #2: > > RFC 8919 and 8920 were written to address ambiguities associated with the > use of multiple applications. > The Introduction sections of both documents discuss this in some detail. > > The clear intent is to make use of ASLA going forward - not to restrict > ASLA only to the set of link attributes defined at the time of the writing > of the RFCs. Failure to do so would reintroduce the same set of issues that > RFC 8919/8920 were written to address. > Your attempt to infer that because Generic-Metric was not defined at the > time that RFC 8919/8920 were written that the RFCs don’t apply to it makes > no sense. > ASLA is in fact a revision to the link attribute architecture and is meant > to be used going forward. > > The more appropriate question to ask is why we need to define a legacy > style sub-TLV for new link attributes? Ketan has made this point in his > post on this thread and I have sympathy with his position. > > We do understand that legacy applications such as RSVP-TE may continue to > be deployed in networks for some time to come. It is not reasonable to > expect that legacy application implementations will be updated to use ASLA, > which is why I do not object to defining a legacy style encoding for > Generic Metric if folks believe that legacy applications may be enhanced to > support new link attributes. > > I strongly disagree with your interpretation that ASLA is limited only to > the code points defined in RFC 8919/8920. > >Les > > > > -Original Message- > > From: Ron Bonica > > Sent: Thursday, July 22, 2021 10:28 AM > > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > > ; Shraddha Hegde ; > > gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; > > lsr@ietf.org > > Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org > > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > > > > Acee, > > > > I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919. > > > > Section 6.1 of RFC 8919 says: > > > > " New applications that future documents define to make use of the > >advertisements defined in this document MUST NOT make use of legacy > >advertisements. This simplifies deployment of new applications by > >eliminating the need to support multiple ways to advertise attributes > >for the new applications." > > > > Section 3 of RFC 8919 defines legacy advertisements. The definition of > legacy > > advertisements does not include new attributes such as > > generic metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not > > violate RFC 8919 > > > > Relevant text from Section 3 of RFC 8919 is included below for > convenience. > > > > Ron > > > > > > RFC 8919, Section 3 > > --- > > 3. Legacy Advertisements > > > > > > Exis
Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
Ron - With respect, it is hard to read your email without feeling that it is disingenuous. But, let's cover the relevant points nonetheless. Point #1: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17#section-12 states: " Link attribute advertisements that are to be used during Flex- Algorithm calculation MUST use the Application-Specific Link Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..." As the new generic-metric is intended for use by flex-algo it needs to conform to this normative statement. Point #2: RFC 8919 and 8920 were written to address ambiguities associated with the use of multiple applications. The Introduction sections of both documents discuss this in some detail. The clear intent is to make use of ASLA going forward - not to restrict ASLA only to the set of link attributes defined at the time of the writing of the RFCs. Failure to do so would reintroduce the same set of issues that RFC 8919/8920 were written to address. Your attempt to infer that because Generic-Metric was not defined at the time that RFC 8919/8920 were written that the RFCs don’t apply to it makes no sense. ASLA is in fact a revision to the link attribute architecture and is meant to be used going forward. The more appropriate question to ask is why we need to define a legacy style sub-TLV for new link attributes? Ketan has made this point in his post on this thread and I have sympathy with his position. We do understand that legacy applications such as RSVP-TE may continue to be deployed in networks for some time to come. It is not reasonable to expect that legacy application implementations will be updated to use ASLA, which is why I do not object to defining a legacy style encoding for Generic Metric if folks believe that legacy applications may be enhanced to support new link attributes. I strongly disagree with your interpretation that ASLA is limited only to the code points defined in RFC 8919/8920. Les > -Original Message- > From: Ron Bonica > Sent: Thursday, July 22, 2021 10:28 AM > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > ; Shraddha Hegde ; > gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ; > lsr@ietf.org > Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > > Acee, > > I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919. > > Section 6.1 of RFC 8919 says: > > " New applications that future documents define to make use of the >advertisements defined in this document MUST NOT make use of legacy >advertisements. This simplifies deployment of new applications by >eliminating the need to support multiple ways to advertise attributes >for the new applications." > > Section 3 of RFC 8919 defines legacy advertisements. The definition of legacy > advertisements does not include new attributes such as > generic metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not > violate RFC 8919 > > Relevant text from Section 3 of RFC 8919 is included below for convenience. > > Ron > > > RFC 8919, Section 3 > --- > 3. Legacy Advertisements > > > Existing advertisements used in support of RSVP-TE include sub-TLVs >for TLVs 22, 23, 25, 141, 222, and 223 and TLVs for Shared Risk Link >Group (SRLG) advertisement. > >Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141, >222, and 223" registry. > >TLVs are defined in the "TLV Codepoints Registry". > > 3.1. Legacy Sub-TLVs > >+==++ >| Type | Description| >+==++ >| 3| Administrative group (color) | >+--++ >| 9| Maximum link bandwidth | >+--++ >| 10 | Maximum reservable link bandwidth | >+--++ >| 11 | Unreserved bandwidth | >+--++ >| 14 | Extended Administrative Group | >+--++ >| 18 | TE Default Metric | >+--++ >| 33 | Unidirectional Link Delay | >+--++ >| 34 | Min/Max Unidirectional Link Delay | >+--++ >| 35 | Unidirectional Delay Variation | >+--++ >| 36 | Unidirectional Link Loss | >+--++ >| 37 | Unidirectional Residual Bandwidth | >+--++ >| 38 | Unidirectional Available Bandwidth | >+-
Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
Acee, I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919. Section 6.1 of RFC 8919 says: " New applications that future documents define to make use of the advertisements defined in this document MUST NOT make use of legacy advertisements. This simplifies deployment of new applications by eliminating the need to support multiple ways to advertise attributes for the new applications." Section 3 of RFC 8919 defines legacy advertisements. The definition of legacy advertisements does not include new attributes such as generic metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919 Relevant text from Section 3 of RFC 8919 is included below for convenience. Ron RFC 8919, Section 3 --- 3. Legacy Advertisements Existing advertisements used in support of RSVP-TE include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 and TLVs for Shared Risk Link Group (SRLG) advertisement. Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223" registry. TLVs are defined in the "TLV Codepoints Registry". 3.1. Legacy Sub-TLVs +==++ | Type | Description| +==++ | 3| Administrative group (color) | +--++ | 9| Maximum link bandwidth | +--++ | 10 | Maximum reservable link bandwidth | +--++ | 11 | Unreserved bandwidth | +--++ | 14 | Extended Administrative Group | +--++ | 18 | TE Default Metric | +--++ | 33 | Unidirectional Link Delay | +--++ | 34 | Min/Max Unidirectional Link Delay | +--++ | 35 | Unidirectional Delay Variation | +--++ | 36 | Unidirectional Link Loss | +--++ | 37 | Unidirectional Residual Bandwidth | +--++ | 38 | Unidirectional Available Bandwidth | +--++ | 39 | Unidirectional Utilized Bandwidth | +--++ Table 1: Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 Juniper Business Use Only -Original Message- From: Lsr On Behalf Of Acee Lindem (acee) Sent: Tuesday, July 20, 2021 1:21 PM To: Les Ginsberg (ginsberg) ; Shraddha Hegde ; gregory.mir...@ztetx.com; ppsenak=40cisco@dmarc.ietf.org; lsr@ietf.org Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt [External Email. Be cautious of content] Speaking as WG member: I agree with Les. The Generic Metric MUST be advertised as an ASLA for usage in Flex Algorithm. Additionally, it may be advertised as a sub-TLV in IS-IS link TLVs. However, the latter encoding really shouldn't be used for new applications (at least that is my reading of RFC 8919). For OSPF, I'd certainly hope one wouldn't originate additional LSAs when an ASLA can support the legacy applications with the ASLA mask. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts
I support LSR WG adoption of both drafts. As an author of draft-hu-lsr-ospf-srv6-yang, I'm not aware of any IPR. Thanks, Acee On 7/22/21, 6:50 AM, "Christian Hopps" wrote: Hi Folks, This begins a 3 week WG Adoption Call for the following related YANG drafts: https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ Please indicate your support or objections by August 12th, 2021 Authors, please respond to the list indicating whether you are aware of any IPR that applies to these drafts. Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Request to consider Flood Reflection going into LC
Speaking as WG member: Hi Tony, Thank you for starting this discussion. I’ve reviewed the draft and have a few comments and questions. 1. I think the concept of a flood reflection cluster should be defined earlier in the document as opposed to being introduced in the TLV description. It seems there can only be one cluster per level-1 area so why isn’t the cluster implied by the area? I don’t see the reason for having a separate Flood Reduction Cluster ID? 1. On Page 7, there is the statement “A solution without tunnels…” I think this should be removed or at least there should be a qualification that it is beyond the scope of the document. I know there are subtle allusions to the tunnel-less solution in other sections but these introduce confusion as well. 1. For the TLVs in section 3, 4, and 5, it is a “MUST” to only have a single instance of the TLVs. However, if there are more than one, this violation is ignored and the first instance of the TLV is used. Perhaps, this should be a “SHOULD”. Also, these violations SHOULD be logged subject to rate-limiting. 1. Section 6 – How does a flood reflector ensure that there are no normal L2 adjacencies? Will adjacency establishment fail if an attempt is made to establish one? This should be specified. 1. Section 6 – Establishment of tunnels between flood reflector clients is a MAY yet the solution work without it unless all the L2 routes are leaked into L1. This is related to #2. 1. Section 7 – This section needs to specify what happens if the adjacency criteria are not met. 2. Section 8 – Does this section assume no tunnels? Is the assumption that if there is an L1/L2 edge router that is not a flood reflector client, there will be another L1/L2 edge that is? Or is this to cover cases where there is an existing portion of the L2 topology that doesn’t support flood reflection. If it is the latter case, than leaking is required to get the L2 routes for this portion of the L2 topology to the flood reflector(s). 1. I don’t understand the last statement in section 9. What do you mean by “look ‘shorter’”? Why wouldn’t the flood reflected path cost be accurate? The L2-only path would certainly be accurate. Thanks, Acee From: Lsr on behalf of Tony Przygienda Date: Friday, July 9, 2021 at 1:27 AM To: lsr Subject: [Lsr] Request to consider Flood Reflection going into LC Dear chairs, flood reflection is implemented/shipped and deploying and we’re on early alloc codepoints that expire start Aug’. No further discussions on the list happened. As far as we see as authors stuff looks shaken out, all things that were found in implementation/use are in the latest draft version and I’d like to test the waters of LC’ing it rather than dragging it on as draft and asking for temporary alloc again which does not seem to serve a purpose AFAIS. thanks -- tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05
Speaking as a WG member, I support publication. I only have one functional comment and that is on Appendix A. Note that a key-chain or key-id would be useful for MD5 as well as TLS and TCP-AO. I’m not suggesting that you add MD5 since it is historic but support of MD5 as specified in RFC 5440 would require configuration of the same key or key-chain on the PCC and PCE server. I also have some editorial comments that you can decide whether or not to apply. Of note are that I don’t think you need to say “looking for connecting with a” and can simply say “looking for a”. Also, once this document is published the capability bits and sub-TLVs are not longer “new”. See full set of editorial comments in attached RFC diff. Thanks, Acee From: Lsr on behalf of "Acee Lindem (acee)" Date: Wednesday, July 21, 2021 at 12:46 PM To: "lsr@ietf.org" Cc: "draft-ietf-lsr-pce-discovery-security-supp...@ietf.org" Subject: [Lsr] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05 This begins a 3-week WG Last Call, ending on August 4th, 2021, for draft-ietf-lsr-pce-discovery-security-support. Please indicate your support or objection to this list before the end of the WG last call. The longer WG last call is to account for IETF week. https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ Thanks, Acee <<< text/html; name="Diff_ draft-ietf-lsr-pce-discovery-security-support-05.txt.orig - draft-ietf-lsr-pce-discovery-security-support-05.txt.html": Unrecognized >>> ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Re： LSR WG Adoption Call for SRv6 YANG drafts
Hi all, I support the adoption of the 2 YANG drafts. Thanks Yisong 发件人: Christian Hopps 时间: 2021/07/22(星期四)18:43 收件人: lsr; 抄送人: lsr-chairs;lsr-ads;chopps; 主题: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts Hi Folks, This begins a 3 week WG Adoption Call for the following related YANG drafts: https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ Please indicate your support or objections by August 12th, 2021 Authors, please respond to the list indicating whether you are aware of any IPR that applies to these drafts. Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] LSR WG Adoption Call for SRv6 YANG drafts
Hi Folks, This begins a 3 week WG Adoption Call for the following related YANG drafts: https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ Please indicate your support or objections by August 12th, 2021 Authors, please respond to the list indicating whether you are aware of any IPR that applies to these drafts. Thanks, Chris. signature.asc Description: PGP signature ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] The LSR WG has placed draft-hu-lsr-ospf-srv6-yang in state "Call For Adoption By WG Issued"
The LSR WG has placed draft-hu-lsr-ospf-srv6-yang in state Call For Adoption By WG Issued (entered by Christian Hopps) The document is available at https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] The LSR WG has placed draft-hu-isis-srv6-yang in state "Call For Adoption By WG Issued"
The LSR WG has placed draft-hu-isis-srv6-yang in state Call For Adoption By WG Issued (entered by Christian Hopps) The document is available at https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
Hi Shraddha, Thanks for your detailed email explanation. I was one of the WG members who indicated that Generic Metric not be advertised in the base as well as ASLA encodings. But what you've missed out was that I asked for it to be used in ASLA alone and not as application independent. Generic metric not only allows advertisement of existing IGP metric types but also introduces new ones e.g. Bandwidth. There will be others/more. We definitely do need the ability to have application specific values for these various Generic Metric types. One use-case is that there be a different reference b/w or threshold yardstick for FlexAlgo and SR Policy. The appl-independent proposal will require the specification and provisioning of new/additional user-defined Generic Metric types - potentially one per application (more if we consider different flex-algo) when we need different TE or B/W metric value per application. While advertising it in ASLA allows the same b/w metric type to be used with different values for FlexAlgo and SR Policy. Regarding the ASLA encoding, there is nothing that prevents the same Generic Metric type/value being shared across applications. We have already implementations that do so for FlexAlgo. This is a solved problem. Therefore, I still do believe that Generic Metric is application specific - as was originally in the draft version that the WG adopted. Coming to Generic Metric in BGP, I agree with the use-case. However, that is orthogonal to how it is advertised in IGPs. On the contrary, having too many user-defined and standard Generic Metric types (as you've proposed) make things more challenging to reconcile at the BGP level when we have a mix of types. Like other WG members, I do still believe that Generic Metric advertisement in ASLA *alone* would be the right way to go as far as having an extensible and generic encoding approach for the IGPs. Thank, Ketan -Original Message- From: Lsr On Behalf Of Shraddha Hegde Sent: 19 July 2021 23:35 To: gregory.mir...@ztetx.com; ppsenak=40cisco@dmarc.ietf.org; lsr@ietf.org Cc: Les Ginsberg (ginsberg) ; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt Hi All, Generic metric was allowed to be advertised in TLV 22/ ELO LSA as well as ASLA TLV before the draft was called for adoption. During the recent WG adoption review, it was pointed out that ASLA architecture does not allow an attribute to be advertised in both application-specific and application-independent manner. As a result of this Generic metric has been made an application-independent attribute in the latest version. The reasons are below 1.Generic metric is required to be advertised in an application-independent manner that is metric-type 128 is advertised for a link and any application like flex-algo, SR-TE, RSVP LFA can make use of it. Metric has scope outside of an IGP domain. It gets advertised in BGP-LU and gets accumulated across domains. There are many usecases that will benefit from advertising generic-metric in an application-independent manner. 2.The recent case of te-metric usecase that I came across where ASLA was being used, really wanted to use a different metric-type for flex-algo and not really different values for same metric type. (Peter, coincidently we may be talking of the same recent usecase which you claimed to be using ASLA) 3.Advertising generic metric in an application independent manner in legacy TLV 22 and ELO LSA does not violate RFC 8919/8920. Application-independent attributes are not expected to use RFC 8919/8920 mechanisms. Generic metric is like igp cost. IGP-cost is never advertised in ASLA but it gets used in flex-algo and generic-metric is being modeled based on igp-cost. As currently written, this document is compliant to every RFC and draft that has been out there and not violating any of them. 4.Generic metric is very flexible. It allows for finest granularity of metric advertisement. Usecase: Lets say flex-algo 128 wants to use metric-type 128 and flex-algo 129 wants to use metric-type 129. An year later operator decides to deploy SR-TE with red LSPs using metric-type 128 and Blue LSPs using metric-type 129. Using generic metric in application-independent manner: 1.configure metric-type 128 and 129 and value pair on each link 2. set flex-algo 128 FAD to use metric-type 128 and flex-algo FAD 129 to use metric-type 129 3. An year later configure Red LSPs to use metric-type 128 and Blue LSPs to use metric-type 129 Using generic metric with ASLA: 1. Define user defined bit-masks for flex-algo 128 and flex-algo 129 and configure on every router 2. configure metric-type 128 and 129 on every link 3. An year later, define user defined bit masks for SR-TE Red LSPs and SR-TE blue LSPs 4. Configure the bit masks on all head-end routers 5. Associate the new bit masks with
