Hi Robert, Thanks a lot for your review! Please, see my inline.
ср, 24 авг. 2022 г. в 10:49, Robert Raszuk <rob...@raszuk.net>: > 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 > [IM] Honestly, nothing prevents us to reproduce the described solution with manual export policies and some vendor scripting system on a box (if it is available), but I just wanted to see a more standard approach. Talking about of Edge_Disriminator. I concur that it is much better to have a control plane solution instead of multiplying the state in the underlay (I'm also not happy about it). But it requires support on ingress PEs only which is a trade-off. Sad, that this solution wasn't implemented widely! > > 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. > [IM] Agree. I understood it well before I started drafting. My goal was as less as possible touch to VPN and other mechanics. BGP NH tracking allows us to implement changes (update boxes) only for MH PEs. > > 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. > [IM] Well, actually I totally missed this mechanic. It sounds really good and I'm surprised that it isn't widely used (at least I haven't encountered it). A careful reading of 4365/4659 didn't show me anything about it, from my understating, RD`s task is just to distinguish routes and nothing more. Maybe it is described anywhere else? > > 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. > [IM] This is obviously not the way, especially for brownfields. > > 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. > [IM] This is more interesting. And I believe the described problem with a couple of CEs can be addressed by Add-Paths for VPNs. > Lastly, why is your draft on the Standards Track ? It does not define any > protocol extension so at best can be Informational. > [IM] The reason is simple, I thought that any changes that a document can introduce to a running code cannot be described in Informational documents. I will fix it, thanks! > 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
