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]> 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 <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 >> <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
