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

2021-09-23 Thread John Scudder
Hi Peter,

Unless you have some special reason for waiting until after AD review (in which 
case please let me know), I’d prefer if you didn’t hold off incorporating 
planned changes.

Thanks,

—John

> On Sep 9, 2021, at 9:30 AM, Peter Psenak  
> wrote:
> 
> Hi Bruno,
> 
> On 09/09/2021 15:27, bruno.decra...@orange.com wrote:
>> 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 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 way connectivity check for any link in the MT topology is orthogonal
>>> to flex-algo and is done once only and used for all algorithms.
>> 
>> OK. Excellent.
>> Could the above be added in the specification, so that we have consistent 
>> behaviour across implementations?
> 
> sure, I will push it with the next revision - after the AD review.
> 
> thanks,
> Peter
> 
> 
>> 
>> Thanks,
>> Regards,
>> Bruno
>>> 
>>> Flex-algo calculation using (a), (b), and (c) is done on top of MT
>>> topology using only links for which the 2WCC has already been performed.
>>> 
>>> 
 
 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?
>>> 
>>> 
>>> none.
>>> 
>>> thanks,
>>> Peter
>>> 
>>> 
 
 A priori I could see multiple options:
 a) link exist
 b) link exist with a standard IGP metric  (seem the option defined in the 
 ISO spec
>>> §7.2.8.2)
 c) link exist with the FlexAlgo metric used by FlexAlgo
 d) link exist with the FlexAlgo metric used by FlexAlgo and link complies 
 to
>>> FlexAlgo constraints.
 
 I think we'll agree that this point requires uniformity across nodes hence
>>> standardization.
 
 Personally, I don't have significant preference, but the algo defined in 
 §13
>>> "Calculation of Flexible Algorithm Paths" could be read as defining option 
>>> "d" (as
>>> links not following the constraints are "pruned from the computation") but 
>>> I'm not
>>> sure that this is intended for the two-way connectivity check.
 
 Thanks,
 Regards,
 --Bruno
 
 
 
 
>>> 
>>> _
 
 Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
 recu ce
>>> message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>>> electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete altere, deforme ou
>>> falsifie. Merci.
 
 This message and its attachments may contain confidential or privileged
>>> information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received this email in error, please notify the sender and 
 delete this
>>> message and its attachments.
 As emails may be altered, Orange is not liable for messages that have been
>>> modified, changed or falsified.
 Thank you.
 
 ___
 Lsr mailing list
 Lsr@ietf.org
 https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QDbnMxgvs-3Nw1duHw-Lo0ToK8aZSyFCYlBRQu-2yr1WReve4IDOKCdjc0OWSA$
 
 
>> 
>> 
>> _
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
>> falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged 
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and 
>> delete this message and its attachments.
>> As emails may be 

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

2021-09-23 Thread Shraddha Hegde
Hi Linda,

Pls see inline..



Juniper Business Use Only
From: Linda Dunbar 
Sent: Thursday, September 23, 2021 8:39 PM
To: Shraddha Hegde ; Acee Lindem (acee) ; 
Tony Li ; Peter Psenak (ppsenak) 
Cc: lsr@ietf.org; bruno.decra...@orange.com; Acee Lindem (acee) 

Subject: RE: questions about draft-ietf-lsr-flex-algo-bw-con-01

[External Email. Be cautious of content]

Shraddha,

Thank you very much for the suggestion.

Should the "Edge computing metric" be a value in Metric-Type of the FlexAlgo 
Sub-TLV?
 metric-type is carried in Flex-algo Definition FAD sub-TLV.

Can multiple sub-sub-TLV carried by the  FlexAlgo SubTLV indicate different 
metric-types?
 For one flex-algo there can be only  FAD sub-TLV and one metric-type.
Flex-algo SPF will be computed based on that metric-type.

If YES, the individual metrics sub-subTLV has its own Metrics Type, which can 
be different from the Metric-Type of the FlexAlgo Sub-TLV.  Is it a problem?
 No. Multiple metric-types in one flex-algo is not allowed.
Why would you want to send multiple metric-types?

I am still not clear the different purpose of "Flex-Algorithm" and "Calc-Type". 
Can someone give an example?
 Flex-algo basically runs an algorithm on a given topology to find 
