Hi Peter, First BGP MP_UNREACH propagation via RRs is really fast.
Please observe that if your BGP implementation is smart you do not need to withdraw prefix by prefix in any application which uses VRFs. You can withdraw RD/64s only when you detect that the PE went down. Furthermore as you know with auto RD allocation RD format is usually BGP_ROUTER-ID:XXXX so to withdraw all service routes once the PE went down you could just send RD/32 single NLRI ! There is a lot of options. In respect to option 2 - you do not need to speed up service BGP withdraws at all. You are using indirection and you are withdrawing recursive next hop irrespective on how many service routes are present including Internet. So it is not "same as above" at all. I am really not sure what is so difficult in this scenario that folks just do not get it. Thx a lot, Robert On Thu, Nov 25, 2021 at 6:45 PM Peter Psenak <[email protected]> wrote: > Robert, > > On 25/11/2021 18:25, Robert Raszuk wrote: > > Dear LSR WG, > > > > I wanted to visualize the scenario we are so deeply discussing here. > > Specifically BGP vs IGP flooding as well as applicability of RFC8679. > > > > Below are three options comparing what it takes to distribute bad news > > in BGP vs IGP. Keep in mind that only PE2 on the illustration is > > interested in this bad news. > > > > All in respect to L3VPN Option C as example of the service. > > > > *Option 1* - Classic/ Today's design. If you simply enable BFD on IBGP > > between PE1 and RR I bet we would not even be discussing anything as > > things will just work well as is today. > > I don't understand how BFD between PE1 and RR is going to address the > problem in hand. If PE1 goes down, RR will have to withdraw all > individual BGP prefixes advertised by PE1. Could be global internet > routes, internet in VRF is not uncommon either. With BGP per prefix > withdrawal the convergence is slow by definition. We want BGP PIC like > behavior and that is not what you have described above. > > > > > image.png > > > > *Option 2 -* BGP recursion as discussed earlier to speed up NH down > > propagation vs service route withdraw. > > same as above. > > > > > > image.png > > > > Again very easy to accomplish today modulo your BGP implementation. RR1 > > to PE1 can be two BGP session - one with BFD one without to easily > > separate the sequence of BGP events. > > > > *Option 3* - BGP-LS from ABRs > > BGP can carry pulses, but as I mentioned several times there are SP > networks that do not run MPLS and use other tunneling mechanisms. They > would not appreciate BGP only solution. > > Having a solution in both IGP and BGP and let user decide which one he > wants to use seems a better approach to me. > > thanks, > Peter > > > image.png > > > > BGP-LS essentially is carrying those PUA/PULSES to those who need it. > > > > In all cases RFC8679 can still protect against PE1 failure at local PLR > > directing traffic to backup PE1' (not on the picture but we assume it is > > there otherwise it is all moot). > > > > And in fact local protection is the only one which can assure minimum > > service disruption time. > > > > For PUA/PULSE to get triggered by ABR all PE1 IGP neighbours must report > > PE1 to be out - hence we are already limited to the local area detection > > of PE1 down and local flooding. > > > > Now imagine someone will not like to use BFD+BGP. Well that means that > > IBGP will time out in 180 sec. That also means that whatever PUA/PULSE > > is there it MUST "last" min 200 sec on the remote PEs. > > > > (Also attaching pdf with the above illustration in case jpg-s are poor). > > > > Many thx, > > Robert > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
