Russ, Comments inline.
Yours Irrespectively, John From: Russ White [mailto:[email protected]] Sent: Tuesday, February 03, 2015 3: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. [JD] The RFC contains multiple examples of why this might happen. 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. [JD] That’s not how it works. A, B, and C will advertise connectivity to the ES in question, A will advertise MAC address X , and B and C will advertise MPLS labels for the EVI in question. An ingress PE will build an forwarding entry for MAC address X, w/ next hops A, B, and C and a reference count of the number of PEs advertising X. If A loses connectivity to the ES in question or it fails, its MAC advertisement for X will be withdrawn . An ingress PE will decrement its reference count, see that it is zero, and remove the forwarding entry. I.e., MAC Advertisement routes cause a forwarding entry to be either created or its reference count to be incremented. MAC Advertisement route withdrawals cause a forwarding entry’s reference count to be decremented or cause a forwarding entry to be deleted. Per EVI Ethernet AD routes and their withdrawals cause next hops to be created or deleted. 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. 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
