RE: WG Last Call: draft-ietf-ccamp-lmp-06 (fwd)

[Jonathan Lang <jplang@calient.net>]

Venkata,
  I'm sorry I missed your earlier email.

  The HelloInterval/HelloDeadInterval timers were debated among the authors
and multiple models (including the IS-IS and OSPF models) were considered.
LMP does require that the timer settings are synchronized to avoid
overloading the receiver, but it is a bit more flexible than some other
models that require parameter synchronization. 

LMP allows you to bring up multiple control channels simultaneously (these
can be over the same interface if desired). This can be used to change the
timers dynamically without risking that your original adjacency is lost.
(once a second control channel is brought up with new parameters you can
bring down the first). As an additional note, LMP allows negotiation of
these parameters with the ConfigNack message which includes an acceptable
value for the parameters. One thing you could do (and it's supported in the
LMP-MIB) is to configure a range of values that are acceptable. If your
neighbor proposes anything within the range, you have agreement.

Thanks,
Jonathan

> Date: Thu, 26 Sep 2002 18:45:40 -0400
> From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
> To: "'Ong, Lyndon'" <LyOng@ciena.com>, 'Ron Bonica' 
> <Ronald.P.Bonica@wcom.com>,
>      ccamp@ops.ietf.org
> Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-06
> 
> LMP guys,
> 
> -> 1)  3.2.1 states that HelloInterval and HelloDeadInterval
> -> MUST be agreed upon by the local and remote nodes, but I
> -> am still looking for a description of how they agree, if
> -> it's there would appreciate a pointer to this (e.g., shortest
> -> value wins?)
> 
>   I have something to say regarding this point.
> 
>   Synchronized Parameter settings are sometimes harmful.
>   Most of the LMP Hello protocol fundamentals are derived
>   from OSPF. But, inherently there are some issues with
>   the OSPF Hello protocol parameter exchange.
> 
>   Radia's 1991 paper reads (FYI):
> 
>   In OSPF, there are several parameters that must be
>   configured identically in routers, or else the router will
>   refuse to communicate with each other. This creates a
>   problem because it is virtually impossible to change the
>   parameter setting via network management. Once a router's
>   parameter setting is changed, it is cut off from the
>   rest of the network since no other routers will be able
>   to communicate with it.
>   . . .
> 
>    - HelloTime and DeadTime:
>      . . .
>      ISIS reports only DeadTime in its Hello messages (not
>      HelloTime). As a result, the ratio between DeadTime and
>      HelloTime is fixed in ISIS, but can be configured in
>      different ways by OSPF. ISIS uses the information solely
>      to determine how long to wait between receipt of Hellos
>      from a particular neighbor before declaring the link
>      to that neighbor down. There is no necessity for
>      neighboring nodes to have the same value.
> 
>      Being able to change these timers in a running network is
>      important. As a LAN becomes larger it might be decided
>      that the overhead from hellos is too great. It also
>      might be important in some configurations to be able to
>      run with different hello timers for different routers.
>      There might be some routers for which quick deletion
>      of failure would be very desirable, whereas for other
>      routers quick deletion of failure might not be as
>      important. To lower overhead these routers might be
>      configured with a longer HelloTime. This cannot be done
>      in OSPF since all routers must have identical timers.
> 
>   Moreover, please remember that LMP hellos are very very
>   granular. The scalability requirements for LMP are little
>   strict when compared to traditional protocols.
> 
>   So, please revisit the LMP hello protocol timer configurations.
> 
>   After all, my 2 cents... :)
> 
> --
> Venkata.
>