Correction below.. (damn auto-completion…:-)
Thanks, Himanshu From: rtgwg <[email protected]> on behalf of Shah, Himanshu <[email protected]> Date: Sunday, April 2, 2023 at 5:22 PM To: Robert Raszuk <[email protected]>, Jalil, Luay <[email protected]> Cc: UTTARO, JAMES <[email protected]>, [email protected] <[email protected]>, RTGWG <[email protected]> Subject: Re: [**EXTERNAL**] Re: [E] RE: TTE Agree with Robert and Jim. I gave similar comments during the IETF meeting last Friday. Switching over to purpose built backup tunnel is better choice to handle “signal degrade”. PLR, who has no visibility of traffic condition after the first hop on the bypass to MP, is risky and may produce domino effect and/or oscillations. I believe the speaker indicated that, this was an implantation implementation choice and informational draft. Thanks, Himanshu From: rtgwg <[email protected]> on behalf of Robert Raszuk <[email protected]> Date: Sunday, April 2, 2023 at 3:27 PM To: Jalil, Luay <[email protected]> Cc: UTTARO, JAMES <[email protected]>, [email protected] <[email protected]>, RTGWG <[email protected]> Subject: [**EXTERNAL**] Re: [E] RE: TTE If your TE does not work as intended, enabling TTE to randomly shift some (who knows what) chunk of traffic (on who knows which nodes) between links seems to introduce even more randomness into your network. So tuple: TTE + PRAY - is not IMHO the right solution to the problem. Cheers, R. On Sun, Apr 2, 2023 at 9:19 PM Jalil, Luay <[email protected]<mailto:[email protected]>> wrote: Agree Robert in most cases. Sometimes the stars align in rare cases in very high scale TE domains, and after going through different knobs or NB controls or whatever your favorite TE model, things don't work as intended/architectured/designed 🙁 Luay On Sun, Apr 2, 2023 at 2:12 PM Robert Raszuk <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[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]<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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtgwg&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=geIDyJVzT9eaMBjqebkjFpsQRFgHCra0UDCSzII-gZFudgSMRxbQiTbI4e3UTBHz&s=6rh3zSyLbNueimVFjAJtv249qTpAiwSr2tK3HirATgs&e=>
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
