Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 12 May 2021 21:09:07 +0000

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

     https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.

Thanks,
Chris and Acee

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 12 May 2021 23:30:08 -0700

Yes/support 

Regards,
Jeff

> On May 12, 2021, at 15:14, Acee Lindem (acee) <acee=[email-masked]> wrote:
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 13 May 2021 06:32:51 +0000

I am not aware of any IPR related to this draft.

Rgds
Shraddha

Juniper Business Use Only
From: Acee Lindem (acee) <[email-masked]>
Sent: Thursday, May 13, 2021 2:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Thanks,
Chris and Acee

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 13 May 2021 02:48:02 -0400

I support WG Adoption.

Kind Regards

Gyan

On Thu, May 13, 2021 at 2:33 AM Shraddha Hegde <shraddha=
[email-masked]> wrote:

> *From:* Acee Lindem (acee) <[email-masked]>
> *Sent:* Thursday, May 13, 2021 2:39 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
> Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Thu, 13 May 2021 15:28:53 +0800 (CST)

Hi WG,

I have a little doubt about the scheme described in this document.

See the following example:

S ---- X1 ----- X2 ---- ... ... ----- X10 ----- D

    \----------------------------------------------/

Suppose the links in S---X1---X2...---D have the same bandwidth  10G, and the link S-D has bandwidth 1G.

Suppose that we select "reference bandwidth = 100G", then, 

each link  in S---X1---X2...---D will have the same bandwidth-metric  10 (i.e., 100/10)

link S-D will have a bandwidth-metric 100 (i.e., 100/100)

So flex-algo path from S to D based on bandwidth-metric will be S-D, not S---X1---X2...---D, because the later has a large cumulative bandwitdh-metric (i.e., 11*10).

But our expect path should be S-D, not S---X1---X2...---D, as it has large bandwidth.

Do I misunderstand anything ?

Regards,

PSF

原始邮件

发件人：AceeLindem(acee)
收件人：[email-masked];
抄送人：[email-masked];
日 期 ：2021年05月13日 05:49
主 题 ：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

 

 

 

 

 

Thanks,

Chris and Acee

---

From: <[email-masked]>
Date: Thu, 13 May 2021 15:34:35 +0800 (CST)

Sorry for spelling mistakens in the previous email.

updated text:

Hi WG,

link S-D will have a bandwidth-metric 100 (i.e., 100/1)

But our expect path should not be S-D, but S---X1---X2...---D, as it has large bandwidth.

Regards,

PSF

发件人：AceeLindem(acee)
收件人：[email-masked];

 

 

 

 

 

Thanks,

Chris and Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 13 May 2021 11:23:13 +0200

Hi Acee,

thanks,
Peter

On 12/05/2021 23:09, Acee Lindem (acee) wrote:
> Please indicate your support or objection by May 27^th , 2021.
>

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 13 May 2021 12:43:54 +0000

Hi Peng shaofu,

As per the draft, if automatic metric calculation with reference bandwidth method is used to calculate the metric
Then as per your example s->D path will be chosen since metric is 10.
Lets say operator wants to choose S->X1->X2--->X10->D path then operator can manually assign higher bandwidth
Metric on S->D link which will ensure S->D path is not the least cost path.

Rgds
Shraddha

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Thursday, May 13, 2021 1:05 PM
To: [email-masked]
Cc: acee=[email-masked]; [email-masked]; [email-masked]
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

updated text:

Hi WG,

Regards,

PSF

发件人：AceeLindem(acee)
收件人：[email-masked]<mailto:[email-masked]>;
抄送人：[email-masked]<mailto:[email-masked]>;
日 期 ：2021年05月13日 05:49
主 题 ：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
Esteemed Members of the LSR WG,

Thanks,
Chris and Acee

---

From: Tony Li <[email-masked]>
Date: Thu, 13 May 2021 08:11:07 -0700

Support as co-author.

I am not aware of any IPR on this draft.

Tony

> On May 12, 2021, at 2:09 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
>      https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/ <https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/>    
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 13 May 2021 15:34:51 +0000

Support

Juniper Business Use Only
From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, May 12, 2021 5:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Thanks,
Chris and Acee

---

From: Lizhenbin <[email-masked]>
Date: Fri, 14 May 2021 02:54:08 +0000

Hi All,
I support the WG adoption.

Best Regards,
Zhenbin (Robin)

--------------------------------------------------
李振斌 Li Zhenbin
Mobile: +86-13651017745<tel:+86-13651017745>/+968-91797068
Email: [email-masked]<mailto:[email-masked]>
发件人：Acee Lindem (acee) <acee=[email-masked]>
收件人：lsr <[email-masked]>
抄 送：draft-hegde-lsr-flex-algo-bw-con <[email-masked]>
时 间：2021-05-13 06:14:57
主 题：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 14 May 2021 07:52:14 +0000

Hi authors,

I’ve read the latest version of this document and have the following comments:

1.       Is the generic metric type applicable to applications other than Flex-Algo? If so, it is better to make this clear in the document, or perhaps it may be defined separately from the Flex-Algo specific extensions?

2.       The “Exclude Minimum Bandwidth” constraint is compared with the maximum link bandwidth to exclude the links from the computation, it would be helpful if there is some analysis about how much this can help in traffic engineering, such as to reduce the congestion or improve the link utilization. One simple example is, if multiple Flex-Algos use this constraint to exclude the same set of links, this may increase the possibility of congestion on the rest of the links?

Perhaps a more general question is, what would be the benefit of introducing bandwidth attribute into Flex-Algo based distributed path computation?  It is known that bandwidth can be used in centralized computation for efficient path placement and resource management, can distributed computation with bandwidth constraint achieve the same, or is there some advantages compared with centralized computation?

3.       With the automatic metric calculation, it could introduce per Flex-Algo link metric value, while the existing Flex-Algo only refers to the metric of the link via metric type. Is this the expected behavior? Will it be further extended to make other link attributes flex-algo specific?

4.       In the reference bandwidth method, the draft says it simplifies the management in case the reference bandwidth needs to be changed. Since the reference bandwidth applies to the metric calculation of all the links in the flex-algo with the same proportion, it seems the change of the reference bandwidth will not impact the result of the path computation in the flex-algo. In which case the reference bandwidth need to be changed?

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Thanks,
Chris and Acee

---

From: Peter Psenak <[email-masked]>
Date: Fri, 14 May 2021 11:12:08 +0200

Hi Jie,

please see the response for one of your questions inline:

On 14/05/2021 09:52, Dongjie (Jimmy) wrote:
> 1.Is the generic metric type applicable to applications other than 
> Flex-Algo? If so, it is better to make this clear in the document, or 
> perhaps it may be defined separately from the Flex-Algo specific extensions?
> 
> 2.The “Exclude Minimum Bandwidth” constraint is compared with the 
> maximum link bandwidth to exclude the links from the computation, it 
> would be helpful if there is some analysis about how much this can help 
> in traffic engineering, such as to reduce the congestion or improve the 
> link utilization. One simple example is, if multiple Flex-Algos use this 
> constraint to exclude the same set of links, this may increase the 
> possibility of congestion on the rest of the links?
> 
> Perhaps a more general question is, what would be the benefit of 
> introducing bandwidth attribute into Flex-Algo based distributed path 
> computation?  It is known that bandwidth can be used in centralized 
> computation for efficient path placement and resource management, can 
> distributed computation with bandwidth constraint achieve the same, or 
> is there some advantages compared with centralized computation?
> 
> 3.With the automatic metric calculation, it could introduce per 
> Flex-Algo link metric value, while the existing Flex-Algo only refers to 
> the metric of the link via metric type. Is this the expected behavior? 
> Will it be further extended to make other link attributes flex-algo 
> specific?

we need to distinguish between:

a) flex-algo application specific metric (applies to all flex-algos)
b) flex-algo X specific metric

(a) already exists in the form of the ASLA advertisement for delay and 
TE-metric. Bandwidth metric will be no different.

(b) there has been no such thing as flex-algo X specific 
metric/attribute defined so far. And we are not defining it in this 
draft either. The draft defines sub-TLVs for automatic bandwidth metric 
calculation. It is the winning FAD for the Flex-Algorithm X that 
specifies whether the automatic bandwidth metric calculation is done or 
not and it would be rather complicated (certainly possible) to have the 
parameters for such calculation being advertised outside of the FAD.

You are right these being part of the FAD may result in the calculated 
bandwidth metric being different for each flex-algo on the same link. 
The intention was NOT to have the different per algo bandwidth metric 
value, rather it was the convenience of reusing the FAD that was the 
motivation for the existing encoding.

So to answer your question, we do NOT intend to make any link attributes 
per flex-algo number.

thanks,
Peter

