[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Christian Hopps]

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

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

Thanks,
Acee and Chris.

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

[Lsr] The LSR WG has placed draft-peng-lsr-algorithm-related-adjacency-sid in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The LSR WG has placed draft-peng-lsr-algorithm-related-adjacency-sid in state
Call For Adoption By WG Issued (entered by Christian Hopps)

The document is available at
https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/


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

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

[Peter Psenak]

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


Tony



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

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

[Tony Li]

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.
>  
> [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 isto 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?
>  


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


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

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

[Tony Li]

Hi Ketan,

> 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.
> [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.


> [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.


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


> 
> 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 ] 
> 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 
> ].  Because it is an 
> application-
>independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.
>  
> Somewhat similar for ISIS as well.


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.


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


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

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

[Lsr] I-D Action: draft-ietf-lsr-flex-algo-16.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : IGP Flexible Algorithm
Authors : Peter Psenak
  Shraddha Hegde
  Clarence Filsfils
  Ketan Talaulikar
  Arkadiy Gulko
Filename: draft-ietf-lsr-flex-algo-16.txt
Pages   : 45
Date: 2021-05-26

Abstract:
   IGP protocols traditionally compute best paths over the network based
   on the IGP metric assigned to the links.  Many network deployments
   use RSVP-TE based or Segment Routing based Traffic Engineering to
   steer traffic over a path that is computed using different metrics or
   constraints than the shortest IGP path.  This document proposes a
   solution that allows IGPs themselves to compute constraint-based
   paths over the network.  This document also specifies a way of using
   Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
   along the constraint-based paths.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-16


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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

[Aijun Wang]

Hi, Tony:

 

From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Wednesday, May 26, 2021 12:31 AM
To: Aijun Wang 
Cc: lsr ; Ketan Jivan Talaulikar ; Acee Lindem 
(acee) ; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
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,

 

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

 

Again, what we’re proposing is cumulative.

 

[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 isto 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

 

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