RE: Addressing doc

["Richard Rabbat" <richard.rabbat@us.fujitsu.com>]

Dimitri,

> 
> this document is not ready as it prevents usage of the control channel
> separation as defined in Section 8 of RFC 3473 (but also 
> representation of
> complex nodes)
> 
> i point out here the sentences from where this can be deduced:
> 
> "  A Path message is sent to the next hop node.  It is 
> RECOMMENDED that
>    the TE router ID of the next hop node be used as an IP destination
>    address in the packet that carries the RSVP-TE message. "
> 
> combined with the following statements
> 
> "  ... an unnumbered link is identified by the
>    combination of TE Router ID and a node-unique Interface ID."
> 
> "  It is RECOMMENDED that the IP tunnel endpoint address in 
> the Session
>    Object [RFC3209] be set to the TE Router ID of the egress since the
>    TE Router ID is a unique routable ID per node."
> 
> [...]
> 
> "  It is RECOMMENDED that the IP tunnel sender address in the Sender
>    Template Object [RFC3209] specifies the TE Router ID of the ingress
>    since the TE Router ID is a unique routable ID per node."
> 
> therefore, usage of the TE Router ID should be reviewed, such 
> that it does
> not recommends the source and destination of IP packets to be 
> the TE Router
> ID but simply a stable reachable control plane IP address of the
> next/previous hop
> 
Thanks for the suggestion. We'll explain accordingly.

> also, there is a sentence in this document
> 
> "  The reason why the TE Router ID must be a reachable IP address is
>    because in GMPLS, control and data plane names /addresses are not
>    completely separated. "
> 
> my response to this is of course if you use it like proposed in this
> document this problem occurs
> 
> ps:
> 
> section 5.1.2 of this document is unclear wrt section 1.1 of
> <http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-ext
ensions-19.txt>

We'll clarify as well.
Richard.