Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

[Peter Psenak <[e-mail]>]

Robert,

On 21/03/2024 17:52, Robert Raszuk wrote:
> Hi,
>
> > When Flex-Algorithm calculation processes the link A to B, it may 
> look at
> > the 'colors' of the link in the reverse direction, e.g., link B to 
> A. This would
> > allow the operator to exclude such link from the Flex-Algorithm 
> topology.
>
> Why do we need the notion of "reverse direction" to be any different then
> the notion of forward direction from node B to A on a link ?

For a link A->B, we typically use attributes in the direction A->B. 
.e.g. link delay, link affinities, etc.

The reason why we want to be able to use reverse affinities is that for 
some cases, it is only B that knows about certain properties that 
relates to traffic A->B. For example only B can detect that there is a 
high rate of errors on that link for incoming traffic.

>
> Can't we just use the reverse metrics locally by computing node 
> without flooding
> anything new ?

no, because we want to use the metric in the forwarding direction, but 
be able to exclude link if the errors are detected on the other side of 
the link in the incoming direction.


>
> > An operator may measure the rate of such input errors and set 
> certain 'color' on a link
> > locally on node B when the input error rate crosses a certain threshold.
>
> IMO the draft should go into more detail or at least provide a pointer 
> to another document with description how to protect from continued 
> churn in propagating those colors when oscillate and go below and 
> above a set threshold many times per second.

the draft defines the mechanism how to advertise and use the reverse 
affinities. When to set it and how frequently, is not something that 
this draft specifies. Not that I disagree with you, but the same applies 
to any link attribute that is used during any calculation, being it TE 
or flex-algo. It's not specific to reverse affinities at all.


>
> Then aside from reducing the propagation frequency local protection 
> from continued SPF runs should also be mentioned. I guess you assume 
> that this is in place anyway.

absolutely.


>
> > The IS-IS Flexible Algorithm Exclude Reverse Admin Group (FAERAG)
>
> I think "FAERAG" is very hard to say. How about just "ERAG" as an 
> acronym ?

whatever you like :)

thanks,
Peter

>
> Thx,
> R.
>
>
> On Mon, Mar 18, 2024 at 9:12 AM <[e-mail]> wrote:
>
>     Internet-Draft
>     draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt is now
>     available. It is a work item of the Link State Routing (LSR) WG of
>     the IETF.
>
>        Title:   IGP Flexible Algorithms Reverse Affinity Constraint
>        Authors: Peter Psenak
>                 Jakub Horn
>                 Amit Dhamija
>        Name: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
>        Pages:   9
>        Dates:   2024-03-18
>
>     Abstract:
>
>        An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
>        constraint-based paths.
>
>        This document extends IGP Flex-Algorithm with additional
>     constraints.
>
>     The IETF datatracker status page for this Internet-Draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-flex-algo-reverse-affinity/
>
>     There is also an HTMLized version available at:
>     https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-flex-algo-reverse-affinity-02
>
>     A diff from the previous version is available at:
>     https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-flex-algo-reverse-affinity-02
>
>     Internet-Drafts are also available by rsync at:
>     rsync.ietf.org::internet-drafts
>
>
>     _______________________________________________
>     Lsr mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/lsr
>