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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 Mar 2004 04:38:44 -0000

(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

---

From: "zafar ali" <[email-masked]>
Date: Fri, 19 Mar 2004 01:11:06 -0500

Dear Adrian and Ccampers:

We have also updated the ID based on the comments received from the list
and contribution from Dimitri. The updated version should appear at the
list shortly, in the mean time mirror copy can be found at, 

http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp-node-i
d-based-hello-01.txt

Comments and suggestions will be appreciated. 

N.b. IMO this draft belongs to BCP category and does NOT change protocol
behavior. 

Thanks

Regards... Zafar

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Thursday, March 18, 2004 11:39 PM
>To: [email-masked]
>Subject: Node-id Hello - standards track or BCP?
>
>
>(or informational?)
>
>An essential difference between the first and the second might 
>be the behavior that one LSR expects from its neighbor.
>

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Fri, 19 Mar 2004 10:46:39 -0500

This belongs to BCP category.

Thanks,
Siva

---

From: Arun Satyanarayana <[email-masked]>
Date: Fri, 19 Mar 2004 13:48:42 -0500 (EST)

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

---

From: "Vishal Sharma" <[email-masked]>
Date: Fri, 19 Mar 2004 11:27:50 -0800

Adrian,

I think this is appropriate for the BCP category.

Also, I think Arun brings up a very good point about consistency
with addressing in Path/Resv. messages, and I support the idea that
it would be good to have clarification to this effect in the draft.

-Vishal

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Thursday, March 18, 2004 8:39 PM
> To: [email-masked]

---

From: Anca Zamfir <[email-masked]>
Date: Fri, 19 Mar 2004 22:19:09 -0500

BCP in my opinion.

/anca

---

From: "zafar ali" <[email-masked]>
Date: Mon, 22 Mar 2004 21:36:47 -0500

Hi Arun, 

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

Please my reply in-line. 

Thanks

Regards... Zafar

>[mailto:[email-masked]] On Behalf Of Arun Satyanarayana
>Sent: Friday, March 19, 2004 1:49 PM
>To: Adrian Farrel
>Cc: [email-masked]; Arun Satyanarayan
>Subject: Re: Node-id Hello - standards track or BCP?
>
>
>
>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_ ============================================================
>> An essential difference between the first and the second 
>might be the 
>> behavior that one LSR expects from its neighbor.
>>

---

From: "zafar ali" <[email-masked]>
Date: Mon, 22 Mar 2004 21:40:49 -0500

>From: Vishal Sharma [mailto:[email-masked]] 
>Sent: Friday, March 19, 2004 2:28 PM
>To: Adrian Farrel; [email-masked]; [email-masked]; Zafar Ali
>Subject: RE: Node-id Hello - standards track or BCP?
>
>
>Adrian,
>
>Also, I think Arun brings up a very good point about 
>consistency with addressing in Path/Resv. messages, and I 
>support the idea that it would be good to have clarification 
>to this effect in the draft.

Hi Vishal, 

Thanks for your feedback; much appreciated. As I mentioned in the reply
to Arun's email, we will put a clarification statement accordingly.

Thanks

Regards... Zafar