Hi, Robert: Aijun Wang China Telecom
> On Nov 20, 2020, at 16:10, 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 ? [WAJ] If ABR can do PUA summary, it is certainly better. Or else, send the “PUA+Summary” for failure prefixes or send the “detailed reachable information-summary“ for connected prefixes, depend which one is less. Do you have other proposals? > Isn't it better to design your area such that ABRs are interconnected with > redundancy ? [WAJ] Such requirement is certainly reasonable, but it still can’t avoid the extreme situation. > > 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)" >>> <[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. >>> >>> >>> >>> >>> >>> -- >>> >>> <> >>> >>> Gyan Mishra >>> Network Solutions Architect >>> M 301 502-1347 >>> 13101 Columbia Pike >>> Silver Spring, MD >>> >>> >> -- >> >> >> Gyan Mishra >> Network Solutions Architect >> M 301 502-1347 >> 13101 Columbia Pike >> Silver Spring, MD >>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
