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

[Robert Raszuk <[e-mail]>]

Hi Jeff,


> With the "or otherwise" detail I missed, what we'd be looking at according
> to your procedures is 30 minutes (no end of rib), set the user timeout, and
> minimally 10 minutes or 5*holdtime if larger than 10.  So, stuck state
> during initial sync could linger up to 40 minutes or longer.
>
> Is that your intent?
>

Yes - as the default. But as we all know those defaults can be configurable
on a per peer basis.

I am not that worried about 40 minutes considering two things ..

* When you bring a BGP session to a peer you watch it. You see how
messages are being exchanged so I am not sure there is really a
practical problem with bringing a BGP session. Likewise when node
reboots we really do not want to be too aggressive in flapping BGP
sessions.

* Current open src implementations by watching buffer full bouncing even in
run time (after EOR) can take hours to detect stuck sessions. And folks are
apparently happy with it.

> The signaling mechanism for TCP user-timeout is already specified in
> > RFC5482. It's optional.
>
> I was thinking specifically of a BGP option to provide for implementations
> that don't want to regularly be watching for changing TCP values.  For
> example, exchanged in a capability.
>

I would have some sympathy for this if we would have dynamic capabilities.
Note
that changing TCP_USER_TIMEOUT as I discussed with Enke does not require
session reset/flap. Otherwise I am really not sure what is the advantage.

Likewise I am not clear how sending value of the timer to a peer in
capability helps
those who "don't want to regularly be watching for changing TCP values".
Which values ?



> Reading deeper into RFC 5482, we see some additionally interesting things:
>
> :   In the absence of an application-specified user timeout, the TCP
> :   specification [RFC0793] defines a default user timeout of 5 minutes.
>


Right ! But as we discussed, that is assumed to be in place if
TCP_USER-TIMEOUT is
enabled by application.

RFC0793 is really not clear if it should be enabled by default.
Apparently it is not.


> That's why I believe a solution at the BGP level would be incomplete
> > and perhaps even more complex. On the other hand, TCP user-timeout is
> > specifically designed to handle these cases. It's more complete and
> > simpler.
>
> As long as you're fine with the one-bit signal of "user timeout has gone
> down".  That's not necessarily a clear win for some of the people who've
> responded to the thread.
>

Hmmm what else do you expect to obtain if we would do that in BGP ?

I am actually afraid much less info or underlying TCP conditions can be
exposed if we
just keep checking the buffer full or not.

Many thx,
R.