The MPLS WG Archive

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

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