Hi Igor, Thank you for sharing your draft. I am cc-ing IDR as you are proposing modifications to core BGP.
What you are proposing IMO will work fine and in fact I recall we had number of discussions on this in the past some of which resulted in definition of Edge_Discriminator Attribute as described in draft-pmohapat-idr-fast-conn-restore-03 However what you are proposing has serious scaling limits and impact to underlay if anyone would like to do this for lot's of VRFs. Let me observe that below quote is not correct: Neither IP VPN [RFC4364] nor IPv6 VPN [RFC4659] have a mass routes withdrawal mechanism. they do from day one. You can easily remove all routes in a given VRF by withdrawing the RD/64 prefix. Single BGP message. So in your case (Internet in a VRF) there is simple solution: Option I ) Put each CE into a separate VRF - when CE goes down - just withdraw the /64 RD. Option II) Alternatively you may ask your favourite vendor to allow multiple RDs in a VRF - one per each CE. Withdraw mechanism will be the same /64 per CE however no impact to the underlay .. still single next hop, single forwarding label etc ... In this option in the case both CEs advertise the same nets you would still advertise the single best path only out of this VRF. Keep in mind however that paths will be different from each CE so upon a CE failure while you can quickly remove the previously advertised routes you need to announce all of them again anyway with different CE paths. So the solutions is not much better then smart implementations and Option I. Lastly, why is your draft on the Standards Track ? It does not define any protocol extension so at best can be Informational. Many thx, Robert. On Tue, Aug 23, 2022 at 3:45 PM Igor Malyushkin <gmalyush...@gmail.com> wrote: > Hi all, > > Recently I posted a draft about a problem I've encountered as an ISP > engineer. It is related to IP VPN convergence and especially is applicable > to multihomed CEs. I think the solution can be useful for many types of IP > VPN deployments, but one of the main drivers for me was the Internet in the > VRF case. Lots of networks I know including the network I operate > distribute Internet prefixes by means of IP VPN instead of the GRT. The > document addresses one of the problems related to this approach but is not > confined to it. > > I kindly ask the WG for comments and suggestions. Also, as I'm absolutely > new to the IETF process I hope that I wasn't wrong with the WG, as I think > that IP VPN problems are related to BESS. > > > https://datatracker.ietf.org/doc/draft-malyushkin-bess-ip-vpn-abstract-next-hops/ > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
