Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts

[Lizhenbin]

Hi All,

I support the adoption of the two SRv6 YANG drafts.


Best Regards,
Zhenbin (Robin)




-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Yingzhen Qu
Sent: Friday, July 23, 2021 12:39 PM
To: Christian Hopps 
Cc: lsr@ietf.org; lsr-...@ietf.org; lsr-cha...@ietf.org
Subject: 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
___
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

[Gyan Mishra]

Hi Les

I completely agree with all your comments as well as Peter’s  that from an
operators perspective the issue solved by RFC 8918 and 8919, being able to
distinguish which applications are using a link attribute is crucial from
an operators perspective especially in many cases where you are running all
three applications simultaneously.  I

ASLA does solve a real word problem and I think by allowing link attributes
that should use ASLA to be advertised as application independent when they
should not be especially in this case with Generic metric and maybe others
that might come up in the future really goes against the goals of what ASLA
is trying to achieve from an LSR WG standpoint.

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 3:18 PM Les Ginsberg (ginsberg) 
wrote:

> Gyan –
>
>
>
> I do not see Generic Metric as an application independent link attribute.
>
> It is an attribute that could be used by multiple applications – in which
> case you would advertise it in ASLA with the logical OR of all of the
> applications using it.
> Gyan> Understood
>
> The only existing example of an application independent attribute is
> Maximum Link Bandwidth. This is an attribute of the physical link –
> independent of the application(s) which use it – in which case
> https://www.rfc-editor.org/rfc/rfc8919.html#section-4.2.1 applies.
>
>
   Gyan> Agreed

If some other attribute is ever defined which has the same characteristic,
> then I would expect the same advertisement model to be used.
>
> Gyan> Agreed
>
> Metric – in all its forms (whether TE, Delay, or now Generic) – is not a
> property of the physical link. It is – as Peter has described - a value
> that is configured or computed to be used by one or more applications. I do
> not see the need to define an application independent method of advertising
> it.
>

Gyan> Understood.  Completely agree.

> If one believes that legacy applications such as RSVP-TE will be extended
> to support Generic Metric, then a valid argument can be made for supporting
> advertisement of Generic Metric as a direct sub-TLV in TLVs 22 et al as
> well as ASLA. I would be somewhat surprised if RSVP-TE were extended in
> this way, but that is up to the marketplace to decide.
>
> Gyan> I would be surprised as well.  Agreed.
>

>
>Les
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Friday, July 23, 2021 11:44 AM
> *To:* Peter Psenak (ppsenak) 
> *Cc:* Acee Lindem (acee) ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Ron Bonica ; Shraddha Hegde <
> shrad...@juniper.net>; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org;
> gregory.mir...@ztetx.com; lsr@ietf.org
> *Subject:* Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>
>
>
>
>
> Peter
>
>
>
> How would you advertise Generic metric link attribute in Flex Algo as both
> ASLA and application independent?
>
>
>
> For ASLA you set the bit vector but application independent in ASLA what
> do you do?
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Fri, Jul 23, 2021 at 4:19 AM Peter Psenak  40cisco@dmarc.ietf.org> wrote:
>
> Hi Ron,
>
> keeping the normative statements aside.
>
> We are defining a Generic Metric TLV.
>
> 1. The first and only defined usage at this point is for Flex-algo.
>
> 2. Generic Metric is not something that must be defined as application
> independent, on the contrary, it's a value that is either assigned by
> operator or computed somehow. Advertising application specific values
> not only make sense, but would add value. TE metric is an example which
> is very close to Generic Metric and is supported in ASLA.
>
> 3. Flex-algo is an application from the ASLA framework perspective and
> so far is only using ASLA encoded link attributes. It would make sense
> to continue to do so for Generic Metric.
>
> 4. If you feel you need the Generic Metric also as an application
> independent value, I'm fine, although I do not see the immediate use case.
>
> Given the above, would not you thing that advertising Generic Metric in
> ASLA make sense?
>
> thanks,
> Peter
>
>
>
>
>
>
>
>
> On 23/07/2021 06:13, 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 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Ketan Talaulikar (ketant)]

