Tony,
I am unsure of the problem you are solving with this draft.. In the
introduction "Unforseen and/or dynamic events, can skew..." Certainly
unforeseen events are not accounted for in the estimate based on historical
demands, what is meant by "dynamic changes" ? and how does it differ from
"unforeseen" ?
The draft goes into addressing predictable patterns of network utilization
using the example of "follow the sun". This is predictable and should be
captured and be part of the historical pattern.. This may be captured and
addressed in a set of changes that 'migrate" traffic to under utilized links.
Of course, this may impact latency or some other metric that is used in SLAs.
How does the solution deal with placing flows on a "backup path" which then may
become congested creating a "ping pong " effect within a sub-graph of the
topology?
There is no discussion in re the longevity of a given set of flows as input to
the "flow selection", an example you use " a singer my announce...", I would
think this would result in many small flows congesting the link which are most
likely short lived.. This is opposed to long lived elephant flows used in the
middle of the night for machine-2-machin type applications.
Thanks,
Jim Uttaro
-----Original Message-----
From: rtgwg <[email protected]> On Behalf Of Tony Li
Sent: Sunday, April 2, 2023 2:20 AM
To: Gyan Mishra <[email protected]>
Cc: Robert Raszuk <[email protected]>; RTGWG <[email protected]>;
[email protected]
Subject: Re: TTE
Hi Gyan,
> The draft is very well written and has a lot of very good discussion points
> that are critical to TE network design.
Thank you. Glad you like it.
> The TTE concept uses all existing mechanisms but the goal is to provide a
> better automated optimization solution to congestion management. Is that
> correct?
The point is to put another tool in the toolbox. One that operates at a faster
time scale rather than global optimization. Because stuff happens.
> Is the intent to make the TTE algorithm for real time congestion control be
> made a constraint that can be pushed via PCEP or Netconf/Yang?
We hadn’t envisioned having configurable algorithms, but that’s not impossible.
> If so then maybe would be good to include in the draft.
Thank you for the suggestion.
> One big difference between RSVP-TE and SR-TE is that in general RSVP-TE has
> been used for bandwidth management and so deployment full mesh via one hop
> tunnels auto tunneling everywhere to manage and control bandwidth usage and
> backup paths complexity where SR-TE was designed for simplicity and thus does
> not have the same bandwidth management capabilities as you have with RSVP-TE
> but also now is not required and now TE can be more tactically deployed where
> it’s necessary and not deployed everywhere. Maybe some of those TE technical
> differences between RSVP-TE and SR-TE should be mentioned.
>
> That way it’s not one bucket solution for TTE.
I’m not quite sure I follow you. The whole point of TE is to manage bandwidth.
It is an essential service in any large scale network. [Aside: it has taken me
30 years to understand, but IGP ‘routing’ as we know it is largely irrelevant.
It gives us topology discovery, but what truly matters then is path computation
and global optimization. The SPF path is an irrelevant special case.]
The point of TTE is not to act as a substitute for global optimization and path
computation. Those are mandatory at scale. The issue is that the timescale for
that, in some networks, is very long and throwing more computational bandwidth
at the problem, while doable, may not be optimal. TTE provides a simple
alternative that may be helpful in the short term.
I am not interested in feeding a war between RSVP-TE and SR-TE. Neither is
perfect. Neither is the right answer. And no, SRv6 isn’t either. TTE can
operate with either RSVP or SR, or any other architecture that we can come up
with that gives us tractable backup paths.
Regards,
Tony
_______________________________________________
rtgwg mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/rtgwg__;!!BhdT!iuLt5taOag0iwgC4BKyyEjSfb6SfAouRnmGOcMu-HGIMAfTPz6wp8W0E94M0JfRI7eYeyteo4pM$
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
