Thanks Robert! I will work on spelling out the scenario in updated LSR presentation.
Thanks Gyan On Tue, Nov 17, 2020 at 5:31 PM Robert Raszuk <rob...@raszuk.net> wrote: > > 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 <hayabusa...@gmail.com> 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 <hayabusa...@gmail.com> >> 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) <a...@cisco.com> >>> 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 <lsr-boun...@ietf.org> on behalf of Gyan Mishra < >>>> hayabusa...@gmail.com> >>>> *Date: *Tuesday, November 17, 2020 at 4:02 AM >>>> *To: *Robert Raszuk <rob...@raszuk.net> >>>> *Cc: *lsr <lsr@ietf.org>, Jeff Tantsura <jefftant.i...@gmail.com>, >>>> Aijun Wang <wangai...@tsinghua.org.cn>, "Acee Lindem (acee)" <acee= >>>> 40cisco....@dmarc.ietf.org> >>>> *Subject: *Re: [Lsr] Prefix Unreachable Announcement Use Cases >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk <rob...@raszuk.net> >>>> 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> >>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%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> >>>> >>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%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 >>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> >>> *Silver >>> Spring, MD >>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%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 >> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver >> Spring, MD >> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
