Re: Node-id Hello - standards track or BCP?

[Arun Satyanarayana <aruns@movaz.com>]

BCP since it does narrow choice.

However, I do have some comments:

The following text in section 2 is not necessarily true:

                                             Specifically, when all TE
   links between neighbor nodes are unnumbered, it is implied that the
   nodes will use node-id based Hellos for detection of signaling
   adjacency failures.

TE links may be unnumbered, but the corresponding control channel(s) may
be numbered. Implementations may choose to use either the control channel
interface addresses or node id's (a.k.a loopback addresses) for RSVP
messages.

In general, it would suffice to say that the IP addressing used in Hellos
follows the addressing used in Path and Resv messages. This includes any
modified IP addressing behaviour for Path and Resv messages, when the
control channel is out-of-band, as well as, when unnumbered data
interfaces are in use. Hence, if implementations do want to narrow Hellos
to node id's (a.k.a loopback addresses), they do so consistently across
all other RSVP messages as well. This means conditions such as Hellos
being up but Path and Resv refreshes being lost, or vice versa do not
occur. It also means that, it is not necessary to consult routing to
correlate node id's to corresponding control channel IP interface
addresses to go from Hellos to Path/Resv state for the sender node and
vice versa.

Thanks,
_arun_
============================================================
On Fri, 19 Mar 2004, Adrian Farrel wrote:

> (or informational?)
>
> The question for you folks is:
>
> does this change protocol behavior (standards track)
> or narrow the choices for an implementation (BCP)
> or describe what some implementations do (informational)
>
> An essential difference between the first and the second might be the behavior that one
> LSR expects from its neighbor.
>
> Opinions are cheap, but I want them anyway.
>
> Thanks,
> Adrian