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

[Acee Lindem]

Hi Ketan, Shraddha, 

> On Apr 27, 2024, at 02:16, Ketan Talaulikar  wrote:
> 
> Hi Acee,
> 
> I've responded to the thread with Shraddha. There are still 3 issues open - 
> (1) an error with TLV reference, (2) a codepoint allocation being done 
> without specification, and (3) regarding the updates to FlexAlgo rules.
> 
> You have asked me about (2). There is no issue with Generic Metric codepoint 
> allocation as a sub-TLV for OSPFv2 Extended Link TLV (which also includes as 
> a sub-TLV of ASLA TLV) - its use for FlexAlgo is fully specified in this 
> document. My objection is to allocation for OSPFv2 TE Opaque LSA without any 
> specification being done on how it is used. I am just asking to leave that 
> out to a document that actually specifies the usage and let this draft 
> progress towards publication.

I agree - this should be removed for the OSPFv2 TE Opaque LSA. 

Shraddha - can you remove this - at least until usage is specified in a 
separate document.

Thanks,
Acee


> 
> Hope that clarifies.
> 
> Thanks,
> Ketan
> 
> On Fri, Apr 26, 2024 at 9:23 PM Acee Lindem  <mailto:acee.lin...@gmail.com>> wrote:
>> Hi Ketan, Shraddha and Les,  
>> 
>> 
>> I’m trying to conclude this thread and send this document to the AD. I’ve 
>> read the Emails but I must admit I don’t understand all the arguments. 
>> 
>> 
>> Ketan - if we have the generic-metric in IS-IS, why wouldn’t define it in 
>> OSPF as well? If you cannot provide a compelling argument, I ‘m going to 
>> request publication of the document send it to the actual LSR AD. 
>> 
>> Shraddha - I see that you included similar text in section 4.3.1 to address 
>> Les’s comment. I guess the example referring to Flex algo 128/129 is not 
>> needed. 
>> 
>> Les - I’m sure what the I-bit but I don’t see that adding it at this 
>> juncture is a good idea unless the described protocol enhancements don’t 
>> work without it. 
>> 
>> Thanks,
>> Acee
>> 
>> 
>> 
>>> On Apr 15, 2024, at 02:46, Shraddha Hegde 
>>> >> <mailto:40juniper@dmarc.ietf.org>> wrote:
>>> 
>>> Hi Ketan,
>>> 
>>>  
>>> 
>>> Thanks for reply.
>>> 
>>> Pls see inline..
>>> 
>>>  
>>> 
>>> 
>>> Juniper Business Use Only
>>> 
>>> From: Ketan Talaulikar >> <mailto:ketant.i...@gmail.com>> 
>>> Sent: Monday, April 8, 2024 2:25 PM
>>> To: Shraddha Hegde mailto:shrad...@juniper.net>>
>>> Cc: Acee Lindem mailto:acee.lin...@gmail.com>>; lsr 
>>> mailto:lsr@ietf.org>>; 
>>> draft-ietf-lsr-flex-algo-bw-...@ietf.org 
>>> <mailto: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 >> <mailto:shrad...@juniper.net>> wrote:
>>> 
>>> Hi Ketan,
>>> 
>>>  
>>> 
>>> Thanks for the review and comments.
>>> 
>>> Pls see inline for replies.
>>> 
>>>  
>>> 
>>>  
>>> 
>>> Juniper Business Use Only
>>> 
>>> From: Ketan Talaulikar >> <mailto:ketant.i...@gmail.com>> 
>>> Sent: Thursday, March 21, 2024 10:07 PM
>>> To: Acee Lindem mailto:acee.lin...@gmail.com>>
>>> Cc: lsr mailto:lsr@ietf.org>>; 
>>> draft-ietf-lsr-flex-algo-bw-...@ietf.org 
>>> <mailto: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 comme

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

[Ketan Talaulikar]

Hi Acee,

I've responded to the thread with Shraddha. There are still 3 issues open -
(1) an error with TLV reference, (2) a codepoint allocation being done
without specification, and (3) regarding the updates to FlexAlgo rules.

You have asked me about (2). There is no issue with Generic Metric
codepoint allocation as a sub-TLV for OSPFv2 Extended Link TLV (which also
includes as a sub-TLV of ASLA TLV) - its use for FlexAlgo is fully
specified in this document. My objection is to allocation for OSPFv2 TE
Opaque LSA without any specification being done on how it is used. I am
just asking to leave that out to a document that actually specifies the
usage and let this draft progress towards publication.

Hope that clarifies.

Thanks,
Ketan

On Fri, Apr 26, 2024 at 9:23 PM 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  40juniper@dmarc.ietf.org> 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
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC9350__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmuk-veyTXw$>].
> The link with maximum generic metric value is not available for the use of
> Flexible Algorithms but is availble for other use cases.
>
>
>
> I believe the FlexAlgo reference here is to
> https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumv0_0Zeg$>
>
>
>
>
> 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
>

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

[Ketan Talaulikar]

Hi Shraddha,

Please check inline below with KT2.

On Mon, Apr 15, 2024 at 12:16 PM 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
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC9350__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmuk-veyTXw$>].
> The link with maximum generic metric value is not available for the use of
> Flexible Algorithms but is availble for other use cases.
>
>
>
> I believe the FlexAlgo reference here is to
> https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumv0_0Zeg$>
>
>
>
>
> 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 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’

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

