Luay, If you/NOC is involved such a situation is solved by the third option: end to end TE of your choice.
Regards, R. On Sun, Apr 2, 2023 at 9:03 PM Jalil, Luay <luay.jalil= [email protected]> wrote: > 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]> 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]> 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://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 >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
