Hi Robert,
On 25/11/2021 20:21, Robert Raszuk wrote:
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.
lot of assumptions about the implementation and deployment. Also for
default table I assume RD does not help.
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.
again, if you use option 2. There are way too many networks without it.
In summary, we need something that works independent of the BGP design
and also works outside of BGP.
thanks,
Peter
Thx a lot,
Robert
On Thu, Nov 25, 2021 at 6:45 PM Peter Psenak <[email protected]
<mailto:[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