[Acee Lindem]

Thanks Les - I just wanted to make sure that the text added in -09 with respect 
to link metric on interface groups addressed your comment. 

Thanks,
Acee

> On Apr 26, 2024, at 13:54, Les Ginsberg (ginsberg) 
>  wrote:
> 
> 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
>  
> From: Acee Lindem 
> Sent: Friday, April 26, 2024 8:53 AM
> To: Shraddha Hegde 
> Cc: 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
>  
> 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 
>  <mailto:shraddha=40juniper@dmarc.ietf.org>> wrote:
>  
> Hi Ketan,
>  
> Thanks for reply.
> Pls see inline..
>  
>  
> Juniper Business Use Only
> 
> From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
> Sent: Monday, April 8, 2024 2:25 PM
> To: Shraddha Hegde mailto:shrad...@juniper.net>>
> Cc: Acee Lindem mailto:acee.lin...@gmail.com>>; lsr 
> mailto:lsr@ietf.org>>; 
> draft-ietf-lsr-flex-algo-bw-...@ietf.org 
> <mailto: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  <mailto:shrad...@juniper.net>> wrote:
> Hi Ketan,
>  
> Thanks for the review and comments.
> Pls see inline for replies.
>  
>  
> Juniper Business Use Only
> 
> From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
> Sent: Thursday, March 21, 2024 10:07 PM
> To: Acee Lindem mailto:acee.lin...@gmail.com>>
> Cc: lsr mailto:lsr@ietf.org>>; 
> draft-ietf-lsr-flex-algo-bw-...@ietf.org 
> <mailto: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 
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC9350__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmuk-veyTXw$>].
>  The link with maximum generic metric value is not available for the use of 
> Flexible Algorithms but is availble for other use cases.
>  
> I believe the FlexAlgo reference here is to 
> https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration 
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumv0_0Zeg$>
>  
>  
> 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

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

[Les Ginsberg (ginsberg)]

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

From: Acee Lindem 
Sent: Friday, April 26, 2024 8:53 AM
To: Shraddha Hegde 
Cc: 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

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 
mailto:shraddha=40juniper@dmarc.ietf.org>>
 wrote:

Hi Ketan,

Thanks for reply.
Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Monday, April 8, 2024 2:25 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: Acee Lindem mailto:acee.lin...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto: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 
mailto:shrad...@juniper.net>> wrote:
Hi Ketan,

Thanks for the review and comments.
Pls see inline for replies.



Juniper Business Use Only
From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Thursday, March 21, 2024 10:07 PM
To: Acee Lindem mailto:acee.lin...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto: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<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC9350__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmuk-veyTXw$>].
 The link with maximum generic metric value is not available for the use of 
Flexible Algorithms but is availble for other use cases.

I believe the FlexAlgo reference here is to 
https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumv0_0Zeg$>

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

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

[Acee Lindem]

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  <mailto:shrad...@juniper.net>> wrote:
> Hi Ketan,
>  
> Thanks for the review and comments.
> Pls see inline for replies.
>  
>  
> Juniper Business Use Only
> 
> From: Ketan Talaulikar mailto:ketant.i...@gmail.com>> 
> Sent: Thursday, March 21, 2024 10:07 PM
> To: Acee Lindem mailto:acee.lin...@gmail.com>>
> Cc: lsr mailto:lsr@ietf.org>>; 
> draft-ietf-lsr-flex-algo-bw-...@ietf.org 
> <mailto: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 
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC9350__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmuk-veyTXw$>].
>  The link with maximum generic metric value is not available for the use of 
> Flexible Algorithms but is availble for other use cases.
>  
> I believe the FlexAlgo reference here is to 
> https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration 
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumv0_0Zeg$>
>  
>  
> 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 
> 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 spec

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

[Shraddha Hegde]

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 
mailto:shrad...@juniper.net>> wrote:
Hi Ketan,

Thanks for the review and comments.
Pls see inline for replies.



Juniper Business Use Only
From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Thursday, March 21, 2024 10:07 PM
To: Acee Lindem mailto:acee.lin...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto: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<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC9350__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmuk-veyTXw$>].
 The link with maximum generic metric value is not available for the use of 
Flexible Algorithms but is availble for other use cases.

I believe the FlexAlgo reference here is to 
https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumv0_0Zeg$>

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 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 se

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

[Shraddha Hegde]

Les,

Given that most cases can be satisfied with the text I proposed,
I don't really see the need of introducing another bit.
I'll add the text in -09 version.

Rgds
Shraddha


Juniper Business Use Only
-Original Message-
From: Les Ginsberg (ginsberg)
Sent: Friday, April 12, 2024 9:46 PM
To: Shraddha Hegde ; Acee Lindem ; lsr
Cc: 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]


Shraddha -

Thanx for the response.
Please see inline.


Juniper Business Use Only
> -Original Message-
> From: Shraddha Hegde
> Sent: Friday, April 12, 2024 8:02 AM
> To: Les Ginsberg (ginsberg) ; Acee Lindem ; lsr
> Cc: 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
>
> Hi Les,
>
> Thanks for bringing-up this point.
> I agree some clarification is required for the case when G bit is set

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

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

