Russ Comments inline. I think my original comment describes the state of play: "Just because you don't like/understand it doesn't necessarily mean it's wrong.".
Yours Irrespectively, John > -----Original Message----- > From: Russ White [mailto:[email protected]] > Sent: Wednesday, February 04, 2015 7:17 AM > To: Ravi Shekhar; John E Drake > Cc: 'Rabadan, Jorge (Jorge)'; [email protected] > Subject: RE: [bess] EVPN Draft Comments > > > > The approach of A/B/C independently generating route to X only based > > on local MAC learning works even if physical link failure detection is > > not an option. And in most practical cases, X will have enough active > > flows that it will cause local learning on A/B/C to hopefully happen > > well before a failure of connection to A happens. In the event that > > this is not the case, current scheme takes care of it via ESI route. > > Then -- again, aliasing is covering a corner case, and I'm not certain of the > value of this mechanism in the main draft. [JD] Unsupported assertion > > > There are other problems with the approach that you have cited - for > > instance, if the advertisement of route to X from A triggered B and C > > to generate route to X as well, what happens if X goes away? Phy-layer > > will not help A/B/C in the detection of X going away. A will keep its > > advertisement intact (even after X has aged out locally) because it is > > seeing route to X from B/C => much like B/C created the route to X > > based on A's advertisement initially. Similarly B/C will keep their > > routes intact because A's route is lingering around. There will be a > > circular dependency created and route to X will never get withdrawn. > > Not to mention, that even if this can be fixed with extra state and > > extra bits in the advertisement from B/C (which may eventually make > > the scheme even complex), advertisement of a route based on another > > route and keeping track of this dependency in the same route table will > require a extra BGP machinery that does not exist today. > > Agreed -- Which is why this needs some brainstorming, rather than just > adding something into BGP that is fragile in the first place. [JD] Unsupported assertion > Another option might be -- > > - B sees A's advertisement with a MAC address it doesn't have in its local > table, or hasn't learned > - B initiates an ARP or some other packet towards this MAC address > - If connectivity exists, normal MAC learning and advertisement now takes > place [JD] This is a local node behavior option that is entirely consistent w/ aliasing as it is currently defined > > As you say -- > > > I would think that the closer a PE is to the source of information > > that causes it to generate a route - like local MAC learning for MAC > > route, or LAG link present for ESI route - the more accurate its > > information will be. The farther the PE is from the source of > > information - like a PE depending on another PE's route to generate > > its own MAC route - convergence will be slower and complexity will be > higher to keep track of dependent state. > > As aliasing suffers from the same criticism, [JD] Unsupported assertion > it would seem, to me, that some > other solution would be better overall, if we can find one. Hence my original > comment that this appears not to be an elegant solution (IMHO), as it's > assuming connectivity that may or may not exist, and needs more thought. [JD] Unsupported assertion > > :-) > > Russ _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
