[Lsr] Re: Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Les Ginsberg (ginsberg)]

Acee -

As regards my comments, Shraddha is correct.
I explicitly stated this back on April 26:


Acee –

I left it up to Shraddha to introduce the I-bit or not – she has chosen not to 
do so.
I believe all of my comments have been addressed to my satisfaction – sorry if 
it appeared that I left this issue unresolved.

   Les


   Les

> -Original Message-
> From: Shraddha Hegde
> Sent: Thursday, May 16, 2024 1:55 AM
> To: Acee Lindem
> Cc: Shraddha Hegde ; Ketan Talaulikar ; lsr ; draft-ietf-lsr-flex-algo-bw-
> c...@ietf.org; Les Ginsberg (ginsberg)
> Subject: RE: [Lsr] Working Group Last Call for "Flexible Algorithms: 
> Bandwidth,
> Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07
> 
> Acee,
> 
> I believe Les and I have agreed to the text that I added and his comments are
> closed.
> Les, let me know if you don't agree.
> 
> I don't agree with Ketan's comment on removing code points from OSPF TE
> opaque LSAs.
> Early code points are already taken and implementations underway. If he can
> elaborate his concern
> With having generic metric in opaque LSA
> We can see what details need to be added in the draft.
> 
> I got some more comments from Peter. Will publish -12 soon.
> 
> 
> Rgds
> Shraddha
> 
> 
> 
> 
> Juniper Business Use Only
> -Original Message-
> From: Acee Lindem 
> Sent: Friday, May 10, 2024 12:29 AM
> To: Acee Lindem 
> Cc: Shraddha Hegde ; Ketan
> Talaulikar ; lsr ; 
> draft-ietf-lsr-flex-algo-
> bw-...@ietf.org; Les Ginsberg (ginsberg) 
> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: 
> Bandwidth,
> Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07
> 
> [External Email. Be cautious of content]
> 
> 
> Any update?
> 
> Thanks,
> Acee
> 
> > On Apr 26, 2024, at 11:53 AM, Acee Lindem 
> wrote:
> >
> > Hi Ketan, Shraddha and Les,
> >
> >
> > I’m trying to conclude this thread and send this document to the AD. I’ve
> read the Emails but I must admit I don’t understand all the arguments.
> >
> >
> > Ketan - if we have the generic-metric in IS-IS, why wouldn’t define it in 
> > OSPF
> as well? If you cannot provide a compelling argument, I ‘m going to request
> publication of the document send it to the actual LSR AD.
> >
> > Shraddha - I see that you included similar text in section 4.3.1 to address
> Les’s comment. I guess the example referring to Flex algo 128/129 is not
> needed.
> >
> > Les - I’m sure what the I-bit but I don’t see that adding it at this 
> > juncture is a
> good idea unless the described protocol enhancements don’t work without it.
> >
> > Thanks,
> > Acee
> >
> >
> >
> >> On Apr 15, 2024, at 02:46, Shraddha Hegde
>  wrote:
> >>
> >> Hi Ketan,
> >>  Thanks for reply.
> >> Pls see inline..
> >>
> >> Juniper Business Use Only
> >> From: Ketan Talaulikar 
> >> Sent: Monday, April 8, 2024 2:25 PM
> >> To: Shraddha Hegde 
> >> Cc: Acee Lindem ; lsr ;
> >> draft-ietf-lsr-flex-algo-bw-...@ietf.org
> >> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms:
> >> Bandwidth, Delay, Metrics and Constraints" -
> >> draft-ietf-lsr-flex-algo-bw-con-07
> >>  [External Email. Be cautious of content]  Hi Shraddha,  Thanks for
> >> your responses. Please check inline below for clarifications with KT.
> >>   On Thu, Apr 4, 2024 at 9:49 AM Shraddha Hegde
>  wrote:
> >> Hi Ketan,
> >>  Thanks for the review and comments.
> >> Pls see inline for replies.
> >>   Juniper Business Use Only
> >> From: Ketan Talaulikar 
> >> Sent: Thursday, March 21, 2024 10:07 PM
> >> To: Acee Lindem 
> >> Cc: lsr ; draft-ietf-lsr-flex-algo-bw-...@ietf.org
> >> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms:
> >> Bandwidth, Delay, Metrics and Constraints" -
> >> draft-ietf-lsr-flex-algo-bw-con-07
> >>  [External Email. Be cautious of content]  Hi All,  I have reviewed
> >> this document and believe it needs some further work before publication.
> >>  I am sharing my comments below:
> >>  1) There is the following text in sec 2.1 and 2.2 for Generic Metric.
> >>  A metric value of 0xFF is considered as maximum link metric and a link
> having this metric value MUST NOT be used during Flex-algorithm calculations
> [RFC9350]. The link with maximum generic metric value is not available for the
> use of Flexible Algorithms but is availble for other use cases.
> >>  I believe the FlexAlgo reference here is to
> https://urldefense.com/v3/__https://www.rfc-
> editor.org/rfc/rfc9350.html*name-max-metric-
> consideration__;Iw!!NEt6yMaO-gk!BeudAtZGk7-XssYqte2dyPuiegf-
> oXoroaYsXYyIEJLEdZf1Bh4Jn5Mopid4VlitSAJoWvYiC0bPAdcSDIhyKQ$   But
> the above text does not align with the RFC9350. If a link is to be made
> unavailable for FlexAlgos operating with a specific Generic Metric, then the
> way to do that is to omit that specific Generic Metric TLV from the ASLA for
> flex-algo application. The same would apply for other applications - just omit
> the metric. Why do we need a special MAX-LINK-METRIC value for 