[Les Ginsberg (ginsberg)]

Shraddha -

Thanx for the response.
Please see inline.

> -Original Message-
> From: Shraddha Hegde
> Sent: Friday, April 12, 2024 8:02 AM
> To: Les Ginsberg (ginsberg) ; Acee Lindem ; lsr
> Cc: 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
> 
> Hi Les,
> 
> Thanks for bringing-up this point.
> I agree some clarification is required for the case when G bit is set.
> 
> In case of automatic metric calculation, there may be some links that are
> outliers and an operator
> may want to statically configure the bandwidth metric for such links. This is
> the reason, if bandwidth metric
> is advertised that MUST be used.
> 
> I think providing an I bit at the FAD level would mean network wide and the
> flexibility of overriding
> On a per-link basis won't be possible.
> 
[LES:] True - but this option is at the control of the operator. They can 
choose to set the I-bit or not.

> "In case of Interface Group Mode, if all the parallel links have been 
> advertised
> with the Bandwidth Metric, The individual link Bandwidth Metric MUST be
> used. If only some links among the parallel links have the Bandwidth Metric
> advertisement, the Bandwidth Metric for such links MUST be ignored and
> automatic
> Metric calculation MUST be used to derive link metric"
>
[LES:] This sounds good to me - but I point out this is the equivalent of 
always having the I-bit set - the only exception being when all links have link 
bandwidth advertised.

 
> For the case you described where for different flex-algorithms are using some
> of the parallel links an operator can use below options.
> > Option 1:
> For flex-algo 128, which uses configured bandwidth metric, use user
> defined metric type 128 and flex-algo 128 to use metric-type 128.
>   For Flex-algo 129 use automatic bandwidth metric with G bit set.
>   > Option 2:
> For flex-algo 128 use configured  bandwidth metric
>   For flex-algo 129 use automatic bandwidth metric.
> 
[LES:] I do not like Option #1. I think user defined metric is intended to 
allow the user to set metric values based on their own heuristics - not to 
address this use case.
Option #2 seems consistent with the new text you proposed above - so this seems 
appropriate to me.

In summary, I think the only open issue is whether to introduce the I-bit or 
not. Doing so would provide some additional flexibility - but given the other 
changes you propose I won’t insist.

   Les

> Let me know what you think.
> 
> 
> Rgds
> Shraddha
> 
> Juniper Business Use Only
> -Original Message-----
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, April 9, 2024 1:08 AM
> To: Acee Lindem ; lsr 
> Cc: 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]
> 
> 
> Draft authors -
> 
> Regarding Section 5, which defines the rules for deriving Bandwidth metric,
> Rule #1 states:
> 
> "If the Generic Metric sub-TLV with Bandwidth metric type is advertised for 
> the
> link as described in Section 4, it MUST be used during the Flex-Algorithm
> calculation."
> 
> I think this constraint does not fit all possible use cases.
> 
> (Note: For brevity, I am inventing the acronym GMBM to represent "Generic
> Metric sub-TLV with Bandwidth metric type".)
> 
> Consider two nodes A, B that are connected by two parallel links - call them
> AB-1 and AB-2.
> 
> Suppose a customer deploys Flex-Algo 128, which specifies use of Bandwidth
> Metric, but also uses affinity to exclude link AB-2. Customer configures
> advertisement of GMBM for link AB-1 - all is working as expected.
> 
> Now customer deploys Flex-Algo 129, also specifying use of bandwidth
> metric, but wants both links (AB-1, AB-2) to be used and wants automatic
> bandwidth metric calculation to be used so metric automatically adapts to the
> number of links which are up between A-B. Since there is advertisement of
> GMBM for link AB-1, automatic bandwidth calculation cannot include Link AB-
> 1 - which means the customer does not have a way to get what is desired
> without:
> 
> o Removing the advertisement of GMBM for AB-1 o Adding automatic
> bandwidth to the FAD for Flex-Algo 128
> 
> This might be quite surprising to a customer - especially if Flex-Algo 128 has
> been deployed for some time and has been working well.
> 
> There are probably 

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

[Shraddha Hegde]

Hi Les,

Thanks for bringing-up this point.
I agree some clarification is required for the case when G bit is set.

In case of automatic metric calculation, there may be some links that are 
outliers and an operator
may want to statically configure the bandwidth metric for such links. This is 
the reason, if bandwidth metric
is advertised that MUST be used.

I think providing an I bit at the FAD level would mean network wide and the 
flexibility of overriding
On a per-link basis won't be possible.

"In case of Interface Group Mode, if all the parallel links have been 
advertised with the Bandwidth Metric, The individual link Bandwidth Metric MUST 
be used. If only some links among the parallel links have the Bandwidth Metric 
advertisement, the Bandwidth Metric for such links MUST be ignored and automatic
Metric calculation MUST be used to derive link metric"

For the case you described where for different flex-algorithms are using some 
of the parallel links an operator can use below options.
> Option 1:
For flex-algo 128, which uses configured bandwidth metric, use user 
defined metric type 128 and flex-algo 128 to use metric-type 128.
  For Flex-algo 129 use automatic bandwidth metric with G bit set.
  > Option 2:
For flex-algo 128 use configured  bandwidth metric
  For flex-algo 129 use automatic bandwidth metric.

Let me know what you think.


Rgds
Shraddha

Juniper Business Use Only
-Original Message-
From: Les Ginsberg (ginsberg) 
Sent: Tuesday, April 9, 2024 1:08 AM
To: Acee Lindem ; lsr 
Cc: 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]


