Robert,
On 21/03/2024 20:52, Robert Raszuk wrote:
Peter,
Ok I think what you are proposing is pretty granular and that is fine.
We may still disagree if link should be used at all if there are
errors on this link in *ANY* direction.
So my suggestion here is to have that support build in as
Peter,
Ok I think what you are proposing is pretty granular and that is fine. We
may still disagree if link should be used at all if there are errors on
this link in *ANY* direction.
So my suggestion here is to have that support build in as well in the nodes
computing the topology and not always
Hi Robert,
On 21/03/2024 18:26, Robert Raszuk wrote:
Hey Peter,
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.
Hey Peter,
> 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
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.
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