Hi Les,

Just a short comment on the RSVP-TE part.

We do have a R bit for RSVP-TE in ASLA SABM so I don’t see the need for the 
advertisement under TLV 22 (et all) in ISIS.

Similar applies for OSPF too, but in that case, there is a separate TE Opaque 
LSA that is dedicated for RSVP-TE and hence advertisement as a sub-TLV there 
that may be considered (as per RFC8920). However, even in OSPF it doesn’t make 
sense to have it as application independent under the OSPFv2 Extended Link LSA 
as that is not really used by RSVP-TE today.

Thanks,
Ketan

From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: 24 July 2021 00:48
To: Gyan Mishra ; Peter Psenak (ppsenak) 

Cc: gregory.mir...@ztetx.com; Ron Bonica ; Shraddha Hegde 
; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; 
lsr@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

Gyan –

I do not see Generic Metric as an application independent link attribute.
It is an attribute that could be used by multiple applications – in which case 
you would advertise it in ASLA with the logical OR of all of the applications 
using it.

The only existing example of an application independent attribute is Maximum 
Link Bandwidth. This is an attribute of the physical link – independent of the 
application(s) which use it – in which case 
https://www.rfc-editor.org/rfc/rfc8919.html#section-4.2.1 applies.
If some other attribute is ever defined which has the same characteristic, then 
I would expect the same advertisement model to be used.

Metric – in all its forms (whether TE, Delay, or now Generic) – is not a 
property of the physical link. It is – as Peter has described - a value that is 
configured or computed to be used by one or more applications. I do not see the 
need to define an application independent method of advertising it.

If one believes that legacy applications such as RSVP-TE will be extended to 
support Generic Metric, then a valid argument can be made for supporting 
advertisement of Generic Metric as a direct sub-TLV in TLVs 22 et al as well as 
ASLA. I would be somewhat surprised if RSVP-TE were extended in this way, but 
that is up to the marketplace to decide.

   Les

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Friday, July 23, 2021 11:44 AM
To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; Les Ginsberg 
(ginsberg) mailto:ginsb...@cisco.com>>; Ron Bonica 
mailto:rbon...@juniper.net>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org;
 gregory.mir...@ztetx.com; 
lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt


Peter

How would you advertise Generic metric link attribute in Flex Algo as both ASLA 
and application independent?

For ASLA you set the bit vector but application independent in ASLA what do you 
do?

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 4:19 AM Peter Psenak 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Ron,

keeping the normative statements aside.

We are defining a Generic Metric TLV.

1. The first and only defined usage at this point is for Flex-algo.

2. Generic Metric is not something that must be defined as application
independent, on the contrary, it's a value that is either assigned by
operator or computed somehow. Advertising application specific values
not only make sense, but would add value. TE metric is an example which
is very close to Generic Metric and is supported in ASLA.

3. Flex-algo is an application from the ASLA framework perspective and
so far is only using ASLA encoded link attributes. It would make sense
to continue to do so for Generic Metric.

4. If you feel you need the Generic Metric also as an application
independent value, I'm fine, although I do not see the immediate use case.

Given the above, would not you thing that advertising Generic Metric in
ASLA make sense?

thanks,
Peter








On 23/07/2021 06:13, 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 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Les Ginsberg (ginsberg)]

Gyan –

I do not see Generic Metric as an application independent link attribute.
It is an attribute that could be used by multiple applications – in which case 
you would advertise it in ASLA with the logical OR of all of the applications 
using it.

The only existing example of an application independent attribute is Maximum 
Link Bandwidth. This is an attribute of the physical link – independent of the 
application(s) which use it – in which case 
https://www.rfc-editor.org/rfc/rfc8919.html#section-4.2.1 applies.
If some other attribute is ever defined which has the same characteristic, then 
I would expect the same advertisement model to be used.