Draft authors -

Regarding Section 5, which defines the rules for deriving Bandwidth metric, 
Rule #1 states:

"If the Generic Metric sub-TLV with Bandwidth metric type is advertised for the 
link as described in Section 4, it MUST be used during the Flex-Algorithm 
calculation."

I think this constraint does not fit all possible use cases.

(Note: For brevity, I am inventing the acronym GMBM to represent "Generic 
Metric sub-TLV with Bandwidth metric type".)

Consider two nodes A, B that are connected by two parallel links - call them 
AB-1 and AB-2.

Suppose a customer deploys Flex-Algo 128, which specifies use of Bandwidth 
Metric, but also uses affinity to exclude link AB-2. Customer configures 
advertisement of GMBM for link AB-1 - all is working as expected.

Now customer deploys Flex-Algo 129, also specifying use of bandwidth metric, 
but wants both links (AB-1, AB-2) to be used and wants automatic bandwidth 
metric calculation to be used so metric automatically adapts to the number of 
links which are up between A-B. Since there is advertisement of GMBM for link 
AB-1, automatic bandwidth calculation cannot include Link AB-1 - which means 
the customer does not have a way to get what is desired without:

o Removing the advertisement of GMBM for AB-1 o Adding automatic bandwidth to 
the FAD for Flex-Algo 128

This might be quite surprising to a customer - especially if Flex-Algo 128 has 
been deployed for some time and has been working well.

There are probably multiple ways this limitation could be overcome.

One way would be to define an additional bit in the bandwidth constraint 
sub-TLVs - call it the I-bit - meaning ignore GMBM even when advertised.
This would specify use of the automated calculation based on the bandwidth of 
all links even in the presence of an explicit GMBM on one or more members of 
the Group.

Related to this, I think some clarification as regards the existing G-bit is 
required i.e., I assume that automatic calculation only includes the bandwidth 
for links which do not have a GMBM advertisement - but the current text is not 
clear on that point.

Les

> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Monday, February 19, 2024 2:26 PM
> To: lsr 
> Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org
> Subject: [Lsr] Working Group Last Call for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-ietf-lsr-flex-algo-bw-con-07
>
>
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07.
> At least some of the flex algorithm enhancements described in the
> document have been implemented.
>
>  Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!CnWa8DhzclXyIWWfxwRc7drMZ8u5PeYwo-igztZ7ldO2XGqLDqrkUF
> YdW-wHndStV44AccJ0eM9SmM_X$

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

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

[Gyan Mishra]

I support publication and I believe this SR Algo feature will be highly
beneficial for operators.


Thanks

Gyan

On Mon, Feb 19, 2024 at 11:26 PM Acee Lindem  wrote:

>
> This starts the Working Group Last call for
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm
> enhancements described in the document have been implemented.
>
>  Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Draft authors -

Regarding Section 5, which defines the rules for deriving Bandwidth metric,
Rule #1 states:

"If the Generic Metric sub-TLV with Bandwidth metric type is advertised for the 
link as described in Section 4, it MUST be used during the Flex-Algorithm 
calculation."

I think this constraint does not fit all possible use cases.

(Note: For brevity, I am inventing the acronym GMBM to represent "Generic 
Metric sub-TLV with Bandwidth metric type".)

Consider two nodes A, B that are connected by two parallel links - call them 
AB-1 and AB-2.

Suppose a customer deploys Flex-Algo 128, which specifies use of Bandwidth 
Metric, but also uses affinity to exclude link AB-2. Customer configures 
advertisement of GMBM for link AB-1 - all is working as expected.

Now customer deploys Flex-Algo 129, also specifying use of bandwidth metric, 
but wants both links (AB-1, AB-2) to be used and wants automatic bandwidth 
metric
calculation to be used so metric automatically adapts to the number of links 
which are up between A-B. Since there is advertisement of GMBM for link AB-1, 
automatic bandwidth calculation cannot include Link AB-1 - which means the 
customer does not have a way to get what is desired without:

o Removing the advertisement of GMBM for AB-1
o Adding automatic bandwidth to the FAD for Flex-Algo 128

This might be quite surprising to a customer - especially if Flex-Algo 128 has 
been deployed for some time and has been working well.

There are probably multiple ways this limitation could be overcome.

One way would be to define an additional bit in the bandwidth constraint 
sub-TLVs - call it the I-bit - meaning ignore GMBM even when advertised.
This would specify use of the automated calculation based on the bandwidth of 
all links even in the presence of an explicit GMBM on one or more members of 
the Group.

Related to this, I think some clarification as regards the existing G-bit is 
required i.e., I assume that automatic calculation only includes the bandwidth 
for links which do not have a GMBM advertisement - but the current text is not 
clear on that point.

Les

> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Monday, February 19, 2024 2:26 PM
> To: lsr 
> Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org
> Subject: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth,
> Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07
> 
> 
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07.
> At least some of the flex algorithm enhancements described in the document
> have been implemented.
> 
>  Please send your support or objection to this before March 5th, 2024.
> 
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

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

[Ketan Talaulikar]

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
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC9350__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmuk-veyTXw$>].
> The link with maximum generic metric value is not available for the use of
> Flexible Algorithms but is availble for other use cases.
>
>
>
> I believe the FlexAlgo reference here is to
> https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumv0_0Zeg$>
>
>
>
>
> 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.


>
>
> 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.


>
>
> 3) Please introduce a reserved field to pad the OSPF FAEMD sub-TLV to a 4
> octet boundary as is the convention in OSPF -
> https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-3.2.2

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

