> 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. So talking about IGP convergence for TCP session to be established is completely irrelevant, #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 #2 - Before PUA/PULSE code kicks in local area must *fully* converge first. #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. Many thx, R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
