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

[Job Snijders <[e-mail]>]

On Wed, Aug 03, 2022 at 03:11:33PM +0200, Robert Raszuk wrote:
> Ok Many thx for this clarification. I think it would be great to add it to
> the draft as far as send() returning an error.

The point is that send() does not return an error, it blocks. (A
blocking system call is one that must wait until the action can be
completed.)

> While I appreciate the proposal I am still not sure if this is a good
> idea.  We are dealing with peer who in spite of not able to receive
> our BGP messages UPDATES or KEEPALIVES keeps session for
> "hours/days/weeks". Isn't this behaviour a direct manifestation of
> ignoring normative aspects of RFC4271 Section 6.5 ?
> 
> 6.5.  Hold Timer Expired Error Handling
> 
>    If a system does not receive successive KEEPALIVE, UPDATE, and/or
>    NOTIFICATION messages within the period specified in the Hold Time
>    field of the OPEN message, then the NOTIFICATION message with the
>    Hold Timer Expired Error Code is sent and the BGP connection is
>    closed.

The subtlety here is that the above detection mechanism cannot cope with
a bad peer that is periodically sending KEEPALIVEs (which could happen
if the KEEPALIVE generation is done in a separate process/thread); while
not processing inbound messages from the healthy peer. There are two
aspects to consider:

1/ A system might be unable to close the BGP connection, because the
final NOTIFICATION message is stuck in the "SendQ", this in turn also
means the local system can't proceed to generate WITHDRAW messages for
routes pointing to the broken peer. See this animation for an
illustration: https://twitter.com/JobSnijders/status/1337803996657016833

2/ The § 6.5 Error Handling is a asynchronous: moving on to the next
state of the FSM depends on successfully receiving successive
KEEPALIVEs; not on successfully writing data to the remote (bad) peer.

> But worse, we are allowing broken peer to keep running, potentially
> poisoning the network and just cutting ourselves from it. He may have
> ignored our withdrawals and hundreds of peers may use wrong information.

Which is *exactly* the reason to cut the poisonous system off the
network.

> IMO such stuck peers should get HIGH SEVERITY syslog msg and NOC
> should take an action by calling the other party or manually bringing
> the peer down. If you say this state is being ignored for
> "hours/days/weeks" I am afraid this is not protocol problem but
> operational issue modulo lack of proper alarming.

Why wait for manually bringing down the peer? :-)

I'm happy to see you now agree the problem scenario is a "HIGH SEVERITY"
situation!

Kind regards,

Job