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://www.ietf.org/mailman/listinfo/rtgwg
