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> >>> *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 > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
