Adrian I am wrapping up the Gen-ART review update.
The normative draft helped tremendously in understanding the problem and solution. Please add to the beginning of the introduction in your next update. https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-interconnect-05#section-9 I have a question related to the partitioning scenario. Comments in-line On Sun, May 16, 2021 at 7:25 AM Adrian Farrel <adr...@olddog.co.uk> wrote: > Hi John, > > > > Trying to dismantle this… > > > > We are saying that a site is integral. You are is asking : what happens if > a site becomes partitioned so that some prefixes are accessible through one > GW and some through another. > > > > Consider a site with a set of prefixes S > > Consider two GWs: GW1 and GW2 > > Initially GW1 and GW2 discover each other. > > So GW1 advertises reachability to S, and by the way GW2 exists > > GW2 advertises reachability to S, and by the way GW1 exists > Gyan> Ack > Now the site becomes partitioned so that GW1 can reach S1 and GW2 can > reach S2. (S = S1 U S2, S1 n S2 = E) > > Gyan> Ack > > You ask: > > 1. What happens to packets for S2 arriving at GW1? > 2. What is the remedy in the protocol? > > > > My answer to 1. is that the packets will be black-holed either at GW1 or > inside the site. > > My observation is that: > > 1. GW1 cannot reach GW2 inside the site. If it could, then S2 would be > reachable via GW1 > 2. It is contrary to BCP38 for GW1 to forward a packet back into the > external AS to be routed to GW2 > > Gyan> How would “b” be possible as loop avoidance would drop the packet > sent from GW1 external to loop back in GW2 being part of the same AS would > drop the packets so they would not be able to re-discover each other via > external. > > My answer to 2. is that when the site becomes partitioned: > > - GW1 will stop advertising the whole of S and will fall back to > advertising just S1 > - GW2 will stop advertising the whole of S and will fall back to > advertising just S2 > - Initially, GW1 and GW2 will still advertise each other’s existence, > but will “soon” un-auto-discover each other > > > - > > At this point the site is effectively two sites that use the same site > identifier. > > Gyan> Ack > > How quickly this takes place depends on precisely what the failure case > is, how fast the failure detection is done, and how fast BGP converges. > > Gyan> Ack > **Perhaps** there is a wrinkle **if** the autodetection advertisements are > sent external to the site. In this case, GW1 would continue to discover GW2 > and so would readvertise it (and vice versa). > Gyan> As I stated above “b” would not be possible so the continuing rediscovery would not occur and GW1 and GW2 would as you stated effectively act as two sites. This would continue to lead to the broken condition you noted. > Gyan> As stated due to as-path loop avoidance the broken condition would not occur. I think we assumed that the peering between GW1 and GW2 would be internal > to the site (because otherwise it would constitute traffic leaving the site > and re-entering it (breaking BCP38 again). If it would help, we could make > this point clear by saying that the peering between GW1 and GW2 must be > within the site. > Gyan>I agree we should add explicit verbiage that iBGP per BCP38 to prevent site partitioning as well as required for both GW1 and GW2 to be part of the same AS and be able to provide failover and back each other Up in case of a failure. Gyan> I believe John mentioned this slightly different scenario but it got lost in the thread and I tried to answer early on but I would like to get your take on the behavior. As this is critical component to complete my Gen-Art review. So if GW2 connection to external was down but GW1 still has its connection to external. GW2 would auto discover GW1 over iBGP and GW2 would advertise both GW1 and GW2 as reachable gateways. However GW2 has its external peer down. So if GW1 continues to advertised GW2 as we stated GW1 will auto discover GW2 over iBGP. So now for any sites trying to reach the Data Center AS that GW1 and GW2 are part of using GW2 to get to S1 and S2 would be black hole. How do we remedy this situation. > > Cheers, > > Adrian > > > > *From:* John Scudder <j...@juniper.net> > *Sent:* 14 May 2021 22:25 > *To:* Adrian Farrel <adr...@olddog.co.uk> > *Cc:* The IESG <i...@ietf.org>; > draft-ietf-bess-datacenter-gate...@ietf.org; bess-cha...@ietf.org; > bess@ietf.org; Matthew Bocci <matthew.bo...@nokia.com> > *Subject:* Re: John Scudder's Discuss on > draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT) > > > > 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*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