Metric – in all its forms (whether TE, Delay, or now Generic) – is not a 
property of the physical link. It is – as Peter has described - a value that is 
configured or computed to be used by one or more applications. I do not see the 
need to define an application independent method of advertising it.

If one believes that legacy applications such as RSVP-TE will be extended to 
support Generic Metric, then a valid argument can be made for supporting 
advertisement of Generic Metric as a direct sub-TLV in TLVs 22 et al as well as 
ASLA. I would be somewhat surprised if RSVP-TE were extended in this way, but 
that is up to the marketplace to decide.

   Les

From: Gyan Mishra 
Sent: Friday, July 23, 2021 11:44 AM
To: Peter Psenak (ppsenak) 
Cc: Acee Lindem (acee) ; Les Ginsberg (ginsberg) 
; Ron Bonica ; Shraddha Hegde 
; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; 
gregory.mir...@ztetx.com; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt


Peter

How would you advertise Generic metric link attribute in Flex Algo as both ASLA 
and application independent?

For ASLA you set the bit vector but application independent in ASLA what do you 
do?

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 4:19 AM Peter Psenak 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Ron,

keeping the normative statements aside.

We are defining a Generic Metric TLV.

1. The first and only defined usage at this point is for Flex-algo.

2. Generic Metric is not something that must be defined as application
independent, on the contrary, it's a value that is either assigned by
operator or computed somehow. Advertising application specific values
not only make sense, but would add value. TE metric is an example which
is very close to Generic Metric and is supported in ASLA.

3. Flex-algo is an application from the ASLA framework perspective and
so far is only using ASLA encoded link attributes. It would make sense
to continue to do so for Generic Metric.

4. If you feel you need the Generic Metric also as an application
independent value, I'm fine, although I do not see the immediate use case.

Given the above, would not you thing that advertising Generic Metric in
ASLA make sense?

thanks,
Peter








On 23/07/2021 06:13, 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) 
> mailto:40cisco@dmarc.ietf.org>>
> Sent: Thursday, July 22, 2021 2:49 PM
> To: Ron Bonica mailto:rbon...@juniper.net>>; Acee Lindem 
> (acee) mailto:a...@cisco.com>>; Shraddha Hegde 
> mailto:shrad...@juniper.net>>; 
> gregory.mir...@ztetx.com; Peter Psenak 
> (ppsenak) mailto:ppse...@cisco.com>>; 
> lsr@ietf.org
> Cc: 
> 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Gyan Mishra]

Peter

How would you advertise Generic metric link attribute in Flex Algo as both
ASLA and application independent?

For ASLA you set the bit vector but application independent in ASLA what do
you do?

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 4:19 AM Peter Psenak  wrote:

> Hi Ron,
>
> keeping the normative statements aside.
>
> We are defining a Generic Metric TLV.
>
> 1. The first and only defined usage at this point is for Flex-algo.
>
> 2. Generic Metric is not something that must be defined as application
> independent, on the contrary, it's a value that is either assigned by
> operator or computed somehow. Advertising application specific values
> not only make sense, but would add value. TE metric is an example which
> is very close to Generic Metric and is supported in ASLA.
>
> 3. Flex-algo is an application from the ASLA framework perspective and
> so far is only using ASLA encoded link attributes. It would make sense
> to continue to do so for Generic Metric.
>
> 4. If you feel you need the Generic Metric also as an application
> independent value, I'm fine, although I do not see the immediate use case.
>
> Given the above, would not you thing that advertising Generic Metric in
> ASLA make sense?
>
> thanks,
> Peter
>
>
>
>
>
>
>
>
> On 23/07/2021 06:13, 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 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Gyan Mishra]

I see it.

Thanks Les & Peter!

Gyan

On Fri, Jul 23, 2021 at 12:34 PM Les Ginsberg (ginsberg) 
wrote:

