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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
