Robert In your BGP PUA/PULSE options where BGP detects the Down PE, how would that event be sent back to IGP to trigger it to converge on alternate path.
As this is an event notification of a Down PE would you use the same next hop tracking BGP callback to IGP for the event notification or maybe some other mechanism? On Sun, Nov 28, 2021 at 6:56 PM Robert Raszuk <[email protected]> wrote: > > So the IGP would provide reachability between the PE and RR loopbacks and >> so the IGP would have to be converged for BGP TCP session to establish. >> >> Am I missing something? >> > > Yes. Entire concept of PUA/PULSE is about detecting transition to "DOWN" > state of the PE. > Gyan> ok > > So talking about IGP convergence for TCP session to be established is > completely irrelevant, > Gyan> So here we are talking specifically about the down event propagation via BGP. Understood. As we delve into convergence and BFD that’s where all my questions noted come up in the thread. I think my convergence related comments on iBGP is still a valid. > > > #2 Both PUA/PULSE are triggered at ABR by local area IGP complete >>> convergence. The very same local IGP convergence will complete faster to >>> RRs in the area when RRs are part of the IGP. That can be a trigger if you >>> are allergic to run BFD over IBGP >>> >> >> Gyan> PUA and Pulse use flooding mechanisms which is instantaneous to >> propagate the down event to then other areas for the protected instant >> convergence. The RR flood of PUA / Pulse event would be hierarchical >> framework so would reflected upstream over multiple hops. As the IGP has >> its local protection optimizations as well as BFD single hop detection of >> next hop failure the convergence would be instantaneous. >> > > Whow ! > > #1 - Nothing is instantaneous > This solution uses IGP flooding mechanics for the event flooding which is fast > > #2 - Before PUA/PULSE code kicks in local area must *fully* converge > first. > Gyan> The event would be flooded domain wide as i would be of interest to any routers in the other area so does not require the local area to be converged first as this is event notification being propagated and not a routing update. Gyan> The sequence of events is first the detection of node down in the origin area, followed by flooding of the event domain wide and lastly convergence of the egress PE based on the event notification. This would be very fast in milliseconds. We are not flooding the entire LSDB it’s just the PE down event being flooded so very fast. > > #3 - Hierarchy is good for you. > > #4 - Withdraw propagation via RRs is very fast (max - miliseconds) > > #5 - Propagating single or few BGP withdrawal messages over two RRs is > much faster then flooding over 2 areas and N IGP nodes (which btw have zero > interest in this opaque to them information). > > > >> #3 As to BFD session scaling, that limit is important in respect to 100s >>> or 1000s EBGP sessions from such PE. Not when talking about adding two more >>> sessions to RRs. >>> >> >> Gyan> Scale would be on the RR now terminating many BFD sessions. >> > > That is not of any practical issue considering current support numbers > used for EBGP BFD as example. > Gyan> Understood > > Many thx, > R. > > -- <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
