Robert Just want to chime in on the primary context of PUA/Pulse design is to provide protection of the underlay egress PE next hops host routes that are summarized to provide an egress PE protection mechanism similar to RFC 8679 but focused on IGP to track the component prefixes of the summary route as the protection mechanism.
So the use case for PUA/Pulse is honed in on being able to eliminate domain wide flooding and make summarization viable and still have FRR style fast protection of next hops so that the overlay service routes have minimal to none disruption. The problem with the summarization is the component prefixes need to be tracked to provide that feedback mechanism that the component is dead so the control plane can converge instantly just as it’s able to converge instantly with domain wide flooding of LPM routes which can take advantage of existing local protection mechanisms LFA/RLFA/TI-LFA. Kind Regards Gyan On Fri, Nov 26, 2021 at 9:07 AM Robert Raszuk <[email protected]> wrote: > Peter, > > >> again, if you use option 2. There are way too many networks without it. >> > > There is even more networks without PUA/PULSE today. Should that be a > factor ? > > >> In summary, we need something that works independent of the BGP design >> and also works outside of BGP. >> > > Really ? Is that the requirement that the solution provided MUST not use > BGP ? > > Please kindly describe a full practical deployment scenario where PULSE > helps when BGP is not used at all in the network for distributing service > reachability. > > OSPF and ISIS are *link state* protocols. You are asking to extend them > to carry *node state* now. Specifically just to carry the UP -> DOWN > transitions of a node state and moreover in an ephemeral fashion. > > Thx, > R, > _______________________________________________ > 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