[Jeff Tantsura]

Hey Acee,

Yes/support, valuable addition.

Thanks,
Jeff

> On Feb 19, 2024, at 14:25, Acee Lindem  wrote:
> 
> 
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm 
> enhancements described in the document have been implemented. 
> 
> Please send your support or objection to this before March 5th, 2024. 
> 
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

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

[Shraddha Hegde]

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<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC9350__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmuk-veyTXw$>].
 The link with maximum generic metric value is not available for the use of 
Flexible Algorithms but is availble for other use cases.

I believe the FlexAlgo reference here is to 
https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumv0_0Zeg$>

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]

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.

3) Please introduce a reserved field to pad the OSPF FAEMD sub-TLV to a 4 octet 
boundary as is the convention in OSPF - 
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-3.2.2<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*section-3.2.2__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmunYcymQgw$>
 OK

4) In section 3.2.2 there is the following text for OSPF. Could you please use 
the TLV/sub-TLV name? OSPF folks are not good at remembering numbers ;-)

The Min Unidirectional Link Delay as advertised by sub-sub-TLV 12 of ASLA 
sub-TLV 
[RFC8920<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC8920__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmun5uDKc7A$>],
 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”

5) Do we want to call out that the reference bandwidth approach requires a 
router to compute and maintain a per link per algo bandwidth metric for every 
link in that algo topology. It may not be very obvious to some.
 updated as below
“Advertising
   the reference bandwidth in the FAD constraints allows the metric
   computation to be done on every node for each link.
   The metric is computed using reference bandwidth and the advertised link 
bandwidth.
   Centralized control of this
   reference bandwidth

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

[Acee Lindem]

Co-Authors, 

I believe these are the only pending WG last comments. 

Thanks,
Acee

> On Mar 21, 2024, at 12:36 PM, Ketan Talaulikar  wrote:
> 
> 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://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration 
> But the above text does not align with the RFC9350. If a link is to be made 
> unavailable for FlexAlgos operating with a specific Generic Metric, then the 
> way to do that is to omit that specific Generic Metric TLV from the ASLA for 
> flex-algo application. The same would apply for other applications - just 
> omit the metric. Why do we need a special MAX-LINK-METRIC value for generic 
> metric given that it is a new thing we are introducing?
> 
> 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.
> 
> 3) Please introduce a reserved field to pad the OSPF FAEMD sub-TLV to a 4 
> octet boundary as is the convention in OSPF - 
> https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-3.2.2
> 
> 4) In section 3.2.2 there is the following text for OSPF. Could you please 
> use the TLV/sub-TLV name? OSPF folks are not good at remembering numbers ;-)
> 
> The Min Unidirectional Link Delay as advertised by sub-sub-TLV 12 of ASLA 
> sub-TLV [RFC8920], MUST be compared against the Maximum delay advertised in 
> the FAEMD sub-TLV. 
> 
> 5) Do we want to call out that the reference bandwidth approach requires a 
> router to compute and maintain a per link per algo bandwidth metric for every 
> link in that algo topology. It may not be very obvious to some.
> 
> 6) There are a lot of procedures which are common to both OSPF and ISIS and 
> are repeated in each section instead of a common section. It would be easier 
> (and avoid errors) if there was some consolidation. 
> https://www.rfc-editor.org/rfc/rfc9350.html#section-5 provides a good 
> reference for such an organization of text.
> 
> 7) Regarding 
> https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-6,
>  it seems like we want to retain a numbering ordering of rules/sequence for 
> flex-algo as extension documents are introduced. Am I correct? If so, then 
> this document should formally "update" RFC9350 since it is changing the "set 
> of rules/sequence" for FlexAlgo computations. Further such extensions will 
> also need to keep updating the base spec similarly. I would suggest that a 
> full set of rules that is a union of what is in RFC9350 and rules added by 
> this draft are maintained in an Appendix section. Other documents in the 
> future can similarly maintain the latest set of rules.
> 
> 8) Please fix idnits warnings - some are related to obsolete references while 
> others are related to formatting. There are also some spelling/grammar errors.
> 
> Thanks,
> Ketan
> 
> 
> On Tue, Feb 20, 2024 at 3:56 AM Acee Lindem  wrote:
> 
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm 
> enhancements described in the document have been implemented. 
> 
>  Please send your support or objection to this before March 5th, 2024. 
> 
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org

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

[Ketan Talaulikar]

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://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration

But the above text does not align with the RFC9350. If a link is to be made
unavailable for FlexAlgos operating with a specific Generic Metric, then
the way to do that is to omit that specific Generic Metric TLV from the
ASLA for flex-algo application. The same would apply for other applications
- just omit the metric. Why do we need a special MAX-LINK-METRIC value for
generic metric given that it is a new thing we are introducing?

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.

