Subject: LDP Hello hold time negotiation

From: "Vach Kompella" <[email-masked]>
Date: Thu, 20 Sep 2001 16:48:40 -0700

Suppose A sends out a Hello with hold time of 30 seconds on an ethernet
interface.  B and C respond, with Hello hold time 20 and 15, respectively.
What is the final hold time in hellos sent out by A?
 - 15 seconds?  You keep taking the minimum, and B has to adjust down also,
since B and C will also form an adjacency?
 - 20 seconds with a reject to C, assuming B's hello got to A first?  Why
deny C and all who follow?
 - 30 seconds, despite B's hello hold time?  That's not what the draft says
(although one email in the archive suggests that is the answer).

I'm assuming that A continues to send only one hello message to the
multicast group.

-Vach

---

From: Bob Thomas <[email-masked]>
Date: Fri, 21 Sep 2001 07:11:28 -0400

Vach,

> since B and C will also form an adjacency?

Yes.

> I'm assuming that A continues to send only one hello message to the

Yes.

RFC3036 does not explicitly address this case.  That was probably
an oversight.

Bob

---

From: Bob Thomas <[email-masked]>
Date: Fri, 21 Sep 2001 07:47:32 -0400

I'd like to correct my prior response to Vach's question.

> RFC3036 does not explicitly address this case.  That was probably

The important thing is that A knows that B's hold time is 20 and
C's hold time is 15.  A should use this information to determine
how frequently it needs to send Hello's on the ethernet to keep
discovery adjacencies it cares about alive.

In its Hello's A should advertise the hold time it uses to timeout
discovery adjacencies.

Whether or not A wants to reduce the hold time it uses to timeout
discovery adjacencies based on the knowledge of what the LSR's it has
discovered are using for hold times is an implementation dependent
decision.

Bob

---

From: Eric Gray <[email-masked]>
Date: Fri, 21 Sep 2001 10:34:10 -0400

Bob,

    And this would be why RFC 3036 SHOULD NOT address this case.
Just to be clear, there is no requirement that LSR A change the hold time
it advertises to either 20 (to match B) or 15 (to match C).  However, A
must use a hold timer value of 20 in its peer relationship with B (for this
adjacency) and A must use a hold timer value of 15 in its peer relationship
with C (again for this adjacency).  This is a bidding negotiation in which
neither party needs to change its 'bid' in order to be certain of agreement.
LSR A MAY decide to force a common timer by changing the value it
advertises to the lowest value any peer on a common link has advertised,
but this is an implementation decision (and, in my opinion, a hard one to
justify).

    Remember that - if A's transport address makes it the passive peer with
respect to either B or C - changing its hold timer value MAY result in the
active peer terminating and restarting the session initialization process.
Also, increasing the rate at which Hello messages must be sent for all peers
to match the frequency required by the most demanding peer is sub-optimal
by a fair piece.

--
Eric Gray

---

From: "Vach Kompella" <[email-masked]>
Date: Fri, 21 Sep 2001 09:10:07 -0700

Bob, Eric,

I think I get it :-)

From the discussion, it is clear there are two issues: what hold timer
should A use, and what is the frequency of hellos it sends out.

A has got one shot each t seconds to tell others on a shared medium like
ethernet that it is still alive (hello-wise), since A doesn't want to send
one hello per adjacency.

Thuogh A maintains two different adjacencies, it is going to send one hello
to satisfy both B and C that it is alive and well.  Therefore, it must
adjust its hello frequency down to once every 5 seconds.

On the other hand, A MUST NOT time out its adjacency with B in less than 20
seconds.  I think that is what Eric is saying.  Likewise, B MUST NOT time
out its adjacency with A in less than 30 seconds, regardless of the fact
that B advertised a hold time of 20 seconds.  Every adjacency merits its own
hold timer.

-Vach

> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 7:34 AM
> To: Bob Thomas
> Cc: Vach Kompella; Mpls-wg
> Subject: Re: LDP Hello hold time negotiation
>
>
> Bob,
>

---

From: Eric Gray <[email-masked]>
Date: Fri, 21 Sep 2001 12:21:26 -0400

Vach,

    Absolutely true.  A should NEVER be allowed to assume that
B MUST peer with C.  Therefore, A MUST not assume that B will
be sending Hello messages to satisify C's expiry criteria (about
which B may be completely unconcerned).

--
Eric Gray

You wrote:

> (Though) A maintains two different adjacencies, it is going to send one
> hello to satisfy both B and C that it is alive and well.  Therefore, it must

---

From: "HariKishan" <[email-masked]>
Date: Fri, 21 Sep 2001 09:58:05 -0700

The case you described results in two adjacencies at each LSR.
The hold times of the two adjacencies are independent of each
other and can be maintained with two timers, one per each adjacency.

But the rate at which you send out Multicast Hellos is effected by the
adjacency with least hold time on the particular Ethernet interface.
The Hello interval becomes 1/3rd of the least adjacency hold time
existing on the given Ethernet Interface.

In the case u described, considering LSR A,

	Adj1 ---> {LSR A, LSR B} -- Hold_Time = 20
	Adj2 ---> {LSR A, LSR C} -- Hold_Time = 15

Hello_Interval = Min( Hold_time(Adj1), Hold_time(Adj2))/3;
			which comes out to be 5.
( RFC recommends to use hello interval  1/3 rd of Hold Interval)

If you send out multicast Hellos at the rate of 1 per every
5 seconds it guarantees that the you can properly operate
with both the peers reachable over the Ethernet link.

--Kishan

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Vach
> Kompella
> Sent: Thursday, September 20, 2001 4:49 PM
> To: Mpls-wg
> Subject: LDP Hello hold time negotiation
>
>

---

From: "HariKishan" <[email-masked]>
Date: Fri, 21 Sep 2001 10:15:51 -0700

I agree that A must not time out its adjacency with B
in less that 20 seconds. As per the RFC,B must not time out
in less than 20 seconds.(The hold time used is the minimum
of the hold times proposed in their hellos).

If B Chooses a value more than
20 seconds, that will never cause any problem. The fact
is, A keeps on sending Hellos with Hold time 30 seconds,
B keeps on sending Hellos with hold time 20 seconds,
and as per the RFC A and B should behave as if the adjacency
hold time is at most 20 seconds at each side.

--Kishan