Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

["UTTARO, JAMES" <[e-mail]>]

Comments In-Line..

Thanks,
	Jim Uttaro

-----Original Message-----
From: Idr <[e-mail]> On Behalf Of Claudio Jeker
Sent: Thursday, August 4, 2022 3:14 AM
To: Robert Raszuk <[e-mail]>
Cc: heasley <[e-mail]>; idr@ietf. org <[e-mail]>; Job Snijders <job=[e-mail]>
Subject: Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

On Thu, Aug 04, 2022 at 12:08:02AM +0200, Robert Raszuk wrote:
> I am clearly stating there is no bgp messages other then keepalives.
> 
> So yr 10240 bytes / 19 octets msg = 539 messages.
> 
> Those for eBGP send every 20 sec will take: 3 hours.
> 
> The same for iBGP send every 60 sec will take: 9 hours.

These numbers are way better than the current status quo where sessions were in such a zombie state for weeks (if not months).
Often the situation goes unnoticed until enough routing errors collected to affect enough traffic to have admins investigate and even then finding the bad session is not trivial.
 
> - - -
> 
> Side question - Say I am RS peer and I advertised my net which got 
> propagated fine to other IX members and my IX fabric connectivity is 
> working fine. Do I really want to automatically cut out my site from 
> reachability only if RS went wild ?

If a RS goes wild, hopefully that IX did their work and deployed 2 different RS. So yes, I want the connection to the bad RS to be cut, that's how admins notice that something is broken.
 
> Yes I want to be aware about the problem and carefully plan the fix 
> not just to be cut from dataplane reachability. Same for IBGP control 
> plane only RRs etc ...

Again, I hope you have more than just one RR in your network. Because you will get cuts anyway because of this massive single point of failure.

[Jim U>] There have been multiple dual failures of route reflectors that have resulted very large outages. When both of the RRs servicing some subset of PEs are compromised it has been due to an event such as a bad actor PE spewing BGP message that RRs in a given cluster cannot handle, malformed update  etc.... In these cases adding tertiary etc. RRs will not address will not help. As there is no issue in the forwarding plane for these FOUs ( NH Viability ) compromising thousands of customers by tearing down the their VPNs is not acceptable

Having software try to limp along for way to long is a bad design choice.
It often causes bigger failures down the road because the whole network gets into an unexpected catastrophic state that nobody knows how to handle.


> On Wed, Aug 3, 2022 at 11:48 PM heasley <[e-mail]> wrote:
> 
> > Wed, Aug 03, 2022 at 11:42:53AM +0200, Robert Raszuk:
> > > If this is just queued keepalives (no BGP churn) then depending on 
> > > the buffer size it may take ages to fill ...
> >
> > Again, it can be filled with any bgp messages.  2.5 full (or <1 king 
> > size) bgp messages fill the default cisco iosxr send-buffer of 10240 
> > bytes (xr4.0 docs; range 4k - 128k).
> >

> _______________________________________________
> Idr mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr_
> _;!!BhdT!jB7E7i5XcjmsCYttfeCW2Xv3On3F9AlU_cZleMTvMLCvlY3zTvF9COGDJwzNp
> 86jKwXepHBYxGrwR1wb$


--
:wq Claudio

_______________________________________________
Idr mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!jB7E7i5XcjmsCYttfeCW2Xv3On3F9AlU_cZleMTvMLCvlY3zTvF9COGDJwzNp86jKwXepHBYxGrwR1wb$