Question on ResvConf from CCAMP WG

[Lou Berger <lberger@movaz.com>]

All,
	My understanding of the issue raised the "ResvConf" issue raised in this 
morning's session is that it's not clear to some what is meant by "...a 
ResvConf message is forwarded to the receiver hop-by-hop, to accommodate 
the hop-by-hop integrity check mechanism."  [RFC2205].  RFC2205 is 
consistent in it's usage of hop-by-hop to mean from rsvp-aware node to 
rsvp-aware node, so an informed read should not need any further clarification.

Just to be absolutely clear, we can make an editorial change to GMPLS-RSVP, 
if the group/chairs/ADs agree.  Specifically we can add ResvConf to section 
10.2, i.e.:

10.2 Addressing Path, PathTear and ResvConf Messages

RSVP was designed to handle dynamic (non-explicit) path changes and non 
RSVP hops along the path.  To this end, the Path, PathTear and ResvConf 
messages carry the destination address of the session in the IP header.  In 
generalized signaling, routes are usually explicitly signaled.  Further, 
hops that cannot allocate labels cannot exist in the path of an LSP.  A 
further difference with traditional RSVP is that at times, an RSVP message 
may travel out of band with respect to an LSP's data channel.

When a node is sending a Path, PathTear or ResvConf message to a node that 
it knows to be adjacent at the data plane (i.e. along the path of the LSP) 
it SHOULD address the message directly to  an address associated with the 
adjacent node's control plane. In this case the router-alert option SHOULD 
not be included.

Lou