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 
>  > 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 
> 
> 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 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 
> 
> 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://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?
>  
>  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 

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
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
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://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?

 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) 

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  > 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 
> 
> 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://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?
>  
>  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. 

[Lsr] lsr - New Meeting Session Request for IETF 120

[IETF Meeting Session Request Tool]

A new meeting session request has just been submitted by Acee Lindem, a Chair
of the LSR Working Group.


-
Working Group Name: Link State Routing
Area Name: Routing Area
Session Requester: Acee Lindem


Number of Sessions: 1
Length of Session(s): 2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 Chair conflict: lsvr rtgwg idr ipsecme tvr
 Technology overlap: spring rift
 Key participant conflict: mpls

   


Participants who must be present:

Resources Requested:

Special Requests:
  
-


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