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

Hi Peter, > From: Peter Psenak > Sent: Thursday, September 9, 2021 3:30 PM > To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org > Subject: Re: [Lsr] draft-ietf-lsr-flex-algo > > Hi Bruno, > > On 09/09/2021 15:27, bruno.decra...@orange.com wrote: > > Hi Peter,

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

Hi Abhinay, On 20/10/2021 10:45, Abhinay R wrote: Hi All,         I see a typo in the flex algo draft [https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/]. 7.3.  OSPF Flexible Algorithm Include-All Admin Group Sub-TLV    The usage of this Sub-TLVs is described in Section 6.3.    

[Lsr] [LSR] draft-ietf-lsr-flex-algo

Hi All, I see a typo in the flex algo draft [ https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/]. 7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV The usage of this Sub-TLVs is described in Section 6.3. The format of the OSPF Flexible Algorithm Include-Any

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

52 PM >>> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org >>> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo >>> >>> Hi Bruno, >>> >>> On 09/09/2021 14:43, bruno.decra...@orange.com wrote: >>>> Hi authors, all, >>>> >&g

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

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

ee Lindem (acee)" 40cisco@dmarc.ietf.org> > *Subject: *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 operator

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

ct: *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 ? The architecture supports it additional constraints. Nobody says they have to be used. This is an interesting

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 addition

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

