Peter, Technically I see no justification to run any service within your own domian over IPSec.
In those cases simple IP encapsulation works fine. So let's zoom on this scenario ... Your PEs communicate over IP encapsulation which does not require any connection establishment. They start to exchange packets using summary routes. PE1 goes down and PULSE reaches remote PE2 - then what exactly is to happen there ? In RIB you still have valid summary route. You do not have in RIB /32 for remote PE1. PULSE comes and what ? If you run BGP it could trigger next hop invalidation and best path re-run. But there is no BGP as you say. Depending on how you implement encapsulation you could remove such encap rewrite from FIB, but for how long ? And what will tell you that the remote PE is up again ? All in all for PULSE to directly affect the data plane I think lot's of new code needs to be written, tested and deployed. Leave alone aspect of network wide flooding of those PULSEs. Many thx, R. On Fri, Nov 26, 2021 at 4:38 PM Peter Psenak <ppse...@cisco.com> wrote: > Robert, > > On 26/11/2021 15:06, Robert Raszuk 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 ? > > the solution should not depend on any particular deployment of the > overlay protocol. > > > > > 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 ? > > for me the solution ideally should work for with any overlay protocol. > > > > > 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. > > I have explained that several times to you. There are SP networks > running the services on top of p2p IP sec tunnels for example, with no BGP. > > > > > 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. > > no, I'm only talking about the prefix unrechability. Something that link > state protocols advertise happily today. > > thanks, > Peter > > > > > > Thx, > > R, > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
