Dear authors The draft is very well written and has a lot of very good discussion points that are critical to TE network design.
The TTE concept uses all existing mechanisms but the goal is to provide a better automated optimization solution to congestion management. Is that correct? 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? If so then maybe would be good to include in the draft. 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. Kind Regards Gyan On Fri, Mar 31, 2023 at 12:00 AM Robert Raszuk <[email protected]> wrote: > Hi, > > I would like to provide feedback on this informational draft. > > *Background: * > > When an operator is building a network a careful planning and > consideration is given to size links according to anywhere from 60%-80% of > expected traffic patterns/demands. > > So when congestion occurs it is usually reason of either: > > A) topology change (already single failure active in the network) > or > B) traffic demand (hopefully transiently) exceeded the expectations. > > *Observation: * > > If congestion is triggered by B) usually already path from ingress to > egress will expect congestion on egress interfaces. > > If this is A) then the number of nodes experiencing congestion of active > paths depends on the location of the failure in the topology. > > *Proposed action:* > > The proposal is suggesting that each node acting autonomously should > enable in a FRR fashion at PLRs a bypass of congested link. > > I think practically this can lead to complete network meltdown for number > of reasons: > > - End to end protocols will need to adjust to new transit times > > - Bypass paths maybe already saturated with traffic causing even further > traffic oscillations > > - It ruins operators intended end to end TE (if in place) which can > potentially result in skipping some of the expected actions to be done on > packets in certain nodes > > *Conclusion: * > > Do not do it. Possible risks exceed the potential gains. > > Kind regards, > Robert. > > PS. > > Section 3.1 is written purely theoretical. Practical networks use QoS and > there is usually a number of queues with different treatment applied to > various traffic packets. > > Take as an example congestion of the best effort queue does not mean > anything serious ... It is best effort after all. It can be safely dropped. > > > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > -- <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
