Re: [bess] draft-malyushkin-bess-ip-vpn-abstract-next-hops for WG review
Hey Igor, > [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. > Some deployments have up to 5000 CEs hanging off the PEs. And those networks have 1000s PEs. We just can not propose a solution which would melt one's underlay. Sure you may just state oh well "use with caution" - my take we can do better. > 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? > Well it came as part of discussions we have had 18 years ago about aggregate withdraws: https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt I actually have built some images to test it in IOS :) But if you want to refocus your draft and use RD based aggregation for withdrawals I am all game to help. Within the last few months I have been approached with at least three cases for such functionality :) It does however touch on base BGP behaviour ... which is the ability to withdraw more specific routes by less specific prefix. So it has to be properly scoped to make it safe. Say only for SAFI 128. > 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. > Not sure about that. > 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. > See Add-paths for VPNs was never needed as good multihoming is done across different PEs (where RDs would be unique). On the other hand advertising multiple paths from a given VRF is not that wise as repair is local and we have no interest to spray all the paths everywhere ...note that what we care about is not control plane, but connectivity for customer packets (connectivity restoration). Best, Robert ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] draft-malyushkin-bess-ip-vpn-abstract-next-hops for WG review
Hi Robert, Thanks a lot for your review! Please, see my inline. ср, 24 авг. 2022 г. в 10:49, Robert Raszuk : > 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 > 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
Re: [bess] draft-malyushkin-bess-ip-vpn-abstract-next-hops for WG review
Hi Linda, Thanks for your comments! I'm glad to know that described problem is under discussion and is also addressed in your solution. I will follow the development of your draft and hope it will be implemented soon. The only thing that concerns me is that the solution described in this document requires full coverage among all installed gear. For some brownfields, it can be really problematic. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] I-D Action: draft-ietf-bess-evpn-fast-df-recovery-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : Fast Recovery for EVPN Designated Forwarder Election Authors : Patrice Brissette Ali Sajassi Luc Andre Burdet John Drake Jorge Rabadan Filename: draft-ietf-bess-evpn-fast-df-recovery-06.txt Pages : 12 Date: 2022-08-24 Abstract: The Ethernet Virtual Private Network (EVPN) solution provides Designated Forwarder election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying Highest Random Weight (HRW) Algorithm for Designated Forwarded election in order to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast Designated Forwarder (DF) election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. The solution is independent of the number of EVIs associated with that Ethernet Segment and it is performed via a simple signaling between the recovered PE and each of the other PEs in the multihoming group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-df-recovery-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-fast-df-recovery-06 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] draft-malyushkin-bess-ip-vpn-abstract-next-hops for WG review
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 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