3) Please introduce a reserved field to pad the OSPF FAEMD sub-TLV to a 4
octet boundary as is the convention in OSPF -
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-3.2.2

4) In section 3.2.2 there is the following text for OSPF. Could you please
use the TLV/sub-TLV name? OSPF folks are not good at remembering numbers ;-)

The Min Unidirectional Link Delay as advertised by *sub-sub-TLV 12* of ASLA
sub-TLV [RFC8920

], MUST be compared against the Maximum delay advertised in the FAEMD
sub-TLV.

5) Do we want to call out that the reference bandwidth approach requires a
router to compute and maintain a per link per algo bandwidth metric for
every link in that algo topology. It may not be very obvious to some.

6) There are a lot of procedures which are common to both OSPF and ISIS and
are repeated in each section instead of a common section. It would be
easier (and avoid errors) if there was some consolidation.
https://www.rfc-editor.org/rfc/rfc9350.html#section-5 provides a good
reference for such an organization of text.

7) Regarding
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-6,
it seems like we want to retain a numbering ordering of rules/sequence for
flex-algo as extension documents are introduced. Am I correct? If so, then
this document should formally "update" RFC9350 since it is changing the
"set of rules/sequence" for FlexAlgo computations. Further such extensions
will also need to keep updating the base spec similarly. I would suggest
that a full set of rules that is a union of what is in RFC9350 and rules
added by this draft are maintained in an Appendix section. Other documents
in the future can similarly maintain the latest set of rules.

8) Please fix idnits warnings - some are related to obsolete references
while others are related to formatting. There are also some
spelling/grammar errors.

Thanks,
Ketan


On Tue, Feb 20, 2024 at 3:56 AM Acee Lindem  wrote:

>
> This starts the Working Group Last call for
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm
> enhancements described in the document have been implemented.
>
>  Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem]

Hi Shraddha, 


> On Mar 18, 2024, at 6:51 AM, Shraddha Hegde 
>  wrote:
> 
> Acee,
>  I read your comment about elephant flow and added below text in sec 4.1.1.2
>  “Note that a single elephant flow is normally
>pinned to a single layer-3 interface. If the single layer-3 link
>bandwidth is not sufficient for any single elephant flow, the mechanisms
>to solve this issue are outside the scope of this document”

Yes. 

> Replace the term “centralized controller” with “PCE”

Yes. A reference for the PCE solution would be good as well. 



>  Posting -08 version now. Pls check


Thanks for addressing my comments. I still have not gotten an IPR statement 
from 
William Britto. If he is no longer associated with the draft, removing him 
would reduce
the number of authors to five. 

Thanks,
Acee



>  Rgds
> Shraddha
>  
> Juniper Business Use Only
> From: Lsr  On Behalf Of Shraddha Hegde
> Sent: Wednesday, March 6, 2024 12:22 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 Acee,
>  Thanks for the review and edits.
> I have incorporated all edits.
> Will post -08 when window opens.
> Pls see inline for replies
>   Juniper Business Use Only
>  Juniper Business Use Only
> From: Acee Lindem  
> Sent: Friday, March 1, 2024 4:16 AM
> 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]
> 
> 
> Authors,
> 
> I support publication of this document but not in its current state. I have 
> the following comments that should be resolved first:
> 
> 1. "Backward Compatibility" section is missing. This should be 
> straightforward given that an FAD computation only includes
> nodes supporting that FAD.
>  OK
> 
>  2. “Security Considerations” is “TBD”.
>  ok
> 
>  3. There is no “Operational Considerations” section. Someone may ask for 
> one.
>  ok
> 
>  4. The document alludes to the problem with elephant flows. Yet for 
> “Interface Group Mode”, the aggregate bandwidth for multiple L3 links is 
> used. How would this work when a flow is typically bound to a single L3 
> interface?
>  All we are trying to do in this document is to assign metric relative to 
> bandwidth. IGPs cannot  do any bandwidth management and path placement and 
> it’s been mentioned in the introduction section clearly.
> 
>  5. #3 in section 5 is very hard to parse. Possibly split into multiple 
> coherent sentences.
>  will do
> 
> 
> Lots of editorial nits - I’m attaching some suggested edits but I’m not sure 
> I got them all.
> 
>   1. Use “sub-TLV” and “Sub-TLV” consistent with the usage in RFC  9350. 
> I tried to fix these on the fly but it probably still needs work. Basically, 
> it is capitalized when used as part of a proper noun identifying a specific 
> sub-TLV. Also, in section titles and captions.
>  will do
> 
>   2. Reference RFC9350 rather than the Flex-Algo draft throughout.
>  ok
> 
>   3. I didn’t make the change but I’d use “Layer-2” and “Layer-3” 
> hyphenated.
> ok
> 
> 
> See attached editorial suggestions  in the RFC diff.
> 
> Thanks,
> Acee
> 
> 
> > On Feb 19, 2024, at 5:25 PM, Acee Lindem  wrote:
> > 
> > 
> > This starts the Working Group Last call for 
> > draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm 
> > enhancements described in the document have been implemented. 
> > 
> > Please send your support or objection to this before March 5th, 2024. 
> > 
> > Thanks,
> > Acee
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$
> ___
> 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] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Acee,