> Gyan –
>
>
>
> This question has been clearly addressed by Peter in his most recent post:
>
>
>
> 
>
> 2. Generic Metric is not something that must be defined as application
>
> independent, on the contrary, it's a value that is either assigned by
>
> operator or computed somehow. Advertising application specific values
>
> not only make sense, but would add value. TE metric is an example which
>
> is very close to Generic Metric and is supported in ASLA.
>
> 
>
>
>
> Please read his email for the complete response.
>
>
>
>Les
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Friday, July 23, 2021 8:26 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Acee Lindem (acee) ; Peter Psenak (ppsenak) <
> ppse...@cisco.com>; Ron Bonica ; Shraddha Hegde <
> shrad...@juniper.net>; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org;
> gregory.mir...@ztetx.com; lsr@ietf.org
> *Subject:* Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>
>
>
>
>
>
>
> I believe the gap is whether or not the Generic metric is like maximum
> bandwidth link attribute which is application independent and based on the
> use case in this draft of the WG can be convinced that this use case is for
> application independent.
>
>
>
> In RFC 8919 and RFC 8920 the normative language was chosen precisely for
> that purpose so that on a case by case basis for a an link attribute to be
> deemed ASLA or application independent.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Thu, Jul 22, 2021 at 3:44 PM Gyan Mishra  wrote:
>
>
>
> 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)  40cisco@dmarc.ietf.org> 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 

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

[Ketan Talaulikar (ketant)]

Hi Acee,

Indeed the mechanism for key rollover is well documented and widely implemented 
via configuration/provisioning methods.

My question was regarding how the specific steps/procedures as described in 
https://datatracker.ietf.org/doc/html/rfc8177#section-2.2 are going to get 
realized in this proposal where we have an IGP and PCEP protocols in operation.

To me the use of this mechanism in such dynamic and distributed routing 
protocol operations seems to be under-specified for a standards track document 
– not good enough for ensuring interoperable implementations.

Hope that clarifies and I’ll rest my case with that.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 23 July 2021 22:24
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Cc: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; p...@ietf.org
Subject: Re: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Friday, July 23, 2021 at 11:20 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org"
 
mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>>,
 "p...@ietf.org" mailto:p...@ietf.org>>
Subject: RE: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hi Acee,

Agree about the keychain provisioning part.

The distribution via IGP for the key selections and the handling  of the same 
in PCEP sounded new to me. Is there any precedent for this? How does it all 
work actually and what is needed on the PCE and PCC to handle the 
change/transitions – this is all missing – probably needs a PCEP spec? This is 
many PCCs trying to connect to a PCE. I was trying to understand this better 
and how all that weighs against a potential for attack/disruption by someone 
doing a M-i-M or replay attack.

Roll-over of keys with key-chains is well-understood.

https://datatracker.ietf.org/doc/html/rfc8177#section-2.2

As is TCP-AO and TLS authentication. The only further specification required 
would the configuration in the PCE YANG model(s).

Thanks,
Acee

Just some questions … as this seemed something new to me and the spec does not 
provide any pointers.

Thanks,
Ketan

From: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Sent: 23 July 2021 18:52
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
lsr@ietf.org
Cc: 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org;
 p...@ietf.org
Subject: Re: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Friday, July 23, 2021 at 9:10 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org"
 
mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>>,
 "p...@ietf.org" mailto:p...@ietf.org>>
Subject: RE: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hello All,

I have reviewed this draft and have the following comments for the authors to 
address and the WG to consider:


1) Is there any precedent for the advertisement of auth keychain info 
(ID/name) in such a manner that is flooded across the IGP domain? When the 
actual keychain anyway needs to be configured on all PCCs what is really the 
value in their advertisement other than possibly exposure to attack? I hope the 
security directorate reviewer looks at this closely and we get some early 
feedback specifically on this aspect.

The key-chain mechanism was standardized in RFC 8177 and is referenced by all 
the routing protocol YANG models. While key-chains, as well as, pre-shared keys 
need to be configured, having multiple configured key-chains that are 
selectable via discovery is obviously more operationally secure than having a 
single one.

