Re: Addressing doc
Igor Bryskin <i_bryskin@yahoo.com> Sat, 16 April 2005 21:37 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 RAA12107 for <ccamp-archive@ietf.org>; Sat, 16 Apr 2005 17:37:08 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMv8z-0000Ln-9H for ccamp-archive@ietf.org; Sat, 16 Apr 2005 17:48:01 -0400
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMusy-0001cL-PG for ccamp-data@psg.com; Sat, 16 Apr 2005 21:31:28 +0000
Received: from [68.142.200.144] (helo=web30801.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DMusw-0001c7-Nu for ccamp@ops.ietf.org; Sat, 16 Apr 2005 21:31:26 +0000
Received: (qmail 51213 invoked by uid 60001); 16 Apr 2005 21:31:26 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Sj0WMQuZ5vmnWObJD7UhAAxWO06/AUYw6DyQnvKarhb4ugeFss78g/0kHFUCd/oesY/a6dcoXjUB4F2CN6rPgazJiSMbqqHf8s0obm2Jm3M1AUATt4xDFB754w/H9hyVoJhL3Axx7S7HyoP8jbyOpCb3BM0KhBMR02GgsXzAVtM= ;
Message-ID: <20050416213126.51211.qmail@web30801.mail.mud.yahoo.com>
Received: from [68.100.80.11] by web30801.mail.mud.yahoo.com via HTTP; Sat, 16 Apr 2005 14:31:26 PDT
Date: Sat, 16 Apr 2005 14:31:26 -0700
From: Igor Bryskin <i_bryskin@yahoo.com>
Subject: Re: Addressing doc
To: Dimitri.Papadimitriou@alcatel.be, Kireeti Kompella <kireeti@juniper.net>
Cc: ccamp@ops.ietf.org
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD autolearn=no version=3.0.1
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
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, thats 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
- Re: Addressing doc Eiji Oki
- Addressing doc Kireeti Kompella
- RE: Addressing doc Zafar Ali
- Re: Addressing doc ibryskin
- Re: Addressing doc Dimitri.Papadimitriou
- Re: Addressing doc Igor Bryskin
- RE: Addressing doc Richard Rabbat
- Re: Addressing doc Dimitri.Papadimitriou
- Re: Addressing doc Igor Bryskin
- Re: Addressing doc Dimitri.Papadimitriou
- RE: Addressing doc Ong, Lyndon
- RE: Addressing doc Richard Rabbat
- RE: Addressing doc Richard Rabbat
- Re: Addressing doc dimitri papadimitriou
- Re: Addressing doc Diego Caviglia
- Re: Addressing doc Diego Caviglia
- RE: Addressing doc Richard Rabbat
- RE: Addressing doc Rajiv Papneja
- Re: Addressing doc Igor Bryskin
- RE: Addressing doc Brungard, Deborah A, ALABS
- Re: Addressing doc Igor Bryskin
- RE: Addressing doc Richard Rabbat
- RE: Addressing doc Brungard, Deborah A, ALABS
- RE: Addressing doc Sadler, Jonathan B.
- RE: Addressing doc Brungard, Deborah A, ALABS
- RE: Addressing doc Ong, Lyndon
- RE: Addressing doc Alan Davey
- Re: Addressing doc dimitri papadimitriou
- Re: Addressing doc Igor Bryskin
- Re: Addressing doc dimitri papadimitriou
- RE: Addressing doc Sadler, Jonathan B.
- OIF topic Richard Rabbat
- RE: Addressing doc inoue.ichiro@lab.ntt.co.jp
- Re: Addressing doc Kohei Shiomoto
- RE: Addressing doc Yumiko Kawashima
- RE : Addressing doc LE ROUX Jean-Louis RD-CORE-LAN
- Re: Addressing doc Hidetsugu Sugiyama
- RE: Addressing doc Vishal Sharma
- RE: Addressing doc Brungard, Deborah A, ALABS
- RE: Addressing doc Ong, Lyndon
- Re: Addressing doc Wataru Imajuku
- Re: Addressing doc Thomas D. Nadeau
- RE: Addressing doc Richard Rabbat
- RE: Addressing doc Dimitri.Papadimitriou
- RE: Addressing doc Richard Rabbat
- RE: Addressing doc Diego Caviglia
- RE: Addressing doc Rajiv Papneja
- Decission on Addressing draft Adrian Farrel
- RE: Addressing doc Richard Rabbat
- RE: Addressing doc Diego Caviglia
- RE: Addressing doc Dimitri.Papadimitriou
- Re: Addressing doc Adrian Farrel
- RE: Addressing doc Richard Rabbat
- Re: Addressing doc Dimitri.Papadimitriou