On Tue, Nov 17, 2020 at 3:06 AM Robert Raszuk <rob...@raszuk.net> wrote:
>
> Moreover it seems that it will just also prevent any local protection to
>> locally bypass the failed destination.
>>
>> *[WAJ] No, It will trigger the local protection instead, not prevent.*
>>
>>
> You missed my point.
>
> I am talking about *local* protection in a sense of adjacent node(s) to
> the PE/ASBR which failed. *Local* to the failure.
>
> You are talking about *local* protection on ingress to the network. Let's
> focus on this:
>
> Q1 - You are installing a /dev/null route in a router. That means that any
> packet sent to this destination will be dropped. How is this of any
> protection ?
>
> Q2 - What you may be actually trying to say is that by installing such PUA
> into RIB you will via RIB let know those clients (ex: BGP) which track this
> route that it is gone and that their possibly best path is no longer valid.
> Sure that is one way to share such information between IGP and BGP. But
> this needs to be described in the document that this is your intention.
> Otherwise when you say you are installing a drop route in RIB & FIB I am
> not sure how helpful that is (well other then transiently relaxing the
> network to drop some traffic few router hops away).
>
Robert, I believe the original intention was related to having the data
plane converge quickly when summarization is used and flip so traffic
converges from the Active ABR to the Backup ABR.
However PUA can be used in the absence of area segmentation within a
single area when a link or node fails to converge the data plane quickly by
sending PUA for the backup path so the active path.
With the IGP tuned with BFD fast detection on ISIS or OSPF links and
LFA & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks
the convergence is well into sub second. So for Intra area convergence
with all the optimizations mentioned I am not sure how much faster the data
plane will converge with PUA.
The one use case I had mentioned to you in the past a while back is
related to BGP PIC core convergence which I mentioned during the
presentation as you brought up BGP next hop convergence as a use case on
the ML. So in cases where you run BGP PIC edge and have the pre programmed
backup path best-external add-paths advertised backup paths you are set,
however with BGP PIC core prefix independent convergence with the H-FIB
next hop rib convergence - with next-hop-self rewrite to the loopback, the
loopback never goes down so that does impact iBGP path PIC core
convergence. So a workaround is to not do next hop self and so when link
goes down its detected and that fixes the issue. Downside is you now have
a massive LFIB FEC binding database if you have tons of customer edges. So
I think PUA could help for this but I was trying to connect the dots and I
think there is something missing but maybe we can figure out how PUA can be
leveraged to fix the PIC Core convergence. I am assuming that is what you
meant on the ML with next hop tracking convergence would be the obvious use
case for PUA. So the tricky part here is you you can send a PUA when your
PE-CE link goes down and now your H-FIB IGP forwarding plane would now
converge immediately on the alternate PUA path, however you still have
next-hop-self rewrite happening to the loopback which is still Up. So even
though PUA fixed the Core IGP detection of the PE-CE link failure, it did
not fix the next hop self rewrite to the loopback which is always Up. I
guess there would be still an improvement with data plane convergence for
the PE-CE with the PUA being sent to converge the BGP next hop when "next
hop self" is not used. It would be nice if there was some way to make PUA
fix the next-hop-self rewrite to loopback to improve PIC core convergence.
You would need a flag to tie the loopback to the PE-CE connected interfaces
state to be tracked. I believe you wrote a draft way back that fixes that
issue but was never adopted I believe. I would have to dig up on ML to
find it.
>
> Thx,
> R.
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