[Lsr] Re: Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Hi Ketan,

Snipping to open points



2) This comment is specific to OSPF given the encoding differences it has with 
ISIS. Section 2.2 allows for Generic Metric TLV to be used in too many places 
without clear specification of what it is used for - this is a potential 
pitfall for interop issues. RFC9492 provides helpful directions for us here.
a) This draft specifies FlexAlgo extensions, it is natural that Generic Metric 
be advertised under ASLA TLV. No issues here.
b) This draft does not specify anything about use of generic metric in base 
OSPF and as a reminder there is nothing like L-bit in OSPF encoding. Therefore, 
it does not make sense to advertise Generic Metric outside of ASLA and under 
the OSPFv2 Extended Link TLV or OSPFv3 Router Link TLV.
c) This draft does not specify anything about use of generic metric with 
RSVP-TE/GMPLS. Therefore, it does not make sense to advertise Generic Metric in 
the TE Opaque LSAs.
We can have specific documents that introduce (b) or (c) when there is a proper 
specification.
 Generic metric is a link attribute and can be used by other applications 
apart from Flex-algo.
I don’t see a reason to not take code-points under other applicable LSAs.

KT> I disagree on this one. There is a reason why what is proposed in the draft 
for ISIS is OK - due to the L-bit in ASLA, we need codepoints both under ASLA 
and at the top level for FlexAlgo. There is no L-bit in OSPF and therefore this 
does not apply. The code-points can be allocated when the behavior is specified 
for those other LSAs and applications (beyond FlexAlgo) in OSPF. We should not 
set the precedent for allocating code-points for TLVs without any defined use 
or behavior.

 Early code points are taken and implementations underway for other 
applications.

“Implementations MUST support sending and receiving generic metric
sub-TLV in ASLA encodings as well as in the TLV 22/extended link LSA/TE-LSAs.
The usage of a generic metric by an individual application is subject to the 
same
rules that apply to other link attributes defined in respective standards.”

The above text clarifies the use of generic metric by individual application.

KT2> I am not sure this is sufficient. Let us take an example. How is the 
Generic Metric TLV received in OSPFv2 TE Opaque LSA handled and what is it used 
for?

 The text in the draft says the applications that make use of link 
attributes from TE LSA will also use generic metric from TE-LSA. All 
traditional TE applications like CSPF/RSVP make use of link-attributes from 
TE-LSA. I don’t see the need to say anything beyond what has already been said 
in the draft.

The Min Unidirectional Link Delay as advertised by sub-sub-TLV 12 of ASLA 
sub-TLV 
[RFC8920],
 MUST be compared against the Maximum delay advertised in the FAEMD sub-TLV.
 changed to “The Unidirectional Link Delay as advertised by sub-sub-TLV 12”

KT> Perhaps my comment was not clear. The following text would be more accurate:

The Min Delay value advertised via the Min/Max Unidirectional Link Delay 
sub-TLV [RFC7471] of the ASLA sub-TLV 
[RFC8920],
 MUST be compared against the Maximum delay advertised in the FAEMD sub-TLV.
 I think there is a misunderstanding here. You are proposing to use 
sub-tlv 13 where as the text in the draft clearly proposes to use sub-tlv 12. 
This probably justifies why it is important to specify sub-tlv number
And not just name.

KT2> Well, that is what I am also trying to point out ... that the draft is 
wrong :-) The one to use is 13  - please check below and let me know if I am 
missing something. I also urge you to stick to using OSPF conventions of using 
TLV names as opposed to the ISIS convention of using TLV numbers.

Refer: 
https://www.rfc-editor.org/rfc/rfc9350.html#section-5.2
 ... look for IGP metric type 1
And then: 
https://www.rfc-editor.org/rfc/rfc7471#section-4.2
 and 
https://www.rfc-editor.org/rfc/rfc8920.html#section-14.1
12
Unidirectional Link Delay
Y

[Lsr] Re: Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Acee,

I believe Les and I have agreed to the text that I added and his comments are 
closed.
Les, let me know if you don't agree.

