> The pulse solution does not suffer from the scale issues. It shifts that "suffering" to flood the entire domain with information which is not needed on P routers and selectively useful on the remote PEs.
Also fast signaling the fact that PE may have been disconnected from the network for a few seconds may be actually more harmful to the actual applications running behind it. For single homed sites this is disaster as after next hop invalidation you are stuck for the timeout (as discussed about 200 sec) before we connect again. For dual homed sites such switchover to a backup PE may result with switchover to a backup CE (where PE-CE signaling is dynamic) where lots of networks uses outbound NAT. While all cool from the perspective of the WAN side - the NAT pool switchover means that application TCP sessions are reset. What may mean real long service disruption for the customers apps (especially those running long lived sessions). The reason I mention this here is that whatever we do we should alway take end to end user application analysis into account. Thx, R. On Wed, Jan 26, 2022 at 10:20 AM Peter Psenak <ppsenak= 40cisco....@dmarc.ietf.org> wrote: > Tony, > > On 25/01/2022 17:11, Tony Li wrote: > > > > > > Peter, > > > >> we just moved the problem from IGPs to some "other" application. > > > > > > That was the entire point. Hopefully, you see that as a good thing. > > actually I don't. I want to solve the problem, not to move it to other > app running on the same nodes. > > > The pulse solution does not suffer from the scale issues. With the limit > of number of concurrent pulses on ABR it also address the catastrophic > failure scenario you were worried about. > > thanks, > Peter > > > > Tony > > > > _______________________________________________ > 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
