Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk <[e-mail]>]

Yes that is the case where I see some potential use case.

Especially considering also https://tools.ietf.org/html/rfc5283 - which by
many network operators is very desired, but not configured due to "slow BGP
convergence" - pls let's not go there :)

But again if someone knows how to configure BGP properly I think IGP
speedup would be marginal or even null hence a grain of hesitation if we
should use IGP flooding for it. Maybe in some scenarios ... which PUA
authors need to spell out to move fwd I suppose.

Cheers,
R.








On Tue, Nov 17, 2020 at 9:40 PM Gyan Mishra <[e-mail]> wrote:

>
> Robert
>
> I am recalling now the BGP use case you mentioned.
>
> If the next hop is being summarized between areas which it would be, the
> next hop failure component prefix is now hidden in the summary and now you
> have to wait for BGP timer to pop and route withdrawal.
>
> So for this failure scenario one option is multihop BFD but that does get
> way complicated.
>
> So here the obvious and best use case for PUA would be for the data plane
> detection of the next hop component down at which time PUA is sent flooded
> and the routers in the other area now set next hop to null for that next
> hop and are forced to converge on alternate next hop.
>
> Let me update the presentation to add this use case.
>
> Thanks
>
> Gyan
>
> On Tue, Nov 17, 2020 at 2:09 PM Gyan Mishra <[e-mail]> wrote:
>
>> Agreed.
>>
>> Robert
>>
>> Can you explain the BGP scenario you had in mind that you have mentioned
>> a number of times that you think this PUA feature would pertain?
>>
>> I will respond to your other email separately.  I was trying to guess  as
>> to the BGP next hop use case you were referring to but apparently was way
>> off.
>>
>> Thank you
>>
>> Gyan
>>
>> On Tue, Nov 17, 2020 at 9:43 AM Acee Lindem (acee) <[e-mail]>
>> wrote:
>>
>>> Speaking as WG member:
>>>
>>>
>>>
>>> I think it would be good to hone in on the BGP PE failure convergence
>>> use case as suggested by Robert. It seems there is some interest here
>>> although I’m not convinced the IGP is the right place to solve this problem.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Acee
>>>
>>>
>>>
>>> *From: *Lsr <[e-mail]> on behalf of Gyan Mishra <
>>> [e-mail]>
>>> *Date: *Tuesday, November 17, 2020 at 4:02 AM
>>> *To: *Robert Raszuk <[e-mail]>
>>> *Cc: *lsr <[e-mail]>, Jeff Tantsura <[e-mail]>,
>>> Aijun Wang <[e-mail]>, "Acee Lindem (acee)" <acee=
>>> [e-mail]>
>>> *Subject: *Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk <[e-mail]> wrote:
>>>
>>>
>>>
>>>
>>>
>>>    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.
>>>
>>>
>>>
>>> I do not buy this use case. Flooding within the area is fast such that
>>> both ABRs will get the same info. As mentioned before there is no practical
>>> use of PUA for making any routing or fwd decision on which ABR to use. If
>>> your ABRs are not connected with min redundancy this draft is a worst patch
>>> ever to work around such a design.
>>>
>>>
>>>
>>>    Gyan> Agreed.  The point of PUA in ABR use case is the ability to
>>> track the component prefixes and in case where component is down and
>>> traffic is still forwarded to the ABR and dropped.  The other more
>>> important use case is when links are down within the area and the area is
>>> partitioned and so one ABR has all component prefixes however other ABR is
>>> missing half the component prefixes.  So since the ABR will by default
>>> advertise the summary as long as their is one component UP the summary is
>>> still advertised.  So this use case is severely impacting as now you have
>>> an ECMP path to the other area for the summary via the two ABRs and you
>>> drop half your traffic.  So now with PUA the problem is fixed and the PUA
>>> is sent and now traffic is only sent to the ABR that has the component
>>> prefixes.
>>>
>>>
>>>
>>> Please present us a picture indicating before and after ABRs behaviour.
>>>
>>>
>>>
>>>      Gyan> will do
>>>
>>>
>>>
>>>    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.
>>>
>>>
>>>
>>> If there is no area segmentation then there is no summaries. So what are
>>> we missing in the first place ?
>>>
>>>
>>>
>>>     Gyan> Sorry I am stating that PUA feature can also be used intra
>>> area where if a link or node goes down to improve data plane convergence.
>>>
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> Even without any of the above listed chain of acronymous things will
>>> generally work well intra-area without PUAs.
>>>
>>>
>>>
>>>     Gyan> Agreed which is why I mentioned the BGP next hop self use case
>>> if I could figure out how PUA could help there that would be a major
>>> benefit of PUA.
>>>
>>>
>>>
>>> Thx,
>>> R.
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>>
>>>
>>> *M 301 502-1347 13101 Columbia Pike
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>> *Silver Spring, MD
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>
>>>
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>