@ietf.org *Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo On Sep 15, 2021, at 11:17 AM, Peter Psenak mailto:ppse...@cisco.com>> wrote: So, if someone wants to define new constraints (e.g., Linda's server/application metrics), they would need to define the sem

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

Hi Linda, Tony, From: Linda Dunbar Date: Wednesday, September 15, 2021 at 3:45 PM To: Tony Li , "Peter Psenak (ppsenak)" Cc: "Acee Lindem (acee)" , Acee Lindem , Bruno Decraene , "lsr@ietf.org" Subject: RE: [Lsr] draft-ietf-lsr-flex-algo Tony, Answers are ins

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

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; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr-flex-algo On Sep 15

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

> On Sep 15, 2021, at 11:17 AM, Peter Psenak wrote: > >> So, if someone wants to define new constraints (e.g., Linda's >> server/application metrics), they would need to define the semantics and >> encodings similar to what is being done for bandwidth metrics in >>

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

s used. > > thanks, > Peter > > > > > > > Linda > > > > -Original Message----- > > From: Peter Psenak > > Sent: Th

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

> -Original Message----- > > From: Peter Psenak > > Sent: Thursday, September 9, 2021 1:00 PM > > To: Tony Li ; Linda Dunbar > > Cc: bruno.decra...@orange.com; lsr@ietf.org > > Subject: Re: [Lsr] draft-ietf-lsr-f

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

k > Sent: Thursday, September 9, 2021 1:00 PM > To: Tony Li ; Linda Dunbar > Cc: bruno.decra...@orange.com; lsr@ietf.org > Subject: Re: [Lsr] draft-ietf-lsr-flex-algo > > Hi Linda, Tony, > > > On 09/09/2021 19:37, Tony Li

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

y, September 9, 2021 1:00 PM > To: Tony Li ; Linda Dunbar > Cc: bruno.decra...@orange.com; lsr@ietf.org > Subject: Re: [Lsr] draft-ietf-lsr-flex-algo > > Hi Linda, Tony, > > > On 09/09/2021 19:37, Tony Li wrote: >> &

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

indicates how metric is used. Metric-Type indicates which metric is used. thanks, Peter Linda -Original Message- From: Peter Psenak Sent: Thursday, September 9, 2021 1:00 PM To: Tony Li ; Linda Dunbar Cc: bruno.decra...@orange.com; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr

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

to explicit indicate the "Metric-Type" in the FAD Sub-TLV? Linda -Original Message- From: Peter Psenak Sent: Thursday, September 9, 2021 1:00 PM To: Tony Li ; Linda Dunbar Cc: bruno.decra...@orange.com; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr-flex-algo Hi Linda, Ton

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

o:lsr@ietf.org> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo Hi Bruno, On 09/09/2021 14:43, bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> wrote: Hi authors, all, I have a question related to the two-way connectivity check performed on each link during the

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

nt: Thursday, September 9, 2021 7:52 AM > To: bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>; > lsr@ietf.org <mailto:lsr@ietf.org> > Subject: Re: [Lsr] draft-ietf-lsr-flex-algo > > Hi Bruno, > > On 09/09/2021 14:43, bruno.decra...@orange.com wrote: >&g

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

to assign one of the values within 2-127 (currently shown unassigned on IANA page)? Linda Dunbar -Original Message- From: Lsr On Behalf Of Peter Psenak Sent: Thursday, September 9, 2021 7:52 AM To: bruno.decra...@orange.com; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr-flex-algo Hi

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

om: Peter Psenak [mailto:ppse...@cisco.com] > >> Sent: Thursday, September 9, 2021 2:52 PM > >> To: DECRAENE Bruno INNOV/NET ; > lsr@ietf.org > >> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo > >> > >> Hi Bruno, > >> > >> On 09/09/2021

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

] draft-ietf-lsr-flex-algo Hi Bruno, On 09/09/2021 14:43, bruno.decra...@orange.com wrote: Hi authors, all, I have a question related to the two-way connectivity check performed on each link during the FlexAlgo SPF. flex-algo is defined as set of: (a) calculation-type (b) metric-type, (c

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

Hi Peter, Thanks for your answer. Please see inline > -Original Message- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Thursday, September 9, 2021 2:52 PM > To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org > Subject: Re: [Lsr] draft-ietf-lsr-flex-algo > > Hi

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

Hi Bruno, On 09/09/2021 14:43, bruno.decra...@orange.com wrote: Hi authors, all, I have a question related to the two-way connectivity check performed on each link during the FlexAlgo SPF. flex-algo is defined as set of: (a) calculation-type (b) metric-type, (c) a set of constraints Two

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

Hi authors, all, I have a question related to the two-way connectivity check performed on each link during the FlexAlgo SPF. Is this point documented in the document? I could not find it so far. If not, what is the (reverse connectivity) check that need to be performed on the reverse link? A

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

WG, This is proposed text change for flex-algo draft. Any comments on this? Rgds Shraddha Juniper Business Use Only -Original Message- From: Shraddha Hegde Sent: Wednesday, July 28, 2021 11:47 PM To: Peter Psenak ; Ron Bonica ; Acee Lindem (acee) ; Les Ginsberg (ginsberg) ;

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

Peter, There is an agreement to open the Flex-algo draft and clarify the text and here is a proposal for the modified text. We can discuss about generic-metric in another thread. New text for section "12. Advertisement of Link Attributes for Flex-Algorithm " 2 nd And 3rd

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

Ron, the problem in hand is whether Generic Metric should be defined as an application specific attribute or not. I have explained several times why making it application specific makes sense and also provided examples of other metrics that are defined as application specific (TE metric,

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

Hi Ron, I think you are not taking into consideration the full picture here and instead you are only focusing only on signaling. So let's take your example of "link's total physical bandwidth" Yes physics wise it is generic, by nature. And that claim is true too: "It will always be the same for

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

Peter, I agree that we will need to update the flexago draft. But before we do that, can you explain why we need to maintain mandatory use of ASLA? AFAIKS, by their nature, some attributes are generic while others are application specific. For example, a link's total physical bandwidth is

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

Ron - Link attributes have since Day 1 (i.e., publication of RFC 3784 (precursor to RFC 5305)) been associated with sub-TLV advertisements. Both RFC 8919 and the Flex Algo draft are discussing attributes advertised in sub-TLVs. IGP metric has never been advertised in a sub-TLV (or even

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

Hi Ron, On 26/07/2021 20:30, Ron Bonica wrote: Peter, I think that we are using the term "link attribute" differently. IMO, a link attribute is any attribute of a link, regardless of whether it is advertised in the fixed portion of a link advertisement or in a TLV. Are you assuming

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

Peter, I think that we are using the term "link attribute" differently. IMO, a link attribute is any attribute of a link, regardless of whether it is advertised in the fixed portion of a link advertisement or in a TLV. Are you assuming otherwise? If so, why?

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

Hi Ron, On 26/07/2021 18:36, Ron Bonica wrote: Acee, We may also need to clean up an inconsistency in draft-ietf-lsr-flex-algo-17. Section 12 of that document says: " Link attribute advertisements that are to be used during Flex- Algorithm calculation MUST use the Application-Specific

[Lsr] draft-ietf-lsr-flex-algo-17 (was: I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt)

Acee, We may also need to clean up an inconsistency in draft-ietf-lsr-flex-algo-17. Section 12 of that document says: " Link attribute advertisements that are to be used during Flex- Algorithm calculation MUST use the Application-Specific Link Attribute (ASLA) advertisements defined in

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

- and this is always what was intended. Les From: Lsr On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: Tuesday, June 15, 2021 7:45 AM To: bruno.decra...@orange.com; draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr-flex-algo Thanks

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

s Option 2 (the overruling is done on a per attribute basis.) G/ From: Lsr On Behalf Of bruno.decra...@orange.com Sent: Friday, June 4, 2021 11:03 AM To: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org Subject: [Lsr] draft-ietf-lsr-flex-algo Hi all, I think that I may have an issue with the way F

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

ra...@orange.com<mailto:bruno.decra...@orange.com> Sent: Friday, June 4, 2021 2:03 AM To: draft-ietf-lsr-flex-a...@ietf.org<mailto:draft-ietf-lsr-flex-a...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: [Lsr] draft-ietf-lsr-flex-algo Hi all, I think that I may have an issue with

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

ay, June 4, 2021 2:03 AM To: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org Subject: [Lsr] draft-ietf-lsr-flex-algo Hi all, I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1] FlexAlgo is distributed routing computation so it's required that all routers use exactly the

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

From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Friday, June 4, 2021 4:50 PM To: DECRAENE Bruno INNOV/NET Cc: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr-flex-algo To me this "permitted" is only about applying ASLA to all apps (no bit mas

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

> > > > *From:* Robert Raszuk [mailto:rob...@raszuk.net] > *Sent:* Friday, June 4, 2021 3:35 PM > *To:* DECRAENE Bruno INNOV/NET > *Cc:* draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org > *Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo > > > > > > Ok you meant

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

From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Friday, June 4, 2021 3:35 PM To: DECRAENE Bruno INNOV/NET Cc: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr-flex-algo Ok you meant domain wide not locally ... but there is already strong normative MUST

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

Ok you meant domain wide not locally ... but there is already strong normative MUST in Flex Algo as the user of ASLA so no loop will happen. The "permitted" from ASLA RFC is just to indicate what applications may use such attribute with zero-length Application Identifier Bit Masks as opposed

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

Hi Robert, From: Robert Raszuk [mailto:rob...@raszuk.net] Hi Bruno, > I think it’s self-evident that we would end up with a permanent routing loop. Is that so ? Wouldn't it just result in unidirectional link for a given app ? Maybe intentional ? It seems that what you described may cause

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

Hi Bruno, > I think it’s self-evident that we would end up with a permanent routing loop. Is that so ? Wouldn't it just result in unidirectional link for a given app ? Maybe intentional ? It seems that what you described may cause asymmetric routing but not a routing loop. After all packets

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

Hi all, I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1] FlexAlgo is distributed routing computation so it's required that all routers use exactly the same data to compute the routes/SPF. FlexAlgo is clear that ASLA MUST be used: "Link attribute advertisements that are

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

Bruno, On 01/06/2021 10:55, bruno.decra...@orange.com wrote: Hi all, Better safe than sorry, I guess. FYI, in -08 (a year ago) draft introduced one single iteration of the FA acronym: "The scope of the FA computation is an area" I'll remove it, I've never intended to use FA for flex-algo

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

Hi all, Better safe than sorry, I guess. FYI, in -08 (a year ago) draft introduced one single iteration of the FA acronym: "The scope of the FA computation is an area" Do we really want to create that FA acronym for Flex Algo? FA has already been used for Forwarding Adjacency (e.g., [1])

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi Tony, Sarah, On 10/08/2020 18:00, tony...@tony.li wrote: Hi Peter, The flex-algo draft mentions "Min Unidirectional Link Delay as defined in [RFC7810 ]". When reading RFC7810, I found two Sub-TLVs: 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi Peter, The flex-algo draft mentions "Min Unidirectional Link Delay as defined in [RFC7810 ]". When reading RFC7810, I found two Sub-TLVs: 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max Unidirectional Link Delay Sub-TLV

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Thank you, Peter, for the clarification. It would be nice to add a reference to the section number Section 4.2 . Thanks, Sarah On Mon, Aug 10, 2020 at 8:56 AM Peter Psenak wrote: > Hi Tony, > > On 10/08/2020 16:21, tony...@tony.li wrote: > > >

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi Tony, On 10/08/2020 16:21, tony...@tony.li wrote: Hi Peter, The flex-algo draft mentions "Min Unidirectional Link Delay as defined in [RFC7810 ]". When reading RFC7810, I found two Sub-TLVs: 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi Peter, >> The flex-algo draft mentions "Min Unidirectional Link Delay as defined in >> [RFC7810 > >]". When reading RFC7810, I found two >> Sub-TLVs: >> 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Tony, ok, seems like Gunter and you share the same concerns. Will clarify the two points discussed. thanks, Peter On 07/08/2020 17:30, tony...@tony.li wrote: Peter, . The existing description in section 5.1 indicate that legacy encoding (RFC7810 and RFC5305) is used for link

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi Sarah, On 08/08/2020 01:33, Sarah Chen wrote: Hi, Peter, The flex-algo draft mentions "Min Unidirectional Link Delay as defined in [RFC7810 ]". When reading RFC7810, I found two Sub-TLVs: 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi, Peter, The flex-algo draft mentions "Min Unidirectional Link Delay as defined in [ RFC7810 ]". When reading RFC7810, I found two Sub-TLVs: 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max Unidirectional Link Delay Sub-TLV Could you please clarify

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Peter, >> . The existing description in section 5.1 indicate that legacy encoding >> (RFC7810 and RFC5305) is used for link attributes. That is not correct based >> upon section 11. To avoid ambiguity can an explicit reference be added for >> [I-D.ietf-isis-te-app]? > > > well, section

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi Gunter, On 06/08/2020 19:11, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: Thanks for the clarification and fast answer. Indeed FAD does not encode any attributes. That was not the point I was trying to make. . The existing description in section 5.1 indicate that legacy encoding

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Thanks for the clarification and fast answer. Indeed FAD does not encode any attributes. That was not the point I was trying to make. .. The existing description in section 5.1 indicate that legacy encoding (RFC7810 and RFC5305) is used for link attributes. That is not correct based upon

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi Gunter, On 06/08/2020 18:31, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: Hi Authors, All, My understanding is that for new LSR applications we should select either “ASLA encoding” or select “legacy encoding” for all Link attributes. Not a mixture of both. There is a clear long term

[Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

Hi Authors, All, My understanding is that for new LSR applications we should select either "ASLA encoding" or select "legacy encoding" for all Link attributes. Not a mixture of both. There is a clear long term technology benefit of using all ASLA encoding. In draft-ietf-lsr-flex-algo-08

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

Hi Bruno, please see inline: On 30/06/2020 18:39, bruno.decra...@orange.com wrote: Hi Peter, From: Peter Psenak [mailto:ppse...@cisco.com] Hi Bruno, On 30/06/2020 18:08, bruno.decra...@orange.com wrote: Hi Peter, Thanks for your reply. From: Peter Psenak [mailto:ppse...@cisco.com] Hi

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

Speaking as WG chair: I'm delighted to see discussion on a draft that isn't in WG last call. Speaking as WG member: Maybe I'm missing something but do we really think we’re going to run out of non-flexible algorithms with 128? I just don't see it happening in my lifetime. Thanks, Acee

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

Hi Peter, > From: Peter Psenak [mailto:ppse...@cisco.com] > > Hi Bruno, > > On 30/06/2020 18:08, bruno.decra...@orange.com wrote: > > Hi Peter, > > > > Thanks for your reply. > > > >> From: Peter Psenak [mailto:ppse...@cisco.com] > >> > >> Hi Bruno, > >> > >> please see inline: > >> > >> On

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

Hi Bruno, On 30/06/2020 18:08, bruno.decra...@orange.com wrote: Hi Peter, Thanks for your reply. From: Peter Psenak [mailto:ppse...@cisco.com] Hi Bruno, please see inline: On 30/06/2020 16:53, bruno.decra...@orange.com wrote: Hi all, I can live with the current text, but I'm just

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

Hi Peter, Thanks for your reply. > From: Peter Psenak [mailto:ppse...@cisco.com] > > Hi Bruno, > > please see inline: > > On 30/06/2020 16:53, bruno.decra...@orange.com wrote: > > Hi all, > > > > I can live with the current text, but I'm just raising the point for > > discussion > (better

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

Hi Bruno, please see inline: On 30/06/2020 16:53, bruno.decra...@orange.com wrote: Hi all, I can live with the current text, but I'm just raising the point for discussion (better safe than sorry). "16.1.1. IGP Algorithm Types Registry This document makes the following registrations in

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

Hi all, I can live with the current text, but I'm just raising the point for discussion (better safe than sorry). "16.1.1. IGP Algorithm Types Registry This document makes the following registrations in the "IGP Algorithm Types" registry: Type: 128-255. Description: Flexible

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

On Wed, May 20, 2020 at 4:16 AM Peter Psenak wrote: > On 20/05/2020 00:37, Gyan Mishra wrote: > > > > > > > > On Tue, May 19, 2020 at 3:38 AM Peter Psenak > > wrote: > > > > Gyan, > > > > On 19/05/2020 03:52, Gyan Mishra wrote: > > > > > > Flex algo

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

On 20/05/2020 00:37, Gyan Mishra wrote: On Tue, May 19, 2020 at 3:38 AM Peter Psenak > wrote: Gyan, On 19/05/2020 03:52, Gyan Mishra wrote: > > Flex algo is usually mentioned in the context of SR-TE to help reduced > SRH size to

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

On Tue, May 19, 2020 at 3:38 AM Peter Psenak wrote: > Gyan, > > On 19/05/2020 03:52, Gyan Mishra wrote: > > > > Flex algo is usually mentioned in the context of SR-TE to help reduced > > SRH size to circumvent MSD issues for both SRV6 and SR-MPLS, > > though segment list reduction may be seen as

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

Gyan, On 19/05/2020 03:52, Gyan Mishra wrote: Flex algo is usually mentioned in the context of SR-TE to help reduced SRH size to circumvent MSD issues for both SRV6 and SR-MPLS, though segment list reduction may be seen as one of the benefits of the flex-algo, it is certainly not the

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

> Cheers! > > > > Wang Weibin > > > > *From:* Jeff Tantsura > *Sent:* 2020年5月10日 3:24 > *To:* Wang, Weibin (NSB - CN/Shanghai) > *Cc:* Ketan Talaulikar (ketant) ; lsr@ietf.org > *Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo > > > > Weibin, > >

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

Jeff, I see what you said, thank you for sharing information; Cheers! Wang Weibin From: Jeff Tantsura Sent: 2020年5月10日 3:24 To: Wang, Weibin (NSB - CN/Shanghai) Cc: Ketan Talaulikar (ketant) ; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr-flex-algo Weibin, One could have an algo with MSD

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

> Thanks, > Ketan > > From: Lsr On Behalf Of Wang, Weibin (NSB - CN/Shanghai) > Sent: 08 May 2020 19:07 > To: lsr@ietf.org > Subject: [Lsr] draft-ietf-lsr-flex-algo > > Hi authors: > > After reading through this draft lsr-flex-algo, I want to know whether ther

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

�C same applies to SR-MPLS where the label stack can be reduced. Thanks, Ketan From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Wang, Weibin (NSB - CN/Shanghai) Sent: 08 May 2020 19:07 To: lsr@ietf.org<mailto:lsr@ietf.org> Subject: [Lsr] draft-ietf-lsr-flex-algo Hi authors: A

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

Hi Wang, You are correct. Though I wouldn't call it a goal but rather a benefit/advantage - same applies to SR-MPLS where the label stack can be reduced. Thanks, Ketan From: Lsr On Behalf Of Wang, Weibin (NSB - CN/Shanghai) Sent: 08 May 2020 19:07 To: lsr@ietf.org Subject: [Lsr] draft-ietf

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

Hi authors: After reading through this draft lsr-flex-algo, I want to know whether there is a potential goal of this draft to reduce the SRH size with enabling flex-algo with admin group in SRv6 deployment, because without flex-algo we have to have a big SRH size when the SRH include more SRv6