Hi Russ, please see inline. From: Russ White [mailto:[email protected]] Sent: Tuesday, February 03, 2015 12:27 PM To: John E Drake Cc: Ravi Shekhar; Rabadan, Jorge (Jorge); [email protected] Subject: Re: [bess] EVPN Draft Comments
I'm on an iPad, so forgive the top post, but this is what I dug up from an email I sent a year+ ago, with some edits added, about aliasing as I understand it. It was never answered, afaict. == Let's say you have PE A, B, and C attached to a single ES. The first problem is -- under what conditions would a host, say X, send a packet to A and not to the others? This must be some sort of segment where no broadcasts are transmitted, somX discovers A through manual configuration or some such. This is a vanishingly small corner case, so I'm not certain this is worth dealing with in the main draft. <Ravi> The grat-ARP or first flow from X will only go out on one of the LAG links – i.e. to PE A/B or C. This is not a corner case. But let's assume it is… the process described in the draft is that A will "alias" itself to B and C, such that the hosts it knows about are reported to be attached to all three. But if A itself fails, the hosts it has learned will be withdrawn, leaving the aliased destinations stranded, and hence they will need to be withdrawn from the table until they send some ne packet and thus readvertised by either B or C, and then another aliasing arrangement set up. This is painful. What would seem to be better would be for something like a type 2 or DIS to be used. A, B, and C would all advertise connection to the ES, and then A would advertise a connection between the ES and each host it knows about, etc. As B receives this advertisement, it can inject this information into its local Mac table, so that if A fails the reachable destination point doesn't change, only the attachment point. <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. <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). <Ravi> Thanks. <Ravi> - Ravi Shekhar. How safe this all is depends on how much you trust the concept of an ES without broadcast capabilities, or rather that this device X will be able to receive unicast from A, B, and C, but B and C will never see a packet from X so long as A is available. == My thinking is that we're too late in the process to change this draft, but that a general revisiting of the aliasing idea in a potential separate draft might be worth the time and effort. :-) Russ
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
