Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Przygienda <[e-mail]>]

the pesky operational issue of those computations to suddenly partition the
graph (if used with dynamic resource updates) or otherwise pile everything
on the same link that led to RFC5120 being built the way it is. It is one
thing to get from RSVP-TE a "no resources to get there" indication and
another for IGP to magically not be getting there anymore while in terms of
best-effort functionality the destination looks perky and happy. One could
argue that you just need a routing table to see whether it's there but the
nature of those algorithms is that people show up with "I want 100MB" and
the answer there is very different from another request for "I want 1GB".
In Fore systems we basically had bunch of pre-defined/configurable profiles
we were pre-computing the answers (obviously also for performance purposes)
and comibned with the Q.2931 doing roughly what RSVP-TE is doing  +
crankback to do low catches stuff was working pretty well. There is a
patent for that still somewhere AFAIR.

-- tony

On Mon, Mar 1, 2021 at 10:48 PM Jeff Tantsura <[e-mail]>
wrote:

> In ol’ good RSVP-TE days we already used “severity/relevance indicator” to
> decide whether changes in link  attributes (BW/etc) are significant enough
> and should be propagated in into TED and trigger re-optimization/rerouting,
> this is no different,  define your threshold for a trigger.
> Note - flex-also requires contiguous topology to work, self isolation as
> the result of (dynamic) topology re-computation would not be a great thing.
>
> Cheers,
> Jeff
> On Mar 1, 2021, 12:48 PM -0800, Tony Li <[e-mail]>, wrote:
>
>
> Robert,
>
> Constructing arbitrary topologies with bw constrain is useful work. For
> example I want to create a topology without links of the capacity less then
> 1 Gbps. All cool. Of course if I have a case where two nodes have 10 L3
> 1Gbps links nicely doing ECMP I will not include those which may be a
> problem.
>
>
>
> I agree that it may be a problem. Maybe it’s not the right tool for the
> job at hand. That doesn’t make it a bad tool, just the wrong one. I try not
> to turn screws with a hammer. And I try not to drive nails with a
> screwdriver.
>
> I will happily stipulate that we need more tools and that these are not
> enough. We should not reject a tool simply because it doesn’t solve all
> problems. Let’s work towards the right set of tools. Linear algebra tells
> us that we want an orthogonal set of basis vectors. What are they? Adding
> them one at a time is not horrible progress.
>
>
> However my observation is precisely related to your last sentence.
>
> Is this extension to be used with static or dynamic data ? If static all
> fine. But as William replied to me earlier link delay may be dynamically
> computed and may include queue wait time. That to me means something much
> different if Flex-Algo topologies will become dynamically adjustable. And I
> am not saying this is not great idea .. My interest here is just to
> understand the current scope.
>
>
>
> Link delay was dynamic before this draft. As William mentioned, TWAMP can
> already be used to provide a dynamic measurement of link delay. That,
> coupled with the link delay metric already gave us dynamic path computation
> requirements and the possibilities of oscillation and instability. We have
> chosen to charge ahead, without addressing those concerns already.
>
> Regards,
> Tony
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>