Hi Gyan, thank you for the most detailed information. With the addition of the single-hop BFD the puzzle is complete. Or almost complete. What I am wondering, is the fact that a PE is likely to be a part of a mesh network that provides more resilient service. As a result, a single BFD session going down would not mean that the PE is disconnected from the network and generating an update seems sub-optimal. I've likely missed how such a scenario is handled in the drafts. Need to read more carefully.
Regards, Greg On Wed, Oct 13, 2021 at 5:38 PM Gyan Mishra <[email protected]> wrote: > > Hi Greg > > This draft would utilize the same IGP optimizations used today such as IGP > single hop BFD for core link failure detection tuning down to sub second. > Most modern routers LC’s are to process BFD control packet processing in > hardware. We are assuming all typical optimizations are in utilized for > close to hitless convergence such as LFA, RLFA, BGP PIC etc. > > Even with all the optimizations, we still need a method of tracking > component prefixes when summarization is employed in very large domains > carved up into many areas or levels. > > The goal of the PUA and Event Notification draft is to be able to track > the component prefixes of ASBR summary advertisement in the use case of BGP > next hop attribute set to self loopback0 on each PE. With the PUA mechanism > a negative advertisement PUA is flooded to force the control plane to > converge when the PE goes down and loopback0 component prefix. This same > mechanism of PUA component prefix tracking of a summary advertisement is > also done via the Event Notification draft IGP extension. > > So an alternative has been proposed to use loopback to loopback multi hop > BFD to track the iBGP peering directly as a mechanism of tracking the same > component prefixes of a summary advertisement if the individual iBGP PE-RR > peering went down. That would be more complicated and convoluted and maybe > not as scalable is the thought for large scale network with 1000s of PEs. > > > Kind Regards > > Gyan > > On Wed, Oct 13, 2021 at 12:07 AM Aijun Wang <[email protected]> > wrote: > >> Hi, Greg: >> >> >> >> The defect detection time should be same as the IGP flooding speed. It >> can achieve such goals via the PUA mechanism. >> >> Or else, we must depends on other mechanism, such as BFD, which requires >> configuration overhead, and the process pressure especially when the timer >> is decreased in multi-hop BFD mode. >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> *From:* [email protected] <[email protected]> *On Behalf Of *Greg >> Mirsky >> *Sent:* Wednesday, October 13, 2021 10:43 AM >> *To:* Aijun Wang <[email protected]> >> *Cc:* [email protected]; Robert Raszuk <[email protected]>; Acee Lindem >> (acee) <[email protected]> >> *Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and >> OSPF Extension for Event Notification" >> >> >> >> Hi Aijun, >> >> could you help me to understand the requirement for defect detection >> time for the method you propose? Single seconds? Tens of seconds? >> >> >> >> Regards, >> >> Greg >> >> >> >> On Tue, Oct 12, 2021, 18:27 Aijun Wang <[email protected]> wrote: >> >> Hi, Robert: >> >> >> >> Answers to your comments are inline below. >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> *From:* [email protected] <[email protected]> *On Behalf Of *Robert >> Raszuk >> *Sent:* Wednesday, October 13, 2021 3:52 AM >> *To:* Acee Lindem (acee) <[email protected]> >> *Cc:* [email protected] >> *Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and >> OSPF Extension for Event Notification" >> >> >> >> Hi Acee, >> >> >> >> I would like to make a comment on your point #1. >> >> >> >> You said: >> >> >> >> "Is this a problem that needs to be solved in the IGPs? The use case >> offered in both drafts is signaling unreachability of a BGP peer. Could >> this better solved with a different mechanism (e.g., BFD)..." >> >> >> >> That is not a very precise statement - simply due to the fact that to >> signal anything in any solution requires a peer to detect giben network >> event. >> >> >> >> In both cases such an event will likely be detected using BFD (if we are >> talking about unreachability of a BGP or IGP peer). >> >> *[WAJ] No. Link or Node Failures are not detected via BFD within one IGP >> domain. It just rely on the normal IGP flooding procedures. Once the ABRs >> receive the updated LSA, they will make the calculation and find the >> missing prefixes.* >> >> >> >> Neither of the drafts mentioned here replaces local BFD detection. >> >> *[WAJ] Deploy such mechanisms can replace the BFD for BGP configuration >> between PEs that located in different IGP domains.* >> >> >> >> I do infer from your message that what was meant to be said was an >> alternative to support BFD sessions across areas/levels for example between >> PEs. Clearly that would get very ugly very quickly. >> >> >> >> However IMO the natural signalling in this case would be to use BGP >> itself. Here are the few reasons: >> >> *[WAJ] How the BGP peer be detected that the peer has been unreachable? >> Via BFD for BGP?* >> >> >> >> * detection time will be the same for IGP or BGP >> >> *[WAJ] It is the ABR**’s summarization action hides the unreachable >> prefixes, then BGP peers located in different IGP domains can’t know the >> failure as quickly as IGP within the same domain.* >> >> >> >> * only those network elements which keep "interesting" state will be >> notified >> >> *[WAJ] To be more accurate, your above statement should be **【* only >> those network elements which keep "interesting" state will act upon the PUA >> messages.】* >> >> >> >> * speed of withdraw can be argued to be as fast as IGP flooding >> especially considering hierarchical IGP design >> >> *[WAJ] When we let ABR send the PUA messages, not hide them, the speed of >> withdraw can certainly be accelerated.* >> >> >> >> * withdraws can be easily aggregated (when we loose PE single prefix can >> be used to remove all paths advertised by given PE) >> >> *[WAJ] This is the effects PUA mechanism. when the BGP peer receives the >> PUA message that includes the PE itself, all the path advertised by the >> given PE can certainly be removed.* >> >> * withdraws can be injected as the next hop /32 or /128 prefixes and >> remote next hop validation can be set not to consider less specific routes >> to resolve next hops (in any case due to MPLS data plane host routes are >> used in many networks today to resolve BGP service routes to LSPs in spite >> of efforts to make this more scalable). >> >> *[WAJ]This the effect of PUA mechanism.* >> >> >> >> Only when we prove that BGP based solutions are not sufficient we >> could/should explore moving such signalling to IGPs. >> >> *[WAJ] Do the above responses prove the BGP based solution are not >> sufficient?* >> >> >> >> Kind regards, >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Oct 12, 2021 at 9:06 PM Acee Lindem (acee) <acee= >> [email protected]> wrote: >> >> Speaking as WG Chairs: >> >> >> >> The authors of “Prefix Unreachable Announcement” have requested an >> adoption. The crux of the draft is to signal unreachability of a prefix >> across OSPF or IS-IS areas when area summarization is employed and prefix >> is summarised. We also have “IS-IS and OSPF Extension for Event >> Notification” which can be used to address the same use case. The drafts >> take radically different approaches to the problem and the authors of both >> drafts do not wish to converge on the other draft’s method so it is >> understandable that merging the drafts really isn’t an option. >> >> >> >> Before an adoption call for either draft, I’d like to ask the WG: >> >> >> >> 1. Is this a problem that needs to be solved in the IGPs? The use case >> offered in both drafts is signaling unreachability of a BGP peer. Could >> this better solved with a different mechanism (e.g., BFD) rather than >> flooding this negative reachability information across the entire IGP >> domain? >> >> 2. Assuming we do want to take on negative advertisement in the IGP, >> what are the technical merits and/or detriments of the two approaches? >> >> >> >> We’ll reserve any further discussion to “WG member” comments on the two >> approaches. >> >> >> >> Thanks, >> Acee and Chris >> >> >> >> >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347* > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
