Re: [Lsr] draft-ietf-lsr-flex-algo

Tony, Yes - spot on. It is like either selecting ingredients to "make your own pizza" vs ordering a fixed one (Pepperoni, Margarita, 4 cheese, style #135 etc...) All I am saying is that both options are useful. And it seems defining few most useful flex-algos may be helpful. Call it well known

Re: [Lsr] draft-ietf-lsr-flex-algo

Robert, > What harm would it make if someone writes a draft, defines a useful flex algo > on which (the usefulness the LSR WG agrees) say using max propagation delay > across hops as as a metric and allocates IANA type 135 for it ? I’m inferring that you are suggesting that we take a code

Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Tony, > Actual interoperability testing where developers sit down and test. To the best of my knowledge the objective of those testing is to detect bugs or make sure that developers of different vendors read the spec they were implementing the same way. > what would you propose? :-) Top

Re: [Lsr] draft-ietf-lsr-flex-algo

Robert, > IMHO the magnitude of those will exponentially increase with flex-algo if it > really takes off. Will it be manageable in some networks - perhaps. Well, you’re welcome to your opinion. :-) The basic set of constraints seem very straightforward and, as always, operators are

Re: [Lsr] draft-ietf-lsr-flex-algo

Tony, > We are all painfully aware of the true challenges of interoperability. Is there really some point to beating on this decades-dead horse? IMHO the magnitude of those will exponentially increase with flex-algo if it really takes off. Will it be manageable in some networks - perhaps. But

Re: [Lsr] draft-ietf-lsr-flex-algo

Dear Gentlebeings, > I was more expressing an option about cross vendor support of various metrics > and constraints as part of a given flexible algorithm. I think putting a hard > line that perhaps very useful set of constraints and metrics - documented as > IETF informational doc - even if

Re: [Lsr] draft-ietf-lsr-flex-algo

> Lack of support for flex algorithm or a particular flex algorithm will not > break things either. > I was not really talking about breaking. I was more expressing an option about cross vendor support of various metrics and constraints as part of a given flexible algorithm. I think putting a

Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Robert, From: Robert Raszuk Date: Thursday, September 16, 2021 at 4:23 PM To: Acee Lindem Cc: Peter Psenak , Linda Dunbar , Tony Li , "lsr@ietf.org" , Bruno Decraene , "Acee Lindem (acee)" Subject: Re: [Lsr] draft-ietf-lsr-flex-algo Acee, Wide communities actually are designed to help

Re: [Lsr] draft-ietf-lsr-flex-algo

Acee, Wide communities actually are designed to help operators in their tasks. I am not sure why you brought it here. Besides please observe that communities are optional attributes. Lack of support on any BGP speaker will not break things or cause a permanent loop by design. Thx R. On Thu,

Re: [Lsr] draft-ietf-lsr-flex-algo

Robert, Acee, On 16/09/2021 22:16, Acee Lindem (acee) wrote: Hi Robert, *From: *Robert Raszuk *Date: *Thursday, September 16, 2021 at 5:34 AM *To: *Peter Psenak *Cc: *Linda Dunbar , Tony Li , "lsr@ietf.org" , Bruno Decraene , Acee Lindem , "Acee Lindem (acee)" *Subject: *Re: [Lsr]

Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Robert, From: Robert Raszuk Date: Thursday, September 16, 2021 at 5:34 AM To: Peter Psenak Cc: Linda Dunbar , Tony Li , "lsr@ietf.org" , Bruno Decraene , Acee Lindem , "Acee Lindem (acee)" Subject: Re: [Lsr] draft-ietf-lsr-flex-algo I believe flex-algo with additional constraints would

Re: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

Hi Linda, > Is it correct that the intent of the draft is to prevent some “elephant > flows” from being placed over certain links? I would phrase it somewhat differently. One of the goals of the draft is to allow network operators to define a minimum bandwidth threshold for a FlexAlgo

[Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

Shraddha, Bill, Rajesh, Bruno, Peter, and Tony, Is it correct that the intent of the draft is to prevent some "elephant flows" from being placed over certain links? Section 2.1 listed the TLV for the ISIS Generic Metric Is the property of preventing some flows being placed on a link to be

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

Hi All, wanted to record my +1 to the comment from Les on this matter. (there is no intent or desire to open this discussion again) G/ From: Lsr On Behalf Of Jeff Tantsura Sent: Friday, August 20, 2021 2:14 AM To: Yingzhen Qu Cc: Les Ginsberg (ginsberg) ; Ron Bonica ; Acee Lindem (acee) ;

Re: [Lsr] draft-ietf-lsr-flex-algo

> I believe flex-algo with additional constraints would be sufficient. Aren't we putting too much operational complexity to the operators ? How can anyone practically assure that such constraints will be understood across a zoo of software versions and various implementations ? For well known

Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, On 15/09/2021 21:45, Linda Dunbar wrote: Tony, Answers are inserted below: *From:* Tony Li *On Behalf Of *Tony Li *Sent:* Wednesday, September 15, 2021 1:26 PM *To:* Peter Psenak *Cc:* Acee Lindem (acee) ; Acee Lindem (acee) ; Linda Dunbar ; bruno.decra...@orange.com;