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

["zafar ali" <zali@cisco.com>]

Hi Arun, 

Sorry for the delay; thanks for your feedback on the draft. 

Please my reply in-line. 

Thanks

Regards... Zafar

>-----Original Message-----
>From: owner-ccamp@ops.ietf.org 
>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Arun Satyanarayana
>Sent: Friday, March 19, 2004 1:49 PM
>To: Adrian Farrel
>Cc: ccamp@ops.ietf.org; Arun Satyanarayan
>Subject: Re: Node-id Hello - standards track or BCP?
>
>
>
>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. 

Yes, this is a good point; we will include the comment accordingly.

>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
>
>
>
>