On 26/01/2022 10:40, Robert Raszuk wrote:
> 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.
yes, but how much data? Minimal. It's not an issue, no matter how many
times you keep repeating it.
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.
above is not the case. For single home services, pulse will not result
in any action.
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).
above applies to regular BGP PIC used without summarization. There's
nothing specific to Pulse.
I feel this discussion has reached a point where we keep repeating what
has been said already several times. No point continuing, unless some
new data are on the table.
Peter
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 <mailto: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 <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