Thanks,
Acee


2) In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their ASCII art 
pictures represent the OSPF TLVs. The ISIS TLV structure is different. While 
this will be obvious to most in this WG, I would request this to be clarified – 
perhaps by introducing separate diagrams for both protocols or skipping the art 
altogether.

3) RFC5088 applies to both OSPFv2 and OSPFv3. This is however not clear in 
the text of this document.

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

[Acee Lindem (acee)]

Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
Date: Friday, July 23, 2021 at 11:20 AM
To: Acee Lindem , "lsr@ietf.org" 
Cc: "draft-ietf-lsr-pce-discovery-security-supp...@ietf.org" 
, "p...@ietf.org" 

Subject: RE: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hi Acee,

Agree about the keychain provisioning part.

The distribution via IGP for the key selections and the handling  of the same 
in PCEP sounded new to me. Is there any precedent for this? How does it all 
work actually and what is needed on the PCE and PCC to handle the 
change/transitions – this is all missing – probably needs a PCEP spec? This is 
many PCCs trying to connect to a PCE. I was trying to understand this better 
and how all that weighs against a potential for attack/disruption by someone 
doing a M-i-M or replay attack.

Roll-over of keys with key-chains is well-understood.

https://datatracker.ietf.org/doc/html/rfc8177#section-2.2

As is TCP-AO and TLS authentication. The only further specification required 
would the configuration in the PCE YANG model(s).

Thanks,
Acee

Just some questions … as this seemed something new to me and the spec does not 
provide any pointers.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 23 July 2021 18:52
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Cc: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; p...@ietf.org
Subject: Re: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Friday, July 23, 2021 at 9:10 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org"
 
mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>>,
 "p...@ietf.org" mailto:p...@ietf.org>>
Subject: RE: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hello All,

I have reviewed this draft and have the following comments for the authors to 
address and the WG to consider:


1)  Is there any precedent for the advertisement of auth keychain info 
(ID/name) in such a manner that is flooded across the IGP domain? When the 
actual keychain anyway needs to be configured on all PCCs what is really the 
value in their advertisement other than possibly exposure to attack? I hope the 
security directorate reviewer looks at this closely and we get some early 
feedback specifically on this aspect.

The key-chain mechanism was standardized in RFC 8177 and is referenced by all 
the routing protocol YANG models. While key-chains, as well as, pre-shared keys 
need to be configured, having multiple configured key-chains that are 
selectable via discovery is obviously more operationally secure than having a 
single one.

Thanks,
Acee


2)  In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their ASCII art 
pictures represent the OSPF TLVs. The ISIS TLV structure is different. While 
this will be obvious to most in this WG, I would request this to be clarified – 
perhaps by introducing separate diagrams for both protocols or skipping the art 
altogether.

3)  RFC5088 applies to both OSPFv2 and OSPFv3. This is however not clear in 
the text of this document.

4)  Looks like RFC5088 asked for the PCE Capabilities Flags registry to be 
created as a top-level IANA OSPF registry - 
https://datatracker.ietf.org/doc/html/rfc5088#section-7.2 – so it should have 
been placed here : 
https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml. What 
seems to have happened is that it got created under OSPFv2 which is wrong - 
https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14.
 Since this draft updates RFC5088, it is necessary for this document to fix 
this error. I would support Les in that perhaps all of this (i.e. everything 
under/related to PCED TLV) ought to be moved under the IANA Common IGP registry 
here : https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml

5)  The document needs to be more specific and clear about which IANA 
registries to be used to avoid errors that have happened in the past (see (3) 
above).

6)  Appendix A, I believe what the authors intended here was that whether 
to use MD5 auth or not was part of discovery but static configuration on the 
PCE and PCC? The keychain introduced in this document can also be used along 
with MD5. Honestly, I don’t see a strong reason to not include MD5 in the 
signalling except that it is deprecated (even if widely deployed). This 
document would not conflict or contradict with RFC5440 if it did include a bit 
for MD5 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Les Ginsberg (ginsberg)]