I read your comment about elephant flow and added below text in sec 4.1.1.2

“Note that a single elephant flow is normally
   pinned to a single layer-3 interface. If the single layer-3 link
   bandwidth is not sufficient for any single elephant flow, the mechanisms
   to solve this issue are outside the scope of this document”
Replace the term “centralized controller” with “PCE”

Posting -08 version now. Pls check

Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Shraddha Hegde
Sent: Wednesday, March 6, 2024 12:22 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 Acee,

Thanks for the review and edits.
I have incorporated all edits.
Will post -08 when window opens.
Pls see inline for replies



Juniper Business Use Only


Juniper Business Use Only
From: Acee Lindem mailto:acee.lin...@gmail.com>>
Sent: Friday, March 1, 2024 4:16 AM
To: Acee Lindem mailto:acee.lin...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto: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]


Authors,

I support publication of this document but not in its current state. I have the 
following comments that should be resolved first:

1. "Backward Compatibility" section is missing. This should be 
straightforward given that an FAD computation only includes
nodes supporting that FAD.
 OK

 2. “Security Considerations” is “TBD”.
 ok

 3. There is no “Operational Considerations” section. Someone may ask for 
one.
 ok

 4. The document alludes to the problem with elephant flows. Yet for 
“Interface Group Mode”, the aggregate bandwidth for multiple L3 links is used. 
How would this work when a flow is typically bound to a single L3 interface?
 All we are trying to do in this document is to assign metric relative to 
bandwidth. IGPs cannot  do any bandwidth management and path placement and it’s 
been mentioned in the introduction section clearly.

 5. #3 in section 5 is very hard to parse. Possibly split into multiple 
coherent sentences.
 will do


Lots of editorial nits - I’m attaching some suggested edits but I’m not sure I 
got them all.

  1. Use “sub-TLV” and “Sub-TLV” consistent with the usage in RFC  9350. I 
tried to fix these on the fly but it probably still needs work. Basically, it 
is capitalized when used as part of a proper noun identifying a specific 
sub-TLV. Also, in section titles and captions.
 will do

  2. Reference RFC9350 rather than the Flex-Algo draft throughout.
 ok

  3. I didn’t make the change but I’d use “Layer-2” and “Layer-3” 
hyphenated.
ok


See attached editorial suggestions  in the RFC diff.

Thanks,
Acee


> On Feb 19, 2024, at 5:25 PM, Acee Lindem 
> mailto:acee.lin...@gmail.com>> wrote:
>
>
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm 
> enhancements described in the document have been implemented.
>
> Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org<mailto:Lsr@ietf.org>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem]

Hi Shraddha, 

See one inline. 

> On Mar 6, 2024, at 1:51 AM, Shraddha Hegde 
>  wrote:
> 
> Hi Acee,
>  Thanks for the review and edits.
> I have incorporated all edits.
> Will post -08 when window opens.
> Pls see inline for replies
>  
> Juniper Business Use Only
> From: Acee Lindem  
> Sent: Friday, March 1, 2024 4:16 AM
> 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]
> 
> 
> Authors,
> 
> I support publication of this document but not in its current state. I have 
> the following comments that should be resolved first:
> 
> 1. "Backward Compatibility" section is missing. This should be 
> straightforward given that an FAD computation only includes
> nodes supporting that FAD.
>  OK
> 
>  2. “Security Considerations” is “TBD”.
>  ok
> 
>  3. There is no “Operational Considerations” section. Someone may ask for 
> one.
>  ok
> 
>  4. The document alludes to the problem with elephant flows. Yet for 
> “Interface Group Mode”, the aggregate bandwidth for multiple L3 links is 
> used. How would this work when a flow is typically bound to a single L3 
> interface?
>  All we are trying to do in this document is to assign metric relative to 
> bandwidth. IGPs cannot  do any bandwidth management and path placement and 
> it’s been mentioned in the introduction section clearly. 

The introduction implies the elephant flow problem is fixed.

High bandwidth traffic such as residential internet traffic and
 machine to machine elephant flows benefit from using high capacity
 links. Accordingly, many network operators define a link's metric
 relative to its capacity to help direct traffic to higher bandwidth
 links, but this is no guarantee that lower bandwidth links will be
 avoided, especially in failure scenarios. To ensure that elephant
 flows are only placed on high capacity links, it would be useful to
 explicitly exclude the high bandwidth traffic from utilizing links
 below a certain capacity. 

It seems that the 4.1.1.2 should either have a caveat that elephant flows would 
normally be pinned to a single layer-3 link or the flow shouldn't be pinned and 
should use all the links in the group. 

Also, I'd remove the last sentence of the Introduction or provide an 
informational reference on the central controller.  
  
 Thus, the procedures described in this document
 are not a replacement to the capability of a centralized controller
   which has dynamic view of the network and provides real time
 bandwidth management or a distributed bandwidth management protocol. 

Thanks,
Acee
 
 