paths. The algorithm is identified by
Calc-type. Currently only SPF algorithm is supported. If you want to run any 
different algorithm you have to
Define new calc-type. From your draft it appeared to me that you will be 
running SPF algorithm on this new type of metric. Is that right?

We will update the draft per Acee's and your suggestion to encode the 5G EC 
servers running environment metrics in the Flexalgo advertisement.

Thank you.

Linda

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: Thursday, September 23, 2021 5:39 AM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Acee Lindem 
(acee) mailto:a...@cisco.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org; 
bruno.decra...@orange.com; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: RE: questions about draft-ietf-lsr-flex-algo-bw-con-01

Hi Linda,

I read your draft draft-dunbar-lsr-5g-edge-compute.
>From my understanding you are using various parameters such as capacity index, 
>preference,network delay etc
To derive a metric. You want to use this derived metric for SPF computation.

My suggestion would be to define new standard metric under generic metric called
"Edge computing metric". This metric would be similar to "bandwidth metric " 
defined in
draft-ietf-lsr-flex-algo-bw-con. This edge computing metric will be computed 
based on various advertised
parameters (similar to bandwidth metric which is computed based on 
link-bandwidth).
A flex-algo can then be used to compute using metric-type "Edge computing 
metric".

Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Linda Dunbar
Sent: Friday, September 17, 2021 12:58 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org; 
bruno.decra...@orange.com; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

[External Email. Be cautious of content]

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 encoded 
in the Value field of the ISIS Generic Metric  in Section 2.1?

Why not directly included in the value field of Flex Algo TLV?  Section 2.3 
says that using FAPM sub-TLV to indicate Flex Algo needs to use the Generic 
Metric. But this property of preventing some flows to be placed on certain 
links doesn't need to be generic, does it?

How does an IGP node know which link to advertise this property? Is it by 
configuration?

Linda Dunbar



From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, September 15, 2021 4:30 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
bruno.decra...@orange.com; 
lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, Tony,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Wednesday, September 15, 2021 at 3:45 PM
To: Tony Li mailto:tony...@tony.li>>, "Peter Psenak (ppsenak)" 
mailto:ppse...@cisco.com>>
Cc: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, Acee 
Lindem mailto:a...@cisco.com>>, Bruno Decraene 

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

2021-09-23 Thread Linda Dunbar
Shraddha,

Thank you very much for the suggestion.

Should the "Edge computing metric" be a value in Metric-Type of the FlexAlgo 
Sub-TLV?
Can multiple sub-sub-TLV carried by the  FlexAlgo SubTLV indicate different 
metric-types?  If YES, the individual metrics sub-subTLV has its own Metrics 
Type, which can be different from the Metric-Type of the FlexAlgo Sub-TLV.  Is 
it a problem?

I am still not clear the different purpose of "Flex-Algorithm" and "Calc-Type". 
Can someone give an example?

We will update the draft per Acee's and your suggestion to encode the 5G EC 
servers running environment metrics in the Flexalgo advertisement.

Thank you.

Linda

From: Shraddha Hegde 
Sent: Thursday, September 23, 2021 5:39 AM
To: Linda Dunbar ; Acee Lindem (acee) 
; Tony Li ; Peter Psenak (ppsenak) 

Cc: lsr@ietf.org; bruno.decra...@orange.com; Acee Lindem (acee) 

Subject: RE: questions about draft-ietf-lsr-flex-algo-bw-con-01

Hi Linda,

I read your draft draft-dunbar-lsr-5g-edge-compute.
>From my understanding you are using various parameters such as capacity index, 
>preference,network delay etc
To derive a metric. You want to use this derived metric for SPF computation.

My suggestion would be to define new standard metric under generic metric called
"Edge computing metric". This metric would be similar to "bandwidth metric " 
defined in
draft-ietf-lsr-flex-algo-bw-con. This edge computing metric will be computed 
based on various advertised
parameters (similar to bandwidth metric which is computed based on 
link-bandwidth).
A flex-algo can then be used to compute using metric-type "Edge computing 
metric".

Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Linda Dunbar
Sent: Friday, September 17, 2021 12:58 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org; 
bruno.decra...@orange.com; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