Gyan –

This question has been clearly addressed by Peter in his most recent post:


2. Generic Metric is not something that must be defined as application
independent, on the contrary, it's a value that is either assigned by
operator or computed somehow. Advertising application specific values
not only make sense, but would add value. TE metric is an example which
is very close to Generic Metric and is supported in ASLA.


Please read his email for the complete response.

   Les

From: Gyan Mishra 
Sent: Friday, July 23, 2021 8:26 AM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Peter Psenak (ppsenak) 
; Ron Bonica ; Shraddha Hegde 
; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; 
gregory.mir...@ztetx.com; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt



I believe the gap is whether or not the Generic metric is like maximum 
bandwidth link attribute which is application independent and based on the use 
case in this draft of the WG can be convinced that this use case is for 
application independent.

In RFC 8919 and RFC 8920 the normative language was chosen precisely for that 
purpose so that on a case by case basis for a an link attribute to be deemed 
ASLA or application independent.

Kind Regards

Gyan

On Thu, Jul 22, 2021 at 3:44 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:

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) 
mailto:40cisco@dmarc.ietf.org>> 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 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Gyan Mishra]

I believe the gap is whether or not the Generic metric is like maximum
bandwidth link attribute which is application independent and based on the
use case in this draft of the WG can be convinced that this use case is for
application independent.

In RFC 8919 and RFC 8920 the normative language was chosen precisely for
that purpose so that on a case by case basis for a an link attribute to be
deemed ASLA or application independent.

Kind Regards

Gyan

On Thu, Jul 22, 2021 at 3:44 PM Gyan Mishra  wrote:

>
> 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)  40cisco@dmarc.ietf.org> 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
>> >

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

[Ketan Talaulikar (ketant)]

Hi Acee,

Agree about the keychain provisioning part.

The distribution via IGP for the key selections and the handling  of the same 
in PCEP sounded new to me. Is there any precedent for this? How does it all 
work actually and what is needed on the PCE and PCC to handle the 
change/transitions – this is all missing – probably needs a PCEP spec? This is 
many PCCs trying to connect to a PCE. I was trying to understand this better 
and how all that weighs against a potential for attack/disruption by someone 
doing a M-i-M or replay attack.

Just some questions … as this seemed something new to me and the spec does not 
provide any pointers.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 23 July 2021 18:52
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Cc: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; p...@ietf.org
Subject: Re: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Friday, July 23, 2021 at 9:10 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org"
 
mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>>,
 "p...@ietf.org" mailto:p...@ietf.org>>
Subject: RE: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hello All,

I have reviewed this draft and have the following comments for the authors to 
address and the WG to consider:


1) Is there any precedent for the advertisement of auth keychain info 
(ID/name) in such a manner that is flooded across the IGP domain? When the 
actual keychain anyway needs to be configured on all PCCs what is really the 
value in their advertisement other than possibly exposure to attack? I hope the 
security directorate reviewer looks at this closely and we get some early 
feedback specifically on this aspect.

The key-chain mechanism was standardized in RFC 8177 and is referenced by all 
the routing protocol YANG models. While key-chains, as well as, pre-shared keys 
need to be configured, having multiple configured key-chains that are 
selectable via discovery is obviously more operationally secure than having a 
single one.

Thanks,
Acee


2) In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their ASCII art 
pictures represent the OSPF TLVs. The ISIS TLV structure is different. While 
this will be obvious to most in this WG, I would request this to be clarified – 
perhaps by introducing separate diagrams for both protocols or skipping the art 
altogether.

3) RFC5088 applies to both OSPFv2 and OSPFv3. This is however not clear in 
the text of this document.

4) Looks like RFC5088 asked for the PCE Capabilities Flags registry to be 
created as a top-level IANA OSPF registry - 
https://datatracker.ietf.org/doc/html/rfc5088#section-7.2 – so it should have 
been placed here : 
https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml. What 
seems to have happened is that it got created under OSPFv2 which is wrong - 
https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14.
 Since this draft updates RFC5088, it is necessary for this document to fix 
