Hi Acee- While this document is well-written and provides an excellent discussion of the subject, I know that variations of the mechanisms have been proposed many times in the past and either haven’t been implemented or haven’t caught on. Can vendors comment if they’ve implemented and deployed such TTE mechanisms? Since the nodes act autonomously, it seems these could be offered without standardization and only deployed in situations where they will not result in downstream congestion and oscillations.
<cb> As Tony stated in his previous email, we have an implementation of what is described in the draft. As a side note, there have been other variations of what is described that are also implemented and deployed. --cb From: Acee Lindem <[email protected]> Date: Friday, March 31, 2023 at 10:50 AM To: Robert Raszuk <[email protected]> Cc: Colby Barth <[email protected]>, Tony Li <[email protected]>, RTGWG <[email protected]> Subject: Re: TTE [External Email. Be cautious of content] On Mar 30, 2023, at 23:59, 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. While this document is well-written and provides an excellent discussion of the subject, I know that variations of the mechanisms have been proposed many times in the past and either haven’t been implemented or haven’t caught on. Can vendors comment if they’ve implemented and deployed such TTE mechanisms? Since the nodes act autonomously, it seems these could be offered without standardization and only deployed in situations where they will not result in downstream congestion and oscillations. Thanks, Acee 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 Juniper Business Use Only
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
