Robert Let me send it over graphical depiction as a picture is worth a thousand words should be easy to see the concept.
Trying to keep as simple as possible. Thanks Gyan On Fri, Nov 20, 2020 at 3:03 AM Robert Raszuk <[email protected]> wrote: > Gyan, > > I like and support your use case #1 > > For use case #2 I have doubts. Imagine indeed an area which get's > partitioned such that ABR will loose connectivity to bunch of nodes. Does > this mean that now such ABR will be blasting globally perhaps 1000s of PUAs > ? How would the ABR be able to send PUA summary provided some disconnected > POPs within area could be nicely summarized ? Isn't it better to design > your area such that ABRs are interconnected with redundancy ? > > Thx, > R. > > > > On Fri, Nov 20, 2020 at 3:28 AM Gyan Mishra <[email protected]> wrote: > >> >> Aijun >> >> I am thinking per the feedback received let’s keep it really simple. We >> need a solid use case to move the ball forward were the PUA data plane >> convergence capabilities can fills a gap that exists today. >> >> I have two simple solutions to start that I will update the presentation >> with to start and present to the WG and we can go from there. >> >> 1. BGP NH tracking via PUA of NH component prefix to converge the data >> plane >> >> 2. Area partitioned scenario where PUA is used for data plane >> convergence to ABR that has reachability to component prefixes. >> >> I will send out tomorrow. >> >> Thanks >> >> Gyan >> >> On Wed, Nov 18, 2020 at 9:37 PM Aijun Wang <[email protected]> >> wrote: >> >>> Hi, Acee: >>> >>> >>> >>> OK, we will try to improve this document to meet this criteria. >>> >>> And, as this topic has been discussed intensely on the mail list, we are >>> also eager to invite more interested experts to join us as co-authors to >>> refine the solutions for more scenarios. >>> >>> >>> >>> Thanks in advance. >>> >>> >>> >>> Best Regards >>> >>> >>> >>> Aijun Wang >>> >>> China Telecom >>> >>> >>> >>> >>> >>> *From:* Acee Lindem (acee) <[email protected]> >>> *Sent:* Thursday, November 19, 2020 12:42 AM >>> *To:* Aijun Wang <[email protected]>; 'Robert Raszuk' < >>> [email protected]>; 'Jeff Tantsura' <[email protected]> >>> *Cc:* 'Gyan Mishra' <[email protected]>; 'lsr' <[email protected]>; >>> 'Acee Lindem (acee)' <[email protected]> >>> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases >>> >>> >>> >>> Speaking as WG Co-Chair: >>> >>> >>> >>> *From: *Aijun Wang <[email protected]> >>> *Date: *Wednesday, November 18, 2020 at 3:05 AM >>> *To: *Robert Raszuk <[email protected]>, Jeff Tantsura < >>> [email protected]> >>> *Cc: *'Gyan Mishra' <[email protected]>, Acee Lindem <[email protected]>, >>> 'lsr' <[email protected]>, "'Acee Lindem (acee)'" < >>> [email protected]> >>> *Subject: *RE: [Lsr] Prefix Unreachable Announcement Use Cases >>> >>> >>> >>> Hi, Robert: >>> >>> >>> >>> The trigger and propagation of PUA info can be standardized, the actions >>> based on the PUA can be different in different situation. >>> >>> We can discuss and describe the actions based on different scenarios >>> after its WG adoption? >>> >>> >>> >>> There will be no adoption call until there is a coherent draft with use >>> case(s) and viable actions. >>> >>> >>> >>> Thanks, >>> >>> Acee >>> >>> >>> >>> >>> >>> Best Regards >>> >>> >>> >>> Aijun Wang >>> >>> China Telecom >>> >>> >>> >>> *From:* Robert Raszuk <[email protected]> >>> *Sent:* Wednesday, November 18, 2020 3:49 PM >>> *To:* Jeff Tantsura <[email protected]> >>> *Cc:* Gyan Mishra <[email protected]>; Acee Lindem (acee) < >>> [email protected]>; lsr <[email protected]>; Aijun Wang < >>> [email protected]>; Acee Lindem (acee) < >>> [email protected]> >>> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases >>> >>> >>> >>> Jeff, >>> >>> >>> >>> Please notice that WAN is not an IX. >>> >>> >>> >>> While you can have full mesh of BFD sessions among all IXP participants >>> each bombarding each over over TB fabric every 100 ms or so to map the same >>> over global WAN is a different game. If nothing else RTT between IXP >>> participants in healthy IX is around 1 ms while RTT between PEs distributed >>> globally is often 100-200 ms. >>> >>> >>> >>> Just imagine 1000 PEs in 10 areas distributed all over the world. That >>> means that in worst case scenario (say same mgmt VPN present on each PE) >>> you will establish 1000*999 BFD sessions. Now for this to make sense timer >>> needs to be 100 ms or so with 3x or 5x multiplier. Anything slower will >>> defeat the purpose as BGP withdraw will be faster. >>> >>> >>> >>> Then we go into queuing issues. If BFD packets are queued at any >>> interface meltdowns may occur which can be far worse in consequences then >>> waiting for BGP service route removal. Such meltdowns often result in >>> cascading effects to the applications itself. >>> >>> >>> >>> So this is not at all about autodiscovery with which address to >>> setup the BFD session. It is much more about operational aspects of going >>> that direction. >>> >>> >>> >>> With that I am supportive of this work even if we label it as >>> experimental for some time. As each network is different what is optimal >>> solution for one design and deployment may not be optimal for the other. >>> >>> >>> >>> Many thx, >>> >>> Robert >>> >>> >>> >>> >>> >>> On Wed, Nov 18, 2020 at 4:34 AM Jeff Tantsura <[email protected]> >>> wrote: >>> >>> We have been discussing for quite some time and in different wg's (there >>> ’s IX with RS use case) BFD verification based on next-hop extraction, >>> Robert - you should know. (also built a well working prototype in previous >>> life). >>> >>> Very simple logic: >>> >>> Upon route import (BGP update received and imported), extract next-hop, >>> walk BFD session table, if no match (no existing session) - establish >>> (S)BFD session (Discriminators distribution is a solved problem) to the >>> next-hop, associate fate of all routes received from it, keep timers >>> reasonable to prevent false positives. >>> >>> State is limited to PE’s importing each others routes (sharing a >>> service) only >>> High degree of automation >>> No IGP pollution >>> >>> >>> >>> Cheers, >>> >>> Jeff >>> >>> On Nov 17, 2020, 6:43 AM -0800, Acee Lindem (acee) <[email protected]>, >>> 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 <[email protected]> on behalf of Gyan Mishra < >>> [email protected]> >>> *Date:* Tuesday, November 17, 2020 at 4:02 AM >>> *To:* Robert Raszuk <[email protected]> >>> *Cc:* lsr <[email protected]>, Jeff Tantsura <[email protected]>, >>> Aijun Wang <[email protected]>, "Acee Lindem (acee)" <acee= >>> [email protected]> >>> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk <[email protected]> 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. >>> >>> >>> >>> >>> >>> -- >>> >>> <> <http://www.verizon.com/> >>> >>> *Gyan Mishra* >>> >>> *Network Solutions Architect * >>> >>> >>> >>> *M 301 502-134713101 Columbia Pike >>> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> >>> <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+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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