this error. I would support Les in that perhaps all of this (i.e. everything 
under/related to PCED TLV) ought to be moved under the IANA Common IGP registry 
here : https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml

5) The document needs to be more specific and clear about which IANA 
registries to be used to avoid errors that have happened in the past (see (3) 
above).

6) Appendix A, I believe what the authors intended here was that whether to 
use MD5 auth or not was part of discovery but static configuration on the PCE 
and PCC? The keychain introduced in this document can also be used along with 
MD5. Honestly, I don’t see a strong reason to not include MD5 in the signalling 
except that it is deprecated (even if widely deployed). This document would not 
conflict or contradict with RFC5440 if it did include a bit for MD5 support as 
well. As  follow-on, perhaps this document should also update RFC5440 – 
specifically for the security section? I see RFC8253 introducing TLS that 
updates RFC5440 but nothing that introduces TCP-AO?. In any case, these are 
aspects for PCE WG so I will leave those to the experts there.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: 21 July 2021 22:16
To: lsr@ietf.org
Cc: 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org
Subject: [Lsr] WG Last Call for IGP extension for 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Acee Lindem (acee)]

Hi Ron, 

So perhaps, generic metric is not a legacy advertisement as strictly defined. 
However, we don't want to go down the path of treating new attributes in the 
same manner as legacy attributes. It seems the discussion is progressing and 
hopefully we will have a resolution. 

Thanks,
Acee

On 7/22/21, 1:28 PM, "Ron Bonica"  wrote:

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] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

[Acee Lindem (acee)]

Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
Date: Friday, July 23, 2021 at 9:10 AM
To: Acee Lindem , "lsr@ietf.org" 
Cc: "draft-ietf-lsr-pce-discovery-security-supp...@ietf.org" 
, "p...@ietf.org" 

Subject: RE: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hello All,

I have reviewed this draft and have the following comments for the authors to 
address and the WG to consider:


1)  Is there any precedent for the advertisement of auth keychain info 
(ID/name) in such a manner that is flooded across the IGP domain? When the 
actual keychain anyway needs to be configured on all PCCs what is really the 
value in their advertisement other than possibly exposure to attack? I hope the 
security directorate reviewer looks at this closely and we get some early 
feedback specifically on this aspect.

The key-chain mechanism was standardized in RFC 8177 and is referenced by all 
the routing protocol YANG models. While key-chains, as well as, pre-shared keys 
need to be configured, having multiple configured key-chains that are 
selectable via discovery is obviously more operationally secure than having a 
single one.

Thanks,
Acee


2)  In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their ASCII art 
pictures represent the OSPF TLVs. The ISIS TLV structure is different. While 
this will be obvious to most in this WG, I would request this to be clarified – 
perhaps by introducing separate diagrams for both protocols or skipping the art 
altogether.

3)  RFC5088 applies to both OSPFv2 and OSPFv3. This is however not clear in 
the text of this document.

4)  Looks like RFC5088 asked for the PCE Capabilities Flags registry to be 
created as a top-level IANA OSPF registry - 
https://datatracker.ietf.org/doc/html/rfc5088#section-7.2 – so it should have 
been placed here : 
https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml. What 
seems to have happened is that it got created under OSPFv2 which is wrong - 
https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14.
 Since this draft updates RFC5088, it is necessary for this document to fix 
this error. I would support Les in that perhaps all of this (i.e. everything 
under/related to PCED TLV) ought to be moved under the IANA Common IGP registry 
here : https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml

5)  The document needs to be more specific and clear about which IANA 
registries to be used to avoid errors that have happened in the past (see (3) 
above).

