> <Ravi> Using a route from another PE (A here) to inject a route by other PEs > (B/C) has its pitfalls. For instance withdrawals are going to be tough. Say A > has died for good, and X goes away – what mechanism will invalidate this > route from B? If it is local-aging at B, then B might as well use > local-learning to > advertise the route in the first place.
This is pitfall in every conceivable scheme, in fact, when you have transmit capability to a device you can't see at the other end of the link to know it's actual status. If the CE and PE both fail at the same time when you're assuming connectivity you can't prove, you're always going to run into this problem -- including your aliasing scheme. > <Ravi> In most practical situations, X would rehash its flow to B/C if A has > died. And B/C will learn the MAC of X (if they already hadn’t due to other > flows), and will publish the route again (if they already hadn’t). So let's work through the process -- - A fails - The advertisements A was sending are, after peer down, removed from the table - X continues sending traffic until it either the session resets or (hopefully) the interface down on A propagates towards X in some way -- but there's no way of actually knowing what this looks like, as we don't have any idea what's actually between A and X - Eventually, X begins refactoring it's hash, and starts sending towards B - B learns the new attached host, and readvertises it There is a lot of "ifs, ands, and buts," in here to cover, and a lot of time. Either both A and B can reach the same set of hosts, or they cannot. If they can, then the link should be treated as a broadcast, which means it's reachable from every upstream on the LAG connected to it. I would still prefer a solution that doesn't play this sort of "I can reach all the same things he can," game -- the DR type of system is much cleaner, and much more robust to modifications and future enhancements than aliasing will be. Of course, the real solution is -- don't use LAGs when you're doing layer 3 control plane mechanisms in the first place, but you must get out of the layer 2 only mindset to see that LAGs are causing you nothing but trouble all around in a proactive control plane with high density link counts. :-) Russ _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
