Re: Last Call comments on draft-ietf-rsvp-node-id-based-hello-00.txt

[dimitri papadimitriou <dpapadimitriou@psg.com>]

hi adrian, thanks for commenting, wrt to the below comments:

> First, to repeat my comments from just before San Diego...
>  
> > 2. Introduction
> >   Even in the case of packet MPLS, when link failure detection is
> >   performed by some means other than RSVP Hellos (e.g., [BFD]), the use
> >   of node-id based Hellos is also optimal for detection of signaling
> >   adjacency failures for RSVP-TE.
> > This optimally only applies when there is more than one link between a pair of node,
> > right?
> > Say so?
> > Ditto section 3.
> >
> > 2. Introduction
> >   This document also clarifies the use of node-id based Hellos when all
> >   or a sub-set of TE links are unnumbered. This draft also clarifies
> >   use of node-id based Hellos in these scenarios.
> > Repeated?
> >
> > 3. Node-id based RSVP Hellos
> >   When a node receives a Hello packet where the destination IP address
> >   is its local node-id as advertised in the IGP-TE topology, the node
> >   MUST use its node-id in replying to the Hello message.
> > This is an interesting use of MUST when the receiving node knows that the use of node-id
> > is inappropriate.
> >
> >
> > I think it is really cute that Danny and Reshad have decided to swap email addresses :-)

concerning the above we have already provided a response during july - 
see following reply on the ccamp mailing list:

<http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00805.html>

and these should be incorporated in the revision of this document

> Further Technical Points:
>
> Would you like to add a comment about IPv6? In particular, in an IPv6 network, from where
> does the "Node ID" come?

if one assumes the Node id comes from the Router_IPv6_Address for
OSPFv3-TE and the same for IS-IS a stable IPv6 TE Router_ID is to be
used - we should come up with some more details and probably leave open
a discussion point for TE Router_ID for v6 as the above are still
individual submissions (i remember that there is no Hello mechanism for
IPv4/v6 2205-based RSVP, so in some sense we are detailing this as part 
of the scope of this document)

> Section 4.
> While I agree with this section, I think you need to justify your statement.

agreed, suggest the following text

"Per [RFC 3209], the Hello mechanism is intended for use between
immediate neighbors and Hello messages are by default sent between
direct RSVP neighbors. This document does not modify this behavior as
it uses as "local node_id" the IPv4/IPv6 source address of the sending
node and as "remote node_id" the IPv4/IPv6 destination address of the
neighbor node. TTL/Hop Limit setting and processing are also left unchanged.

Moreover, this document does not modify the use of Hello Processing for
State Recovery as defined in Section 9.3 of [RFC 3473] (including
definition and processing of the RESTART_CAP object)."

anything else we could add in order to justify this statement

> Section 5.
> Again, I agree. But can you say *why* no new security issues are introduced?

there are two views on this either one accepts that we do not open more 
security breaks from the companions documents (as the information 
elements on which this document relies are the same) or we go through 
RFC 2747 and parse the details of INTEGRITY object and processing

we will incorporate the below in the next revision of the document

> Editorial nits:
>
> Title and Abstract don't actually give any clue that you are talking about MPLS and GMPLS!
> You need to add this.
>
> Please run the draft through the ID-nits script at http://ietf.levkowetz.com/tools/idnits/
>
> You have IPR boilerplate issues to sort out.
>
> You can remove the "Routing Area ID Summary" at this point.
>
> You don't need a Table of Contents (but you are welcome to keep it).
>
> Section 2
> "not terminated on  data bearer links? interfaces even if (some of) "
> -- spurious double space
> -- spurious question mark
>
> Please try to be consistent with "Hello" or "hello"
>
> Section 3
> "the neighbor?s node-id in the destination address field of the IP"
>
> -- spurious question mark
>
> Please use page throws and sort out the double page numbering.
>
> Please be consistent "node-id" or "node id" (See the title!)
>
> References need a bit of formatting.
>
> ISIS-TE is now RFC3784
>
>
>
> Will definitely need a respin at the end of last call.
> Thanks,
> Adrian

i agree,

thanks,
- dimitri.