6)  Appendix A, I believe what the authors intended here was that whether 
to use MD5 auth or not was part of discovery but static configuration on the 
PCE and PCC? The keychain introduced in this document can also be used along 
with MD5. Honestly, I don’t see a strong reason to not include MD5 in the 
signalling except that it is deprecated (even if widely deployed). This 
document would not conflict or contradict with RFC5440 if it did include a bit 
for MD5 support as well. As  follow-on, perhaps this document should also 
update RFC5440 – specifically for the security section? I see RFC8253 
introducing TLS that updates RFC5440 but nothing that introduces TCP-AO?. In 
any case, these are aspects for PCE WG so I will leave those to the experts 
there.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 21 July 2021 22:16
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


___
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

[Ketan Talaulikar (ketant)]

Hello All,

I have reviewed this draft and have the following comments for the authors to 
address and the WG to consider:


  1.  Is there any precedent for the advertisement of auth keychain info 
(ID/name) in such a manner that is flooded across the IGP domain? When the 
actual keychain anyway needs to be configured on all PCCs what is really the 
value in their advertisement other than possibly exposure to attack? I hope the 
security directorate reviewer looks at this closely and we get some early 
feedback specifically on this aspect.
  2.  In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their ASCII art 
pictures represent the OSPF TLVs. The ISIS TLV structure is different. While 
this will be obvious to most in this WG, I would request this to be clarified – 
perhaps by introducing separate diagrams for both protocols or skipping the art 
altogether.
  3.  RFC5088 applies to both OSPFv2 and OSPFv3. This is however not clear in 
the text of this document.
  4.  Looks like RFC5088 asked for the PCE Capabilities Flags registry to be 
created as a top-level IANA OSPF registry - 
https://datatracker.ietf.org/doc/html/rfc5088#section-7.2 – so it should have 
been placed here : 
https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml. What 
seems to have happened is that it got created under OSPFv2 which is wrong - 
https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14.
 Since this draft updates RFC5088, it is necessary for this document to fix 
this error. I would support Les in that perhaps all of this (i.e. everything 
under/related to PCED TLV) ought to be moved under the IANA Common IGP registry 
here : https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml
  5.  The document needs to be more specific and clear about which IANA 
registries to be used to avoid errors that have happened in the past (see (3) 
above).
  6.  Appendix A, I believe what the authors intended here was that whether to 
use MD5 auth or not was part of discovery but static configuration on the PCE 
and PCC? The keychain introduced in this document can also be used along with 
MD5. Honestly, I don’t see a strong reason to not include MD5 in the signalling 
except that it is deprecated (even if widely deployed). This document would not 
conflict or contradict with RFC5440 if it did include a bit for MD5 support as 
well. As  follow-on, perhaps this document should also update RFC5440 – 
specifically for the security section? I see RFC8253 introducing TLS that 
updates RFC5440 but nothing that introduces TCP-AO?. In any case, these are 
aspects for PCE WG so I will leave those to the experts there.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 21 July 2021 22:16
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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts

[Ketan Talaulikar (ketant)]

Hello All,

I support the adoption of these drafts. This work is required to provide the 
necessary manageability YANG models for the equivalent protocol extension WG 
drafts.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 22 July 2021 16:18
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

[Peter Psenak]

Hi Ron,

keeping the normative statements aside.

We are defining a Generic Metric TLV.

1. The first and only defined usage at this point is for Flex-algo.

2. Generic Metric is not something that must be defined as application 
independent, on the contrary, it's a value that is either assigned by 
operator or computed somehow. Advertising application specific values 
not only make sense, but would add value. TE metric is an example which 
is very close to Generic Metric and is supported in ASLA.


3. Flex-algo is an application from the ASLA framework perspective and 
so far is only using ASLA encoded link attributes. It would make sense 
to continue to do so for Generic Metric.


4. If you feel you need the Generic Metric also as an application 
independent value, I'm fine, although I do not see the immediate use case.


Given the above, would not you thing that advertising Generic Metric in 
ASLA make sense?


thanks,
Peter








On 23/07/2021 06:13, 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 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Les Ginsberg (ginsberg)]

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
> 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Gyan Mishra]

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: