Luay,
I hear you.. Perfect should not be the enemy of the good..
Thanks,
Jim Uttaro
From: Jalil, Luay <[email protected]>
Sent: Sunday, April 2, 2023 3:02 PM
To: UTTARO, JAMES <[email protected]>
Cc: Tony Li <[email protected]>; RTGWG <[email protected]>; [email protected]
Subject: Re: [E] RE: TTE
Total agreement Jim
I actually looked at it from a different perspective; the lesser of the two
evils to start with. If it gets so bad that I'm down to 2 options: start
changing metrics OR turn this on. My naive answer based on the draft is I'll
turn this on. Changing metrics on the fly without modeling is dangerous š
Luay
On Sun, Apr 2, 2023 at 7:20āÆAM UTTARO, JAMES
<[email protected]<mailto:[email protected]>> wrote:
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]<mailto:[email protected]>> On Behalf
Of Tony Li
Sent: Sunday, April 2, 2023 2:20 AM
To: Gyan Mishra <[email protected]<mailto:[email protected]>>
Cc: Robert Raszuk <[email protected]<mailto:[email protected]>>; RTGWG
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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]<mailto:[email protected]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/rtgwg__;!!BhdT!iuLt5taOag0iwgC4BKyyEjSfb6SfAouRnmGOcMu-HGIMAfTPz6wp8W0E94M0JfRI7eYeyteo4pM$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rtgwg__;!!BhdT!iuLt5taOag0iwgC4BKyyEjSfb6SfAouRnmGOcMu-HGIMAfTPz6wp8W0E94M0JfRI7eYeyteo4pM$>
_______________________________________________
rtgwg mailing list
[email protected]<mailto:[email protected]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtgwg&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=B_9wb9CwhUQHm4loc8HVzbMNsiP-dM2-WY6KCSQRhbo4AtxIv1Y8GaU-2sVwA_7S&s=ySURqXmZ5wEIDtaIguIFTK-f1W-TZuC8wd4LIQP6VCU&e=
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
