Hi John I agree with your comments that the scenario I mentioned is covered in Section 3 and agree as well on the RFC 2119 keyword usage scrub.
In-line On Mon, May 17, 2021 at 3:55 PM John Scudder <[email protected]> wrote: > Hi Gyan, > > > On May 17, 2021, at 1:50 PM, Gyan Mishra <[email protected]> wrote: > > > > 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. > > Isn’t this scenario covered? From §3: > > If a gateway becomes disconnected from the backbone network, or if > the SR domain operator decides to terminate the gateway's activity, > it withdraws the advertisements described above. This means that > remote gateways at other sites will stop seeing advertisements from > this gateway. Gyan> Yes. Agreed. I wanted to draw some more attention to this to the authors on the withdrawal that it’s critical and agreed a MUST. > > > So when GW2’s external peering goes down, GW2 withdraws its auto discovery > route, and therefore GW1 re-advertises its routes externally without GW2 > listed in the tunnel attribute. > > I will say that reviewing the above-quoted text — which seems tailor-made > for a “MUST withdraw” — made me notice that the draft makes only sporadic > and desultory use of RFC2119 keywords. In fact there are so few used, that > it seems like it might be better to scrub those two SHOULD and two MUST out > and remove the 2119 citation. Gyan> Agreed. I will parse the draft for RFC 2119 keyword placement in my final GEN-ART review update > > > —John -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
