Hi Adrian I may have missed this in the draft but the solution for this failover scenario is if each GW can only advertise itself, which I think that is stated in section 3 then GW1 can only advertise itself via tunnel encapsulation attribute and not GW2 as GW2 can only advertise itself when it’s eBGP tie to the core comes Up. Problem solved.
Kind Regards Gyan On Fri, May 14, 2021 at 7:02 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > > Hi Adrian > > I believe what John is describing is a valid failure scenario where one of > the GWs is no longer a valid gateway because it’s eBGP peering to core > domain is down, however the routing underlay is stable between the GWs > within the DC site. We are assuming the GWs at the site run an IGP to > advertise next hop attribute and maybe also have next hop self configured > between then for iBGP. So the GW that had eBGP peer to core is able to > send the auto discovery loopback prefix tunnel sub TLV for both GWs. > That’s the problem. > > So that would cause the black hole of traffic between sites for the GW > that has its eBGP link to the core down. > > The other question asked was eve set of internal prefixes how are they > advertised and is that just over the native AFI SAFI iBGP peering between > the GWs. > > So GW1 that is up advertises via iBGP the set of internal prefixes learned > from the other domain. > > Kind Regards > > Gyan > > On Fri, May 14, 2021 at 5:25 PM John Scudder <jgs= > 40juniper....@dmarc.ietf.org> wrote: > >> Having re-read Section 3 carefully (and skimmed the rest) I still think >> what the document says (as opposed to what’s in the authors’ heads?) is the >> first description I give below. Let me know if you want me to walk through >> my reasoning in detail with reference to the document. >> >> —John >> >> On May 14, 2021, at 4:12 PM, John Scudder <j...@juniper.net> wrote: >> >> Hi Adrian, >> >> >> Thanks for your reply. Pressed for time at the moment but one partial >> response: >> >> On May 14, 2021, at 1:04 PM, Adrian Farrel <adr...@olddog.co.uk> wrote: >> >> Agree with you that "stuff happens." I think that what you have described >> is a window not a permanent situation. >> When GW2 knows it can't reach X any more, it will stop advertising X, and >> GW1 will receive that and will update what it advertises on behalf of GW2. >> >> >> Ah, perhaps I have badly misunderstood the way this works. I had thought >> it went something like this: >> >> - GW1 knows it can reach GW2 because of GW2’s auto discovery route >> - GW1 knows the set S of internal prefixes it can reach >> - GW1 advertises each prefix from S with both GW1 and GW2 in the tunnel >> attribute >> >> In the description above, there’s no notion of GW2 telling GW1 what >> internal prefixes GW2 can reach, or GW1 caring. Now I suppose you are >> telling me that it goes: >> >> - GW1 knows it can reach GW2 because of GW2’s auto discovery route >> - GW1 knows the full set of prefixes GW2 can reach. _How does it know >> this?_ >> - GW1 constructs each advertisement listing only the correct set of >> gateways in the tunnel attribute >> >> The key question is the one I’ve highlighted: how does GW1 come to know >> GW2’s internally-reachable prefixes? I didn’t notice any of this in the >> spec. Maybe it was just my sloppy reading, I’ll look again. >> >> Further, if GW1 can no longer receive advertisements from GW2 then it >> will stop advertising on behalf of GW2. >> >> >> Yes, that’s understood, but I was positing a case where just because GW1 >> can reach GW2 stably, and just because GW1 can reach X stably, it does not >> imply GW2 can reach X. >> >> —John >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