[External Email. Be cautious of content]

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 encoded 
in the Value field of the ISIS Generic Metric  in Section 2.1?

Why not directly included in the value field of Flex Algo TLV?  Section 2.3 
says that using FAPM sub-TLV to indicate Flex Algo needs to use the Generic 
Metric. But this property of preventing some flows to be placed on certain 
links doesn't need to be generic, does it?

How does an IGP node know which link to advertise this property? Is it by 
configuration?

Linda Dunbar



From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, September 15, 2021 4:30 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
bruno.decra...@orange.com; 
lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, Tony,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Wednesday, September 15, 2021 at 3:45 PM
To: Tony Li mailto:tony...@tony.li>>, "Peter Psenak (ppsenak)" 
mailto:ppse...@cisco.com>>
Cc: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, Acee 
Lindem mailto:a...@cisco.com>>, Bruno Decraene 
mailto:bruno.decra...@orange.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] draft-ietf-lsr-flex-algo

Tony,

Answers are inserted below:




From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, September 15, 2021 1:26 PM
To: Peter Psenak mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; Acee 
Lindem (acee) mailto:a...@cisco.com>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
bruno.decra...@orange.com; 
lsr@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 semantics and 
encodings similar to what is being done for bandwidth metrics in 

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

2021-09-23 Thread Shraddha Hegde
Hi Linda,

I read your draft draft-dunbar-lsr-5g-edge-compute.
>From my understanding you are using various parameters such as capacity index, 
>preference,network delay etc
To derive a metric. You want to use this derived metric for SPF computation.

My suggestion would be to define new standard metric under generic metric called
"Edge computing metric". This metric would be similar to "bandwidth metric " 
defined in
draft-ietf-lsr-flex-algo-bw-con. This edge computing metric will be computed 
based on various advertised
parameters (similar to bandwidth metric which is computed based on 
link-bandwidth).
A flex-algo can then be used to compute using metric-type "Edge computing 
metric".

Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Linda Dunbar
Sent: Friday, September 17, 2021 12:58 AM
To: Acee Lindem (acee) ; Tony Li ; Peter 
Psenak (ppsenak) 
Cc: lsr@ietf.org; bruno.decra...@orange.com; Acee Lindem (acee) 

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

[External Email. Be cautious of content]

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 encoded 
in the Value field of the ISIS Generic Metric  in Section 2.1?

Why not directly included in the value field of Flex Algo TLV?  Section 2.3 
says that using FAPM sub-TLV to indicate Flex Algo needs to use the Generic 
Metric. But this property of preventing some flows to be placed on certain 
links doesn't need to be generic, does it?

How does an IGP node know which link to advertise this property? Is it by 
configuration?

Linda Dunbar



From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, September 15, 2021 4:30 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
bruno.decra...@orange.com; 
lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, Tony,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Wednesday, September 15, 2021 at 3:45 PM
To: Tony Li mailto:tony...@tony.li>>, "Peter Psenak (ppsenak)" 
mailto:ppse...@cisco.com>>
Cc: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, Acee 
Lindem mailto:a...@cisco.com>>, Bruno Decraene 
mailto:bruno.decra...@orange.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] draft-ietf-lsr-flex-algo

Tony,

Answers are inserted below:




From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, September 15, 2021 1:26 PM
To: Peter Psenak mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; Acee 
Lindem (acee) mailto:a...@cisco.com>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
bruno.decra...@orange.com; 
lsr@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 semantics and 
encodings similar to what is being done for bandwidth metrics in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
 . Then the flex algos could be defined using these metrics. Correct?

yes, they would need to define a new FAD constraint and/or metric only.


I agree that if the goal is a new metric, then that's sufficient.  [Plug for 
generic metrics.]

It sounded a bit like Linda was wanting a fundamental change to the SPF 
algorithm.  If, so, I believe that would require a new Calc-Type. Linda, could 
you please clarify?
[Linda] I don't think so. We want a constrained SPF algorithm that take into 
additional metrics. Just like TE being added into the SPF.

I was thinking that as well. These metrics would be defined to have precedence 
over the path cost - sort of like OSPF Type 2 external metrics do for OSPF AS 
External routes.

Thanks,
Acee

Linda Dunbar

Tony

___
Lsr mailing list
Lsr@ietf.org