RE: Addressing doc
"Richard Rabbat" <richard.rabbat@us.fujitsu.com> Wed, 20 April 2005 03:40 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 XAA22157 for <ccamp-archive@ietf.org>; Tue, 19 Apr 2005 23:40:15 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO6Fg-0002T0-TY for ccamp-archive@ietf.org; Tue, 19 Apr 2005 23:51:50 -0400
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DO5sE-000KOH-Vt for ccamp-data@psg.com; Wed, 20 Apr 2005 03:27:34 +0000
Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DO5sA-000KNQ-3P for ccamp@ops.ietf.org; Wed, 20 Apr 2005 03:27:30 +0000
Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j3K3ROB2027860; Tue, 19 Apr 2005 20:27:25 -0700 (PDT)
Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j3K3RO1k027857; Tue, 19 Apr 2005 20:27:24 -0700 (PDT)
Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.2/8.13.2) with ESMTP id j3K3ROSc006868; Tue, 19 Apr 2005 20:27:24 -0700 (PDT)
Received: from PHOENIX (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id j3K3RGx00330; Tue, 19 Apr 2005 20:27:17 -0700 (PDT)
From: Richard Rabbat <richard.rabbat@us.fujitsu.com>
To: Dimitri.Papadimitriou@alcatel.be, 'Igor Bryskin' <i_bryskin@yahoo.com>
Cc: 'Kireeti Kompella' <kireeti@juniper.net>, ccamp@ops.ietf.org
Subject: RE: Addressing doc
Date: Tue, 19 Apr 2005 23:26:26 -0400
Message-ID: <003201c54558$bfe79130$1410a485@PHOENIX>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C54537.38D5F130"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <OFCB704F90.729B8AF8-ONC1256FE6.004DEC10-C1256FE6.004DF38C@netfr.alcatel.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.0.1
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 466662da679e1d2dece19de64e166a5b
We mentioned in the discussion in Minneapolis that the objective was *NOT* to standardize broken implementations interwork with the correct implementations. Agree with Igor's and your comments. In the introduction, we said: For the purposes of this document it is assumed that there is a one-to-one correspondence between control plane and data plane entities. I think we covered this well. As we mentioned in the draft, "Generally speaking there is a need for a module/protocol that discovers and manages control plane/data plane address bindings for the address spaces to be completely separated. In this case, the TE Router ID could be just a network unique number. Mandating that TE Router ID be a reachable IP address eliminates the need of the mentioned above module ・the next hop data plane TE Router ID could be used as a destination for IP packets encapsulating the LSP setup (RSVP Path) message." We will update the draft to show that we are inclusive of both the simple case and the more complex case that requires the mapping that we discussed above. Based on that, why not to progress it to WG draft? Moving it to WG draft means that the WG is interested in the topic and wants to address the topic. Richard. -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Dimitri.Papadimitriou@alcatel.be Sent: Sunday, April 17, 2005 10:11 AM To: Igor Bryskin Cc: Dimitri.Papadimitriou@alcatel.be; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Addressing doc igor, i mentioned this because when some implement - for whatever purpose - a subset of capabilities and draw recommendations from this partial set, these should not by any means retrofit to the complete set of capabilities this protocol suite delivers or imply recommendations that would prevent from using its full set coming to the below you have been mentioned on what this so-called separation does imply is that for constructing - and LMP can be used in helping this construction but this is also not mandatory - the TE topology make use of the TE router ID for the identification unnumbered interfaces and (abstract) nodes, (numbered interfaces are also part of this class of information - but obviously does not require the use of the TE Router ID) afterwards any control plane message exchange can make use of the IP control plane topology as long as these messages are exchanged between control plane entities that have initially advertized (i.e. as owner of) this information hope this clarifies, - dimitri. Igor Bryskin <i_bryskin@yahoo.com> Sent by: owner-ccamp@ops.ietf.org 04/17/2005 05:50 MST To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella <kireeti@juniper.net>, ccamp@ops.ietf.org bcc: Subject: Re: Addressing doc Dimitri, I think we are in agreement here. The only thing I disagree with is your statement that the document is not ready to be WG document for the reasons you have provided. I am not the author of this document and I let the authors tell what they think. However, the whole point of the document, as far as I understand it, is not to mandate something, rather, to provide a set of recommendations based on the interop tests experience, so that interoperability between different vendors would be easier to achieve. Hence, they do not need to spell out word RECOMMEND in every clause. WRT TE Router ID. Of course, IFF there is some knowledge or mechanism to translate TE addresses into control plane IP addresses, any of next hop IP addresses could be used as destination in RSVP Path message IP packet. In this case IHMO Te Router ID does not even have to be routable, and full separation between TE and control plane name spaces could be achieved. I think LMP could help to do this. However, one cannot mandate using LMP for every link in every layer, especially, for IP/MPLS layer(s). Igor --- Dimitri.Papadimitriou@alcatel.be wrote: > > 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 > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
- 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