I don't agree with Ketan's comment on removing code points from OSPF TE opaque 
LSAs.
Early code points are already taken and implementations underway. If he can 
elaborate his concern
With having generic metric in opaque LSA
We can see what details need to be added in the draft.

I got some more comments from Peter. Will publish -12 soon.


Rgds
Shraddha




Juniper Business Use Only
-Original Message-
From: Acee Lindem 
Sent: Friday, May 10, 2024 12:29 AM
To: Acee Lindem 
Cc: Shraddha Hegde ; Ketan Talaulikar 
; lsr ; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org; Les Ginsberg (ginsberg) 

Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]


Any update?

Thanks,
Acee

> On Apr 26, 2024, at 11:53 AM, Acee Lindem  wrote:
>
> Hi Ketan, Shraddha and Les,
>
>
> I’m trying to conclude this thread and send this document to the AD. I’ve 
> read the Emails but I must admit I don’t understand all the arguments.
>
>
> Ketan - if we have the generic-metric in IS-IS, why wouldn’t define it in 
> OSPF as well? If you cannot provide a compelling argument, I ‘m going to 
> request publication of the document send it to the actual LSR AD.
>
> Shraddha - I see that you included similar text in section 4.3.1 to address 
> Les’s comment. I guess the example referring to Flex algo 128/129 is not 
> needed.
>
> Les - I’m sure what the I-bit but I don’t see that adding it at this juncture 
> is a good idea unless the described protocol enhancements don’t work without 
> it.
>
> Thanks,
> Acee
>
>
>
>> On Apr 15, 2024, at 02:46, Shraddha Hegde 
>>  wrote:
>>
>> Hi Ketan,
>>  Thanks for reply.
>> Pls see inline..
>>
>> Juniper Business Use Only
>> From: Ketan Talaulikar 
>> Sent: Monday, April 8, 2024 2:25 PM
>> To: Shraddha Hegde 
>> Cc: Acee Lindem ; lsr ;
>> draft-ietf-lsr-flex-algo-bw-...@ietf.org
>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms:
>> Bandwidth, Delay, Metrics and Constraints" -
>> draft-ietf-lsr-flex-algo-bw-con-07
>>  [External Email. Be cautious of content]  Hi Shraddha,  Thanks for
>> your responses. Please check inline below for clarifications with KT.
>>   On Thu, Apr 4, 2024 at 9:49 AM Shraddha Hegde  wrote:
>> Hi Ketan,
>>  Thanks for the review and comments.
>> Pls see inline for replies.
>>   Juniper Business Use Only
>> From: Ketan Talaulikar 
>> Sent: Thursday, March 21, 2024 10:07 PM
>> To: Acee Lindem 
>> Cc: lsr ; draft-ietf-lsr-flex-algo-bw-...@ietf.org
>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms:
>> Bandwidth, Delay, Metrics and Constraints" -
>> draft-ietf-lsr-flex-algo-bw-con-07
>>  [External Email. Be cautious of content]  Hi All,  I have reviewed
>> this document and believe it needs some further work before publication.
>>  I am sharing my comments below:
>>  1) There is the following text in sec 2.1 and 2.2 for Generic Metric.
>>  A metric value of 0xFF is considered as maximum link metric and a link 
>> having this metric value MUST NOT be used during Flex-algorithm calculations 
>> [RFC9350]. The link with maximum generic metric value is not available for 
>> the use of Flexible Algorithms but is availble for other use cases.
>>  I believe the FlexAlgo reference here is to 
>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!BeudAtZGk7-XssYqte2dyPuiegf-oXoroaYsXYyIEJLEdZf1Bh4Jn5Mopid4VlitSAJoWvYiC0bPAdcSDIhyKQ$
>>But the above text does not align with the RFC9350. If a link is to be 
>> made unavailable for FlexAlgos operating with a specific Generic Metric, 
>> then the way to do that is to omit that specific Generic Metric TLV from the 
>> ASLA for flex-algo application. The same would apply for other applications 
>> - just omit the metric. Why do we need a special MAX-LINK-METRIC value for 
>> generic metric given that it is a new thing we are introducing?
>>   I see what you are saying. Text is updated as below for ISIS and 
>> similar for OSPF.
>> “A metric value of
>>0xFF is considered as maximum link metric and a link having
>>this metric value MUST be used during Flex-algorithm calculations
>>as a last resort link as described in sec 15.3 of RFC[9350]  KT>
>> Thanks - that works. Perhaps also clarify that to make the link unusable by 
>> FlexAlgo using that generic metric, the advertisement of the particular 
>> generic metric can be skipped.
>>  ok
>>   2) This comment is specific to OSPF given the encoding differences it has 
>> with ISIS. Section 2.2 allows for Generic Metric TLV to be used in too many 
>> places without clear specification of what it is used for - this is a 
>> potential pitfall for interop issues. RFC9492 provides helpful directions 
>> for