The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

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:

> 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.
>
> (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
> 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:eric.gray@sandburst.com]
> > Sent: Friday, September 21, 2001 7:34 AM
> > To: Bob Thomas
> > Cc: Vach Kompella; Mpls-wg
> > Subject: Re: LDP Hello hold time negotiation
> >
> >
> > 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
> >
> > You wrote:
> >
> > > I'd like to correct my prior response to Vach's question.
> > >
> > > > Vach,
> > > >
> > > > > 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?
> > > >
> > > > Yes.
> > > >
> > > > >  - 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.
> > > >
> > > > Yes.
> > > >
> > > > RFC3036 does not explicitly address this case.  That was probably
> > > > an oversight.
> > >
> > > 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
> >