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

[Robert Raszuk <[e-mail]>]

Hello Jeff,

Just to clarify a few things as I have a feeling that they were not too
well described by me.

> Long run we could use BGP PING and BFD and retire KEEPALIVEs.
>
> As much as I'm a fan of BFD, it is unlikely to become pervasive for all
> situations where BGP gets used.  Also, BFD is insufficiently coupled to the
> BGP session state.  By analogy, LDP still has keepalives in its TCP session
> even though it has a separate hello layer.
>

What I meant by "retire" was not in general spec/IETF wise. I meant to
disable/suspend
only a given session when both BFD and BGP PING would operate.

I don't think think the op message helps us here either.  The whole point is
> the connection is unidirectionally stalled and the upstream wants to take
> action on that.
>

Yes ... I mentioned OP MSG to highlight that BGP level PING would be very
different
from it - not in any form or shape to bring it as a candidate for this
discussion.

Where could this go into BGP?  Ideally, a clean update to the PDU format.
> As a hack?  As two uint32's embedded in the Marker, capability negotiated.
>
> The better question, does this help the situation in question?
> In my opinion, no.
>

Interesting ... Wouldn't it test BGP -- TCP --- NETWORK -- TCP --- BGP path
in a
bi-dir style ? Wouldn't it likely detect more "stuck" elements ?

Your below paragraph rather confirms that it would detect a stuck peer.


> In a "ping" or "bidirectional check" mode, the general idea becomes, "I
> sent
> you seq# X and I want to eventually see this come back to me".
>
> To get the echo reply, the echo must first work its way from the sender's
> TCP send buffer, across the network, through the receiver's TCP receive
> buffer, into the BGP, then the full loop again through their send and your
> receive buffers.  You'd also require a message to message to piggyback the
> reply to.  When there are pending updates, it's easy.  Otherwise, you could
> force another message like keepalive.
>

Note I am proposing a new BGP MESSAGE - BGP PING MESSAGE. Not to
piggyback in the Marker.



> (Yes, arguably you could do a less frequent "ping", but now you're also
> adding another set of optional timer procedures.)
>
> By analogy to BFD, you're getting the result of BFD Echo mode rather than
> BFD Async mode - and it's likely far longer than is desired for this use
> case.
>

Yes this came to me too, but it would not be BGP level so I dismissed it.


> Side reading, some thinking on timestamping BGP updates:
> https://datatracker.ietf.org/doc/html/draft-litkowski-idr-bgp-timestamp-00


Thx


> [1] Discussions with BGP developers over the years about various upgrade
> scenarios often comes back to the fact that the holdtimer is
> unidirectional.
> During an upgrade where the TCP and BGP RIB state is maintained, it's
> useful
> to simply pause consuming incoming routing state and do nothing other than
> send your keepalives.  The challenge for this discussion is that this
> "feature" is indistinguishable from bugs observed for sessions that are
> stuck for too long.
>

Yes .. and instead hacking what's working fine say in 99% of deployments
give
an option to check BGP peer liveness by BGP level PING.

Again with all of the above discussion I am yet to see a solid prove of the
seriousness of the issue.

Best,
Robert.