Re: Addressing doc

[Dimitri.Papadimitriou@alcatel.be]

igor, my point is that if you recommend

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

and

"  ... an unnumbered link is identified by the combination of TE Router
  ID and a node-unique Interface ID."

then it is clear that the following occurs

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

and the only change that needs to be done in this document in section 4.3

"It is RECOMMENDED that a stable
   control plane IP address of the next/previous hop node be used as an
   IP destination address in RSVP-TE message.

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

is to remove the second paragraph, as there is nothing that mandates that
communication between adjacent controllers should achieved through TE
router ID (note: reading the document you will see that the section 5.2.1
is indeed
not completed just for this reason)

in fact, this boils down to say that the TE router ID is not mandatorily
used for hop-by-hop exchange of control messages as i can build adjacencies
between neighboring nodes using the base IP routing topology, (by the way
from where all restrictions that are pointed here below come from ?)

thanks,
- dimitri.
---

Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message? You are saying that it should a stable
IP address of the controller managing the next hop.
Where the processing controller is supposed to get
this stable IP address from? All that it has is a
numbered or unnumbered next hop TE link ID. It is not
guaranteed that numbered TE link ID is a routable
address, however, it could be easily resolved to TE
Router ID. In case of unnumbered TE link the TE Router
ID is a part of the link ID. It is also guaranteed
that TE Router ID is a stable routable IP address of
the controller advertising the TE link. Hence, the
recommendation makes a lot of sense to me ? extract TE
Router ID from unnumbered link ID ERO subobject or
resolve numbered TE link ID into TE Router ID, set it
as destination in IP header of the RSVP Path message
and forward the packet ?the message will arrive at the
controller managing next hop no matter how many actual
IP hops the packet will make. In fact, that's how the
control plane and data plane separation needs to be
supported.

Cheers,
Igor

--- Dimitri.Papadimitriou@alcatel.be wrote:
>
> 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
>
> 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-extensions-19.txt>
>
>
>
>




__________________________________
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide