Hi Robert, Well, I’m sorry you don’t like this proposal.
> 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 This is correct. As we mentioned, any change of path for any reason can result in a change in RTT and trigger slow start. It’s not wonderful, but it’s better than packet loss due to link congestion. > - Bypass paths maybe already saturated with traffic causing even further > traffic oscillations This is true, but then that implies that the network is not prepared to handle link failure of the protected link. If the network is under-engineered to begin with, this feature will not magically improve things. Capacity is a zero-sum game and this feature assumes that there is adequate capacity. > - 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 If having traffic on a bypass path violates required actions, then I would strongly recommend not using bypass paths, whether or not TTE is in use. As stated, TTE is meant to be used in conjunction with classical TE operating on a much longer time scale. If classical TE corrects the overload situation (which itself will require path changes and impact end-to-end protocols), then TTE will deactivate prefixes and labels and return traffic to the primary path. None of this begins to approach “complete network meltdown” and to claim that is wholly unjustified. > 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. Some people actually like delivering their best effort traffic. Section 3.1 describes code that I have personally written and is operational (but not quite shipping). Tony _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