> 
> 4.In the reference bandwidth method, the draft says it simplifies the 
> management in case the reference bandwidth needs to be changed. Since 
> the reference bandwidth applies to the metric calculation of all the 
> links in the flex-algo with the same proportion, it seems the change of 
> the reference bandwidth will not impact the result of the path 
> computation in the flex-algo. In which case the reference bandwidth need 
> to be changed?
> 
> Best regards,
> 
> Jie
> 
> *From:*Lsr [mailto:[email-masked]] *On Behalf Of *Acee Lindem (acee)
> *Sent:* Thursday, May 13, 2021 5:09 AM
> *To:* [email-masked]
> *Subject:* [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: 
> Bandwidth, Delay, Metrics and Constraints" - 
> draft-hegde-lsr-flex-algo-bw-con-02
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 14 May 2021 09:50:32 +0000

Hi Peter, 

Thanks for your reply, please see inline:

> -----Original Message-----
> From: Peter Psenak [mailto:[email-masked]]
> Sent: Friday, May 14, 2021 5:12 PM
> To: Dongjie (Jimmy) <[email-masked]>; Acee Lindem (acee)
> <acee=[email-masked]>; [email-masked]
> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
> > would be helpful if there is some analysis about how much this can
> > help in traffic engineering, such as to reduce the congestion or
> > improve the link utilization. One simple example is, if multiple
> > Flex-Algos use this constraint to exclude the same set of links, this
> > may increase the possibility of congestion on the rest of the links?
> >
> > Flex-Algo link metric value, while the existing Flex-Algo only refers
> > to the metric of the link via metric type. Is this the expected behavior?

Yes, here I mean flex-algo number specific metric.

> 
> (a) already exists in the form of the ASLA advertisement for delay and TE-metric.
> Bandwidth metric will be no different.
> 
> (b) there has been no such thing as flex-algo X specific metric/attribute defined
> so far. And we are not defining it in this draft either. The draft defines sub-TLVs
> for automatic bandwidth metric calculation. It is the winning FAD for the
> Flex-Algorithm X that specifies whether the automatic bandwidth metric
> calculation is done or not and it would be rather complicated (certainly possible)
> to have the parameters for such calculation being advertised outside of the
> FAD.
> 
> You are right these being part of the FAD may result in the calculated bandwidth
> metric being different for each flex-algo on the same link.
> The intention was NOT to have the different per algo bandwidth metric value,
> rather it was the convenience of reusing the FAD that was the motivation for
> the existing encoding.

Understood. Perhaps some text to clarify this would be helpful, such as:

The reference bandwidth is considered a global parameter for the network, it is not expected to use different reference bandwidth for different flex-algos.

> 
> So to answer your question, we do NOT intend to make any link attributes per
> flex-algo number.

This answer is clear, thanks.

Best regards,
Jie

> > links in the flex-algo with the same proportion, it seems the change
> > of the reference bandwidth will not impact the result of the path
> > computation in the flex-algo. In which case the reference bandwidth
> > need to be changed?
> >
> > Best regards,
> >
> > Jie
> >

---

From: <[email-masked]>
Date: Mon, 17 May 2021 10:09:36 +0800 (CST)

Hi Shraddha,

Thanks for your rely.

So it seems that the scheme may lead to the selection of links with less bandwidth. To address this point, the method as you described to assign more bandwidth to high bandwidth links seems not always possible, e.g, adding more fiber ?

Can this point can be addressed by combination of bandwidth attribute of link and other metric that is cumulative ? IMO, bandwidth is not cumulative.

Regards

PSF

原始邮件

发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：acee=[email-masked];[email-masked];[email-masked];
日 期 ：2021年05月13日 21:01
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Peng shaofu,

Lets say operator wants to choose S->X1->X2-àX10->D path then operator can manually assign higher bandwidth

 

Rgds

Shraddha

 

 

 

updated text:

Hi WG,

Regards,

PSF

 

发件人：AceeLindem(acee)

收件人：[email-masked];

日 期 ：2021年05月13日 05:49

 

 

 

 

 

Thanks,

Chris and Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 17 May 2021 04:15:42 +0000

Hi Pengshaofu,

I was suggesting to manually assign bandwidth metric which will override the automatic metric calculation
as described in the draft section 5. Physically adding more fiber/capacity is not a feasible solution.

Rgds
Shraddha

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Monday, May 17, 2021 7:40 AM
To: Shraddha Hegde <[email-masked]>
Cc: acee=[email-masked]; [email-masked]; [email-masked]
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Shraddha,

Thanks for your rely.

Regards

PSF

原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：acee=[email-masked];[email-masked];[email-masked]<mailto:acee=[email-masked];[email-masked];[email-masked]>;
日 期 ：2021年05月13日 21:01
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Peng shaofu,

Rgds
Shraddha

Juniper Business Use Only
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 13, 2021 1:05 PM
To: [email-masked]<mailto:[email-masked]>
Cc: acee=[email-masked]<mailto:acee=[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

updated text:

Hi WG,

Regards,

PSF

发件人：AceeLindem(acee)
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsL6l_0sA$>

     https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsET5yKGD$>

Thanks,
Chris and Acee

---

From: <[email-masked]>
Date: Mon, 17 May 2021 15:19:15 +0800 (CST)

Hi Shraddha,

The two methods of automatic generation of BW-metric introduced in the draft are also likely to be the method of manual configuration of BW-metric by operators. Operators can certainly manually configure any  BW-metric he wants to configure.

However, the manually configured BW-metric cannot deviate from the actual bandwidth capacity of the link, otherwise it could be any other names such as BX-metric.

For manual assignment, the problem may still exist We can find an example that  the accumulated bandwidth-metric on the path may offset the manually increased bandwidth-metric of links on the path.

Combination of bandwidth attribute of link and other metric that is cumulative may be another co-exist way to completely address this issue.

Regards,

PSF

原始邮件

发件人：ShraddhaHegde
收件人：彭少富10053815;
日 期 ：2021年05月17日 12:15

Hi Pengshaofu,

 

Rgds

Shraddha

 

 

 

Hi Shraddha,

Thanks for your rely.

Regards

PSF

原始邮件

发件人：ShraddhaHegde

收件人：彭少富10053815;

日 期 ：2021年05月13日 21:01

Hi Peng shaofu,

 

Rgds

Shraddha

 

 

 

updated text:

Hi WG,

Regards,

PSF

 

发件人：AceeLindem(acee)

收件人：[email-masked];

日 期 ：2021年05月13日 05:49

 

 

 

 

 

Thanks,

Chris and Acee

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 18 May 2021 02:28:03 +0000

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? Many thanks.

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi authors,

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Thanks,
Chris and Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 18 May 2021 05:01:01 +0000

Hi Pengshaofu,

If an operator wants to configure any other metric type draft provides a mechanism with generic metric.
Generic metric allows any standard or user-defined type metric to be configured.
The draft allows for any computing application such as Flex-algo, CSPF etc to make use of the
Metric. The intention of the draft is that for a particular computation same metric-type is used
throughout the network. If that is not clear, I’ll add some text in the draft.

Using a combination of different metrics for a single computation would need significant change to SPF algorithm and it is not in the scope of the draft "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints".

Hope that clarifies.

Rgds
Shraddha

Sent: Monday, May 17, 2021 12:49 PM

Hi Shraddha,

Regards,

PSF

原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;

Rgds
Shraddha

To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>

Hi Shraddha,

Thanks for your rely.

Regards

PSF

原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;

Rgds
Shraddha

updated text:

Hi WG,

Regards,

PSF

发件人：AceeLindem(acee)

Thanks,
Chris and Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 18 May 2021 05:17:37 +0000

Hi Jimmy,

Thanks for the review and comments.Pls see inline

Juniper Business Use Only
From: Dongjie (Jimmy) <[email-masked]>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Best regards,
Jie

To: Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi authors,

I've read the latest version of this document and have the following comments:

1.       Is the generic metric type applicable to applications other than Flex-Algo? If so, it is better to make this clear in the document, or perhaps it may be defined separately from the Flex-Algo specific extensions?
<Shraddha>Yes. Any application can make use of generic metric including Flex-algo and SR-TE.
                      Sure. I'll add some text to clarify this.

2.       The "Exclude Minimum Bandwidth" constraint is compared with the maximum link bandwidth to exclude the links from the computation, it would be helpful if there is some analysis about how much this can help in traffic engineering, such as to reduce the congestion or improve the link utilization. One simple example is, if multiple Flex-Algos use this constraint to exclude the same set of links, this may increase the possibility of congestion on the rest of the links?
<Shraddha> The motivation for "Exclude Minimum Bandwidth" is to avoid low capacity links for the high bandwidth traffic. For example if the Flex-algo 128 carries high bw traffic flows of bw greater than 10g, it makes sense to remove 1g links from this flex-algo topology since these links if happen to carry traffic, it  will get congested and traffic will be dropped. The introduction section talks about this motivation.

<shraddha> Many network operators assign link metric relative to bandwidth of the link and it is an existing practice. The draft is defining new attributes and constraints in order to simplify and automate this process.

It does not propose any bandwidth reservation/ bandwidth management solutions that a centralized computation or distributed RSVP based solutions provide.

4.       In the reference bandwidth method, the draft says it simplifies the management in case the reference bandwidth needs to be changed. Since the reference bandwidth applies to the metric calculation of all the links in the flex-algo with the same proportion, it seems the change of the reference bandwidth will not impact the result of the path computation in the flex-algo. In which case the reference bandwidth need to be changed?
<Shraddha> Lets take a hypothetical example. Lets say a network starts with all 1G links and 10G reference bw.
Over the years, many links get upgraded to 10G links and some get upgraded to 100G links. Using a 10G reference bandwidth will not be feasible and reference bw need to get increased to a value > 100G.

Best regards,
Jie

     https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QjpfqmfDtSmB967Xe4sgDxr_V5e5fKU85mRhXYGofuadzmAhYjkW1d3yMUntZ2nT$>

Thanks,
Chris and Acee

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 19 May 2021 07:29:20 +0000

Hi Shraddha,

Thanks for your reply. Please see further inline:

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Jimmy,

Juniper Business Use Only
From: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Best regards,
Jie

Hi authors,

[Jie] OK, thanks.

[Jie] I can understand how this works for a single Flex-Algo, while my question was if more than one Flex-Algo use bandwidth as constraint to exclude some links, what would be the consequence to the network?

[Jie] OK it is clear that this mechanism will not replace the centralized bandwidth computation or distributed bandwidth reservation solutions.  While if the purpose is just to simplify and automate the metric configuration process, , it seems the gain is relatively limited?

[Jie] Yes this is a valid case of changing the reference bandwidth, although it happens in a relative large time scale.

Best regards,
Jie

Thanks,
Chris and Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 19 May 2021 10:42:01 +0000

>[Jie] I can understand how this works for a single Flex-Algo, while my question was if more than one Flex-Algo use
>bandwidth as constraint to exclude some links, what would be the consequence to the network?

Operators design and plan whether one flex-algo is suitable for their network or multiple. The planning also involves
the definition of each flex-algo that is suitable for their network. This network planning exercise has to be done
irrespective of whether bandwidth constraints are used in the flex-algo to ensure traffic distribution is even.

Rgds
Shraddha

Juniper Business Use Only
From: Dongjie (Jimmy) <[email-masked]>
Sent: Wednesday, May 19, 2021 12:59 PM
To: Shraddha Hegde <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Shraddha,

Hi Jimmy,

Best regards,
Jie

Hi authors,

[Jie] OK, thanks.

Best regards,
Jie

Thanks,
Chris and Acee

---

From: <[email-masked]>
Date: Thu, 20 May 2021 09:55:49 +0800 (CST)

Hi Shraddha,

Thanks. Actually, I don't really want to define other metric types.

Let's go back to the bandwidth-metric related to bandwidth capability. My worry is that bandwidth-metric (whether it is automatically calculated or manually configured) is not cumulative in nature, which is different from IGP default metric/TE metric/delay metric, so that SPF based on bandwidth-metric may get an unexpected path (see the example of the original mail). Can more text be added in the draft to describe why this can work ?

Regards,

PSF

原始邮件

发件人：ShraddhaHegde
收件人：彭少富10053815;
日 期 ：2021年05月18日 13:01

Hi Pengshaofu,

 

 

Hope that clarifies.

Rgds

Shraddha

 

 

 

Hi Shraddha,

Regards,

PSF

 

原始邮件

发件人：ShraddhaHegde

收件人：彭少富10053815;

日 期 ：2021年05月17日 12:15

Hi Pengshaofu,

 

Rgds

Shraddha

 

 

 

Hi Shraddha,

Thanks for your rely.

Regards

PSF

原始邮件

发件人：ShraddhaHegde

收件人：彭少富10053815;

日 期 ：2021年05月13日 21:01

Hi Peng shaofu,

 

Rgds

Shraddha

 

 

 

updated text:

Hi WG,

Regards,

PSF

 

发件人：AceeLindem(acee)

收件人：[email-masked];

日 期 ：2021年05月13日 05:49

 

 

 

 

 

Thanks,

Chris and Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 20 May 2021 04:16:58 +0000

Hi Pengshaofu,

Pls see inline..

Sent: Thursday, May 20, 2021 7:26 AM

Hi Shraddha,

Let's go back to the bandwidth-metric related to bandwidth capability. My worry is that bandwidth-metric (whether it is automatically calculated or manually configured) is not cumulative in nature,

<Shraddha> Yes that is correct.

which is different from IGP default metric/TE metric/delay metric,

so that SPF based on bandwidth-metric may get an unexpected path (see the example of the original mail).

Can more text be added in the draft to describe why this can work ?

<Shraddha> Knowing that metric derived inversely from the link bandwidth is not additive in nature, should set the expectation right. I can add some text in this regard.

Regards,

PSF

原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;

Hope that clarifies.

Rgds
Shraddha

Hi Shraddha,

Regards,

PSF

原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;

Rgds
Shraddha

Hi Shraddha,

Thanks for your rely.

Regards

PSF

原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;

Rgds
Shraddha

updated text:

Hi WG,

Regards,

PSF

发件人：AceeLindem(acee)

Thanks,
Chris and Acee

---

From: Tony Li <[email-masked]>
Date: Wed, 19 May 2021 21:20:08 -0700

Hi Peng Shaofu,

> On May 19, 2021, at 6:55 PM, [email-masked] wrote:
> 

The whole point of the bandwidth metric (and indeed, of all of FlexAlgo) is to get a different path computation result than what we might get with the standard IGP metric. What it will do in any given topology is highly dependent on the topology, as you’ve seen.  It may or may not ‘work’ by whatever definition you have in mind. However, what matters is what the network operator is trying to achieve. It doesn’t have to work for every topology or every purpose.

Tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 20 May 2021 10:22:29 +0000

Speaking as WG member:

I agree with Tony.

Furthermore, the extensions in the draft provide mechanisms to constraint bandwidth beyond your concern that bandwidth be used as a cumulative metric. I support WG adoption.

Thanks,
Acee

From: Tony Li <[email-masked]> on behalf of Tony Li <[email-masked]>
Date: Thursday, May 20, 2021 at 12:20 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Peng Shaofu,

On May 19, 2021, at 6:55 PM, [email-masked]<mailto:[email-masked]> wrote:

Tony

---

From: <[email-masked]>
Date: Fri, 21 May 2021 09:10:29 +0800 (CST)

Hi Shraddha,

Thanks for your reply. I have no questions any more.

Regards,

PSF

原始邮件

发件人：ShraddhaHegde
收件人：彭少富10053815;
日 期 ：2021年05月20日 12:17

Hi Pengshaofu,

Pls see inline..

 

 

 

Hi Shraddha,

Regards,

PSF

原始邮件

发件人：ShraddhaHegde

收件人：彭少富10053815;

日 期 ：2021年05月18日 13:01

Hi Pengshaofu,

 

 

Hope that clarifies.

Rgds

Shraddha

 

 

 

Hi Shraddha,

Regards,

PSF

 

原始邮件

发件人：ShraddhaHegde

收件人：彭少富10053815;

日 期 ：2021年05月17日 12:15

Hi Pengshaofu,

 

Rgds

Shraddha

 

 

 

Hi Shraddha,

Thanks for your rely.

Regards

PSF

原始邮件

发件人：ShraddhaHegde

收件人：彭少富10053815;

日 期 ：2021年05月13日 21:01

Hi Peng shaofu,

 

Rgds

Shraddha

 

 

 

updated text:

Hi WG,

Regards,

PSF

 

发件人：AceeLindem(acee)

收件人：[email-masked];

日 期 ：2021年05月13日 05:49

 

 

 

 

 

Thanks,

Chris and Acee

---

From: <[email-masked]>
Date: Fri, 21 May 2021 09:48:02 +0800 (CST)

Dear Acee, Tony,

Thanks!

Tony's explanation gives the essential use of bandwidth-metric. My previous understanding is mainly based on the problem to be solved in another draft https://datatracker.ietf.org/doc/draft-lp-lsr-fa-bandwidth/. Sorry to insert an advertisement in this adoption.  : ) 

In draft-lp, the path will be selected strictly according to the actual bandwidth capacity of the link. The main issue is that the computation method  is not optimal, just a basic expression of this idea. 

Just for the expected requirement "to select a path with the maximum link bandwidth from the source node to the destination node", it seems that one scheme try to satisfy most of scenarios, and the other try to satisfy 100%.

Regards

PSF

原始邮件

发件人：AceeLindem(acee)
收件人：Tony Li;彭少富10053815;
抄送人：[email-masked];[email-masked];[email-masked];
日 期 ：2021年05月20日 18:22
主 题 ：Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Speaking as WG member:

I agree with Tony.

 

Thanks,
 Acee

 

Hi Peng Shaofu,

 

 

 

 

Tony

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 21 May 2021 02:39:21 +0000

Hi Shraddha,

Thanks for your further explanation.

I agree if operators design it properly, it could provide the desired result of excluding links whose maximum bandwidth is lower than the specified constraint.

As you said it is not related to the bandwidth management or reservation, thus it is more like a mechanism of relative static network planning, without considering the dynamics of the link bandwidth utilization.

I don't have further questions.

Best regards,
Jie

Sent: Wednesday, May 19, 2021 6:42 PM

Rgds
Shraddha

To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Shraddha,

Hi Jimmy,

Best regards,
Jie

Hi authors,

[Jie] OK, thanks.

Best regards,
Jie

Thanks,
Chris and Acee

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 21 May 2021 11:43:08 +0800

Hi, 

I support the adoption of the “FAD constraint sub-TLV” part(Section 3),  but not support the introduce of  “Bandwidth Metric Advertisement” part (Section 4) and other related parts.

With the introduce of additional constraint information, the problem described in “Introduction” part(Section 1) can be solved.

The usage of bandwidth metric in large network is not feasible. 

And, would you like to explain more for the following statements(in Section 4.1.1.2)

“In the interface group mode, every node MUST identify the set of

   parallel links between a pair of nodes based on IGP link

   advertisements and MUST consider cumulative bandwidth of the parallel

   links while arriving at the metric of each link.”

based on example described in Figure 7? 

How the cumulative bandwidth will be used to achieve the result that traffic from B to D will prefer B-C-F-D, not B-E-D? 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Thanks,

Chris and Acee

---

From: Tony Li <[email-masked]>
Date: Fri, 21 May 2021 08:28:38 -0700

Hi Aijun,

> I support the adoption of the “FAD constraint sub-TLV” part(Section 3),  but not support the introduce of  “Bandwidth Metric Advertisement” part (Section 4) and other related parts.

As I understand it, we don’t get a line item veto, so I don’t know how the chairs will take this.

> With the introduce of additional constraint information, the problem described in “Introduction” part(Section 1) can be solved.

Please say more.  Claims without rationale are not reasoning.

> The usage of bandwidth metric in large network is not feasible. 

Ditto.

> based on example described in Figure 7? 

The paragraph immediately above explains exactly that. B->C has two parallel 10Gbps links, so it should be considered to be 20Gbps.

> How the cumulative bandwidth will be used to achieve the result that traffic from B to D will prefer B-C-F-D, not B-E-D? 

B-C-F-D is 20Gbps. B-E-D is 10Gbps.

Tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 21 May 2021 15:37:39 +0000

Hi Tony, Aijun,

From: Tony Li <[email-masked]> on behalf of Tony Li <[email-masked]>
Date: Friday, May 21, 2021 at 11:29 AM
To: Aijun Wang <[email-masked]>
Cc: Acee Lindem <[email-masked]>, lsr <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Aijun,

As WG chair, I don’t see that Aijun’s concerns would prevent WG adoption. The draft has plenty of support. The discussion can continue after adoption.

Thanks,
Acee

Ditto.

Tony

---

From: Aijun Wang <[email-masked]>
Date: Sat, 22 May 2021 06:21:52 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On May 21, 2021, at 23:29, Tony Li <[email-masked]> wrote:
> 
> 
> 
> Hi Aijun,
> 

[WAJ] The reasonable solution is to take out of the controversial part from the adopted document.

> Please say more.  Claims without rationale are not reasoning.
[WAJ]  The introduction part talks mainly how to divert the elephant traffic away from the low bandwidth link. This can be achieved via the introduction of additional constraints information for Flex-ALGO.
>> The usage of bandwidth metric in large network is not feasible. 
[WAJ] The main reason is that bandwidth metric is not cumulative.  
> B-C-F-D is 20Gbps. B-E-D is 10Gbps.

[WAJ] OK, let’s add two nodes between node B and C, say they are node M and N. They have also two parallel links to B and C respectively. The two possible path from B to D will be:
Path 1: B-M-N-C-F-D
Path 2: B-E-D
If the “reference bandwidth” is 100G, then metric for each link in B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1 “B—N-C-F-D” will be 25, right?
The metric for each link in B-E-D will be 10, the cumulative metric from B-D for Path 2 will be 20, right?
How can you prefer to the high bandwidth path?

---

From: Aijun Wang <[email-masked]>
Date: Sat, 22 May 2021 06:31:45 +0800

Hi, Acee:
For adoption call of one document, you are counting the number of support votes, not to let the authors solve/explain the disputed part?
My understanding is that the WG Chairs should help to solve the controversial points, or make judgements based on his knowledges.

Aijun Wang
China Telecom

> On May 21, 2021, at 23:38, Acee Lindem (acee) <acee=[email-masked]> wrote:
> 
> 
> Hi Tony, Aijun,
>

---

From: Tony Li <[email-masked]>
Date: Fri, 21 May 2021 15:40:46 -0700

Hi Aijun,

> [WAJ]  The introduction part talks mainly how to divert the elephant traffic away from the low bandwidth link. This can be achieved via the introduction of additional constraints information for Flex-ALGO

Which is exactly what we’ve done: added bandwidth constraints. 

> [WAJ] The main reason is that bandwidth metric is not cumulative.  

??? What are you seeing that implies that?  That is not my understanding at all.

> How can you prefer to the high bandwidth path?

Override the metric on B-E-D to be even higher.

The point of the bandwidth metric (at least in this incarnation) is not to make hop count irrelevant. It is to set the metrics relative to the bandwidth so that traffic skews towards higher bandwidths. Hops are still relevant. An operator can adjust the reference bandwidth and add manual metrics to achieve different effects, depending on their precise needs.

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 21 May 2021 18:59:07 -0400

Aijun

This is a similar concept to what exists today with most vendors CLI
configured reference bandwidth that can be overridden by manual metrics
link by link to skew traffic to avoid bottle necks, but now applying that
same concept that has existed historically to Flex Algo  new “bandwidth
metric” static generic metric TLV and new automatic reference bandwidth
based metric.

With this algorithm change the issue that has existed with IGP ECMP
parallel links is that they are all treated as individual and so the total
group bandwidth is not taken into account.  So this is a major benefit to
now being incorporated into Flex Algo.   Also the concept of being able to
exclude links based on minimum bandwidth is as well a benefit so traffic is
skewed to the higher bandwidth links.

This is basically another option for operators using Flex Algo in the
operators toolbox.

Kind Regards

Gyan

On Fri, May 21, 2021 at 6:40 PM Tony Li <[email-masked]> wrote:

>
> Hi Aijun,
>
> With the introduce of additional constraint information, the problem
> described in “Introduction” part(Section 1) can be solved.
>
>
>
> [WAJ]  The introduction part talks mainly how to divert the elephant
> traffic away from the low bandwidth link. This can be achieved via the
> introduction of additional constraints information for Flex-ALGO
>
>
>
> The paragraph immediately above explains exactly that. B->C has two
> parallel 10Gbps links, so it should be considered to be 20Gbps.
>
>
>
> How the cumulative bandwidth will be used to achieve the result that
> traffic from B to D will prefer B-C-F-D, not B-E-D?
>
>
>
> [WAJ] OK, let’s add two nodes between node B and C, say they are node M
> and N. They have also two parallel links to B and C respectively. The two
> possible path from B to D will be:
> Path 1: B-M-N-C-F-D
> Path 2: B-E-D
> If the “reference bandwidth” is 100G, then metric for each link in
> B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1
> “B—N-C-F-D” will be 25, right?
> The point of the bandwidth metric (at least in this incarnation) is not to
> make hop count irrelevant. It is to set the metrics relative to the
> bandwidth so that traffic skews towards higher bandwidths. Hops are still
> relevant. An operator can adjust the reference bandwidth and add manual
> metrics to achieve different effects, depending on their precise needs.
>
> Tony
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Aijun Wang <[email-masked]>
Date: Sat, 22 May 2021 06:59:47 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On May 22, 2021, at 06:40, Tony Li <[email-masked]> wrote:
> 
> 
> 
> Hi Aijun,
> 

[WAJ] Yes, I agree with this.

> ??? What are you seeing that implies that?  That is not my understanding at all.

[WAJ] The operator must plan carefully for the metric assignment accordingly to their specific topology to let the traffic pass the necessary high bandwidth path as done in the following example.

> Override the metric on B-E-D to be even higher.

[WAJ] If such work must be done manually, it certainly weaken the necessary of the automatic metric calculations based on link bandwidth, also the introduction of bandwidth metric.

> 
> The point of the bandwidth metric (at least in this incarnation) is not to make hop count irrelevant. It is to set the metrics relative to the bandwidth so that traffic skews towards higher bandwidths.

[WAJ] This can be done via the “bandwidth constraints sub TLV” that is introduced in this document.

> Hops are still relevant. An operator can adjust the reference bandwidth and add manual metrics to achieve different effects, depending on their precise needs.
[WAJ] Is it more simple and easy to get determined results via setting the link metric based on the additive information?

---

From: Aijun Wang <[email-masked]>
Date: Sat, 22 May 2021 07:19:50 +0800

Hi, Gyan:

Aijun Wang
China Telecom

> On May 22, 2021, at 06:59, Gyan Mishra <[email-masked]> wrote:
> 
> 
> 
> Aijun 
> 
> This is a similar concept to what exists today with most vendors CLI configured reference bandwidth that can be overridden by manual metrics link by link to skew traffic to avoid bottle necks, but now applying that same concept that has existed historically to Flex Algo  new “bandwidth metric” static generic metric TLV and new automatic reference bandwidth based metric.  
[WAJ] Yes, I know.  But the reality is that we rarely use such bandwidth based automatic metric assignments method because it can’t get the determined results as we expected. For example, if two links between the one node pair has different bandwidth, the lower bandwidth link will be not utilized at all.
There may exist other issues in large complex network. The operator must take care of each possible unexpected scenario manually.
> 
> With this algorithm change the issue that has existed with IGP ECMP parallel links is that they are all treated as individual and so the total group bandwidth is not taken into account. 
[WAJ] But in some situations, especially the high bandwidth path has multiple hops than the low bandwidth path, the operator must intervene manually to change the automatic obtained bandwidth metric to achieve the expected results, as also agree with Tony in our discussed example.
Will you bother yourself for knob?

> So this is a major benefit to now being incorporated into Flex Algo.   Also the concept of being able to exclude links based on minimum bandwidth is as well a benefit so traffic is skewed to the higher bandwidth links.  
[WAJ] Yes, I agree with the introduction of minimum bandwidth constraints in Flex-Algorithm, but not the bandwidth metric.
> 
> This is basically another option for operators using Flex Algo in the operators toolbox.
> 
> Kind Regards 
> 
> Gyan
> 
> Gyan Mishra
> Network Solutions Architect 
> Email [email-masked]
> M 301 502-1347
> 
>

---

From: Tony Li <[email-masked]>
Date: Fri, 21 May 2021 16:35:21 -0700

Hi Aijun,

> [WAJ] The operator must plan carefully for the metric assignment accordingly to their specific topology to let the traffic pass the necessary high bandwidth path as done in the following example.

That’s only if they have no concerns about the hop count.

Previous experience with other routing protocols that have a bandwidth based metric and do compute a cumulative metric does show that it is indeed possible to run many large networks this way and get
acceptable results.

> [WAJ] If such work must be done manually, it certainly weaken the necessary of the automatic metric calculations based on link bandwidth, also the introduction of bandwidth metric.

In many cases, that’s probably not necessary.

> [WAJ] This can be done via the “bandwidth constraints sub TLV” that is introduced in this document.

No, that alone would exclude the hop count, resulting in a different path computation.

> [WAJ] Is it more simple and easy to get determined results via setting the link metric based on the additive information?

I don’t understand what you’re asking.

Please remember that we are not trying to solve all problems for all people. We are trying to provide tools so that operators can drive traffic automatically in the way that they want. We’re trying to provide a variety of tools, with appropriate nerd knobs so that we can do useful traffic engineering without resorting to the very big hammer of having a centralized controller compute everything and program the entire network.

Tonny

---

From: Aijun Wang <[email-masked]>
Date: Sat, 22 May 2021 08:18:41 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On May 22, 2021, at 07:35, Tony Li <[email-masked]> wrote:
> 
> 
> Hi Aijun,
> 
[WAJ] Hop count have little influence on the application performance. Nearly every router can forward traffic in line speed as declared by every device vendor?
> Previous experience with other routing protocols that have a bandwidth based metric and do compute a cumulative metric does show that it is indeed possible to run many large networks this way and g…
[WAJ] We prefer to the solution that can get determined results under various scenarios, not just fit part of them.

> I don’t understand what you’re asking.
[WAJ] For example, if we set the metric based on the distance between two nodes, we can certainly say that the best path will have the shortest E2E distance; if we set the metric based on the link delay, we can assure the traffic will be forwarded in least delay path. 
But if we set the metric based on the link bandwidth, I think you cannot assure the E2E traffic will always pass the expected high bandwidth path. Is it right?
> Please remember that we are not trying to solve all problems for all people. We are trying to provide tools so that operators can drive traffic automatically in the way that they want. We’re trying…

[WAJ] My observation is that the operator will need more judgment works in their centralized controller to utilize such tools, especially in some complex topology (because you need even manual intervention in some common topology scenarios)
I am also prefer to more automatic work been done in distributed manner. But shouldn’t such work/tools get determined expected results automatically even in some simple topology?

---

From: Tony Li <[email-masked]>
Date: Fri, 21 May 2021 17:24:33 -0700

Hi Aijun,

> [WAJ] Hop count have little influence on the application performance. Nearly every router can forward traffic in line speed as declared by every device vendor?

Yes, but hop count has a significant impact on the bits * miles/km product that represents ISP cost.

> [WAJ] We prefer to the solution that can get determined results under various scenarios, not just fit part of them.

There are no solutions that fit all scenarios. Otherwise, we would not have traffic engineering and interesting path computation.

> But if we set the metric based on the link bandwidth, I think you cannot assure the E2E traffic will always pass the expected high bandwidth path. Is it right?

Not per the current formulation, but then that’s not what we’re after.

> I am also prefer to more automatic work been done in distributed manner. But shouldn’t such work/tools get determined expected results automatically even in some simple topology?

As I alluded to previously, bandwidth based metrics that have some respect for hop count have been found to be automatically helpful in MANY, MANY, MANY networks in previous routing protocols.  Perhaps one of my competitors would be willing to say the name that I am unable to mention.

Tony

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 23 May 2021 13:04:05 -0700

Hi Shraddha, Authors, et al.,
I apologize if my question has already been discussed. The unit for the
maximum link delay in the draft is a microsecond. There is a group of
services that require a highly accurate bounded delay. Have you considered
using a nanosecond as the unit for the link delay?

Regards,
Greg

On Wed, May 19, 2021 at 9:17 PM Shraddha Hegde <shraddha=
[email-masked]> wrote:

> *From:* [email-masked] <[email-masked]>
> *Sent:* Thursday, May 20, 2021 7:26 AM
> *To:* Shraddha Hegde <[email-masked]>
> *Cc:* acee=[email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Let's go back to the bandwidth-metric related to bandwidth capability. My
> worry is that bandwidth-metric (whether it is automatically calculated or
> manually configured) is not cumulative in nature,
>
> <Shraddha> Knowing that metric derived inversely from the link bandwidth
> is not additive in nature, should set the expectation right. I can add some
> text in this regard.
>
>
>
> Regards,
>
> PSF
>
>
>
>
>
> 原始邮件
>
> *发件人：*ShraddhaHegde
>
> *收件人：*彭少富10053815;
>
> *抄送人：*
> acee=[email-masked];[email-masked];[email-masked]
> ;
>
> *日* *期* *：*2021年05月18日 13:01
>
> *主* *题* *：**RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> draft-hegde-lsr-flex-algo-bw-con-02*
>
> Hi Pengshaofu,
>
>
>
> Using a combination of different metrics for a single computation would
> need significant change to SPF algorithm and it is not in the scope of the
> draft "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints".
>
>
>
> Hope that clarifies.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> *From:* [email-masked] <[email-masked]>
> *Sent:* Monday, May 17, 2021 12:49 PM
> *To:* Shraddha Hegde <[email-masked]>
> *Cc:* acee=[email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> The two methods of automatic generation of BW-metric introduced in the
> draft are also likely to be the method of manual configuration of BW-metric
> by operators. Operators can certainly manually configure any  BW-metric he
> wants to configure.
>
> However, the manually configured BW-metric cannot deviate from the actual
> bandwidth capacity of the link, otherwise it could be any other names such
> as BX-metric.
>
> For manual assignment, the problem may still exist We can find an example
> that  the accumulated bandwidth-metric on the path may offset the manually
> increased bandwidth-metric of links on the path.
>
> Combination of bandwidth attribute of link and other metric that is
> cumulative may be another co-exist way to completely address this issue.
>
>
>
> Regards,
>
> PSF
>
>
>
>
>
>
>
>
>
> 原始邮件
>
> *发件人：*ShraddhaHegde
>
> *收件人：*彭少富10053815;
>
> *抄送人：*
> acee=[email-masked];[email-masked];[email-masked]
> ;
>
> *日* *期* *：*2021年05月17日 12:15
>
> *主* *题* *：**RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> draft-hegde-lsr-flex-algo-bw-con-02*
>
> Hi Pengshaofu,
>
>
>
> *From:* [email-masked] <[email-masked]>
> *Sent:* Monday, May 17, 2021 7:40 AM
> *To:* Shraddha Hegde <[email-masked]>
> *Cc:* acee=[email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> So it seems that the scheme may lead to the selection of links with less
> bandwidth. To address this point, the method as you described to assign
> more bandwidth to high bandwidth links seems not always possible, e.g,
> adding more fiber ?
>
> Can this point can be addressed by combination of bandwidth attribute of
> link and other metric that is cumulative ? IMO, bandwidth is not cumulative.
>
>
>
> Regards
>
> PSF
>
>
>
> 原始邮件
>
> *发件人：*ShraddhaHegde
>
> *收件人：*彭少富10053815;
>
> *抄送人：*
> acee=[email-masked];[email-masked];[email-masked]
> ;
>
> *日* *期* *：*2021年05月13日 21:01
>
> *主* *题* *：**RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> draft-hegde-lsr-flex-algo-bw-con-02*
>
> Hi Peng shaofu,
>
>
>
> *From:* [email-masked] <[email-masked]>
> *Sent:* Thursday, May 13, 2021 1:05 PM
> *To:* [email-masked]
> *Cc:* acee=[email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> So flex-algo path from S to D based on bandwidth-metric will be S-D,
> not S---X1---X2...---D, because the later has a large cumulative
> bandwitdh-metric (i.e., 11*10).
>
> *发件人：*AceeLindem(acee)
> *收件人：[email-masked];
> *抄送人：[email-masked];
>
> *日* *期* *：*2021年05月13日 05:49
>
> *主* *题* *：**[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> draft-hegde-lsr-flex-algo-bw-con-02*
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsL6l_0sA$>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsET5yKGD$>
>
>
>
>

---

From: Tony Li <[email-masked]>
Date: Sun, 23 May 2021 13:56:16 -0700

Hi Greg,

That’s a very fair question and not one that has been discussed.

Do we have that kind of accuracy from any of our measurement tools? Is that even on the horizon?  I haven’t seen that…

If it is time for nanosecond level measurement, then is it time to shift to floating point to give us more range?

Tony

> On May 23, 2021, at 1:04 PM, Greg Mirsky <[email-masked]> wrote:
> 
> I apologize if my question has already been discussed. The unit for the maximum link delay in the draft is a microsecond. There is a group of services that require a highly accurate bounded delay. Have you considered using a nanosecond as the unit for the link delay?
> 
> Regards,
> Greg
> 
> On Wed, May 19, 2021 at 9:17 PM Shraddha Hegde <shraddha=[email-masked] <mailto:[email-masked]>> wrote:
> Hi Pengshaofu,
> 
>  
> 
> Pls see inline..
> 
>  
> 
>  
> 
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
> To: Shraddha Hegde <[email-masked] <mailto:[email-masked]>>
> Cc: acee=[email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 抄送人：acee=[email-masked];[email-masked];[email-masked] <mailto:acee=[email-masked];[email-masked];[email-masked]>;
> 
> 日 期 ：2021年05月18日 13:01
> 
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
> To: Shraddha Hegde <[email-masked] <mailto:[email-masked]>>
> Cc: acee=[email-masked] <mailto:acee=[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 抄送人：acee=[email-masked];[email-masked];[email-masked] <mailto:acee=[email-masked];[email-masked];[email-masked]>;
> 
> 日 期 ：2021年05月17日 12:15
> 
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
> To: Shraddha Hegde <[email-masked] <mailto:[email-masked]>>
> Cc: acee=[email-masked] <mailto:acee=[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 抄送人：acee=[email-masked];[email-masked];[email-masked] <mailto:acee=[email-masked];[email-masked];[email-masked]>;
> 
> 日 期 ：2021年05月13日 21:01
> 
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
> To: [email-masked] <mailto:[email-masked]>
> Cc: acee=[email-masked] <mailto:acee=[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 收件人：[email-masked] <mailto:[email-masked]>;
> 
> 抄送人：[email-masked] <mailto:[email-masked]>;
> 
> 日 期 ：2021年05月13日 05:49
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsL6l_0sA$>
>      https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsET5yKGD$>    
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 24 May 2021 00:06:32 +0000

Hi Greg,

Additionally, in a vacuum light will only travel 300 meters in a microsecond. So, in a nanosecond, that is less than a foot. What transmission technology and application do you anticipate that will require this this precision?

Thanks,
Acee

From: Tony Li <[email-masked]> on behalf of Tony Li <[email-masked]>
Date: Sunday, May 23, 2021 at 4:56 PM
To: Greg Mirsky <[email-masked]>
Cc: Shraddha Hegde <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Greg,

Tony

On May 23, 2021, at 1:04 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Greg

On Wed, May 19, 2021 at 9:17 PM Shraddha Hegde <shraddha=[email-masked]<mailto:[email-masked]>> wrote:
Hi Pengshaofu,

Pls see inline..

Cc: acee=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Shraddha,

Regards,
PSF

原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;

Hope that clarifies.

Rgds
Shraddha

Hi Shraddha,

Regards,
PSF

原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;

Rgds
Shraddha

Hi Shraddha,

Thanks for your rely.

Regards
PSF

原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;

Rgds
Shraddha

Hi WG,

Regards,
PSF

发件人：AceeLindem(acee)

Thanks,
Chris and Acee

---

From: Christian Hopps <[email-masked]>
Date: Sun, 23 May 2021 21:04:29 -0400

"Acee Lindem (acee)" <acee=[email-masked]> writes:

> Hi Greg,
>
>
>
> Additionally, in a vacuum light will only travel 300 meters in a
> microsecond. So, in a nanosecond, that is less than a foot. What
> transmission technology and application do you anticipate that will
> require this this precision?

Off by a few magnitude; light travels just shy of 300,000,000 meters per second.

Consider that 100Gbps links transmit 100 bits every nanosecond. So about 5 nanoseconds to send a minimum sized ethernet frame (sans the pre/postamble).

Thanks,
Chris.

> Cc: Shraddha Hegde <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]"
> <[email-masked]>, Acee Lindem
> <[email-masked]>
> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Do we have that kind of accuracy from any of our measurement tools?
> Is that even on the horizon?  I haven’t seen that…
>
>
>
> If it is time for nanosecond level measurement, then is it time to
> shift to floating point to give us more range?
>
>
>
> Tony
>
>
>
>     I apologize if my question has already been discussed. The unit
>     for the maximum link delay in the draft is a microsecond. There
>     is a group of services that require a highly accurate bounded
>     delay. Have you considered using a nanosecond as the unit for the
>     link delay?
>
>
>
>     Regards,
>
>     Greg
>
>
>
>         Cc: acee=[email-masked]; [email-masked];
>         Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible
>         Algorithms: Bandwidth, Delay, Metrics and Constraints" -
>         Let's go back to the bandwidth-metric related to bandwidth
>         capability. My worry is that bandwidth-metric (whether it is
>         automatically calculated or manually configured) is not
>         cumulative in nature,
>
>         so that SPF based on bandwidth-metric may get an unexpected
>         path (see the example of the original mail).
>
>         <Shraddha> Knowing that metric derived inversely from the
>         link bandwidth is not additive in nature, should set the
>         expectation right. I can add some text in this regard.
>
>
>
>         Regards,
>
>         PSF
>
>
>
>
>
>                                   原始邮件
>
>         发件人：ShraddhaHegde
>
>         收件人：彭少富10053815;
>
>         抄送人：acee=[email-masked];[email-masked];
>         [email-masked];
>
>         日期：2021年05月18日 13:01
>
>         主题：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible
>         Algorithms: Bandwidth, Delay, Metrics and Constraints" -
>         If an operator wants to configure any other metric type draft
>         provides a mechanism with generic metric.
>
>         Using a combination of different metrics for a single
>         computation would need significant change to SPF algorithm
>         and it is not in the scope of the draft "Flexible Algorithms:
>         Bandwidth, Delay, Metrics and Constraints".
>
>
>
>         Hope that clarifies.
>
>
>
>         Rgds
>
>         Shraddha
>
>
>
>
>
>         Cc: acee=[email-masked]; [email-masked];
>         Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible
>         Algorithms: Bandwidth, Delay, Metrics and Constraints" -
>         The two methods of automatic generation of BW-metric
>         introduced in the draft are also likely to be the method of
>         manual configuration of BW-metric by operators. Operators
>         can certainly manually configure any  BW-metric he wants to
>         configure.
>
>         However, the manually configured BW-metric cannot deviate
>         from the actual bandwidth capacity of the link, otherwise it
>         could be any other names such as BX-metric.
>
>         For manual assignment, the problem may still exist We can
>         find an example that  the accumulated bandwidth-metric on the
>         path may offset the manually increased bandwidth-metric of
>         links on the path.
>
>         Combination of bandwidth attribute of link and other metric
>         that is cumulative may be another co-exist way to completely
>         address this issue.
>
>
>
>         Regards,
>
>         PSF
>
>
>
>
>
>
>
>
>
>                                   原始邮件
>
>         发件人：ShraddhaHegde
>
>         收件人：彭少富10053815;
>
>         抄送人：acee=[email-masked];[email-masked];
>         [email-masked];
>
>         日期：2021年05月17日 12:15
>
>         主题：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible
>         Algorithms: Bandwidth, Delay, Metrics and Constraints" -
>         I was suggesting to manually assign bandwidth metric which
>         will override the automatic metric calculation
>
>         as described in the draft section 5. Physically adding more
>         fiber/capacity is not a feasible solution.
>
>
>
>         Rgds
>
>         Shraddha
>
>
>
>
>
>         Cc: acee=[email-masked]; [email-masked];
>         Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible
>         Algorithms: Bandwidth, Delay, Metrics and Constraints" -
>         So it seems that the scheme may lead to the selection of
>         links with less bandwidth. To address this point, the method
>         as you described to assign more bandwidth to high bandwidth
>         links seems not always possible, e.g, adding more fiber ?
>
>         Can this point can be addressed by combination of bandwidth
>         attribute of link and other metric that is cumulative ? IMO,
>         bandwidth is not cumulative.
>
>
>
>         Regards
>
>         PSF
>
>
>
>                                   原始邮件
>
>         发件人：ShraddhaHegde
>
>         收件人：彭少富10053815;
>
>         抄送人：acee=[email-masked];[email-masked];
>         [email-masked];
>
>         日期：2021年05月13日 21:01
>
>         主题：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible
>         Algorithms: Bandwidth, Delay, Metrics and Constraints" -
>         As per the draft, if automatic metric calculation with
>         reference bandwidth method is used to calculate the metric
>
>         Lets say operator wants to choose S->X1->X2-àX10->D path then
>         operator can manually assign higher bandwidth
>
>         Cc: acee=[email-masked]; [email-masked];
>         Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible
>         Algorithms: Bandwidth, Delay, Metrics and Constraints" -
>         Suppose the links in S---X1---X2...---D have the same
>         bandwidth  10G, and the link S-D has bandwidth 1G.
>
>         So flex-algo path from S to D based on bandwidth-metric will
>         be S-D, not S---X1---X2...---D, because the later has a large
>         cumulative bandwitdh-metric (i.e., 11*10).
>
>         But our expect path should not be S-D, but
>         S---X1---X2...---D, as it has large bandwidth.
>
>         日期：2021年05月13日 05:49
>         主题：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
>         Please indicate your support or objection by May 27^th, 2021.
>
>
>
>         Authors, please respond to the list indicating whether you
>         are aware of any IPR that applies to this draft.
>
>
>
>         Thanks,
>
>         Chris and Acee
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 23 May 2021 18:24:53 -0700

Acee is talking propagation delay.
Chris is talking transmission delay.
Link delay is the sum of propagation and transmission delay.  (Perhaps that
clarification should be added to the draft?)
But most ASICs have a minimum delay just to get the packet through the
ASIC.  The smallest numbers I have seen are around 200 nsec, and they are
rare.  This must be added to the transmission delay.

Cables can be quite short within a data center.  See slide 8:
https://www.ieee802.org/3/400GSG/public/13_11/booth_400_01a_1113.pdf
But I don't think this technology is too interesting for use inside a data
center, and even if it was rounding such links to 1 usec would probably be
OK.

As such, to me the 1 usec granularity looks OK.

On Sun, May 23, 2021 at 6:12 PM Christian Hopps <[email-masked]> wrote:

> Consider that 100Gbps links transmit 100 bits every nanosecond. So about 5
> nanoseconds to send a minimum sized ethernet frame (sans the pre/postamble).
>
> Thanks,
> Chris.
>
>
> >
> >
> >
> > Thanks,
> >
> > Acee
> >
> >
> >

---

From: Christian Hopps <[email-masked]>
Date: Sun, 23 May 2021 21:33:26 -0400

Christian Hopps <[email-masked]> writes:

> [[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps <[email-masked]> (trust ultimate) created at 2021-05-23T21:12:09-0400 using RSA]]
>

Or not.. getting my kilometers, meters, us and ns mixed up here. :) Your right on the transmission delay, sorry.

Thanks,
Chris.

> [[End of PGP Signed Part]]

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 24 May 2021 04:27:00 +0000

Greg and others,

The measurement mechanisms and advertisements in ISIS support micro-second granularity (RFC 8570).
The current draft is defining constraints on these advertised link delay.
The thread below seems to be converging towards micro-second granularity but even if we needed nano second granularity, it would not be in the scope of this document. We will first have to standardize measurement and advertisement of link delay in  nano second granularity.

Rgds
Shraddha

-----Original Message-----
From: Christian Hopps <[email-masked]>
Sent: Monday, May 24, 2021 7:03 AM
To: Christian Hopps <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; Greg Mirsky <[email-masked]>; [email-masked]; [email-masked]; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; [email-masked]
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Christian Hopps <[email-masked]> writes:

> [[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps 
> <[email-masked]> (trust ultimate) created at 
> 2021-05-23T21:12:09-0400 using RSA]]
>

Thanks,
Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 24 May 2021 11:08:43 +0000

On 5/23/21, 9:12 PM, "Christian Hopps" <[email-masked]> wrote:

300,000,000 meters per second / 1,000,000 microseconds per second = 300 meters per microsecond 

So, I don't think this is wrong. Also there is the standard definition of light microsecond - https://www.convert-me.com/en/convert/length/lightmicrosecond.html?u=lightmicrosecond&v=1

Thanks
Acee

    Thanks,
    Chris.

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 24 May 2021 08:27:22 -0700

The part that Chris mentioned (transmission delay) doesn't depend on speed
of light or cable length; it only depends on link speed.
The part that you mentioned (propagation delay) depends only on cable
length and speed of light in that medium and is independent of link speed.

Typically, the speed of light in fiber is estimated to be around 2x10^8
m/sec.

There's also packet processing delay which I mentioned in my other email
and queueing delay which I forgot to mention.

I think it might be a good idea if the draft mentioned what delay(s)
"SHOULD" be used.

On Mon, May 24, 2021 at 4:10 AM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> So, I don't think this is wrong. Also there is the standard definition of
> light microsecond -
> https://www.convert-me.com/en/convert/length/lightmicrosecond.html?u=lightmicrosecond&v=1
>
>
> Thanks
> Acee
>
>     Consider that 100Gbps links transmit 100 bits every nanosecond. So
> about 5 nanoseconds to send a minimum sized ethernet frame (sans the
> pre/postamble).
>
>     Thanks,
>     Chris.
>
>
>     >
>     >
>     >
>     > Thanks,
>     >
>     > Acee
>     >
>     >
>     >

---

From: Tony Li <[email-masked]>
Date: Mon, 24 May 2021 08:33:01 -0700

> On May 24, 2021, at 8:27 AM, Anoop Ghanwani <[email-masked]> wrote:
> 
> I think it might be a good idea if the draft mentioned what delay(s) "SHOULD" be used.

Why?

It seems like this is local to a domain. The network administrator is free to do as he sees fit and include whatever parameters make sense to them. As long as the network is self-consistent, that should operate correctly.

Tony

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 24 May 2021 08:39:01 -0700

I thought that it might help operators and vendors think about
these components.

On Mon, May 24, 2021 at 8:33 AM Tony Li <[email-masked]> wrote:

> It seems like this is local to a domain. The network administrator is free
> to do as he sees fit and include whatever parameters make sense to them. As
> long as the network is self-consistent, that should operate correctly.
>
> Tony
>
>

---

From: Tony Li <[email-masked]>
Date: Mon, 24 May 2021 08:42:29 -0700

> On May 24, 2021, at 8:39 AM, Anoop Ghanwani <[email-masked]> wrote:
> 
> I thought that it might help operators and vendors think about these components.

I would have no objection to simply enumerating the possibilities and noting the consistency requirement.

Tony

> 
> On Mon, May 24, 2021 at 8:33 AM Tony Li <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On May 24, 2021, at 8:27 AM, Anoop Ghanwani <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 24 May 2021 08:46:34 -0700

Yes, I think that would be useful.

On Mon, May 24, 2021 at 8:42 AM Tony Li <[email-masked]> wrote:

>> It seems like this is local to a domain. The network administrator is
>> free to do as he sees fit and include whatever parameters make sense to
>> them. As long as the network is self-consistent, that should operate
>> correctly.
>>
>> Tony
>>
>>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 24 May 2021 16:38:59 +0000

Any measurement of delay would include the both components of delay.
Thanks,
Acee

From: Anoop Ghanwani <[email-masked]>
Date: Monday, May 24, 2021 at 11:28 AM
To: Acee Lindem <[email-masked]>
Cc: Christian Hopps <[email-masked]>, Greg Mirsky <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Shraddha Hegde <[email-masked]>, Tony Li <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

The part that Chris mentioned (transmission delay) doesn't depend on speed of light or cable length; it only depends on link speed.
The part that you mentioned (propagation delay) depends only on cable length and speed of light in that medium and is independent of link speed.

Typically, the speed of light in fiber is estimated to be around 2x10^8 m/sec.

There's also packet processing delay which I mentioned in my other email and queueing delay which I forgot to mention.

On Mon, May 24, 2021 at 4:10 AM Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:

On 5/23/21, 9:12 PM, "Christian Hopps" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks
Acee

    Thanks,
    Chris.

    >
    >
    >
    > Thanks,
    >
    > Acee
    >
    >
    >
    > From: Tony Li <[email-masked]<mailto:[email-masked]>> on behalf of Tony Li
    > <[email-masked]<mailto:[email-masked]>>
    > To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
    > Cc: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
    > <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
    > "[email-masked]<mailto:[email-masked]>"
    > <[email-masked]<mailto:[email-masked]>>, Acee Lindem
    > <[email-masked]<mailto:[email-masked]>>
    >     [email-masked]<mailto:[email-masked]>> wrote:
    >
    >         Hi Pengshaofu,
    >
    >
    >
    >         Pls see inline..
    >
    >
    >
    >
    >
    >         Cc: acee=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
    >         [email-masked]<mailto:[email-masked]>
    >         抄送人：acee=[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;
    >         [email-masked]<mailto:[email-masked]>;
    >
    >         日期：2021年05月18日 13:01
    >
    >         Cc: acee=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
    >         [email-masked]<mailto:[email-masked]>
    >         抄送人：acee=[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;
    >         [email-masked]<mailto:[email-masked]>;
    >
    >         日期：2021年05月17日 12:15
    >
    >         Cc: acee=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
    >         [email-masked]<mailto:[email-masked]>
    >         抄送人：acee=[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;
    >         [email-masked]<mailto:[email-masked]>;
    >
    >         日期：2021年05月13日 21:01
    >
    >         Cc: acee=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
    >         [email-masked]<mailto:[email-masked]>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 24 May 2021 17:27:44 +0000

Hello Authors/All,

In general, I support the adoption of this document. There is, however, one specific point which is not clear to me (8) below that I would appreciate some clarity on before adoption.

Some questions/comments/suggestions:

  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, I do see MAX METRIC being referred to as 4,261,412,864.
  2.  Would be good to cover the max-metric considerations for the Generic Metric. Similar to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3
  3.  Since the draft is covering FlexAlgo, I would have expected that Generic Metric is carried only in the ASLA and this document specifies usage only for the FA application. Later this can be also used/extended for other applications but still within ASLA. Keeping an option of advertising both outside and within the ASLA is problematic – we will need precedence rules and such. I prefer we avoid this complication.
  4.  For the newly proposed FAD b/w constraints, I would suggest the following names for the constraint sub-TLVs where the b/w value signalled by all is compared with the Max Link B/w attribute. This is just to make the meaning, at least IMHO, more clear.
     *   Exclude Higher Bandwidth Links
     *   Exclude Lower Bandwidth Links
     *   Include-Only Higher Bandwidth Links
     *   Include-Only Lower Bandwidth Links
  5.  Similar naming for the FAD delay constraints as well would help. Though I can only think of the use of “exclude” for links above a certain delay threshold to be more practical but perhaps others might eventually be required as well?
  6.  For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7, in case of ISIS also, it is not really appropriate for use within ASLA - https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1?
  7.  Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric.
  8.  The document introduces a new Generic Metric type called Bandwidth metric. I’ve been trying to follow some of the discussion related to this on the mailing list – about it being cumulative or not. I am perhaps somewhat confused by those discussions. The OSPF/ISIS SPT computation has always worked with cumulative link (and prefix) metrics. If the computation for the Generic Metric of this new type b/w is not going to be cumulative (I thought it is – but not very clear anymore), then the document needs to describe the computation algorithm. Is it then hop count based? Perhaps I am missing something very basic here and if so, please point me to the text in the draft.

Thanks,
Ketan

Sent: 13 May 2021 02:39

Thanks,
Chris and Acee

---

From: Tony Li <[email-masked]>
Date: Mon, 24 May 2021 11:44:57 -0700

Hi Ketan,

> In general, I support the adoption of this document. There is, however, one specific point which is not clear to me (8) below that I would appreciate some clarity on before adoption.

As the chairs have noted, adoption is binary and not contingent upon rough consensus on the content, just on rough consensus on the interest.

> Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, I do see MAX METRIC being referred to as 4,261,412,864.

Because I’m a lazy sod.

It’s far easier to detect metric overflow on three byte values than four byte values. True, four byte is not impossible, but it’s just quick and easy with three byte values.  Adding a fourth byte would add range to the metric space, but in practice, this seemed like it was not really relevant. Most areas are not a very high diameter and the need for detailed metric distinctions has not been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and that seems to work.

> Would be good to cover the max-metric considerations for the Generic Metric. Similar to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3>

Fair

> Since the draft is covering FlexAlgo, I would have expected that Generic Metric is carried only in the ASLA and this document specifies usage only for the FA application. Later this can be also used/extended for other applications but still within ASLA. Keeping an option of advertising both outside and within the ASLA is problematic – we will need precedence rules and such. I prefer we avoid this complication.

We preferred avoiding ASLA.

> For the newly proposed FAD b/w constraints, I would suggest the following names for the constraint sub-TLVs where the b/w value signalled by all is compared with the Max Link B/w attribute. This is just to make the meaning, at least IMHO, more clear.
> Exclude Higher Bandwidth Links
> Exclude Lower Bandwidth Links
> Include-Only Higher Bandwidth Links
> Include-Only Lower Bandwidth Links
> Similar naming for the FAD delay constraints as well would help. Though I can only think of the use of “exclude” for links above a certain delay threshold to be more practical but perhaps others might eventually be required as well?

Thank you for the suggestions.

> For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7 <https://datatracker.ietf.org/doc/html/rfc8920#section-7>, in case of ISIS also, it is not really appropriate for use within ASLA -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1 <https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1>?

I’m sorry, I don’t understand this comment.

> Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric.

Nor this one.

> The document introduces a new Generic Metric type called Bandwidth metric. I’ve been trying to follow some of the discussion related to this on the mailing list – about it being cumulative or not. I am perhaps somewhat confused by those discussions. The OSPF/ISIS SPT computation has always worked with cumulative link (and prefix) metrics. If the computation for the Generic Metric of this new type b/w is not going to be cumulative (I thought it is – but not very clear anymore), then the document needs to describe the computation algorithm. Is it then hop count based? Perhaps I am missing something very basic here and if so, please point me to the text in the draft.
> 

I’m sorry if this has been confusing. My understanding is that the metric is cumulative. Others had other expectations.

When there are multiple links with the same bandwidth, and thus the same metric, then the total path metric becomes (link metric) * (number of links).

Regards,
Tony

---

From: Peter Psenak <[email-masked]>
Date: Mon, 24 May 2021 20:58:12 +0200

Hi Tony,

On 24/05/2021 20:44, Tony Li wrote:
> 
> Hi Ketan,
> 
>> In general, I support the adoption of this document. There is, 
>> however, one specific point which is not clear to me (8) below that I 
>> would appreciate some clarity on before adoption.
> 
> 
> As the chairs have noted, adoption is binary and not contingent upon 
> rough consensus on the content, just on rough consensus on the interest.
> 
> 
> 
>>  1. Why is the Generic Metric type in ISIS limited to 3 byte size?
>>     OSPF allows 4 byte size and so why not the same for ISIS?
>>     Elsewhere in the document, I do see MAX METRIC being referred to
>>     as 4,261,412,864.
> 
> 
> Because I’m a lazy sod.
> 
> It’s far easier to detect metric overflow on three byte values than four 
> byte values. True, four byte is not impossible, but it’s just quick and 
> easy with three byte values.  Adding a fourth byte would add range to 
> the metric space, but in practice, this seemed like it was not really 
> relevant. Most areas are not a very high diameter and the need for 
> detailed metric distinctions has not been that high.  Thus, we went with 
> a 3 byte metric in RFC 5305 (sec 3.7) and that seems to work.
> 
>> 1.
>>  2. Would be good to cover the max-metric considerations for the
>>     Generic Metric. Similar
>>     tohttps://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3
> 
> 
> Fair
> 
> 
>> 2.
>>  3. Since the draft is covering FlexAlgo, I would have expected that
>>     Generic Metric is carried only in the ASLA and this document
>>     specifies usage only for the FA application. Later this can be
>>     also used/extended for other applications but still within ASLA.
>>     Keeping an option of advertising both outside and within the ASLA
>>     is problematic – we will need precedence rules and such. I prefer
>>     we avoid this complication.
> 
> 

we are not avoiding ASLA. We allow the ISIS Generic Metric sub-TLV to be 
sent inside or outside ASLA.

For flex-algo purposes we mandate it to be in ASLA. That's all what we 
need for the purpose of this draft. The rest is for future.

> 
> 
>> 3.
>>  4. For the newly proposed FAD b/w constraints, I would suggest the
>>     following names for the constraint sub-TLVs where the b/w value
>>     signalled by all is compared with the Max Link B/w attribute. This
>>     is just to make the meaning, at least IMHO, more clear.
>>      1. Exclude Higher Bandwidth Links
>>      2. Exclude Lower Bandwidth Links
>>      3. Include-Only Higher Bandwidth Links
>>      4. Include-Only Lower Bandwidth Links
>>  5. Similar naming for the FAD delay constraints as well would help.
>>     Though I can only think of the use of “exclude” for links above a
>>     certain delay threshold to be more practical but perhaps others
>>     might eventually be required as well?
> 
> 
>> 5.
>>  6. For the Max B/w Link attribute and its comparison with the FAD b/w
>>     constraints, I see the reference to ASLA. While in OSPF
>>     max-bandwidth is not allowed in ASLA
>>     -https://datatracker.ietf.org/doc/html/rfc8920#section-7, in case
>>     of ISIS also, it is not really appropriate for use within ASLA
>>     -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1?
> 
> 
>> 6.
>> 7.
>>  8. The document introduces a new Generic Metric type called Bandwidth
>>     metric. I’ve been trying to follow some of the discussion related
>>     to this on the mailing list – about it being cumulative or not. I
>>     am perhaps somewhat confused by those discussions. The OSPF/ISIS
>>     SPT computation has always worked with cumulative link (and
>>     prefix) metrics. If the computation for the Generic Metric of this
>>     new type b/w is not going to be cumulative (I thought it is – but
>>     not very clear anymore), then the document needs to describe the
>>     computation algorithm. Is it then hop count based? Perhaps I am
>>     missing something very basic here and if so, please point me to
>>     the text in the draft.
>>
>>
> 
> I’m sorry if this has been confusing. My understanding is that the 
> metric is cumulative. Others had other expectations.

my expectation is to be cumulative as well.

thanks,
Peter

> 
> When there are multiple links with the same bandwidth, and thus the same 
> metric, then the total path metric becomes (link metric) * (number of 
> links).
> 
> Regards,
> Tony
>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 25 May 2021 10:00:53 +0800

Hi, Tony:

7.      The document introduces a new Generic Metric type called Bandwidth metric. I’ve been trying to follow some of the discussion related to this on the mailing list – about it being cumulative or not. I am perhaps somewhat confused by those discussions. The OSPF/ISIS SPT computation has always worked with cumulative link (and prefix) metrics. If the computation for the Generic Metric of this new type b/w is not going to be cumulative (I thought it is – but not very clear anymore), then the document needs to describe the computation algorithm. Is it then hop count based? Perhaps I am missing something very basic here and if so, please point me to the text in the draft.

[WAJ] Such cumulative may be problematic in some situations and would need the manual intervention to “override” the automatic calculation “total path metric” to achieve the desired results. (please refer to the example in https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/

The difficulty is to how to find the unexpected paths in complex topology.

My suggestion is still not introduce such non-cumulative metric to cumulative based SPF calculation process.

Best Regards

Aijun Wang

China Telecom

 

Regards,

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 25 May 2021 09:30:44 -0700

Hi Aijun,

> My suggestion is still not introduce such non-cumulative metric to cumulative based SPF calculation process.

Again, what we’re proposing is cumulative.

Tony

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 26 May 2021 06:38:38 +0000

Hi Tony,

Please check inline below.

From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Ketan,

As the chairs have noted, adoption is binary and not contingent upon rough consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of the proposal to adopt and/or to split documents. I have seen this in recent past in other WGs. In any case, it is not a point that I wish to argue or debate on – especially in the context of this document. My point (8) was clarified and hence I fall in the binary YES in this instance.

Because I’m a lazy sod.

It’s far easier to detect metric overflow on three byte values than four byte values. True, four byte is not impossible, but it’s just quick and easy with three byte values.  Adding a fourth byte would add range to the metric space, but in practice, this seemed like it was not really relevant. Most areas are not a very high diameter and the need for detailed metric distinctions has not been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and that seems to work.
[KT] The Generic Metric is by definition something that will get extended in the future and we don’t know what use-cases might arise. It doesn’t seem right to follow in the steps of an administratively assigned metric type like the TE metric. Therefore, I suggest to make it variable.

[KT] Regarding metric overflow, I think it would be better to leave it to implementations on how to deal with it. A guidance similar to below (from draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does not cause interop issues. Theoretically, it is something that is independent of the size of the metric.

   During the route computation, it is possible for the Flex-Algorithm
   specific metric to exceed the maximum value that can be stored in an
   unsigned 32-bit variable.  In such scenarios, the value MUST be
   considered to be of value 4,294,967,295 during the computation and
   advertised as such.

  1.

Fair

  1.
  2.  Since the draft is covering FlexAlgo, I would have expected that Generic Metric is carried only in the ASLA and this document specifies usage only for the FA application. Later this can be also used/extended for other applications but still within ASLA. Keeping an option of advertising both outside and within the ASLA is problematic – we will need precedence rules and such. I prefer we avoid this complication.

We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA (quite correctly) for FlexAlgo application. Peter has confirmed the same. I am simply asking to avoid the complications of using Generic Metric in both ASLA and outside it. Whatever new “application” we invent to use this generic metric type, can use ASLA so that the Generic Metric can be very cleanly shared between applications. The encoding allows for using the same value – sharing single advertisement across applications or doing a different one per-application.

  1.
  2.  For the newly proposed FAD b/w constraints, I would suggest the following names for the constraint sub-TLVs where the b/w value signalled by all is compared with the Max Link B/w attribute. This is just to make the meaning, at least IMHO, more clear.

  1.  Similar naming for the FAD delay constraints as well would help. Though I can only think of the use of “exclude” for links above a certain delay threshold to be more practical but perhaps others might eventually be required as well?

  1.
  2.  For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7, in case of ISIS also, it is not really appropriate for use within ASLA -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1?

I’m sorry, I don’t understand this comment.
[KT] In https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1

The Maximum Link Bandwidth as advertised by the sub-sub-

   TLV 23 of ASLA [RFC 8920<https://datatracker.ietf.org/doc/html/rfc8920>] MUST be compared against the Minimum

   bandwidth advertised in FAEMB sub-TLV.

And in the https://datatracker.ietf.org/doc/html/rfc8920#section-7

Maximum link bandwidth is an application-independent attribute of the

   link that is defined in [RFC3630<https://datatracker.ietf.org/doc/html/rfc3630>].  Because it is an application-

   independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.

Somewhat similar for ISIS as well.

  1.
  2.  Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric.

Nor this one.
[KT] Generic Metric is used for the links. When we get to the computation of inter-area or external routes, we will need to get into FAPM. The draft at a minimum should discuss the applicability of the Generic Metric and its use as FAPM. Now, if we do make the Generic Metric size variable (as suggested above), then we will likely need a new TLV for a variable size FAPM equivalent?

  1.
  2.  The document introduces a new Generic Metric type called Bandwidth metric. I’ve been trying to follow some of the discussion related to this on the mailing list – about it being cumulative or not. I am perhaps somewhat confused by those discussions. The OSPF/ISIS SPT computation has always worked with cumulative link (and prefix) metrics. If the computation for the Generic Metric of this new type b/w is not going to be cumulative (I thought it is – but not very clear anymore), then the document needs to describe the computation algorithm. Is it then hop count based? Perhaps I am missing something very basic here and if so, please point me to the text in the draft.

I’m sorry if this has been confusing. My understanding is that the metric is cumulative. Others had other expectations.
[KT] Thanks for this important clarification.

Thanks,
Ketan

Regards,
Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 26 May 2021 15:11:23 +0800

Hi, Tony:

From: [email-masked] <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, May 26, 2021 12:31 AM
To: Aijun Wang <[email-masked]>
Cc: lsr <[email-masked]>; Ketan Jivan Talaulikar <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; [email-masked]
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Aijun,

[WAJ] My arguments is that your cumulative proposal (section 4.1.1.1 or 4.1.1.2) can get unexpected result, that is, if there is no manual intervention, the E2E sub-optimal path will be selected. You have also confirmed this in https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/, said as below:

“Override the metric on B-E-D to be even higher.

The point of the bandwidth metric (at least in this incarnation) is not to make hop count irrelevant. It is    to set the metrics relative to the bandwidth so that traffic skews towards higher bandwidths. Hops are still relevant. An operator can adjust the reference bandwidth and add manual metrics to achieve different effects, depending on their precise needs.”

The operator must investigate their topology carefully to add necessary manual metric to avoid the unexpected sub-optimal path.  Is it nightmare?

Best Regards

Aijun Wang

China Telecom

 

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 26 May 2021 09:40:07 -0700

Hi Ketan,

> [KT] The Generic Metric is by definition something that will get extended in the future and we don’t know what use-cases might arise. It doesn’t seem right to follow in the steps of an administrati…

Thank you for the suggestion. I don’t think anyone has suggested a variable length metric before.  A variable length metric is difficult to implement as if the length exceeds your processors word size, you need to resort to long integer software emulation packages. These are a huge performance penalty.

>    considered to be of value 4,294,967,295 during the computation and

In fact, we are not specifying how implementations deal with it.

> [KT] In https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1 <https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1>
>  
>    TLV 23 of ASLA [RFC 8920 <https://datatracker.ietf.org/doc/html/rfc8920>] MUST be compared against the Minimum
> And in the https://datatracker.ietf.org/doc/html/rfc8920#section-7 <https://datatracker.ietf.org/doc/html/rfc8920#section-7>
>  
>    link that is defined in [RFC3630 <https://datatracker.ietf.org/doc/html/rfc3630>].  Because it is an application-

I’m sorry, I’m still not understanding your comment. Are you objecting because we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested this, updating the other two protocols.

> [KT] Generic Metric is used for the links. When we get to the computation of inter-area or external routes, we will need to get into FAPM. The draft at a minimum should discuss the applicability of…

We would need a new TLV regardless of the metric size as the FAPM TLV only carries the default metric. We are not proposing that TLV at this time. That’s future work.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 26 May 2021 09:47:34 -0700

Hi Aijun,

> [WAJ] My arguments is that your cumulative proposal (section 4.1.1.1 or 4.1.1.2) can get unexpected result, that is, if there is no manual intervention, the E2E sub-optimal path will be selected. You have also confirmed this in https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/ <https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/>, said as below:
>  

I’m sorry, but I seem to be unable to help you reset your expectations. 

The bandwidth metric is NOT intended to find the absolute highest bandwidth path to the destination regardless of all other considerations. It is simply using link metrics based on bandwidth as a means of skewing paths towards higher bandwidths, but it is still cumulative so that a significantly longer path may still drive traffic away from a higher bandwidth.

If it is any consideration, you should be aware that most implementations already set their default link metrics based on interface bandwidth. This results in EXACTLY this same behavior, with administrators making manual adjustments if necessary.

Regards,
Tony

---

From: Peter Psenak <[email-masked]>
Date: Wed, 26 May 2021 18:57:22 +0200

Hi Tony, Ketan,

On 26/05/2021 18:40, Tony Li wrote:

>> */[KT] Generic Metric is used for the links. When we get to the 
>> computation of inter-area or external routes, we will need to get into 
>> FAPM. The draft at a minimum should discuss the applicability of the 
>> Generic Metric and its use as FAPM. Now, if we do make the Generic 
>> Metric size variable (as suggested above), then we will likely need a 
>> new TLV for a variable size FAPM equivalent?/*
> 
> 
> We would need a new TLV regardless of the metric size as the FAPM TLV 
> only carries the default metric. We are not proposing that TLV at this 
> time. That’s future work.

we only need the new TLV to carry FAPM if we make the Generic Metric's 
size variable. If we keep it fixed size, we should be fine with the 
existing FAPM.

thanks,
Peter

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 27 May 2021 12:36:41 +0000

>we only need the new TLV to carry FAPM if we make the Generic Metric's size variable. If we keep it fixed size, we >should be fine with the existing FAPM.

Yes agree. 
The idea of making generic metric variable length is worth considering.
I don't see a strong enough usecase right now to make it variable length but will wait
for inputs from WG.

Rgds
Shraddha 

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Wednesday, May 26, 2021 10:27 PM
To: Tony Li <[email-masked]>; Ketan Jivan Talaulikar <[email-masked]>
Cc: [email-masked]; [email-masked]; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Tony, Ketan,

On 26/05/2021 18:40, Tony Li wrote:

>> computation of inter-area or external routes, we will need to get 
>> into FAPM. The draft at a minimum should discuss the applicability of 
>> the Generic Metric and its use as FAPM. Now, if we do make the 
>> Generic Metric size variable (as suggested above), then we will 
>> likely need a new TLV for a variable size FAPM equivalent?/*
>
>

we only need the new TLV to carry FAPM if we make the Generic Metric's size variable. If we keep it fixed size, we should be fine with the existing FAPM.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 27 May 2021 14:49:51 +0200

> I don't see a strong enough usecase right now to make it variable length but will wait

nor do I.

thanks,
Peter

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 27 May 2021 13:01:08 +0000

Snipped..

5.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>, in case of ISIS also, it is not really appropriate for use within ASLA -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxHHnJfE7$>?

I'm sorry, I don't understand this comment.
[KT] In https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxAEMtKzf$>

   TLV 23 of ASLA [RFC 8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMntRW1t$>] MUST be compared against the Minimum

And in the https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>

   link that is defined in [RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMwurpJX$>].  Because it is an application-

I'm sorry, I'm still not understanding your comment. Are you objecting because we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested this, updating the other two protocols.

<shraddha> As per RFC 8920, Maximum Link Bandwidth cannot be advertised in ASLA. Will update the text to reflect Maximum Link Bandwidth sub-TLV in Extended Link TLV of Extended Link opaque LSA.

For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that different values for different applications is not allowed. Maximum Link bandwidth is also allowed with all bits set to zero in SABM/UDABM  or each individual application bit set for all applications making use of ASLA.

RFC 8919 sec 4.2.1
"  Maximum link bandwidth is an application-independent attribute of the
   link.  When advertised using the Application-Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised.
   This can be accomplished most efficiently by having a single
   advertisement for a given link where the Application Identifier Bit
   Mask identifies all the applications that are making use of the value
   for that link."

  1.  Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric.
<shraddha> As long as we have fixed length generic metric, there won't be any changes to FAPM. We'll add a section to clarify about FAPM

Juniper Business Use Only
From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, May 26, 2021 10:10 PM
To: Ketan Jivan Talaulikar <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Ketan,

Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte values. True, four byte is not impossible, but it's just quick and easy with three byte values.  Adding a fourth byte would add range to the metric space, but in practice, this seemed like it was not really relevant. Most areas are not a very high diameter and the need for detailed metric distinctions has not been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and that seems to work.
[KT] The Generic Metric is by definition something that will get extended in the future and we don't know what use-cases might arise. It doesn't seem right to follow in the steps of an administratively assigned metric type like the TE metric. Therefore, I suggest to make it variable.

Thank you for the suggestion. I don't think anyone has suggested a variable length metric before.  A variable length metric is difficult to implement as if the length exceeds your processors word size, you need to resort to long integer software emulation packages. These are a huge performance penalty.

  1.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>, in case of ISIS also, it is not really appropriate for use within ASLA -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxHHnJfE7$>?

I'm sorry, I don't understand this comment.
[KT] In https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxAEMtKzf$>

   TLV 23 of ASLA [RFC 8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMntRW1t$>] MUST be compared against the Minimum

And in the https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>

   link that is defined in [RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMwurpJX$>].  Because it is an application-

I'm sorry, I'm still not understanding your comment. Are you objecting because we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested this, updating the other two protocols.

  1.

Nor this one.

We would need a new TLV regardless of the metric size as the FAPM TLV only carries the default metric. We are not proposing that TLV at this time. That's future work.

Tony

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 27 May 2021 13:06:27 +0000

Snipped..

  1.  Since the draft is covering FlexAlgo, I would have expected that Generic Metric is carried only in the ASLA and this document specifies usage only for the FA application. Later this can be also used/extended for other applications but still within ASLA. Keeping an option of advertising both outside and within the ASLA is problematic - we will need precedence rules and such. I prefer we avoid this complication.

We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA (quite correctly) for FlexAlgo application. Peter has confirmed the same. I am simply asking to avoid the complications of using Generic Metric in both ASLA and outside it. Whatever new "application" we invent to use this generic metric type, can use ASLA so that the Generic Metric can be very cleanly shared between applications. The encoding allows for using the same value - sharing single advertisement across applications or doing a different one per-application.
<Shraddha> Generic metric is allowed in ASLA, it is also allowed in all traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of generic metric.

Juniper Business Use Only
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Tony,

From: Tony Li <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Ketan,

As the chairs have noted, adoption is binary and not contingent upon rough consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of the proposal to adopt and/or to split documents. I have seen this in recent past in other WGs. In any case, it is not a point that I wish to argue or debate on - especially in the context of this document. My point (8) was clarified and hence I fall in the binary YES in this instance.

Because I'm a lazy sod.

  1.
  2.  Would be good to cover the max-metric considerations for the Generic Metric. Similar to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15*section-15.3__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKigDlnfK$>

Fair

  1.
  2.  Since the draft is covering FlexAlgo, I would have expected that Generic Metric is carried only in the ASLA and this document specifies usage only for the FA application. Later this can be also used/extended for other applications but still within ASLA. Keeping an option of advertising both outside and within the ASLA is problematic - we will need precedence rules and such. I prefer we avoid this complication.

We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA (quite correctly) for FlexAlgo application. Peter has confirmed the same. I am simply asking to avoid the complications of using Generic Metric in both ASLA and outside it. Whatever new "application" we invent to use this generic metric type, can use ASLA so that the Generic Metric can be very cleanly shared between applications. The encoding allows for using the same value - sharing single advertisement across applications or doing a different one per-application.

  1.

  1.  Similar naming for the FAD delay constraints as well would help. Though I can only think of the use of "exclude" for links above a certain delay threshold to be more practical but perhaps others might eventually be required as well?

  1.
  2.  For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKlvO8Grj$>, in case of ISIS also, it is not really appropriate for use within ASLA -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKrdBaWXz$>?

I'm sorry, I don't understand this comment.
[KT] In https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKn7h1XsO$>

   TLV 23 of ASLA [RFC 8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKiuV4Gz8$>] MUST be compared against the Minimum

And in the https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKlvO8Grj$>

   link that is defined in [RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKgE3htSJ$>].  Because it is an application-

  1.

Nor this one.

  1.
  2.  The document introduces a new Generic Metric type called Bandwidth metric. I've been trying to follow some of the discussion related to this on the mailing list - about it being cumulative or not. I am perhaps somewhat confused by those discussions. The OSPF/ISIS SPT computation has always worked with cumulative link (and prefix) metrics. If the computation for the Generic Metric of this new type b/w is not going to be cumulative (I thought it is - but not very clear anymore), then the document needs to describe the computation algorithm. Is it then hop count based? Perhaps I am missing something very basic here and if so, please point me to the text in the draft.

I'm sorry if this has been confusing. My understanding is that the metric is cumulative. Others had other expectations.
[KT] Thanks for this important clarification.

Thanks,
Ketan

Regards,
Tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 May 2021 13:14:23 +0000

Authors,

There is a lot of interest in the document and sufficient support for WG adoption. Please republish as draft-ietf-lsr-flex-algo-bw-con-00.txt.

Of course, the current discussion of some of the finer points can continue.

Thanks,
Chris and Acee

From: Acee Lindem <[email-masked]>
Date: Wednesday, May 12, 2021 at 5:09 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Thanks,
Chris and Acee

---

From: <[email-masked]>
Date: Thu, 27 May 2021 13:22:27 +0000

Acee, Chris,

I’m not aware of non-disclosed IPR.

Thanks,
--Bruno

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Wednesday, May 12, 2021 11:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Thanks,
Chris and Acee

_________________________________________________________________________________________________________________________

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.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 27 May 2021 13:33:38 +0000

Perhaps, I should have been more careful with the word "variable". Initially, I meant allowing either 24 or 32 bits size (to me making it 32 just covers both the bases). But then the discussions on delay brought to my mind that perhaps even 64-bit metric might be useful. So the variable in my mind was either 32 or 64.

And I agree that there is no impact on FAPM if we picked the Generic Metric of 32-bit (or even kept it 24-bit). And yes, thanks Shraddha for agreeing to cover the applicability and aspects of FAPM in this document. Similar also applies for the OSPF FAAM, btw.

Thanks,
Ketan

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: 27 May 2021 18:20
To: Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; [email-masked]; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

nor do I.

thanks,
Peter

> Cc: [email-masked]; [email-masked]; Acee 
> Lindem (acee) <acee=[email-masked]>
>>> into FAPM. The draft at a minimum should discuss the applicability 
>>> of the Generic Metric and its use as FAPM. Now, if we do make the 
>> only carries the default metric. We are not proposing that TLV at 
>> this time. That’s future work.
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 27 May 2021 13:37:45 +0000

Hi Shraddha,

Please check inline below with KT2

From: Lsr <[email-masked]> On Behalf Of Shraddha Hegde
Sent: 27 May 2021 18:31
To: Tony Li <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; [email-masked]; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Snipped..

5.

[KT2] Thanks.

For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that different values for different applications is not allowed. Maximum Link bandwidth is also allowed with all bits set to zero in SABM/UDABM  or each individual application bit set for all applications making use of ASLA.
[KT2] Yes, you are correct. The RFC8919 does not mandate or require Max Link Bandwidth to be signaled within ASLA (at least that was my reading). If so, perhaps it is better to not require that in this document - just keep in the base. Would that not work? And if it were advertised in the ASLA (as RFC8919 allows it), then perhaps a reference to the RFC8919 will be important on how it is to be done - basically exactly what you described above.

Thanks,
Ketan

RFC 8919 sec 4.2.1

To: Ketan Jivan Talaulikar <[email-masked]<mailto:[email-masked]>>

Hi Ketan,

Because I'm a lazy sod.

  1.

  1.

Nor this one.

Tony

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 27 May 2021 13:43:04 +0000

Hi Shraddha,

This is a new attribute that we are introducing and we are saying that it has application specific semantics. We now have the ASLA mechanics defined in both OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA introduces ambiguity for which applications can use it - we get into complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde <[email-masked]>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) <[email-masked]>; Tony Li <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Snipped..

Juniper Business Use Only
From: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Tony,

Hi Ketan,

Because I'm a lazy sod.

  1.

Fair

  1.

  1.

  1.

  1.

Nor this one.

  1.

Thanks,
Ketan

Regards,
Tony

---

From: Peter Psenak <[email-masked]>
Date: Thu, 27 May 2021 15:50:36 +0200

Hi Ketan,

On 27/05/2021 15:37, Ketan Talaulikar (ketant) wrote:

> 
> For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that 
> different values for different applications is not allowed. Maximum Link 
> bandwidth is also allowed with all bits set to zero in SABM/UDABM  or 
> each individual application bit set for all applications making use of ASLA.
> 
> */[KT2] Yes, you are correct. The RFC8919 does not mandate or require 
> Max Link Bandwidth to be signaled within ASLA (at least that was my 
> reading). If so, perhaps it is better to not require that in this 
> document – just keep in the base. Would that not work? And if it were 
> advertised in the ASLA (as RFC8919 allows it), then perhaps a reference 
> to the RFC8919 will be important on how it is to be done – basically 
> exactly what you described above./*
> 

given that RFC8919 allows the Max Link Bandwidth to be signaled within 
ASLA, we need to be able to support it, in case someone uses that. What 
we would probably need to do is to look at the ASLA advertisement of Max 
Link Bandwidth first and if none is available fallback to legacy 
advertisement.

thanks,
Peter

---

From: William Britto A J <[email-masked]>
Date: Thu, 27 May 2021 15:08:30 +0000

Thanks,
William

From: Lsr <[email-masked]> on behalf of Acee Lindem (acee) <acee=[email-masked]>
Date: Thursday, 13 May 2021 at 2:51 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]

Thanks,
Chris and Acee

---

From: Rajesh M <[email-masked]>
Date: Thu, 27 May 2021 16:38:46 +0000

I am not aware of any IPR that applies to this draft.

Thanks,
Rajesh

Thanks,
Chris and Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 May 2021 17:02:09 +0000

Thanks – I now have all the declarations.
Acee

From: Rajesh M <[email-masked]>
Date: Thursday, May 27, 2021 at 12:39 PM
To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Thanks,
Rajesh

Thanks,
Chris and Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 31 May 2021 03:42:53 +0000

Ketan,

Networks that deploy a single TE application and already advertising and using attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific cases that are ambiguous.

Rgds
Shraddha

Juniper Business Use Only
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Shraddha,

Thanks,
Ketan

From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Snipped..

Hi Tony,

Hi Ketan,

Because I'm a lazy sod.

  1.

Fair

  1.

  1.

  1.

  1.

Nor this one.

  1.

Thanks,
Ketan

Regards,
Tony

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 31 May 2021 07:44:09 +0000

Hi Shraddha,

When you refer to "a single TE application", it is not clear which one you are referring to : RSVP-TE or SR Policy?

I believe, for ISIS, you are referring to this specific section of RFC8919 : https://datatracker.ietf.org/doc/html/rfc8919#section-6.1

There is no ambiguity here. This section is about use of "legacy" advertisement. The Generic Metric is a new TLV and hence cannot be considered as "legacy" by any interpretation of the word.

Coming to OSPF, the considerations are similar. Additionally we also have to deal with different LSA types here.

Please refer to https://datatracker.ietf.org/doc/html/rfc8920#section-12.1 for the equivalent discussion for OSPF. This section is about "legacy" advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you were referring to was RSVP-TE, then there is also additional guidance provided here : https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4

Please clarify where RFC8920 describes advertisement of application-specific attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.

Thanks,
Ketan

Sent: 31 May 2021 09:13

Ketan,

Rgds
Shraddha

To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>

Hi Shraddha,

Thanks,
Ketan

Snipped..

Hi Tony,

Hi Ketan,

Because I'm a lazy sod.

  1.

Fair

  1.

  1.

  1.

  1.

Nor this one.

  1.

Thanks,
Ketan

Regards,
Tony

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 31 May 2021 08:49:44 +0000

Hi Ketan,

Pls see inline..

Sent: Monday, May 31, 2021 1:14 PM

Hi Shraddha,

When you refer to "a single TE application", it is not clear which one you are referring to : RSVP-TE or SR Policy?
<Shraddha> It could be either of them

I believe, for ISIS, you are referring to this specific section of RFC8919 : https://datatracker.ietf.org/doc/html/rfc8919#section-6.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-6.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdZHekgKS$>

There is no ambiguity here. This section is about use of "legacy" advertisement. The Generic Metric is a new TLV and hence cannot be considered as "legacy" by any interpretation of the word.
<Shraddha> For ISIS, I hope you agree that generic metric sub-TLV is allowed to get advertised under TLV 22.

Please refer to https://datatracker.ietf.org/doc/html/rfc8920#section-12.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_Adc5YCVr4$> for the equivalent discussion for OSPF. This section is about "legacy" advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you were referring to was RSVP-TE, then there is also additional guidance provided here : https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.2.4__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdRkvFDI2$>

Please clarify where RFC8920 describes advertisement of application-specific attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.
<Shraddha> From what I understand, you agree that the generic metric sub-TLV should be allowed in TE Opaque LSA.
You have concerns only on it being allowed in Extended Link opaque LSA top level Extended Link TLV right?

Thanks,
Ketan

Ketan,

Rgds
Shraddha

Hi Shraddha,

Thanks,
Ketan

Snipped..

Hi Tony,

Hi Ketan,

Because I'm a lazy sod.

  1.

Fair

  1.

  1.

  1.

  1.

Nor this one.

  1.

Thanks,
Ketan

Regards,
Tony

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 31 May 2021 10:43:53 +0000

Hi Shraddha,

My point is that Generic Metric is not a legacy advertisement and it is application specific. Therefore, the place to advertise it is within the ASLA Sub-TLV - this applies to both ISIS and OSPF.

The references in RFC8919 and RFC8920 are about legacy advertisements and do not apply in this discussion.

Thanks,
Ketan

Sent: 31 May 2021 14:20

Hi Ketan,

Pls see inline..

Hi Shraddha,

Thanks,
Ketan

Ketan,

Rgds
Shraddha

Hi Shraddha,

Thanks,
Ketan

Snipped..

Hi Tony,

Hi Ketan,

Because I'm a lazy sod.

  1.

Fair

  1.

  1.

  1.

  1.

Nor this one.

  1.

Thanks,
Ketan

Regards,
Tony