Hi Tony In-line
On Sun, Apr 2, 2023 at 2:19 AM Tony Li <[email protected]> wrote: > > 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. > Gyan> Welcome. This seems like a application or controller based solution that could be vendor specific and protocol independent or agnostic so then why the need for standardization. I can see maybe if new protocol extensions were being created but if this is a bandwidth management that an operator would purchase I don’t see a need to standardize. As this draft is informational and not standards track is the goal to socialize this subject to get community feedback on developing this tool? > > > > 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. > > Gyan> Understood. I think the points made regarding flow selection of > long lived elephant flows and short lived mice flows is a careful > consideration to take into account. RSVP-TE path optimization is set on a > per node basis and can be automated path optimization or can be left > disabled using manual or automated revertive optimization during > maintenance windows. Is this possible with TTE? Also does the TTE bandwidth management have to be done holistically across all nodes or can the network graph be subdivided so not to impact the entire network or exclude critical links, nodes or paths within the network. > > > 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. Gyan> I was just mentioning the differences between SR being stateless and RSVP being stateful the design and deployment strategies are vastly different and thus the use case for this TTE tool would vary dramatically as to how it would be applicable. > > > Regards, > Tony > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
