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