> 
>  5. #3 in section 5 is very hard to parse. Possibly split into multiple 
> coherent sentences.
>  will do
> 
> 
> Lots of editorial nits - I’m attaching some suggested edits but I’m not sure 
> I got them all.
> 
>   1. Use “sub-TLV” and “Sub-TLV” consistent with the usage in RFC  9350. 
> I tried to fix these on the fly but it probably still needs work. Basically, 
> it is capitalized when used as part of a proper noun identifying a specific 
> sub-TLV. Also, in section titles and captions.
>  will do
> 
>   2. Reference RFC9350 rather than the Flex-Algo draft throughout.
>  ok
> 
>   3. I didn’t make the change but I’d use “Layer-2” and “Layer-3” 
> hyphenated.
> ok
> 
> 
> See attached editorial suggestions  in the RFC diff.
> 
> Thanks,
> Acee
> 
> 
> > On Feb 19, 2024, at 5:25 PM, Acee Lindem  wrote:
> > 
> > 
> > This starts the Working Group Last call for 
> > draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm 
> > enhancements described in the document have been implemented. 
> > 
> > Please send your support or objection to this before March 5th, 2024. 
> > 
> > Thanks,
> > Acee
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$
> ___
> 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] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Hi Acee,

Thanks for the review and edits.
I have incorporated all edits.
Will post -08 when window opens.
Pls see inline for replies



Juniper Business Use Only
From: Acee Lindem 
Sent: Friday, March 1, 2024 4:16 AM
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]


Authors,

I support publication of this document but not in its current state. I have the 
following comments that should be resolved first:

1. "Backward Compatibility" section is missing. This should be 
straightforward given that an FAD computation only includes
nodes supporting that FAD.
 OK

 2. “Security Considerations” is “TBD”.
 ok

 3. There is no “Operational Considerations” section. Someone may ask for 
one.
 ok

 4. The document alludes to the problem with elephant flows. Yet for 
“Interface Group Mode”, the aggregate bandwidth for multiple L3 links is used. 
How would this work when a flow is typically bound to a single L3 interface?
 All we are trying to do in this document is to assign metric relative to 
bandwidth. IGPs cannot  do any bandwidth management and path placement and it’s 
been mentioned in the introduction section clearly.

 5. #3 in section 5 is very hard to parse. Possibly split into multiple 
coherent sentences.
 will do


Lots of editorial nits - I’m attaching some suggested edits but I’m not sure I 
got them all.

  1. Use “sub-TLV” and “Sub-TLV” consistent with the usage in RFC  9350. I 
tried to fix these on the fly but it probably still needs work. Basically, it 
is capitalized when used as part of a proper noun identifying a specific 
sub-TLV. Also, in section titles and captions.
 will do

  2. Reference RFC9350 rather than the Flex-Algo draft throughout.
 ok

  3. I didn’t make the change but I’d use “Layer-2” and “Layer-3” 
hyphenated.
ok


See attached editorial suggestions  in the RFC diff.

Thanks,
Acee


> On Feb 19, 2024, at 5:25 PM, Acee Lindem 
> mailto:acee.lin...@gmail.com>> wrote:
>
>
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm 
> enhancements described in the document have been implemented.
>
> Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org<mailto:Lsr@ietf.org>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[GAURAV HALWASIA]

 I support publication of this document.

ThanksGaurav Halwasia
On Tuesday, 20 February, 2024 at 03:56:32 am IST, Acee Lindem 
 wrote:  
 
 
This starts the Working Group Last call for draft-ietf-lsr-flex-algo-bw-con-07. 
At least some of the flex algorithm enhancements described in the document have 
been implemented. 

 Please send your support or objection to this before March 5th, 2024. 

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

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

[Les Ginsberg (ginsberg)]

I also support publication of this document.
The functionality defined herein adds valuable flexibility to the way Flex 
Topologies can be defined.

Although I have not reviewed Acee’s comments exhaustively, I agree with the 
points he is making and would like to see an updated version of the draft prior 
to making a final determination.

   Les


From: Lsr  On Behalf Of Acee Lindem
Sent: Thursday, February 29, 2024 2:46 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

Authors,

I support publication of this document but not in its current state. I have the 
following comments that should be resolved first:

1. "Backward Compatibility" section is missing. This should be 
straightforward given that an FAD computation only includes
nodes supporting that FAD.
 2. “Security Considerations” is “TBD”.
 3. There is no “Operational Considerations” section. Someone may ask for 
one.
 4. The document alludes to the problem with elephant flows. Yet for 
“Interface Group Mode”, the aggregate bandwidth for multiple L3 links is used. 
How would this work when a flow is typically bound to a single L3 interface?
 5. #3 in section 5 is very hard to parse. Possibly split into multiple 
coherent sentences.

Lots of editorial nits - I’m attaching some suggested edits but I’m not sure I 
got them all.

  1. Use “sub-TLV” and “Sub-TLV” consistent with the usage in RFC  9350. I 
tried to fix these on the fly but it probably still needs work. Basically, it 
is capitalized when used as part of a proper noun identifying a specific 
sub-TLV. Also, in section titles and captions.
  2. Reference RFC9350 rather than the Flex-Algo draft throughout.
  3. I didn’t make the change but I’d use “Layer-2” and “Layer-3” 
hyphenated.

See attached editorial suggestions  in the RFC diff.

Thanks,
Acee



> On Feb 19, 2024, at 5:25 PM, Acee Lindem 
> mailto:acee.lin...@gmail.com>> wrote:
>
>
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm 
> enhancements described in the document have been implemented.
>
> Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org<mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr