Hi, Robert: Aijun Wang China Telecom
> On Nov 27, 2021, at 00:47, Robert Raszuk <rob...@raszuk.net> wrote: > > > Peter, > > As I told you many times I do see a need to signal summary member liveness. > Otherwise I would not be spending time here. [WAJ] Welcome to join us. > > But what I am trying to discuss is the proposed mechanism of such signalling > and possible alternatives. [WAJ] As Peter and I state several times, we want to find the generic solution for different scenarios. BGP exist or not. > > I suggested to you to do selective leaking. I do not recall seeing any answer > from you on that. Les acked you did not. Maybe you want to first discuss > internally which is fine. [WAJ] For BGP scenarios, there maybe only subset of nodes interested in such messages. But for other scenarios, such as SRv6 policy based TE, the node within the IGP all interested such messages. Flooding them within the IGP is the efficient way. Selective leaking requires the additional configuration which we want to avoid from the beginning. > > So back to the topic. > > How about you just leak those PEs which went down with a flag "DOWN" and when > it comes up you clear that flag. That way the IGP carries the liveness in > exactly the same way as today via leaking everything. > > However you at least is going to be leaking subset not everything. And this > is not going to be ephemeral but permanent. Maybe when PE is back stable > after 12h or any other long timer you stop leaking. [WAJ] Theoretically, the “DOWN” information should only be sent once to trigger the control plane action. For reliability, they can be sent several times(operator can configure), doesn’t need last until the node is backup again. > > See it is very hard to support a proposal when you - someone who wrote a > prototype for it - can not answer basic question on how will it work with > just encapsulation. Yet you use p2p tunnel as example on how this is useful. > Sure tunnel will go down and will not come up till remote PE is back in > business. > But with just encap (say mGRE) this is no longer possible as the interface > there is p2mp so it can not go down if even one remote PE is still up. [WAJ] P2MP tunnel should take different action. Only the failure endpoint will not be used. > > Thx, > R. > > > > >> On Fri, Nov 26, 2021 at 5:36 PM Peter Psenak <ppse...@cisco.com> wrote: >> Robert, >> >> On 26/11/2021 17:18, Robert Raszuk wrote: >> > Peter, >> > >> > Technically I see no justification to run any service within your own >> > domian over IPSec. >> >> tell people that are doing so, not me. >> >> > >> > 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. >> >> it's tunneling and there can be L3 or L2 client traffic being sent over >> these tunnels. Having a fast tunnel end-pointy down notification >> (without the need to run multi-hop BFD) helps the overlay network >> convergence. Same as with BGP. >> >> Just accept the fact that other overlay protocols exists out there and >> are actively being used. If you are not willing to accept tt, no point >> discussing further. >> >> thanks, >> Peter >> >> >> > >> > 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 >> > <mailto: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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
