Subject: [Idr] Hold Negotiation

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 7 Mar 2008 18:17:57 -0800

Hi Sue/ Yakov,

I found an ambiguity in the Hold Time negotiation for the value of 0 received.

The idea of negotiation of the Hold time is that if we will use the
smaller of the two values of Hold time to be the actual Hold Time. A
value of 0, actually means the Maximum Hold time. So in case we get a
value of 0 from the neighbor, should we use the value of Hold time as
0(a smaller numeric value - but a bigger  value as such) or should we
use the value of (x > 0) as it is logically lesser than the value of 0
Hold time.

I would think we want the latter. Do let me know what you think?

Thanks,
Vishwas
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 Mar 2008 09:07:02 -0400

> I would think we want the latter. Do let me know what you think?

RFC 4271 says the following:
: If the negotiated hold time value is zero, then the HoldTimer and
: KeepaliveTimer are not started.

This is supported at various points throughout the FSM documentation
calling out the case of non-zero and zero.  For example:

:         - if the HoldTimer initial value is non-zero,
:             - starts the KeepaliveTimer with the initial value and
:             - resets the HoldTimer to the negotiated value,
:           else, if the HoldTimer initial value is zero,
:             - resets the KeepaliveTimer and
:             - resets the HoldTimer value to zero,
:         - and changes its state to OpenConfirm.

So, while non-zero values are a negotiated timer the zero case is
intended to shut off the timers.

-- Jeff

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 10 Mar 2008 06:54:09 -0800

Hi Jeff,

>  : KeepaliveTimer are not started.
The point that I raise is the value that is negotiated. If my
configured HoldTime is 0 and the received Hold time is 90. What is the
smaller HoldTime? Is it 0 (which is just a place holder which implies
infinity Hold Time as the timers are not started at all - so in
practice is a larger Hold Time than 90) or is it 90 (numerically
bigger than 0 - but in practice a smaller value).

By the logic of it, the negotiated value should be 90 seconds and not
0 seconds, shouldn't it? As the RFC also states that:

         Upon
         receipt of an OPEN message, a BGP speaker MUST calculate the
         value of the Hold Timer by using the smaller of its configured
         Hold Time and the Hold Time received in the OPEN message.

I agree to the other part of the text you quote, it does seem to clarify this.

Thanks,
Vishwas

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 Mar 2008 12:39:41 -0400

> bigger than 0 - but in practice a smaller value).

Here's the contorted logic I'd use to interpret this:

0 < 90.  Therefore the negotiated value would be 0.  This would mean
that neither party should send keepalives, etc.  However:

:   If the Hold Time field of the OPEN message is unacceptable, then the
:   Error Subcode MUST be set to Unacceptable Hold Time.  An
:   implementation MUST reject Hold Time values of one or two seconds.
:   An implementation MAY reject any proposed Hold Time.  An
:   implementation that accepts a Hold Time MUST use the negotiated value
:   for the Hold Time.

If I want to use keepalives and you don't, I'll send a notification.
Thus, regardless of whether or not the negotiated value would be zero,
it must still be acceptable to both parties.

-- Jeff

---

From: Danny McPherson <[email-masked]>
Date: Mon, 10 Mar 2008 10:44:48 -0600

> bigger than 0 - but in practice a smaller value).

Numerically, yes.  Logically, no.

>         Hold Time and the Hold Time received in the OPEN message.

That's not negotiation, it's computation.  If 0 represents infinity
and 90 represents, well, 90.  I'd consider 0 larger, if such a thing
were to occur.

-danny

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 10 Mar 2008 08:47:30 -0800

Hi Jeff,

Thanks for the reply.

So you are saying it is not about a shorter Hold Time, but actually
just the value received in the time field.

Thanks,
Vishwas