Re: Addressing doc

Dimitri.Papadimitriou@alcatel.be Sat, 16 April 2005 20:16 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07140 for <ccamp-archive@ietf.org>; Sat, 16 Apr 2005 16:16:23 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMtsm-00078I-6U for ccamp-archive@ietf.org; Sat, 16 Apr 2005 16:27:14 -0400
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMtZ4-000H2Z-AG for ccamp-data@psg.com; Sat, 16 Apr 2005 20:06:50 +0000
Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DMtZ3-000H29-72 for ccamp@ops.ietf.org; Sat, 16 Apr 2005 20:06:49 +0000
Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j3GK6i9x011053; Sat, 16 Apr 2005 22:06:44 +0200
To: Kireeti Kompella <kireeti@juniper.net>
Cc: ccamp@ops.ietf.org
From: Dimitri.Papadimitriou@alcatel.be
Subject: Re: Addressing doc
MIME-Version: 1.0
Date: Sat, 16 Apr 2005 22:06:42 +0200
Message-ID: <OFD60EAB50.6D60A7CD-ONC1256FE5.006E79D8-C1256FE5.006E7A4A@netfr.alcatel.fr>
X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 04/16/2005 22:06:44
Content-type: text/plain; charset="us-ascii"
X-Alcanet-MTA-scanned-and-authorized: yes
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.3 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336

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>