From pce-bounces@lists.ietf.org Wed Mar 01 10:12:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FET0b-00030i-QA; Wed, 01 Mar 2006 10:12:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FET0a-00030d-VI for pce@ietf.org; Wed, 01 Mar 2006 10:12:56 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FET0Z-0001CT-CP for pce@ietf.org; Wed, 01 Mar 2006 10:12:56 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 01 Mar 2006 07:12:54 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,157,1139212800"; d="scan'208"; a="22794846:sNHT22426108" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k21FCsqM003782; Wed, 1 Mar 2006 10:12:55 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 10:12:54 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 10:12:54 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Wed, 1 Mar 2006 10:12:18 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 01 Mar 2006 15:12:54.0495 (UTC) FILETIME=[9D6D26F0:01C63D42] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Pce] PCECP Design Team: thanks ! X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, Adrian and myself wanted to warmly thank the DT for the tremendous amount of work and great achievement on the PCECP requirements. As you know, the generic PCECP requirement document passed WG Last Call and will be of a great help designing PCEP. There is still a good amount of work to be done on the application-specific documents. Let's close the DT (thanks again) and continue the discussion on the list. JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 02 18:28:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExEA-0005Yp-12; Thu, 02 Mar 2006 18:28:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExE4-0005Qx-Om; Thu, 02 Mar 2006 18:28:52 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEvwq-0007np-UV; Thu, 02 Mar 2006 17:07:00 -0500 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEulE-00019V-Jv; Thu, 02 Mar 2006 15:51:00 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k22Ko2vP005700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEukM-0003Ru-Iv; Thu, 02 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 02 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-req-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering Author(s) : E. Oki Filename : draft-ietf-pce-inter-layer-req-01.txt Pages : 8 Date : 2006-3-2 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-inter-layer-req-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-inter-layer-req-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-2141039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-inter-layer-req-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2141039.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Thu Mar 02 23:31:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF1wi-00036l-Mt; Thu, 02 Mar 2006 23:31:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF1wh-00036f-2S for pce@ietf.org; Thu, 02 Mar 2006 23:31:15 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF1wg-0001kW-5D for pce@ietf.org; Thu, 02 Mar 2006 23:31:15 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k234URxw007750 for ; Fri, 3 Mar 2006 13:30:27 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k234URMp026115 for ; Fri, 3 Mar 2006 13:30:27 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k234UQFs012824 for ; Fri, 3 Mar 2006 13:30:26 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k234UQqG018665 for ; Fri, 3 Mar 2006 13:30:26 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k234UPRL021605 for ; Fri, 3 Mar 2006 13:30:26 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb.m.ecl.ntt.co.jp [129.60.5.226]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k234UP8C021602 for ; Fri, 3 Mar 2006 13:30:25 +0900 (JST) Received: from [129.60.80.109] ([129.60.80.109]) by imb.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k234UPac018851 for ; Fri, 3 Mar 2006 13:30:25 +0900 (JST) Date: Fri, 03 Mar 2006 13:30:24 +0900 From: Eiji Oki To: pce@ietf.org Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-req-01.txt In-Reply-To: References: Message-Id: <20060303124647.98C1.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi all, A new version of the inter-layer PCC-PCE communication requirements has been published: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-01.txt Main changes: - Texts related to the applicability of PCEs for inter-layer path computation were moved to the applicability draft, http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-app-00.txt - Section 5.1.2: New requirements on control of the type of path to be computed, were added. The definition of mono-layer path and multi-layer path was moved here from original section 4. - Several texts were re-written for the sake of clarity. Any comments and suggestions are highly appreciated. Thank you. Eiji On Thu, 02 Mar 2006 15:50:02 -0500 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Path Computation Element Working Group of the IETF. > > Title : PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering > Author(s) : E. Oki > Filename : draft-ietf-pce-inter-layer-req-01.txt > Pages : 8 > Date : 2006-3-2 > > The Path Computation Element (PCE) provides functions of path > computation in support of traffic engineering in Multi-Protocol > Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > MPLS and GMPLS networks may be constructed from layered service > networks. It is advantageous for overall network efficiency to > provide end-to-end traffic engineering across multiple network > layers. PCE is a candidate solution for such requirements. > > Generic requirements for a communication protocol between Path > Computation Clients (PCCs) and PCEs are presented in "PCE > Communication Protocol Generic Requirements". This document > complements the generic requirements and presents a detailed set of > PCC-PCE communication protocol requirements for inter-layer traffic > engineering. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pce-inter-layer-req-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pce-inter-layer-req-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Mar 03 19:05:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFKGl-0006Vc-1N; Fri, 03 Mar 2006 19:05:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFK28-0006e1-9x; Fri, 03 Mar 2006 18:50:04 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFK27-00039w-DI; Fri, 03 Mar 2006 18:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k23No20e006665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FFK26-0000ga-M4; Fri, 03 Mar 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 03 Mar 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-pcep-01.txt Pages : 57 Date : 2006-3-3 This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of MPLS and GMPLS Traffic Engineering. The PCEP protocol is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-pcep-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-pcep-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-3162457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcep-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcep-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-3162457.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Fri Mar 03 20:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFLlz-0002Fd-1w; Fri, 03 Mar 2006 20:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFLjX-0005nX-7Z for pce@ietf.org; Fri, 03 Mar 2006 20:38:59 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFKHD-0006hI-Kv for pce@ietf.org; Fri, 03 Mar 2006 19:05:39 -0500 Received: from smail.alcatel.fr ([64.208.49.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FFKES-0000Pu-12 for pce@ietf.org; Fri, 03 Mar 2006 19:02:51 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id k2402jnk022616; Sat, 4 Mar 2006 01:02:46 +0100 In-Reply-To: <20060303124647.98C1.OKI.EIJI@lab.ntt.co.jp> To: Eiji Oki Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-req-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sat, 4 Mar 2006 01:02:44 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 03/04/2006 01:02:45, Serialize complete at 03/04/2006 01:02:45 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: -2.6 (--) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi eiji the doc mentions " A request from a PCC to a PCE MUST allow control of the type of the path to be computed by selection from the following list: - A mono-layer path that includes already established lower-layer LSPs " i am not sure to really understand the constaint you are referring to, per RFC4206 there is no distinction between a TE link being an FA or TE link being not sustained by an FA hence the same would apply for the information gathered by the PCE thanks for clarifying - dimitri. Eiji Oki 03/03/2006 05:30 To: pce@ietf.org cc: Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-req-01.txt Hi all, A new version of the inter-layer PCC-PCE communication requirements has been published: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-01.txt Main changes: - Texts related to the applicability of PCEs for inter-layer path computation were moved to the applicability draft, http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-app-00.txt - Section 5.1.2: New requirements on control of the type of path to be computed, were added. The definition of mono-layer path and multi-layer path was moved here from original section 4. - Several texts were re-written for the sake of clarity. Any comments and suggestions are highly appreciated. Thank you. Eiji On Thu, 02 Mar 2006 15:50:02 -0500 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Path Computation Element Working Group of the IETF. > > Title : PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering > Author(s) : E. Oki > Filename : draft-ietf-pce-inter-layer-req-01.txt > Pages : 8 > Date : 2006-3-2 > > The Path Computation Element (PCE) provides functions of path > computation in support of traffic engineering in Multi-Protocol > Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > MPLS and GMPLS networks may be constructed from layered service > networks. It is advantageous for overall network efficiency to > provide end-to-end traffic engineering across multiple network > layers. PCE is a candidate solution for such requirements. > > Generic requirements for a communication protocol between Path > Computation Clients (PCCs) and PCEs are presented in "PCE > Communication Protocol Generic Requirements". This document > complements the generic requirements and presents a detailed set of > PCC-PCE communication protocol requirements for inter-layer traffic > engineering. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pce-inter-layer-req-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pce-inter-layer-req-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Mar 04 05:40:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFUBy-0001U5-Qb; Sat, 04 Mar 2006 05:40:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFUBx-0001TJ-8K for pce@ietf.org; Sat, 04 Mar 2006 05:40:53 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFUBu-0003Sg-4Z for pce@ietf.org; Sat, 04 Mar 2006 05:40:53 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k24AehI0027601; Sat, 4 Mar 2006 19:40:43 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k24AegRk004540; Sat, 4 Mar 2006 19:40:42 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k24Aegph023012; Sat, 4 Mar 2006 19:40:42 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k24Aef4V000429; Sat, 4 Mar 2006 19:40:41 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k24AefIO024641; Sat, 4 Mar 2006 19:40:41 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb.m.ecl.ntt.co.jp [129.60.5.226]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k24AefRl024636; Sat, 4 Mar 2006 19:40:41 +0900 (JST) Received: from [192.168.1.2] ([129.60.15.201]) by imb.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k24AebBW009054; Sat, 4 Mar 2006 19:40:40 +0900 (JST) Date: Sat, 04 Mar 2006 19:40:38 +0900 From: Eiji Oki To: Dimitri.Papadimitriou@alcatel.be Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-req-01.txt In-Reply-To: References: <20060303124647.98C1.OKI.EIJI@lab.ntt.co.jp> Message-Id: <20060304191046.3EC0.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, Thanks for your comments. You are right. PCE cannot distinguish the difference with the IGP-TE. It should be described as, - A mono-layer path that is formed by a series of TE-links, which are expressed with strict hop(s). Eiji On Sat, 4 Mar 2006 01:02:44 +0100 Dimitri.Papadimitriou@alcatel.be wrote: > hi eiji > > the doc mentions > > " A request from a PCC to a PCE MUST allow control of the type of the > path to be computed by selection from the following list: > - A mono-layer path that includes already established lower-layer > LSPs " > > i am not sure to really understand the constaint you are referring to, per > RFC4206 there is no distinction between a TE link being an FA or TE link > being not sustained by an FA hence the same would apply for the > information gathered by the PCE > > thanks for clarifying > - dimitri. > > > > > > > > Eiji Oki > 03/03/2006 05:30 > > To: pce@ietf.org > cc: > Subject: Re: [Pce] I-D > ACTION:draft-ietf-pce-inter-layer-req-01.txt > > > Hi all, > > A new version of the inter-layer PCC-PCE communication requirements has > been published: > http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-01.txt > > Main changes: > - Texts related to the applicability of PCEs for inter-layer path > computation were moved to the applicability draft, > http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-app-00.txt > - Section 5.1.2: New requirements on control of the type of path to be > computed, were added. The definition of mono-layer path and multi-layer > path was moved here from original section 4. > - Several texts were re-written for the sake of clarity. > > Any comments and suggestions are highly appreciated. > > Thank you. > Eiji > > On Thu, 02 Mar 2006 15:50:02 -0500 > Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Path Computation Element Working Group > of the IETF. > > > > Title : PCC-PCE Communication > Requirements for Inter-Layer Traffic Engineering > > Author(s) : E. Oki > > Filename : > draft-ietf-pce-inter-layer-req-01.txt > > Pages : 8 > > Date : 2006-3-2 > > > > The Path Computation Element (PCE) provides functions of path > > computation in support of traffic engineering in Multi-Protocol > > Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > > > MPLS and GMPLS networks may be constructed from layered service > > networks. It is advantageous for overall network efficiency to > > provide end-to-end traffic engineering across multiple network > > layers. PCE is a candidate solution for such requirements. > > > > Generic requirements for a communication protocol between Path > > Computation Clients (PCCs) and PCEs are presented in "PCE > > Communication Protocol Generic Requirements". This document > > complements the generic requirements and presents a detailed set of > > PCC-PCE communication protocol requirements for inter-layer traffic > > engineering. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-01.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-pce-inter-layer-req-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-ietf-pce-inter-layer-req-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use > this > > feature, insert the command "ENCODING mime" before the > "FILE" > > command. To decode the response(s), you will need > "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been > split > > up into multiple messages), so check your local > documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Mar 06 04:16:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBoy-0006BW-85; Mon, 06 Mar 2006 04:16:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBow-0006AP-Mi; Mon, 06 Mar 2006 04:16:02 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGAj4-0004Sn-SN; Mon, 06 Mar 2006 03:05:54 -0500 Received: from [156.154.24.129] (helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGATi-0004op-9f; Mon, 06 Mar 2006 02:50:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k267o19W025668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 07:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGATh-0008LL-Mk; Mon, 06 Mar 2006 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 06 Mar 2006 02:50:01 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-igp-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : IGP protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-igp-01.txt Pages : 32 Date : 2006-3-5 There are various circumstances in which it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Element(s) (PCE), along with some of information that can used for PCE selection. When the PCE is an LSR participating to the IGP, or even a server participating passively to the IGP, a simple and efficient way for PCE discovery consists of relying on IGP flooding. For that purpose this document defines OSPF and ISIS extensions for the advertisement of PCE Discovery information within an IGP area or the entire routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-igp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-igp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-igp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-5192345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-igp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-igp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-5192345.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Mon Mar 06 11:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIVu-0001vZ-DN; Mon, 06 Mar 2006 11:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIVs-0001vU-MQ for pce@ietf.org; Mon, 06 Mar 2006 11:24:48 -0500 Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGIVs-0000L6-5g for pce@ietf.org; Mon, 06 Mar 2006 11:24:48 -0500 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id E670113F81 for ; Mon, 6 Mar 2006 11:23:19 -0500 (EST) Message-ID: <012701c6413a$7bd36d00$7a1810ac@movaz.com> From: "Igor Bryskin" To: References: Date: Mon, 6 Mar 2006 11:24:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Subject: [Pce] Fw: I-D ACTION:draft-bryskin-pce-policy-enabled-path-comp-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, The following two PCE policy related drafts were presented on IETF64: draft-berger-pce-policy-architecture-00.txt; draft-bryskin-pce-policy-enabled-path-comp-00.txt The former document has introduced among other things a policy element into PCE architecture and provided policy related definitions. It was decided that these definitions as well as some other topics described in the document should belong to the PCE architecture document and were incorporated into the draft-ietf-pce-architecture-04.txt.The rest of the draft-berger-pce-policy-architecture-00.txt is merged with the draft-bryskin-pce-policy-enabled-path-comp-00.txt into draft-bryskin-pce-policy-enabled-path-comp-01.txt. The intention of the merged document is to outline the policy enabled path computation framework and stage up the work for creating the Path Computation Policy Information Model (PCPIM) and the infrastructure for its support.Igor (and Dimitri and Lou) > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Policy-Enabled Path Computation Framework > Author(s) : I. Bryskin, ey al. > Filename : draft-bryskin-pce-policy-enabled-path-comp-01.txt > Pages : 28 > Date : 2006-3-5 > > The PCE architecture [PCE-ARCH] introduces the concept of policy in > the context of path computation. This document provides additional > details on policy within the PCE Architecture and also provides > context for the support of PCE Policy. This document introduces the > use of the Policy Core Information Model (PCIM) as a framework for > supporting path computation policy. This document also provides > configuration scenarios for the support of PCE Policy. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bryskin-pce-policy-enabled-path-comp-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-bryskin-pce-policy-enabled-path-comp-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bryskin-pce-policy-enabled-path-comp-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Mar 06 15:06:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGLyj-0004dW-Hf; Mon, 06 Mar 2006 15:06:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGLyi-0004dJ-H3 for pce@ietf.org; Mon, 06 Mar 2006 15:06:48 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGLyh-0007Xz-QC; Mon, 06 Mar 2006 15:06:48 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Mar 2006 15:06:48 -0500 X-IronPort-AV: i="4.02,168,1139202000"; d="scan'208,217"; a="83612192:sNHT77365014" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k26K6lWc005339; Mon, 6 Mar 2006 15:06:47 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 15:06:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Mar 2006 15:06:45 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D3320131F892@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Thread-Index: AcY9d8T9GgaiLa33RiWUaPre1Gn2NwD3o5wA From: "Rich Bradford \(rbradfor\)" To: X-OriginalArrivalTime: 06 Mar 2006 20:06:47.0292 (UTC) FILETIME=[7F7533C0:01C64159] X-Spam-Score: 0.2 (/) X-Scan-Signature: 91d41a7910bc138368a2b7a939f0ed3f Cc: pce@ietf.org Subject: [Pce] RE: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0297945570==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0297945570== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64159.7F3EC291" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64159.7F3EC291 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear WG, =20 Just to let you know that a new ID has been posted proposing a simple extension to the ERO to allow path segments in separate ASs to remain confidential. There are indeed various circumstances that require "encoding" a path segment in some form. I've included the abstract below. Note that this ID may eventually be split to be discussed separately in CCAMP and PCE but we prefer to start with a single ID first to be discussed in CCAMP. =20 Comments are very welcome. =20 Thanks, Rich =20 =20 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 Reply-To: internet-drafts@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 =20 Title : Protocol Extensions for Signaling=20 Confidential Path Segments in Multiprotocol=20 Label Switching Traffic Engineering. Author(s) : R. Bradford, et al. Filename : draft-rbradfor-ccamp-confidential-segment-00.txt Pages :=20 Date : 2006-3-1 =20 Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths=20 (LSPs) may be computed by Path Computation Elements (PCEs). Where the=20 LSP crosses multiple domains such as Autonomous Systems (ASs) the=20 path may be computed by multiple PCEs that cooperate, with each=20 responsible for computing a segment of the path.=20 =20 However, in some cases such as when ASs are administered by separate=20 Service Providers, it would break confidentiality rules for a PCE to=20 supply a path segment to a PCE in another domain. This issue may be=20 circumvented by returning a loose hop and by invoking a new path=20 computation from the domain boundary LSR during LSP setup as the LSP=20 enters the second domain, but this technique has several issues=20 including the problem of maintaining path diversity.=20 =20 This document allows a PCE to provide a full path, but to hide the=20 contents of a segment of that path called the Confidential Path=20 Segment (CPS). The CPS may be conveyed in the PCE Communication=20 Protocol (PCEP) and signaled in a Resource Reservation Protocol=20 (RSVP) explicit route either by replacing it with a path key or by=20 encrypting it.=20 =20 =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-confidential-se gment-00.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 =20 Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rbradfor-ccamp-confidential-segment-00.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2006-3-1103934.I-D@ietf.org> =20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce =20 ------_=_NextPart_001_01C64159.7F3EC291 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear WG,

 

Just to let you know that a new ID has been posted proposing a = simple extension to the ERO to allow path segments in separate ASs to remain confidential. There are indeed various circumstances that require = "encoding" a path segment in some form. I've included the abstract below. Note that = this ID may eventually be split to be discussed separately in CCAMP and PCE = but we prefer to start with a single ID first to be discussed in = CCAMP.

 

Comments are very welcome.

 

Thanks,

Rich

 

 

Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt <= /p>

 

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

 

 

       &nbs= p;  Title        &n= bsp;         : Protocol Extensions for Signaling 

    =                       = Confidential Path Segments in Multiprotocol 

    =                       = Label Switching Traffic Engineering.

       &nbs= p;  Author(s)        &n= bsp; : R. Bradford, et al.

       &nbs= p;  Filename        &n= bsp;  : draft-rbradfor-ccamp-confidential-segment-00.txt

       &nbs= p;  Pages        &n= bsp;      : 

       &nbs= p;  Date        &n= bsp;        : 2006-3-1

       &nbs= p; 

Routes for Multiprotocol Label Switching (MPLS) Label Switched = Paths 

(LSPs) may be computed by Path Computation Elements (PCEs). = Where the 

LSP crosses multiple domains such as Autonomous Systems (ASs) = the 

path may be computed by multiple PCEs that cooperate, with = each 

responsible for computing a segment of the path. 

 

However, in some cases such as when ASs are administered by = separate 

Service Providers, it would break confidentiality rules for a = PCE to 

supply a path segment to a PCE in another domain. This issue may = be 

circumvented by returning a loose hop and by invoking a new = path 

computation from the domain boundary LSR during LSP setup as the = LSP 

enters the second domain, but this technique has several = issues 

including the problem of maintaining path diversity. 

 

This document allows a PCE to provide a full path, but to hide = the 

contents of a segment of that path called the Confidential = Path 

Segment (CPS). The CPS may be conveyed in the PCE = Communication 

Protocol (PCEP) and signaled in a Resource Reservation = Protocol 

(RSVP) explicit route either by replacing it with a path key or = by 

encrypting it. 

 

 

A URL for this Internet-Draft is:

 

To remove yourself from the I-D Announcement list, send a = message to 

i-d-announce-request@ietf.o= rg with the word unsubscribe in the body of the message.  

to change your subscription = settings.

 

 

Internet-Drafts are also available by anonymous FTP. Login with = the username

"anonymous" and a password of your e-mail address. = After logging in,

type "cd internet-drafts" and = then

       &nbs= p;  "get draft-rbradfor-ccamp-confidential-segment-00.txt".

 

A list of Internet-Drafts directories can be found = in

 

 

Internet-Drafts can also be obtained by = e-mail.

 

Send a message to:

       &nbs= p;  mailserv@ietf.org.

In the body type:

       &nbs= p;  "FILE /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt".<= o:p>

       &nbs= p; 

NOTE:        &n= bsp;  The mail server at ietf.org can return the document = in

       &nbs= p;  MIME-encoded form by using the "mpack" utility.  To use this

       &nbs= p;  feature, insert the command "ENCODING mime" before the = "FILE"

       &nbs= p;  command.  To decode the response(s), = you will need "munpack" or

       &nbs= p;  a MIME-compliant mail reader.  = Different MIME-compliant mail readers

       &nbs= p;  exhibit different behavior, especially when dealing with

       &nbs= p;  "multipart" MIME messages (i.e. documents which have been split

       &nbs= p;  up into multiple messages), so check your local documentation = on

       &nbs= p;  how to manipulate these messages.

       &nbs= p;            = ; 

       &nbs= p;            = ; 

Below is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

Content-Type: text/plain

 

_______________________________________________=

I-D-Announce mailing list

 

------_=_NextPart_001_01C64159.7F3EC291-- --===============0297945570== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0297945570==-- From pce-bounces@lists.ietf.org Mon Mar 06 16:21:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGN9O-0007m0-CV; Mon, 06 Mar 2006 16:21:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGN9M-0007ks-6I for pce@ietf.org; Mon, 06 Mar 2006 16:21:52 -0500 Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGN9L-00077X-33; Mon, 06 Mar 2006 16:21:52 -0500 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 9D327140A6; Mon, 6 Mar 2006 16:20:22 -0500 (EST) Message-ID: <026201c64163$fb681d30$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Rich Bradford (rbradfor)" , References: <3C292CE901FC634693F24FB2DDC4D3320131F892@xmb-rtp-20d.amer.cisco.com> Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Date: Mon, 6 Mar 2006 16:21:49 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ec0f3d4960e6167ab597cf7076be2db Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1232257432==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1232257432== Content-Type: multipart/alternative; boundary="----=_NextPart_000_025F_01C6413A.12611A20" This is a multi-part message in MIME format. ------=_NextPart_000_025F_01C6413A.12611A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'd like to know what prevents a curious/malicious PCC after receiving = form a PCE paths with PKSs to impersonate an ASBR and resolve the PKSs = into explicit segments? Thanks, Igor Bryskin ----- Original Message -----=20 From: Rich Bradford (rbradfor)=20 To: ccamp@ietf.org=20 Cc: pce@ietf.org=20 Sent: Monday, March 06, 2006 3:06 PM Subject: [Pce] RE: = I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 Dear WG, =20 Just to let you know that a new ID has been posted proposing a simple = extension to the ERO to allow path segments in separate ASs to remain = confidential. There are indeed various circumstances that require = "encoding" a path segment in some form. I've included the abstract = below. Note that this ID may eventually be split to be discussed = separately in CCAMP and PCE but we prefer to start with a single ID = first to be discussed in CCAMP. =20 Comments are very welcome. =20 Thanks, Rich =20 =20 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 Reply-To: internet-drafts@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 =20 Title : Protocol Extensions for Signaling=20 Confidential Path Segments in Multiprotocol=20 Label Switching Traffic Engineering. Author(s) : R. Bradford, et al. Filename : = draft-rbradfor-ccamp-confidential-segment-00.txt Pages :=20 Date : 2006-3-1 =20 Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths=20 (LSPs) may be computed by Path Computation Elements (PCEs). Where the=20 LSP crosses multiple domains such as Autonomous Systems (ASs) the=20 path may be computed by multiple PCEs that cooperate, with each=20 responsible for computing a segment of the path.=20 =20 However, in some cases such as when ASs are administered by separate=20 Service Providers, it would break confidentiality rules for a PCE to=20 supply a path segment to a PCE in another domain. This issue may be=20 circumvented by returning a loose hop and by invoking a new path=20 computation from the domain boundary LSR during LSP setup as the LSP=20 enters the second domain, but this technique has several issues=20 including the problem of maintaining path diversity.=20 =20 This document allows a PCE to provide a full path, but to hide the=20 contents of a segment of that path called the Confidential Path=20 Segment (CPS). The CPS may be conveyed in the PCE Communication=20 Protocol (PCEP) and signaled in a Resource Reservation Protocol=20 (RSVP) explicit route either by replacing it with a path key or by=20 encrypting it.=20 =20 =20 A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-confidential-seg= ment-00.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce = to change your subscription settings. =20 =20 Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rbradfor-ccamp-confidential-segment-00.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE = /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the = "FILE" command. To decode the response(s), you will need "munpack" = or a MIME-compliant mail reader. Different MIME-compliant mail = readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been = split up into multiple messages), so check your local = documentation on how to manipulate these messages. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2006-3-1103934.I-D@ietf.org> =20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce =20 -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_025F_01C6413A.12611A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I'd like to know what prevents a=20 curious/malicious PCC after receiving form a PCE paths with PKSs to = impersonate=20 an ASBR and resolve the PKSs into explicit segments?
 
Thanks,
Igor Bryskin
----- Original Message -----
From:=20 Rich = Bradford=20 (rbradfor)
Sent: Monday, March 06, 2006 = 3:06=20 PM
Subject: [Pce] RE:=20 I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt

Dear WG,

 

Just to let you know that a new ID has been = posted=20 proposing a simple extension to the ERO to allow path segments in = separate ASs=20 to remain confidential. There are indeed various circumstances that = require=20 "encoding" a path segment in some form. I've included the abstract = below. Note=20 that this ID may eventually be split to be discussed separately in = CCAMP and=20 PCE but we prefer to start with a single ID first to be discussed in=20 CCAMP.

 

Comments are very=20 welcome.

 

Thanks,

Rich

 

 

To:=20 i-d-announce@ietf.org

Subject:=20 I-D=20 ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt <= /P>

Reply-To:=20 internet-drafts@ietf.org

 

A New Internet-Draft is available from the = on-line=20 Internet-Drafts directories.

 

 

         =20 Title        &n= bsp;        =20 : Protocol Extensions for Signaling 

   =20                     =  =20 Confidential Path Segments in Multiprotocol 

   =20                     =  =20 Label Switching Traffic = Engineering.

         =20 Author(s)        &n= bsp;=20 : R. Bradford, et al.

         =20 Filename        &n= bsp; =20 : = draft-rbradfor-ccamp-confidential-segment-00.txt

         =20 Pages        &n= bsp;     =20 : 

         =20 Date        &n= bsp;       =20 : 2006-3-1

         =20

Routes for Multiprotocol Label Switching = (MPLS) Label=20 Switched Paths 

<= /DIV>

(LSPs) may be computed by Path Computation = Elements=20 (PCEs). Where the 

<= /DIV>

LSP crosses multiple domains such as = Autonomous=20 Systems (ASs) the 

<= /DIV>

path may be computed by multiple PCEs that = cooperate,=20 with each 

<= /DIV>

responsible for computing a segment of the = path. 

<= /DIV>

 

However, in some cases such as when ASs are=20 administered by separate 

<= /DIV>

Service Providers, it would break = confidentiality=20 rules for a PCE to 

<= /DIV>

supply a path segment to a PCE in another = domain. This=20 issue may be 

<= /DIV>

circumvented by returning a loose hop and by = invoking=20 a new path 

<= /DIV>

computation from the domain boundary LSR = during LSP=20 setup as the LSP 

<= /DIV>

enters the second domain, but this technique = has=20 several issues 

<= /DIV>

including the problem of maintaining path=20 diversity. 

<= /DIV>

 

This document allows a PCE to provide a full = path, but=20 to hide the 

<= /DIV>

contents of a segment of that path called = the=20 Confidential Path 

<= /DIV>

Segment (CPS). The CPS may be conveyed in = the PCE=20 Communication 

<= /DIV>

Protocol (PCEP) and signaled in a Resource = Reservation=20 Protocol 

<= /DIV>

(RSVP) explicit route either by replacing it = with a=20 path key or by 

<= /DIV>

encrypting it. 

<= /DIV>

 

 

A URL for this Internet-Draft=20 is:

http://www.ietf.org/internet-drafts/draft-rbradfor-c= camp-confidential-segment-00.txt

 

To remove yourself from the I-D Announcement = list,=20 send a message to 

<= /DIV>

i-d-announce-request@ietf.o= rg=20 with the word unsubscribe in the body of the message.  

<= /DIV>

You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce 

<= /DIV>

to change your subscription=20 settings.

 

 

Internet-Drafts are also available by = anonymous FTP.=20 Login with the username

"anonymous" and a password of your e-mail = address.=20 After logging in,

type "cd internet-drafts" and=20 then

         =20 "get=20 = draft-rbradfor-ccamp-confidential-segment-00.txt".

 

A list of Internet-Drafts directories can be = found=20 in

http://www.ietf.org/shadow.html<= /A> 

<= /DIV>

or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

 

 

Internet-Drafts can also be obtained by=20 e-mail.

 

Send a message = to:

         =20 mailserv@ietf.org.

In the body = type:

         =20 "FILE=20 = /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt".<= /o:p>

         =20

NOTE:        &n= bsp; =20 The mail server at ietf.org can return the document=20 in

         =20 MIME-encoded form by using the "mpack" = utility.  To use = this

         =20 feature, insert the command "ENCODING mime" = before the=20 "FILE"

         =20 command. =20 To decode the response(s), you will need "munpack"=20 or

         =20 a MIME-compliant mail reader.  Different MIME-compliant = mail=20 readers

         =20 exhibit different behavior, especially when = dealing=20 with

         =20 "multipart" MIME messages (i.e. documents which = have been=20 split

         =20 up into multiple messages), so check your local=20 documentation on

         =20 how to manipulate these = messages.

           &= nbsp;         =20

           &= nbsp;         =20

Below is the data which will enable a MIME = compliant=20 mail reader

implementation to automatically retrieve the = ASCII=20 version of the

Internet-Draft.

Content-Type:=20 text/plain

Content-ID: <2006-3-1103934.I-D@ietf.org>

 

_______________________________________________

I-D-Announce mailing=20 list

I-D-Announce@ietf.org

https://www1= .ietf.org/mailman/listinfo/i-d-announce

<= /DIV>

 

_______________________________________________
Pce mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR> ------=_NextPart_000_025F_01C6413A.12611A20-- --===============1232257432== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1232257432==-- From pce-bounces@lists.ietf.org Mon Mar 06 16:32:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNJD-0005hB-0F; Mon, 06 Mar 2006 16:32:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNJB-0005fp-41 for pce@ietf.org; Mon, 06 Mar 2006 16:32:01 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNJA-0007vo-A5; Mon, 06 Mar 2006 16:32:01 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Mar 2006 13:32:00 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208,217"; a="23095400:sNHT72558648" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k26LVxVU028569; Mon, 6 Mar 2006 16:31:59 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 16:31:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Date: Mon, 6 Mar 2006 16:31:56 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D3320131F904@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Thread-Index: AcZBZAUB7TN1Q5ncTv2WGGPs9893cwAACsfg From: "Rich Bradford \(rbradfor\)" To: "Igor Bryskin" , X-OriginalArrivalTime: 06 Mar 2006 21:31:59.0151 (UTC) FILETIME=[665CFBF0:01C64165] X-Spam-Score: 0.2 (/) X-Scan-Signature: d5a53803c96025bf50973370d4b800ed Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1489775883==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1489775883== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64165.662B24D4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64165.662B24D4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Igor, thanks for the question. =20 If I understand the question correctly, then a PCE which was configured to supply PKSs to any PCC outside the AS would also be configured not to decode the PKS for any PCC outside the AS. -- Rich =20 =20 ________________________________ From: Igor Bryskin [mailto:ibryskin@movaz.com]=20 Sent: Monday, March 06, 2006 4:22 PM To: Rich Bradford (rbradfor); ccamp@ietf.org Cc: pce@ietf.org Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Hi, =20 I'd like to know what prevents a curious/malicious PCC after receiving form a PCE paths with PKSs to impersonate an ASBR and resolve the PKSs into explicit segments? =20 Thanks, Igor Bryskin ----- Original Message -----=20 From: Rich Bradford (rbradfor) =20 To: ccamp@ietf.org=20 Cc: pce@ietf.org=20 Sent: Monday, March 06, 2006 3:06 PM Subject: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Dear WG, =20 Just to let you know that a new ID has been posted proposing a simple extension to the ERO to allow path segments in separate ASs to remain confidential. There are indeed various circumstances that require "encoding" a path segment in some form. I've included the abstract below. Note that this ID may eventually be split to be discussed separately in CCAMP and PCE but we prefer to start with a single ID first to be discussed in CCAMP. =20 Comments are very welcome. =20 Thanks, Rich =20 =20 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 Reply-To: internet-drafts@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 =20 Title : Protocol Extensions for Signaling=20 Confidential Path Segments in Multiprotocol=20 Label Switching Traffic Engineering. Author(s) : R. Bradford, et al. Filename : draft-rbradfor-ccamp-confidential-segment-00.txt Pages :=20 Date : 2006-3-1 =20 Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths=20 (LSPs) may be computed by Path Computation Elements (PCEs). Where the=20 LSP crosses multiple domains such as Autonomous Systems (ASs) the=20 path may be computed by multiple PCEs that cooperate, with each=20 responsible for computing a segment of the path.=20 =20 However, in some cases such as when ASs are administered by separate=20 Service Providers, it would break confidentiality rules for a PCE to=20 supply a path segment to a PCE in another domain. This issue may be=20 circumvented by returning a loose hop and by invoking a new path computation from the domain boundary LSR during LSP setup as the LSP=20 enters the second domain, but this technique has several issues=20 including the problem of maintaining path diversity.=20 =20 This document allows a PCE to provide a full path, but to hide the=20 contents of a segment of that path called the Confidential Path=20 Segment (CPS). The CPS may be conveyed in the PCE Communication=20 Protocol (PCEP) and signaled in a Resource Reservation Protocol=20 (RSVP) explicit route either by replacing it with a path key or by=20 encrypting it.=20 =20 =20 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-confidential-se gment-00.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 =20 Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rbradfor-ccamp-confidential-segment-00.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2006-3-1103934.I-D@ietf.org> =20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce =20 =09 ________________________________ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C64165.662B24D4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Igor, thanks for the = question.

 

If I understand the question = correctly, then a PCE which was configured to supply PKSs to any PCC outside the AS = would also be configured not to decode the PKS for any PCC outside the = AS.

-- = Rich

 

 

From: Igor = Bryskin [mailto:ibryskin@movaz.com]
Sent: Monday, March 06, = 2006 4:22 PM
To: Rich Bradford (rbradfor); ccamp@ietf.org
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt =

 

Hi,

 

I'd like to know what prevents a = curious/malicious PCC after receiving form a PCE paths with PKSs to impersonate an ASBR and = resolve the PKSs into explicit segments?

 

Thanks,

Igor Bryskin

----- Original Message ----- =

Cc: pce@ietf.org =

Sent: Monday, = March 06, 2006 3:06 PM

Subject: [Pce] = RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt =

 

Dear WG,

 

Just to let you know that a new ID has been posted proposing a = simple extension to the ERO to allow path segments in separate ASs to remain = confidential. There are indeed various circumstances that require "encoding" = a path segment in some form. I've included the abstract below. Note that this = ID may eventually be split to be discussed separately in CCAMP and PCE but we = prefer to start with a single ID first to be discussed in = CCAMP.

 

Comments are very welcome.

 

Thanks,

Rich

 

 

Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt <= /p>

 

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

 

 

       &nbs= p;  Title        &n= bsp;         : Protocol Extensions for Signaling 

    =                       = Confidential Path Segments in Multiprotocol 

    =                       = Label Switching Traffic Engineering.

       &nbs= p;  Author(s)        &n= bsp; : R. Bradford, et al.

       &nbs= p;  Filename        &n= bsp;  : draft-rbradfor-ccamp-confidential-segment-00.txt

       &nbs= p;  Pages        &n= bsp;      : 

       &nbs= p;  Date        &n= bsp;        : 2006-3-1

       &nbs= p; 

Routes for Multiprotocol Label Switching (MPLS) Label Switched = Paths 

(LSPs) may be computed by Path Computation Elements (PCEs). = Where the 

LSP crosses multiple domains such as Autonomous Systems (ASs) = the 

path may be computed by multiple PCEs that cooperate, with = each 

responsible for computing a segment of the path. 

 

However, in some cases such as when ASs are administered by = separate 

Service Providers, it would break confidentiality rules for a = PCE to 

supply a path segment to a PCE in another domain. This issue may = be 

circumvented by returning a loose hop and by invoking a new = path 

computation from the domain boundary LSR during LSP setup as the = LSP 

enters the second domain, but this technique has several = issues 

including the problem of maintaining path diversity. 

 

This document allows a PCE to provide a full path, but to hide = the 

contents of a segment of that path called the Confidential = Path 

Segment (CPS). The CPS may be conveyed in the PCE = Communication 

Protocol (PCEP) and signaled in a Resource Reservation = Protocol 

(RSVP) explicit route either by replacing it with a path key or = by 

encrypting it. 

 

 

A URL for this Internet-Draft is:

 

To remove yourself from the I-D Announcement list, send a = message to 

i-d-announce-request@ietf.o= rg with the word unsubscribe in the body of the message.  

to change your subscription = settings.

 

 

Internet-Drafts are also available by anonymous FTP. Login with = the username

"anonymous" and a password of your e-mail address. = After logging in,

type "cd internet-drafts" and = then

       &nbs= p;  "get draft-rbradfor-ccamp-confidential-segment-00.txt".

 

A list of Internet-Drafts directories can be found = in

 

 

Internet-Drafts can also be obtained by = e-mail.

 

Send a message to:

       &nbs= p;  mailserv@ietf.org.

In the body type:

       &nbs= p;  "FILE = /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt".<= o:p>

       &nbs= p; 

NOTE:        &n= bsp;  The mail server at ietf.org can return the document = in

       &nbs= p;  MIME-encoded form by using the "mpack" = utility.  To use this

       &nbs= p;  feature, insert the command "ENCODING = mime" before the "FILE"

       &nbs= p;  command.  = To decode the response(s), you will need "munpack" = or

       &nbs= p;  a MIME-compliant mail reader.  Different MIME-compliant = mail readers

       &nbs= p;  exhibit different behavior, especially when dealing = with

       &nbs= p;  "multipart" MIME messages (i.e. documents = which have been split

       &nbs= p;  up into multiple messages), so check your local documentation on

       &nbs= p;  how to manipulate these messages.

       &nbs= p;            = ; 

       &nbs= p;            = ; 

Below is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

Content-Type: text/plain

 

_______________________________________________=

I-D-Announce mailing list

 

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

------_=_NextPart_001_01C64165.662B24D4-- --===============1489775883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1489775883==-- From pce-bounces@lists.ietf.org Tue Mar 07 10:37:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGeFT-0004NU-GR; Tue, 07 Mar 2006 10:37:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGe0H-00086E-Hv for pce@ietf.org; Tue, 07 Mar 2006 10:21:37 -0500 Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGe0G-0006KS-25; Tue, 07 Mar 2006 10:21:37 -0500 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id E5A0714502; Tue, 7 Mar 2006 10:20:04 -0500 (EST) Message-ID: <008c01c641fa$d10f0610$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Rich Bradford (rbradfor)" , References: <3C292CE901FC634693F24FB2DDC4D3320131F904@xmb-rtp-20d.amer.cisco.com> Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Date: Tue, 7 Mar 2006 10:21:32 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ff4385cf5f055d6f6dabfc300106446 X-Mailman-Approved-At: Tue, 07 Mar 2006 10:37:18 -0500 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1927787282==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1927787282== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01C641D0.E81151D0" This is a multi-part message in MIME format. ------=_NextPart_000_0089_01C641D0.E81151D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rich, My point is that path(s) containing PKSs will also contain address of = the ASBR, hence the PCC can issue a request to the PCC pretending that = it is the ASBR and resolve PKSs into explicit path segments. Your draft = says that this resolution is accomplished via a PCEP request, and my = understanding is that PCEP does not have any protection from such = impersonation. Thanks, Igor ----- Original Message -----=20 From: Rich Bradford (rbradfor)=20 To: Igor Bryskin ; ccamp@ietf.org=20 Cc: pce@ietf.org=20 Sent: Monday, March 06, 2006 4:31 PM Subject: RE: [Pce] RE: = I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 Igor, thanks for the question. =20 If I understand the question correctly, then a PCE which was = configured to supply PKSs to any PCC outside the AS would also be = configured not to decode the PKS for any PCC outside the AS. -- Rich =20 =20 -------------------------------------------------------------------------= ----- From: Igor Bryskin [mailto:ibryskin@movaz.com]=20 Sent: Monday, March 06, 2006 4:22 PM To: Rich Bradford (rbradfor); ccamp@ietf.org Cc: pce@ietf.org Subject: Re: [Pce] RE: = I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Hi, =20 I'd like to know what prevents a curious/malicious PCC after receiving = form a PCE paths with PKSs to impersonate an ASBR and resolve the PKSs = into explicit segments? =20 Thanks, Igor Bryskin ----- Original Message -----=20 From: Rich Bradford (rbradfor)=20 To: ccamp@ietf.org=20 Cc: pce@ietf.org=20 Sent: Monday, March 06, 2006 3:06 PM Subject: [Pce] RE: = I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Dear WG, =20 Just to let you know that a new ID has been posted proposing a = simple extension to the ERO to allow path segments in separate ASs to = remain confidential. There are indeed various circumstances that require = "encoding" a path segment in some form. I've included the abstract = below. Note that this ID may eventually be split to be discussed = separately in CCAMP and PCE but we prefer to start with a single ID = first to be discussed in CCAMP. =20 Comments are very welcome. =20 Thanks, Rich =20 =20 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt = Reply-To: internet-drafts@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 =20 Title : Protocol Extensions for Signaling = Confidential Path Segments in = Multiprotocol=20 Label Switching Traffic Engineering. Author(s) : R. Bradford, et al. Filename : = draft-rbradfor-ccamp-confidential-segment-00.txt Pages :=20 Date : 2006-3-1 =20 Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths = (LSPs) may be computed by Path Computation Elements (PCEs). Where = the=20 LSP crosses multiple domains such as Autonomous Systems (ASs) the=20 path may be computed by multiple PCEs that cooperate, with each=20 responsible for computing a segment of the path.=20 =20 However, in some cases such as when ASs are administered by separate = Service Providers, it would break confidentiality rules for a PCE to = supply a path segment to a PCE in another domain. This issue may be=20 circumvented by returning a loose hop and by invoking a new path=20 computation from the domain boundary LSR during LSP setup as the LSP = enters the second domain, but this technique has several issues=20 including the problem of maintaining path diversity.=20 =20 This document allows a PCE to provide a full path, but to hide the=20 contents of a segment of that path called the Confidential Path=20 Segment (CPS). The CPS may be conveyed in the PCE Communication=20 Protocol (PCEP) and signaled in a Resource Reservation Protocol=20 (RSVP) explicit route either by replacing it with a path key or by=20 encrypting it.=20 =20 =20 A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-confidential-seg= ment-00.txt =20 To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body = of the message. =20 You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 =20 Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rbradfor-ccamp-confidential-segment-00.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE = /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt". =20 NOTE: The mail server at ietf.org can return the document = in MIME-encoded form by using the "mpack" utility. To use = this feature, insert the command "ENCODING mime" before the = "FILE" command. To decode the response(s), you will need = "munpack" or a MIME-compliant mail reader. Different MIME-compliant = mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been = split up into multiple messages), so check your local = documentation on how to manipulate these messages. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2006-3-1103934.I-D@ietf.org> =20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce =20 -------------------------------------------------------------------------= --- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0089_01C641D0.E81151D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Rich,
 
My point is that path(s) containing = PKSs will also=20 contain address of the ASBR, hence the PCC can issue a request to the = PCC=20 pretending that it is the ASBR and resolve PKSs into explicit path = segments.=20 Your draft says that this resolution is accomplished via a PCEP request, = and my=20 understanding is that PCEP does not have any protection from such=20 impersonation.
 
Thanks,
Igor
----- Original Message -----
From:=20 Rich = Bradford=20 (rbradfor)
Sent: Monday, March 06, 2006 = 4:31=20 PM
Subject: RE: [Pce] RE:=20 I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt

Igor, = thanks for the=20 question.

 

If I = understand the=20 question correctly, then a PCE which was configured to supply PKSs to = any PCC=20 outside the AS would also be configured not to decode the PKS for any = PCC=20 outside the AS.

--=20 Rich

 

 

From: Igor=20 Bryskin [mailto:ibryskin@movaz.com]
Sent: Monday, March 06, 2006 = 4:22=20 PM
To: = Rich Bradford (rbradfor); ccamp@ietf.org
= Cc: pce@ietf.org
Subject: Re: [Pce] RE:=20 I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20

 

Hi,

 

I'd like to = know what=20 prevents a curious/malicious PCC after receiving form a PCE paths with = PKSs to=20 impersonate an ASBR and resolve the PKSs into explicit=20 segments?

 

Thanks,

Igor=20 Bryskin

----- Original Message = -----=20

From: Rich = Bradford=20 (rbradfor)

To: ccamp@ietf.org=20

Cc: pce@ietf.org=20

Sent: Monday,=20 March 06, 2006 3:06 PM

Subject: [Pce]=20 RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20

 

Dear WG,

 

Just to let you know that a new ID has = been posted=20 proposing a simple extension to the ERO to allow path segments in = separate=20 ASs to remain confidential. There are indeed various circumstances = that=20 require "encoding" a path segment in some form. I've included the = abstract=20 below. Note that this ID may eventually be split to be discussed = separately=20 in CCAMP and PCE but we prefer to start with a single ID first to be = discussed in CCAMP.

 

Comments are very=20 welcome.

 

Thanks,

Rich

 

 

To:=20 i-d-announce@ietf.org

Subject:=20 I-D=20 ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt <= /P>

Reply-To:=20 internet-drafts@ietf.org

 

A New Internet-Draft is available from the = on-line=20 Internet-Drafts directories.

 

 

         =20 Title        &n= bsp;        =20 : Protocol Extensions for Signaling 

   =20                   =    =20 Confidential Path Segments in = Multiprotocol 

   =20                   =    =20 Label Switching Traffic=20 Engineering.

         =20 Author(s)        &n= bsp;=20 : R. Bradford, et al.

         =20 Filename        &n= bsp; =20 :=20 = draft-rbradfor-ccamp-confidential-segment-00.txt

         =20 Pages        &n= bsp;     =20 : 

         =20 Date        &n= bsp;       =20 : 2006-3-1

         =20

Routes for Multiprotocol Label Switching = (MPLS)=20 Label Switched Paths 

<= /DIV>

(LSPs) may be computed by Path Computation = Elements=20 (PCEs). Where the 

<= /DIV>

LSP crosses multiple domains such as = Autonomous=20 Systems (ASs) the 

<= /DIV>

path may be computed by multiple PCEs that = cooperate, with each 

<= /DIV>

responsible for computing a segment of the = path. 

<= /DIV>

 

However, in some cases such as when ASs = are=20 administered by separate 

<= /DIV>

Service Providers, it would break = confidentiality=20 rules for a PCE to 

<= /DIV>

supply a path segment to a PCE in another = domain.=20 This issue may be 

<= /DIV>

circumvented by returning a loose hop and = by=20 invoking a new path 

<= /DIV>

computation from the domain boundary LSR = during LSP=20 setup as the LSP 

<= /DIV>

enters the second domain, but this = technique has=20 several issues 

<= /DIV>

including the problem of maintaining path=20 diversity. 

<= /DIV>

 

This document allows a PCE to provide a = full path,=20 but to hide the 

<= /DIV>

contents of a segment of that path called = the=20 Confidential Path 

<= /DIV>

Segment (CPS). The CPS may be conveyed in = the PCE=20 Communication 

<= /DIV>

Protocol (PCEP) and signaled in a Resource = Reservation Protocol 

<= /DIV>

(RSVP) explicit route either by replacing = it with a=20 path key or by 

<= /DIV>

encrypting it. 

<= /DIV>

 

 

A URL for this Internet-Draft=20 is:

http://www.ietf.org/internet-drafts/draft-rbradfor-c= camp-confidential-segment-00.txt

 

To remove yourself from the I-D = Announcement list,=20 send a message to 

<= /DIV>

i-d-announce-request@ietf.o= rg=20 with the word unsubscribe in the body of the message.  

<= /DIV>

You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce 

<= /DIV>

to change your subscription=20 settings.

 

 

Internet-Drafts are also available by = anonymous FTP.=20 Login with the username

"anonymous" and a password of your e-mail = address.=20 After logging in,

type "cd internet-drafts" and=20 then

         =20 "get=20 = draft-rbradfor-ccamp-confidential-segment-00.txt".

 

A list of Internet-Drafts directories can = be found=20 in

http://www.ietf.org/shadow.html<= /A> 

<= /DIV>

or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

 

 

Internet-Drafts can also be obtained by=20 e-mail.

 

Send a message=20 to:

         =20 mailserv@ietf.org.

In the body = type:

         =20 "FILE=20 = /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt".<= /o:p>

         =20

NOTE:        &n= bsp; =20 The mail server at ietf.org can return the document=20 in

         =20 MIME-encoded form by using the "mpack" = utility.  To use = this

         =20 feature, insert the command "ENCODING mime" = before the=20 "FILE"

         =20 command. =20 To decode the response(s), you will need "munpack"=20 or

         =20 a MIME-compliant mail reader.  Different MIME-compliant = mail=20 readers

         =20 exhibit different behavior, especially when = dealing=20 with

         =20 "multipart" MIME messages (i.e. documents which = have=20 been split

         =20 up into multiple messages), so check your local = documentation on

         =20 how to manipulate these = messages.

           &= nbsp;         =20

           &= nbsp;         =20

Below is the data which will enable a MIME = compliant=20 mail reader

implementation to automatically retrieve = the ASCII=20 version of the

Internet-Draft.

Content-Type:=20 text/plain

Content-ID: <2006-3-1103934.I-D@ietf.org>

 

_______________________________________________

I-D-Announce mailing=20 list

I-D-Announce@ietf.org

https://www1= .ietf.org/mailman/listinfo/i-d-announce

<= /DIV>

 

_______________________________________________
Pce=20 mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= o:p>

= ------=_NextPart_000_0089_01C641D0.E81151D0-- --===============1927787282== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1927787282==-- From pce-bounces@lists.ietf.org Tue Mar 07 11:55:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfT5-0007q9-N2; Tue, 07 Mar 2006 11:55:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfC9-0001qj-9R for pce@ietf.org; Tue, 07 Mar 2006 11:37:57 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfC4-0001IE-MJ; Tue, 07 Mar 2006 11:37:57 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Mar 2006 11:37:52 -0500 X-IronPort-AV: i="4.02,172,1139202000"; d="scan'208,217"; a="83670560:sNHT87507588" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k27GbqWc004004; Tue, 7 Mar 2006 11:37:52 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Mar 2006 11:37:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Date: Tue, 7 Mar 2006 11:37:50 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D3320131FB3D@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Thread-Index: AcZB+tU6TkOqHQyvTSe2Js6X6j0wyAAB+fng From: "Rich Bradford \(rbradfor\)" To: "Igor Bryskin" , X-OriginalArrivalTime: 07 Mar 2006 16:37:51.0924 (UTC) FILETIME=[7A359740:01C64205] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4a923df63e527497399b493144287dff X-Mailman-Approved-At: Tue, 07 Mar 2006 11:55:26 -0500 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0443271212==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0443271212== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64205.7A091B4E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64205.7A091B4E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Igor,=20 Thanks for the clarification. The authentication called out in section 12 of PCEP could be used to address this concern. If this restriction were enabled, a PCE would only expand a PKS for authenticated clients, making MD5 (or its equivalent from PCEP) required for this extension. The downside of requiring authentication is called out in section 12.1 of PCEP, which describes the operator overhead of implementing these keys as onerous. However, these keys would only need to be configured on the AS-border LSRs (and the PCEs), since those would be the only nodes where the expansion would be needed. Perhaps use of authentication in this situation could be suggested or recommended. Would that address the issue adequately? Sincerely, Rich =20 =20 =20 ________________________________ From: Igor Bryskin [mailto:ibryskin@movaz.com]=20 Sent: Tuesday, March 07, 2006 10:22 AM To: Rich Bradford (rbradfor); ccamp@ietf.org Cc: pce@ietf.org Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Rich, =20 My point is that path(s) containing PKSs will also contain address of the ASBR, hence the PCC can issue a request to the PCC pretending that it is the ASBR and resolve PKSs into explicit path segments. Your draft says that this resolution is accomplished via a PCEP request, and my understanding is that PCEP does not have any protection from such impersonation. =20 Thanks, Igor ----- Original Message -----=20 From: Rich Bradford (rbradfor) =20 To: Igor Bryskin ; ccamp@ietf.org=20 Cc: pce@ietf.org=20 Sent: Monday, March 06, 2006 4:31 PM Subject: RE: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Igor, thanks for the question. =20 If I understand the question correctly, then a PCE which was configured to supply PKSs to any PCC outside the AS would also be configured not to decode the PKS for any PCC outside the AS. -- Rich =20 =20 =09 ________________________________ From: Igor Bryskin [mailto:ibryskin@movaz.com]=20 Sent: Monday, March 06, 2006 4:22 PM To: Rich Bradford (rbradfor); ccamp@ietf.org Cc: pce@ietf.org Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Hi, =20 I'd like to know what prevents a curious/malicious PCC after receiving form a PCE paths with PKSs to impersonate an ASBR and resolve the PKSs into explicit segments? =20 Thanks, Igor Bryskin ----- Original Message -----=20 From: Rich Bradford (rbradfor) =20 To: ccamp@ietf.org=20 Cc: pce@ietf.org=20 Sent: Monday, March 06, 2006 3:06 PM Subject: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Dear WG, =20 Just to let you know that a new ID has been posted proposing a simple extension to the ERO to allow path segments in separate ASs to remain confidential. There are indeed various circumstances that require "encoding" a path segment in some form. I've included the abstract below. Note that this ID may eventually be split to be discussed separately in CCAMP and PCE but we prefer to start with a single ID first to be discussed in CCAMP. =20 Comments are very welcome. =20 Thanks, Rich =20 =20 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 Reply-To: internet-drafts@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 =20 Title : Protocol Extensions for Signaling=20 Confidential Path Segments in Multiprotocol=20 Label Switching Traffic Engineering. Author(s) : R. Bradford, et al. Filename : draft-rbradfor-ccamp-confidential-segment-00.txt Pages :=20 Date : 2006-3-1 =20 Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths=20 (LSPs) may be computed by Path Computation Elements (PCEs). Where the=20 LSP crosses multiple domains such as Autonomous Systems (ASs) the=20 path may be computed by multiple PCEs that cooperate, with each=20 responsible for computing a segment of the path.=20 =20 However, in some cases such as when ASs are administered by separate=20 Service Providers, it would break confidentiality rules for a PCE to=20 supply a path segment to a PCE in another domain. This issue may be=20 circumvented by returning a loose hop and by invoking a new path=20 computation from the domain boundary LSR during LSP setup as the LSP=20 enters the second domain, but this technique has several issues=20 including the problem of maintaining path diversity.=20 =20 This document allows a PCE to provide a full path, but to hide the=20 contents of a segment of that path called the Confidential Path=20 Segment (CPS). The CPS may be conveyed in the PCE Communication=20 Protocol (PCEP) and signaled in a Resource Reservation Protocol=20 (RSVP) explicit route either by replacing it with a path key or by=20 encrypting it.=20 =20 =20 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-confidential-se gment-00.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 =20 Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rbradfor-ccamp-confidential-segment-00.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2006-3-1103934.I-D@ietf.org> =20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce =20 =09 ________________________________ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C64205.7A091B4E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Igor,

Thanks for the = clarification.

The authentication called out in = section 12 of PCEP could be used to address this concern. If this restriction = were enabled, a PCE would only expand a PKS for authenticated clients, making = MD5 (or its equivalent from PCEP) required for this extension. The downside of requiring authentication is called out in section 12.1 of PCEP, which = describes the operator overhead of implementing these keys as onerous. However, = these keys would only need to be configured on the AS-border LSRs (and the PCEs), = since those would be the only nodes where the expansion would be needed. Perhaps use = of authentication in this situation could be suggested or recommended. = Would that address the issue adequately?

Sincerely,<= /p>

Rich

 =

 

 

From: Igor = Bryskin [mailto:ibryskin@movaz.com]
Sent: Tuesday, March 07, = 2006 10:22 AM
To: Rich Bradford (rbradfor); ccamp@ietf.org
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt =

 

Rich,

 

My point is that path(s) containing PKSs will also = contain address of the ASBR, hence the PCC can issue a request to the PCC = pretending that it is the ASBR and resolve PKSs into explicit path segments. Your = draft says that this resolution is accomplished via a PCEP request, and my understanding is that PCEP does not have any protection from such impersonation.

 

Thanks,

Igor

----- Original Message ----- =

Cc: pce@ietf.org =

Sent: Monday, = March 06, 2006 4:31 PM

Subject: RE: = [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt =

 

Igor, thanks for the = question.

 

If I understand the question = correctly, then a PCE which was configured to supply PKSs to any PCC outside the AS = would also be configured not to decode the PKS for any PCC outside the = AS.

-- = Rich

 

 

From: Igor = Bryskin [mailto:ibryskin@movaz.com]
Sent: Monday, March 06, = 2006 4:22 PM
To: Rich Bradford (rbradfor); ccamp@ietf.org
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt =

 

Hi,

 

I'd like to know what prevents a = curious/malicious PCC after receiving form a PCE paths with PKSs to impersonate an ASBR and = resolve the PKSs into explicit segments?

 

Thanks,

Igor Bryskin

----- Original Message ----- =

Cc: pce@ietf.org =

Sent: Monday, = March 06, 2006 3:06 PM

Subject: [Pce] = RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt =

 

Dear WG,

 

Just to let you know that a new ID has been posted proposing a = simple extension to the ERO to allow path segments in separate ASs to remain confidential. There are indeed various circumstances that require "encoding" a path segment in some form. I've included the = abstract below. Note that this ID may eventually be split to be discussed = separately in CCAMP and PCE but we prefer to start with a single ID first to be = discussed in CCAMP.

 

Comments are very welcome.

 

Thanks,

Rich

 

 

Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt <= /p>

 

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

 

 

       &nbs= p;  Title        &n= bsp;         : Protocol Extensions for Signaling 

    =                       = Confidential Path Segments in Multiprotocol 

    =                       = Label Switching Traffic Engineering.

       &nbs= p;  Author(s)        &n= bsp; : R. Bradford, et al.

       &nbs= p;  Filename        &n= bsp;  : draft-rbradfor-ccamp-confidential-segment-00.txt

       &nbs= p;  Pages        &n= bsp;      : 

       &nbs= p;  Date        &n= bsp;        : 2006-3-1

       &nbs= p; 

Routes for Multiprotocol Label Switching (MPLS) Label Switched = Paths 

(LSPs) may be computed by Path Computation Elements (PCEs). = Where the 

LSP crosses multiple domains such as Autonomous Systems (ASs) = the 

path may be computed by multiple PCEs that cooperate, with = each 

responsible for computing a segment of the path. 

 

However, in some cases such as when ASs are administered by = separate 

Service Providers, it would break confidentiality rules for a = PCE to 

supply a path segment to a PCE in another domain. This issue may = be 

circumvented by returning a loose hop and by invoking a new = path 

computation from the domain boundary LSR during LSP setup as the = LSP 

enters the second domain, but this technique has several = issues 

including the problem of maintaining path diversity. 

 

This document allows a PCE to provide a full path, but to hide = the 

contents of a segment of that path called the Confidential = Path 

Segment (CPS). The CPS may be conveyed in the PCE = Communication 

Protocol (PCEP) and signaled in a Resource Reservation = Protocol 

(RSVP) explicit route either by replacing it with a path key or = by 

encrypting it. 

 

 

A URL for this Internet-Draft is:

 

To remove yourself from the I-D Announcement list, send a = message to 

i-d-announce-request@ietf.o= rg with the word unsubscribe in the body of the message.  

to change your subscription = settings.

 

 

Internet-Drafts are also available by anonymous FTP. Login with = the username

"anonymous" and a password of your e-mail address. = After logging in,

type "cd internet-drafts" and = then

       &nbs= p;  "get = draft-rbradfor-ccamp-confidential-segment-00.txt".

 

A list of Internet-Drafts directories can be found = in

 

 

Internet-Drafts can also be obtained by = e-mail.

 

Send a message to:

       &nbs= p;  mailserv@ietf.org.

In the body type:

       &nbs= p;  "FILE /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt".<= o:p>

       &nbs= p; 

NOTE:        &n= bsp;  The mail server at ietf.org can return the document = in

       &nbs= p;  MIME-encoded form by using the "mpack" = utility.  To use this

       &nbs= p;  feature, insert the command "ENCODING = mime" before the "FILE"

       &nbs= p;  command.  = To decode the response(s), you will need "munpack" = or

       &nbs= p;  a MIME-compliant mail reader.  Different MIME-compliant = mail readers

       &nbs= p;  exhibit different behavior, especially when dealing = with

       &nbs= p;  "multipart" MIME messages (i.e. documents = which have been split

       &nbs= p;  up into multiple messages), so check your local documentation on

       &nbs= p;  how to manipulate these messages.

       &nbs= p;            = ; 

       &nbs= p;            = ; 

Below is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

Content-Type: text/plain

 

_______________________________________________=

I-D-Announce mailing list

 

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

------_=_NextPart_001_01C64205.7A091B4E-- --===============0443271212== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0443271212==-- From pce-bounces@lists.ietf.org Tue Mar 07 11:57:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfVC-00023N-3o; Tue, 07 Mar 2006 11:57:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfVB-00023I-3Y for pce@ietf.org; Tue, 07 Mar 2006 11:57:37 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfVA-000267-2V; Tue, 07 Mar 2006 11:57:37 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FGfVO-0003Dl-00; Tue, 07 Mar 2006 16:57:50 +0000 Received: from Puppy ([59.37.9.191] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 16:57:56 +0000 Message-ID: <02de01c64208$d38a5df0$bf09253b@Puppy> From: "Adrian Farrel" To: "Igor Bryskin" , "Rich Bradford \(rbradfor\)" , References: <3C292CE901FC634693F24FB2DDC4D3320131F904@xmb-rtp-20d.amer.cisco.com> <008c01c641fa$d10f0610$7a1810ac@movaz.com> Subject: Re: [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Date: Tue, 7 Mar 2006 17:01:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2006 16:57:57.0656 (UTC) FILETIME=[48E1B180:01C64208] X-Spam-Score: 3.1 (+++) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Igor, Are you saying that PCEP doesn't have any authentication? If it doesn't it will have! No way it will get through IESG review without that. Adrian ----- Original Message ----- From: "Igor Bryskin" To: "Rich Bradford (rbradfor)" ; Cc: Sent: Tuesday, March 07, 2006 3:21 PM Subject: Re: [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Rich, My point is that path(s) containing PKSs will also contain address of the ASBR, hence the PCC can issue a request to the PCC pretending that it is the ASBR and resolve PKSs into explicit path segments. Your draft says that this resolution is accomplished via a PCEP request, and my understanding is that PCEP does not have any protection from such impersonation. Thanks, Igor ----- Original Message ----- From: Rich Bradford (rbradfor) To: Igor Bryskin ; ccamp@ietf.org Cc: pce@ietf.org Sent: Monday, March 06, 2006 4:31 PM Subject: RE: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Igor, thanks for the question. If I understand the question correctly, then a PCE which was configured to supply PKSs to any PCC outside the AS would also be configured not to decode the PKS for any PCC outside the AS. -- Rich -------------------------------------------------------------------------- ---- From: Igor Bryskin [mailto:ibryskin@movaz.com] Sent: Monday, March 06, 2006 4:22 PM To: Rich Bradford (rbradfor); ccamp@ietf.org Cc: pce@ietf.org Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Hi, I'd like to know what prevents a curious/malicious PCC after receiving form a PCE paths with PKSs to impersonate an ASBR and resolve the PKSs into explicit segments? Thanks, Igor Bryskin ----- Original Message ----- From: Rich Bradford (rbradfor) To: ccamp@ietf.org Cc: pce@ietf.org Sent: Monday, March 06, 2006 3:06 PM Subject: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Dear WG, Just to let you know that a new ID has been posted proposing a simple extension to the ERO to allow path segments in separate ASs to remain confidential. There are indeed various circumstances that require "encoding" a path segment in some form. I've included the abstract below. Note that this ID may eventually be split to be discussed separately in CCAMP and PCE but we prefer to start with a single ID first to be discussed in CCAMP. Comments are very welcome. Thanks, Rich To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protocol Extensions for Signaling Confidential Path Segments in Multiprotocol Label Switching Traffic Engineering. Author(s) : R. Bradford, et al. Filename : draft-rbradfor-ccamp-confidential-segment-00.txt Pages : Date : 2006-3-1 Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the LSP crosses multiple domains such as Autonomous Systems (ASs) the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases such as when ASs are administered by separate Service Providers, it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary LSR during LSP setup as the LSP enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document allows a PCE to provide a full path, but to hide the contents of a segment of that path called the Confidential Path Segment (CPS). The CPS may be conveyed in the PCE Communication Protocol (PCEP) and signaled in a Resource Reservation Protocol (RSVP) explicit route either by replacing it with a path key or by encrypting it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rbradfor-ccamp-confidential-segment-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2006-3-1103934.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -------------------------------------------------------------------------- -- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce -------------------------------------------------------------------------- ------ > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Mar 07 12:00:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfXx-0004zC-OU; Tue, 07 Mar 2006 12:00:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfXf-0004U4-RJ for pce@ietf.org; Tue, 07 Mar 2006 12:00:13 -0500 Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfXf-0002Cw-6u; Tue, 07 Mar 2006 12:00:11 -0500 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id C6317127D1; Tue, 7 Mar 2006 11:58:40 -0500 (EST) Message-ID: <00f701c64208$97f6e6f0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Rich Bradford (rbradfor)" , References: <3C292CE901FC634693F24FB2DDC4D3320131FB3D@xmb-rtp-20d.amer.cisco.com> Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Date: Tue, 7 Mar 2006 12:00:10 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1063742291==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1063742291== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F4_01C641DE.AEF2F120" This is a multi-part message in MIME format. ------=_NextPart_000_00F4_01C641DE.AEF2F120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rich, Yes, I think PCEP needs some strong authentication mechanism, I'd say = similar to one used in HTTP. It is not just about resolving of PKSs. For = example, two PCCs may request from a PCE a TE path between two ASBRs = across an AS. Suppose, PCC1 belongs to the AS, and PCC2 does not. How = can the PCE return an explicit path to PCC1 without authenticating it = first? Igor=20 ----- Original Message -----=20 From: Rich Bradford (rbradfor)=20 To: Igor Bryskin ; ccamp@ietf.org=20 Cc: pce@ietf.org=20 Sent: Tuesday, March 07, 2006 11:37 AM Subject: RE: [Pce] RE: = I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 Igor,=20 Thanks for the clarification. The authentication called out in section 12 of PCEP could be used to = address this concern. If this restriction were enabled, a PCE would only = expand a PKS for authenticated clients, making MD5 (or its equivalent = from PCEP) required for this extension. The downside of requiring = authentication is called out in section 12.1 of PCEP, which describes = the operator overhead of implementing these keys as onerous. However, = these keys would only need to be configured on the AS-border LSRs (and = the PCEs), since those would be the only nodes where the expansion would = be needed. Perhaps use of authentication in this situation could be = suggested or recommended. Would that address the issue adequately? Sincerely, Rich =20 =20 =20 -------------------------------------------------------------------------= ----- From: Igor Bryskin [mailto:ibryskin@movaz.com]=20 Sent: Tuesday, March 07, 2006 10:22 AM To: Rich Bradford (rbradfor); ccamp@ietf.org Cc: pce@ietf.org Subject: Re: [Pce] RE: = I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Rich, =20 My point is that path(s) containing PKSs will also contain address of = the ASBR, hence the PCC can issue a request to the PCC pretending that = it is the ASBR and resolve PKSs into explicit path segments. Your draft = says that this resolution is accomplished via a PCEP request, and my = understanding is that PCEP does not have any protection from such = impersonation. =20 Thanks, Igor ------=_NextPart_000_00F4_01C641DE.AEF2F120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Rich,
 
Yes, I think PCEP needs some strong = authentication=20 mechanism, I'd say similar to one used in HTTP. It is not just about = resolving=20 of PKSs. For example, two PCCs may request from a PCE a TE path between = two=20 ASBRs across an AS. Suppose, PCC1 belongs to the AS, and PCC2 does = not. How=20 can the PCE return an explicit path to PCC1 without authenticating = it=20 first?
 
Igor 
----- Original Message -----
From:=20 Rich = Bradford=20 (rbradfor)
Sent: Tuesday, March 07, 2006 = 11:37=20 AM
Subject: RE: [Pce] RE:=20 I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt

Igor,=20

Thanks for = the=20 clarification.

The = authentication=20 called out in section 12 of PCEP could be used to address this = concern. If=20 this restriction were enabled, a PCE would only expand a PKS for = authenticated=20 clients, making MD5 (or its equivalent from PCEP) required for this = extension.=20 The downside of requiring authentication is called out in section 12.1 = of=20 PCEP, which describes the operator overhead of implementing these keys = as=20 onerous. However, these keys would only need to be configured on the = AS-border=20 LSRs (and the PCEs), since those would be the only nodes where the = expansion=20 would be needed. Perhaps use of authentication in this situation could = be=20 suggested or recommended. Would that address the issue=20 adequately?

Sincerely,

Rich

 

 

 

From: Igor=20 Bryskin [mailto:ibryskin@movaz.com]
Sent: Tuesday, March 07, 2006 = 10:22=20 AM
To: = Rich Bradford (rbradfor); ccamp@ietf.org
Cc: pce@ietf.org
Subject: Re: [Pce] RE:=20 I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20

 

Rich,

 

My point is that path(s) = containing PKSs will also contain address of the ASBR, hence the PCC = can issue=20 a request to the PCC pretending that it is the ASBR and resolve PKSs = into=20 explicit path segments. Your draft says that this resolution is = accomplished=20 via a PCEP request, and my understanding is that PCEP does not have = any=20 protection from such impersonation.

 

Thanks,

Igor

 

<= /BODY> ------=_NextPart_000_00F4_01C641DE.AEF2F120-- --===============1063742291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1063742291==-- From pce-bounces@lists.ietf.org Tue Mar 07 12:06:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfe0-0002YE-Ta; Tue, 07 Mar 2006 12:06:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfe0-0002Y9-HM for pce@ietf.org; Tue, 07 Mar 2006 12:06:44 -0500 Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfdz-0002VL-RK; Tue, 07 Mar 2006 12:06:44 -0500 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 506D214B8F; Tue, 7 Mar 2006 12:05:13 -0500 (EST) Message-ID: <010201c64209$81f258c0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "Rich Bradford (rbradfor)" , References: <3C292CE901FC634693F24FB2DDC4D3320131F904@xmb-rtp-20d.amer.cisco.com> <008c01c641fa$d10f0610$7a1810ac@movaz.com> <02de01c64208$d38a5df0$bf09253b@Puppy> Subject: Re: [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Date: Tue, 7 Mar 2006 12:06:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Adrian, I assume the authentication mechaisms will be described in furure revs of PCEP, as well as key distribution mechanisms to interpret encrypted EROs. Ia my assumption correct? Thanks, Igor ----- Original Message ----- From: "Adrian Farrel" To: "Igor Bryskin" ; "Rich Bradford (rbradfor)" ; Cc: Sent: Tuesday, March 07, 2006 12:01 PM Subject: Re: [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > Igor, > > Are you saying that PCEP doesn't have any authentication? > If it doesn't it will have! > > No way it will get through IESG review without that. > > Adrian > > ----- Original Message ----- > From: "Igor Bryskin" > To: "Rich Bradford (rbradfor)" ; > Cc: > Sent: Tuesday, March 07, 2006 3:21 PM > Subject: Re: [Pce] > RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > > Rich, > > My point is that path(s) containing PKSs will also contain address of the > ASBR, hence the PCC can issue a request to the PCC pretending that it is > the ASBR and resolve PKSs into explicit path segments. Your draft says > that this resolution is accomplished via a PCEP request, and my > understanding is that PCEP does not have any protection from such > impersonation. > > Thanks, > Igor > ----- Original Message ----- > From: Rich Bradford (rbradfor) > To: Igor Bryskin ; ccamp@ietf.org > Cc: pce@ietf.org > Sent: Monday, March 06, 2006 4:31 PM > Subject: RE: [Pce] RE: > I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > > Igor, thanks for the question. > > > > If I understand the question correctly, then a PCE which was configured > to supply PKSs to any PCC outside the AS would also be configured not to > decode the PKS for any PCC outside the AS. > > -- Rich > > > > > > > -------------------------------------------------------------------------- > ---- > > From: Igor Bryskin [mailto:ibryskin@movaz.com] > Sent: Monday, March 06, 2006 4:22 PM > To: Rich Bradford (rbradfor); ccamp@ietf.org > Cc: pce@ietf.org > Subject: Re: [Pce] RE: > I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > > > Hi, > > > > I'd like to know what prevents a curious/malicious PCC after receiving > form a PCE paths with PKSs to impersonate an ASBR and resolve the PKSs > into explicit segments? > > > > Thanks, > > Igor Bryskin > > ----- Original Message ----- > > From: Rich Bradford (rbradfor) > > To: ccamp@ietf.org > > Cc: pce@ietf.org > > Sent: Monday, March 06, 2006 3:06 PM > > Subject: [Pce] RE: > I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > > > Dear WG, > > > > Just to let you know that a new ID has been posted proposing a simple > extension to the ERO to allow path segments in separate ASs to remain > confidential. There are indeed various circumstances that require > "encoding" a path segment in some form. I've included the abstract below. > Note that this ID may eventually be split to be discussed separately in > CCAMP and PCE but we prefer to start with a single ID first to be > discussed in CCAMP. > > > > Comments are very welcome. > > > > Thanks, > > Rich > > > > > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > Reply-To: internet-drafts@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Protocol Extensions for Signaling > > Confidential Path Segments in Multiprotocol > > Label Switching Traffic Engineering. > > Author(s) : R. Bradford, et al. > > Filename : > draft-rbradfor-ccamp-confidential-segment-00.txt > > Pages : > > Date : 2006-3-1 > > > > Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths > > (LSPs) may be computed by Path Computation Elements (PCEs). Where the > > LSP crosses multiple domains such as Autonomous Systems (ASs) the > > path may be computed by multiple PCEs that cooperate, with each > > responsible for computing a segment of the path. > > > > However, in some cases such as when ASs are administered by separate > > Service Providers, it would break confidentiality rules for a PCE to > > supply a path segment to a PCE in another domain. This issue may be > > circumvented by returning a loose hop and by invoking a new path > > computation from the domain boundary LSR during LSP setup as the LSP > > enters the second domain, but this technique has several issues > > including the problem of maintaining path diversity. > > > > This document allows a PCE to provide a full path, but to hide the > > contents of a segment of that path called the Confidential Path > > Segment (CPS). The CPS may be conveyed in the PCE Communication > > Protocol (PCEP) and signaled in a Resource Reservation Protocol > > (RSVP) explicit route either by replacing it with a path key or by > > encrypting it. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-rbradfor-ccamp-confidential-segment-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the > "FILE" > > command. To decode the response(s), you will need "munpack" > or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been > split > > up into multiple messages), so check your local > documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > Content-Type: text/plain > > Content-ID: <2006-3-1103934.I-D@ietf.org> > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > -------------------------------------------------------------------------- > -- > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > -------------------------------------------------------------------------- > ------ > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Mar 07 13:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgUT-00055b-HV; Tue, 07 Mar 2006 13:00:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgUS-00054E-MS for pce@ietf.org; Tue, 07 Mar 2006 13:00:56 -0500 Received: from mx1.alcatel.com ([192.75.23.73] helo=smtp1.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGgUS-0004iR-71; Tue, 07 Mar 2006 13:00:56 -0500 Received: from CAOTTN03070 (caottn03070.ca.newbridge.com [138.120.44.30]) by smtp1.ca.alcatel.com (ALCANET) with ESMTP id k27I0sCf030795; Tue, 7 Mar 2006 12:00:54 -0600 From: "Andrew Dolganow" To: "'Adrian Farrel'" , "'Igor Bryskin'" , "'Rich Bradford \(rbradfor\)'" , Subject: RE: [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Date: Tue, 7 Mar 2006 13:00:53 -0500 Message-ID: <008401c64211$13d32600$1e2c788a@ad3.ad.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZCCFM4EDp798whRA+FB/240UYgbwACAbsA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <02de01c64208$d38a5df0$bf09253b@Puppy> X-Scanned-By: MIMEDefang 2.51 on 138.120.252.78 X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org The discussion on adding more authentication/security for link establishment and potentially other messages has been taken place. My believe is that we do intend to add functionality addressing such concerns to PCEP. Andrew > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, March 07, 2006 12:02 PM > To: Igor Bryskin; Rich Bradford (rbradfor); ccamp@ietf.org > Cc: pce@ietf.org > Subject: Re: [Pce] > RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > Igor, > > Are you saying that PCEP doesn't have any authentication? > If it doesn't it will have! > > No way it will get through IESG review without that. > > Adrian > > ----- Original Message ----- > From: "Igor Bryskin" > To: "Rich Bradford (rbradfor)" ; > Cc: > Sent: Tuesday, March 07, 2006 3:21 PM > Subject: Re: [Pce] > RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > > Rich, > > My point is that path(s) containing PKSs will also contain > address of the > ASBR, hence the PCC can issue a request to the PCC pretending > that it is > the ASBR and resolve PKSs into explicit path segments. Your draft says > that this resolution is accomplished via a PCEP request, and my > understanding is that PCEP does not have any protection from such > impersonation. > > Thanks, > Igor > ----- Original Message ----- > From: Rich Bradford (rbradfor) > To: Igor Bryskin ; ccamp@ietf.org > Cc: pce@ietf.org > Sent: Monday, March 06, 2006 4:31 PM > Subject: RE: [Pce] RE: > I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > > Igor, thanks for the question. > > > > If I understand the question correctly, then a PCE which > was configured > to supply PKSs to any PCC outside the AS would also be > configured not to > decode the PKS for any PCC outside the AS. > > -- Rich > > > > > > > -------------------------------------------------------------- > ------------ > ---- > > From: Igor Bryskin [mailto:ibryskin@movaz.com] > Sent: Monday, March 06, 2006 4:22 PM > To: Rich Bradford (rbradfor); ccamp@ietf.org > Cc: pce@ietf.org > Subject: Re: [Pce] RE: > I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > > > Hi, > > > > I'd like to know what prevents a curious/malicious PCC > after receiving > form a PCE paths with PKSs to impersonate an ASBR and resolve the PKSs > into explicit segments? > > > > Thanks, > > Igor Bryskin > > ----- Original Message ----- > > From: Rich Bradford (rbradfor) > > To: ccamp@ietf.org > > Cc: pce@ietf.org > > Sent: Monday, March 06, 2006 3:06 PM > > Subject: [Pce] RE: > I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > > > Dear WG, > > > > Just to let you know that a new ID has been posted > proposing a simple > extension to the ERO to allow path segments in separate ASs to remain > confidential. There are indeed various circumstances that require > "encoding" a path segment in some form. I've included the > abstract below. > Note that this ID may eventually be split to be discussed > separately in > CCAMP and PCE but we prefer to start with a single ID first to be > discussed in CCAMP. > > > > Comments are very welcome. > > > > Thanks, > > Rich > > > > > > To: i-d-announce@ietf.org > > Subject: I-D > ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > > Reply-To: internet-drafts@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Protocol Extensions > for Signaling > > Confidential Path Segments in > Multiprotocol > > Label Switching Traffic Engineering. > > Author(s) : R. Bradford, et al. > > Filename : > draft-rbradfor-ccamp-confidential-segment-00.txt > > Pages : > > Date : 2006-3-1 > > > > Routes for Multiprotocol Label Switching (MPLS) Label > Switched Paths > > (LSPs) may be computed by Path Computation Elements > (PCEs). Where the > > LSP crosses multiple domains such as Autonomous Systems (ASs) the > > path may be computed by multiple PCEs that cooperate, with each > > responsible for computing a segment of the path. > > > > However, in some cases such as when ASs are administered > by separate > > Service Providers, it would break confidentiality rules > for a PCE to > > supply a path segment to a PCE in another domain. This > issue may be > > circumvented by returning a loose hop and by invoking a new path > > computation from the domain boundary LSR during LSP setup > as the LSP > > enters the second domain, but this technique has several issues > > including the problem of maintaining path diversity. > > > > This document allows a PCE to provide a full path, but to hide the > > contents of a segment of that path called the Confidential Path > > Segment (CPS). The CPS may be conveyed in the PCE Communication > > Protocol (PCEP) and signaled in a Resource Reservation Protocol > > (RSVP) explicit route either by replacing it with a path key or by > > encrypting it. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-confi > dential-segment-00.txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe > in the body of > the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. > Login with the > username > > "anonymous" and a password of your e-mail address. After > logging in, > > type "cd internet-drafts" and then > > "get draft-rbradfor-ccamp-confidential-segment-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt". > > > > NOTE: The mail server at ietf.org can return > the document in > > MIME-encoded form by using the "mpack" utility. > To use this > > feature, insert the command "ENCODING mime" before the > "FILE" > > command. To decode the response(s), you will > need "munpack" > or > > a MIME-compliant mail reader. Different > MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which > have been > split > > up into multiple messages), so check your local > documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > Content-Type: text/plain > > Content-ID: <2006-3-1103934.I-D@ietf.org> > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > -------------------------------------------------------------- > ------------ > -- > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > -------------------------------------------------------------- > ------------ > ------ > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 08 05:58:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGwMk-0001pT-57; Wed, 08 Mar 2006 05:58:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtJF-0000Fm-DF for pce@ietf.org; Wed, 08 Mar 2006 02:42:13 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGtJD-0001aX-VG; Wed, 08 Mar 2006 02:42:13 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 08:42:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Date: Wed, 8 Mar 2006 08:42:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt Thread-Index: AcZB/QqQniiHiyRPQWShVOqdPdAHpAAhkB1w From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , "Rich Bradford \(rbradfor\)" , X-OriginalArrivalTime: 08 Mar 2006 07:42:07.0487 (UTC) FILETIME=[CD0B80F0:01C64283] X-Spam-Score: 0.2 (/) X-Scan-Signature: a6e51d56b6bcc6fcf34ac89be5076332 X-Mailman-Approved-At: Wed, 08 Mar 2006 05:58:00 -0500 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1590547806==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1590547806== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64283.CCD2984B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64283.CCD2984B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, =20 PCEP supports MD-5 authentication that prevents against impersonation =20 Regards =20 JL ________________________________ De : Igor Bryskin [mailto:ibryskin@movaz.com]=20 Envoy=E9 : mardi 7 mars 2006 16:22 =C0 : Rich Bradford (rbradfor); ccamp@ietf.org Cc : pce@ietf.org Objet : Re: [Pce] = RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =09 =09 Rich, =20 My point is that path(s) containing PKSs will also contain address of = the ASBR, hence the PCC can issue a request to the PCC pretending that = it is the ASBR and resolve PKSs into explicit path segments. Your draft = says that this resolution is accomplished via a PCEP request, and my = understanding is that PCEP does not have any protection from such = impersonation. =20 Thanks, Igor ----- Original Message -----=20 From: Rich Bradford (rbradfor) =20 To: Igor Bryskin ; ccamp@ietf.org=20 Cc: pce@ietf.org=20 Sent: Monday, March 06, 2006 4:31 PM Subject: RE: [Pce] RE: = I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 Igor, thanks for the question. =20 If I understand the question correctly, then a PCE which was = configured to supply PKSs to any PCC outside the AS would also be = configured not to decode the PKS for any PCC outside the AS. -- Rich =20 =20 =09 ________________________________ From: Igor Bryskin [mailto:ibryskin@movaz.com]=20 Sent: Monday, March 06, 2006 4:22 PM To: Rich Bradford (rbradfor); ccamp@ietf.org Cc: pce@ietf.org Subject: Re: [Pce] RE: = I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Hi, =20 I'd like to know what prevents a curious/malicious PCC after receiving = form a PCE paths with PKSs to impersonate an ASBR and resolve the PKSs = into explicit segments? =20 Thanks, Igor Bryskin ----- Original Message -----=20 From: Rich Bradford (rbradfor) =20 To: ccamp@ietf.org=20 Cc: pce@ietf.org=20 Sent: Monday, March 06, 2006 3:06 PM Subject: [Pce] RE: = I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 =20 Dear WG, =20 Just to let you know that a new ID has been posted proposing a simple = extension to the ERO to allow path segments in separate ASs to remain = confidential. There are indeed various circumstances that require = "encoding" a path segment in some form. I've included the abstract = below. Note that this ID may eventually be split to be discussed = separately in CCAMP and PCE but we prefer to start with a single ID = first to be discussed in CCAMP. =20 Comments are very welcome. =20 Thanks, Rich =20 =20 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20 Reply-To: internet-drafts@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 =20 Title : Protocol Extensions for Signaling=20 Confidential Path Segments in Multiprotocol = Label Switching Traffic Engineering. Author(s) : R. Bradford, et al. Filename : = draft-rbradfor-ccamp-confidential-segment-00.txt Pages :=20 Date : 2006-3-1 =20 Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths=20 (LSPs) may be computed by Path Computation Elements (PCEs). Where the = LSP crosses multiple domains such as Autonomous Systems (ASs) the=20 path may be computed by multiple PCEs that cooperate, with each=20 responsible for computing a segment of the path.=20 =20 However, in some cases such as when ASs are administered by separate=20 Service Providers, it would break confidentiality rules for a PCE to=20 supply a path segment to a PCE in another domain. This issue may be=20 circumvented by returning a loose hop and by invoking a new path=20 computation from the domain boundary LSR during LSP setup as the LSP=20 enters the second domain, but this technique has several issues=20 including the problem of maintaining path diversity.=20 =20 This document allows a PCE to provide a full path, but to hide the=20 contents of a segment of that path called the Confidential Path=20 Segment (CPS). The CPS may be conveyed in the PCE Communication=20 Protocol (PCEP) and signaled in a Resource Reservation Protocol=20 (RSVP) explicit route either by replacing it with a path key or by=20 encrypting it.=20 =20 =20 A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-confidential-seg= ment-00.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body = of the message. =20 You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 =20 Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rbradfor-ccamp-confidential-segment-00.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE = /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt". =20 NOTE: The mail server at ietf.org can return the document = in MIME-encoded form by using the "mpack" utility. To use = this feature, insert the command "ENCODING mime" before the = "FILE" command. To decode the response(s), you will need = "munpack" or a MIME-compliant mail reader. Different MIME-compliant = mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been = split up into multiple messages), so check your local = documentation on how to manipulate these messages. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2006-3-1103934.I-D@ietf.org> =20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce =20 =09 ________________________________ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C64283.CCD2984B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Igor,
 
PCEP supports MD-5 authentication that prevents = against=20 impersonation
 
Regards
 
JL

De : Igor Bryskin=20 [mailto:ibryskin@movaz.com]
Envoy=E9 : mardi 7 mars = 2006=20 16:22
=C0 : Rich Bradford (rbradfor);=20 ccamp@ietf.org
Cc : pce@ietf.org
Objet : = Re:=20 [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20

Rich,
 
My point is that path(s) containing = PKSs will=20 also contain address of the ASBR, hence the PCC can issue a request to = the PCC=20 pretending that it is the ASBR and resolve PKSs into explicit path = segments.=20 Your draft says that this resolution is accomplished via a PCEP = request, and=20 my understanding is that PCEP does not have any protection from such=20 impersonation.
 
Thanks,
Igor
----- Original Message -----
From:=20 Rich Bradford=20 (rbradfor)
Sent: Monday, March 06, 2006 = 4:31=20 PM
Subject: RE: [Pce] RE:=20 I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt

Igor, = thanks for=20 the question.

 

If I = understand the=20 question correctly, then a PCE which was configured to supply PKSs = to any=20 PCC outside the AS would also be configured not to decode the PKS = for any=20 PCC outside the AS.

--=20 Rich

 

 

From: Igor=20 Bryskin [mailto:ibryskin@movaz.com]
Sent: Monday, March 06, 2006 = 4:22=20 PM
To: = Rich Bradford (rbradfor); = ccamp@ietf.org
= Cc: pce@ietf.org
Subject: Re: [Pce] RE:=20 I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20

 

Hi,

 

I'd like to = know what=20 prevents a curious/malicious PCC after receiving form a PCE paths = with PKSs=20 to impersonate an ASBR and resolve the PKSs into explicit=20 segments?

 

Thanks,

Igor=20 Bryskin

----- Original = Message -----=20

From: Rich = Bradford=20 (rbradfor)

To: ccamp@ietf.org=20

Cc: pce@ietf.org =

Sent:=20 Monday, March 06, 2006 3:06 PM

Subject: [Pce]=20 RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt=20

 

Dear WG,

 

Just to let you know that a new ID has = been posted=20 proposing a simple extension to the ERO to allow path segments in = separate=20 ASs to remain confidential. There are indeed various circumstances = that=20 require "encoding" a path segment in some form. I've included the = abstract=20 below. Note that this ID may eventually be split to be discussed=20 separately in CCAMP and PCE but we prefer to start with a single = ID first=20 to be discussed in CCAMP.

 

Comments are very=20 welcome.

 

Thanks,

Rich

 

 

To:=20 i-d-announce@ietf.org

Subject:=20 I-D=20 ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt <= /P>

Reply-To:=20 internet-drafts@ietf.org

 

A New Internet-Draft is available from = the on-line=20 Internet-Drafts directories.

 

 

         =20 Title        &n= bsp;        =20 : Protocol Extensions for Signaling 

   =20                   =  =20   Confidential Path Segments in=20 Multiprotocol 

   =20                   =  =20   Label Switching Traffic=20 Engineering.

         =20 Author(s)        &n= bsp;=20 : R. Bradford, et al.

         =20 Filename        &n= bsp; =20 :=20 = draft-rbradfor-ccamp-confidential-segment-00.txt

         =20 Pages        &n= bsp;     =20 : 

         =20 Date        &n= bsp;       =20 : 2006-3-1

         =20

Routes for Multiprotocol Label Switching = (MPLS)=20 Label Switched Paths 

<= /DIV>

(LSPs) may be computed by Path = Computation=20 Elements (PCEs). Where the 

<= /DIV>

LSP crosses multiple domains such as = Autonomous=20 Systems (ASs) the 

<= /DIV>

path may be computed by multiple PCEs = that=20 cooperate, with each 

<= /DIV>

responsible for computing a segment of = the=20 path. 

<= /DIV>

 

However, in some cases such as when ASs = are=20 administered by separate 

<= /DIV>

Service Providers, it would break = confidentiality=20 rules for a PCE to 

<= /DIV>

supply a path segment to a PCE in = another domain.=20 This issue may be 

<= /DIV>

circumvented by returning a loose hop = and by=20 invoking a new path 

<= /DIV>

computation from the domain boundary LSR = during=20 LSP setup as the LSP 

<= /DIV>

enters the second domain, but this = technique has=20 several issues 

<= /DIV>

including the problem of maintaining = path=20 diversity. 

<= /DIV>

 

This document allows a PCE to provide a = full path,=20 but to hide the 

<= /DIV>

contents of a segment of that path = called the=20 Confidential Path 

<= /DIV>

Segment (CPS). The CPS may be conveyed = in the PCE=20 Communication 

<= /DIV>

Protocol (PCEP) and signaled in a = Resource=20 Reservation Protocol 

<= /DIV>

(RSVP) explicit route either by = replacing it with=20 a path key or by 

<= /DIV>

encrypting it. 

<= /DIV>

 

 

A URL for this Internet-Draft=20 is:

http://www.ietf.org/internet-drafts/draft-rbradfor-c= camp-confidential-segment-00.txt

 

To remove yourself from the I-D = Announcement list,=20 send a message to 

<= /DIV>

i-d-announce-request@ietf.o= rg=20 with the word unsubscribe in the body of the message.  

<= /DIV>

You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce 

<= /DIV>

to change your subscription=20 settings.

 

 

Internet-Drafts are also available by = anonymous=20 FTP. Login with the username

"anonymous" and a password of your = e-mail address.=20 After logging in,

type "cd internet-drafts" and=20 then

         =20 "get=20 = draft-rbradfor-ccamp-confidential-segment-00.txt".

 

A list of Internet-Drafts directories = can be found=20 in

http://www.ietf.org/shadow.html<= /A> 

<= /DIV>

or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

 

 

Internet-Drafts can also be obtained by=20 e-mail.

 

Send a message=20 to:

         =20 mailserv@ietf.org.

In the body=20 type:

         =20 "FILE=20 = /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt".<= /o:p>

         =20

NOTE:        &n= bsp; =20 The mail server at ietf.org can return the document=20 in

         =20 MIME-encoded form by using the "mpack" = utility.  To use = this

         =20 feature, insert the command "ENCODING mime" = before=20 the "FILE"

         =20 command. =20 To decode the response(s), you will need "munpack"=20 or

         =20 a MIME-compliant mail reader.  Different = MIME-compliant mail=20 readers

         =20 exhibit different behavior, especially when = dealing=20 with

         =20 "multipart" MIME messages (i.e. documents = which have=20 been split

         =20 up into multiple messages), so check your = local=20 documentation on

         =20 how to manipulate these=20 messages.

           &= nbsp;         =20

           &= nbsp;         =20

Below is the data which will enable a = MIME=20 compliant mail reader

implementation to automatically retrieve = the ASCII=20 version of the

Internet-Draft.

Content-Type:=20 text/plain

Content-ID: <2006-3-1103934.I-D@ietf.org>

 

_______________________________________________

I-D-Announce mailing=20 list

I-D-Announce@ietf.org

https://www1= .ietf.org/mailman/listinfo/i-d-announce

<= /DIV>

 

_______________________________________________
Pce=20 mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= o:p>

------_=_NextPart_001_01C64283.CCD2984B-- --===============1590547806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1590547806==-- From pce-bounces@lists.ietf.org Wed Mar 08 08:51:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz4Y-0000f1-ME; Wed, 08 Mar 2006 08:51:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz4X-0000ew-Bx for pce@ietf.org; Wed, 08 Mar 2006 08:51:25 -0500 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGz4W-0001hB-0q for pce@ietf.org; Wed, 08 Mar 2006 08:51:25 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k28DpMjb012275 for ; Wed, 8 Mar 2006 14:51:22 +0100 Received: from [172.25.80.62] ([172.25.80.62]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006030814512085:4048 ; Wed, 8 Mar 2006 14:51:20 +0100 Message-ID: <440EE15A.6060303@alcatel.fr> Date: Wed, 08 Mar 2006 14:51:22 +0100 From: Richard.Douville@alcatel.fr Organization: Alcatel User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pce@ietf.org Subject: [Pce] clarification on draft-ietf-pce-pcecp-01.txt X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/08/2006 14:51:20, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/08/2006 14:51:22, Serialize complete at 03/08/2006 14:51:22 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Dear authors, I noticed in part 7.3.2. "Handling of the RP object", that the line "If the C bit of the RP message carried within a PCReq message is set..." is confusing even if I think the C bit refer to the C bit of the optional METRIC object. Maybe a simple modification of that line can enhance the comprehension. Regards, Richard _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 08 08:53:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz6S-0002qv-6T; Wed, 08 Mar 2006 08:53:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz6Q-0002ql-Un for pce@ietf.org; Wed, 08 Mar 2006 08:53:22 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGz6P-0001oA-Lc for pce@ietf.org; Wed, 08 Mar 2006 08:53:22 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2006 05:53:21 -0800 X-IronPort-AV: i="4.02,175,1139212800"; d="scan'208"; a="413501865:sNHT31849224" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k28DrJH1001617; Wed, 8 Mar 2006 05:53:21 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 08:53:19 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 08:53:19 -0500 In-Reply-To: <440EE15A.6060303@alcatel.fr> References: <440EE15A.6060303@alcatel.fr> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] clarification on draft-ietf-pce-pcecp-01.txt Date: Wed, 8 Mar 2006 08:52:43 -0500 To: Richard.Douville@alcatel.fr X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 08 Mar 2006 13:53:19.0776 (UTC) FILETIME=[A85D1A00:01C642B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, On Mar 8, 2006, at 8:51 AM, Richard.Douville@alcatel.fr wrote: > Dear authors, > > I noticed in part 7.3.2. "Handling of the RP object", that the line > "If the C bit of the RP message carried within a PCReq message is > set..." is confusing even if I think the C bit refer to the C bit > of the optional METRIC object. Maybe a simple modification of that > line can enhance the comprehension. > Thanks Richard, this will be clarified in the next revision. JP. > Regards, > Richard > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 08 08:56:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz98-0006Qe-7y; Wed, 08 Mar 2006 08:56:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz97-0006Pw-7R for pce@ietf.org; Wed, 08 Mar 2006 08:56:09 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGz94-0001uo-OY for pce@ietf.org; Wed, 08 Mar 2006 08:56:09 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 08 Mar 2006 05:56:06 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k28Du27h014875 for ; Wed, 8 Mar 2006 05:56:06 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 08:56:05 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 08:56:04 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) To: pce@ietf.org Message-Id: <1C054AAE-F40F-40D0-AF1A-77201EFEF418@cisco.com> References: From: JP Vasseur Subject: Fwd: [Pce] I-D ACTION:draft-ietf-pce-pcep-01.txt Date: Wed, 8 Mar 2006 08:55:28 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 08 Mar 2006 13:56:04.0543 (UTC) FILETIME=[0A928CF0:01C642B8] X-Spam-Score: 2.1 (++) X-Scan-Signature: 27f32072baa9c4fb41949212e86ea6d2 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0793238747==" Errors-To: pce-bounces@lists.ietf.org --===============0793238747== Content-Type: multipart/alternative; boundary=Apple-Mail-17-310171001 --Apple-Mail-17-310171001 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, Just to inform you that a new revision of PCEP has been posted, with the following main changes: 1) We fixed a number of inconsistencies between MUST, MAY, ... + other semantic inconsistencies here and there, add new references to the application-specific requirement ID for reference, clarified the text in a number of places, clarified the notion of optional/ mandatory objects. 2) The ID has been restructured a little bit: the Elements of Procedure related to several objects were defined in a separate section 9, making the ID not easily readable. 3) Appendix A has been removed since it was essentially useful during the protocol selection process. Some substantial changes ******************************* 1) We had introduced two modes: permanent versus per-request. We actually do not need to specify this and negotiate the mode upon session establishment. If the PCC desires to use a per-request mode and establishes a new PCEP session on a per-request basis, this is by default supported. So we updated the ID accordingly. 3) Close message + CLOSE Object added. 4) We added a Deadtimer field in the Open message rather than fixing the Deadtimer to x times the Keepalive since this might be quite useful in several circumstances. 5) The PCEP Session establishment phase with parameter negotiation has been updated. Now a PCEP peer can propose alternative PCEP session characteristics value by including an OPEN message in PCErr. Note that this is also reflected in the FSM. 6) The DELAY object has been removed. A new object (more generic) and named the METRIC object has been defined that can be used within a PCReq to specify the metric that should be optimized and also a bound (optionally) and in a PCRep to indicate the computed path metric. This introduces a new more flexible logic (C bit of the RP object has been removed). 7) The logic of the P-flag and I-Flag (in common header) has been rewritten. 8) The structure of the OPEN object has been changed (reduced). R- flag removed. 9) NO-PATH object: section has been reworded for the sake of clarity. Ability to suggest a value instead of just reporting the unsatisfied constraint. Example added. 10) We clarified that the IP address in the END-POINTS object does not have to be the source/destination addresses of the TE LSP since this was discussed on the list. 11) SVEC object: added to ability to send synchronized path computations in multiple PCReq messages (new PCEP variable added). 12) The B and N bits of the LSPA object have been removed. 13) PCRep message structure has been updated Of course, comments are more than welcome ! Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 3, 2006 6:50:02 PM EST > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working > Group of the IETF. > > Title : Path Computation Element (PCE) communication > Protocol (PCEP) - Version 1 > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-pce-pcep-01.txt > Pages : 57 > Date : 2006-3-3 > > This document specifies the Path Computation Element communication > Protocol (PCEP) for communications between a Path Computation > Client > (PCC) and a Path Computation Element (PCE), or between two PCEs. > Such interactions include path computation requests and path > computation replies as well as notifications of specific states > related to the use of a PCE in the context of MPLS and GMPLS > Traffic > Engineering. The PCEP protocol is designed to be flexible and > extensible so as to easily allow for the addition of further > messages > and objects, should further requirements be expressed in the > future. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pce-pcep-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pce-pcep-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-3-3162457.I-D@ietf.org> > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-17-310171001 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Dear WG,

Just to inform you that a = new revision of PCEP has been posted, with the following main = changes:

1) We fixed a number of inconsistencies between = MUST, MAY, ... + other semantic inconsistencies here and there, add new = references to the application-specific requirement ID for reference, = clarified the text in a number of places, clarified the notion of = optional/mandatory objects.
2) The ID has = been restructured a little bit: the Elements of Procedure related to = several objects were defined in a separate section 9, making the ID not = easily readable.=A0
3) Appendix A has been = removed since it was essentially useful during the protocol selection = process.

Some = substantial changes

1) We had introduced two modes: permanent versus = per-request. We actually do not need to specify this and negotiate the = mode upon session establishment. If the PCC desires to use a per-request = mode and establishes a new PCEP session on a per-request basis, this is = by default supported. So we updated the ID accordingly.=A0

3) Close message + CLOSE Object added.

4) We added a = Deadtimer field in the Open message rather than fixing the Deadtimer to = x times the Keepalive since this might be quite useful in several = circumstances.

5) The = PCEP Session establishment phase with parameter negotiation has been = updated. Now a PCEP peer can propose alternative PCEP session = characteristics value by including an OPEN message in PCErr. Note that = this is also reflected in the FSM.

6) The DELAY object has been removed. A new object = (more generic) and named the METRIC object has been defined that can be = used within a PCReq to specify the metric that should be optimized and = also a bound (optionally) and in a PCRep to indicate the computed path = metric. This introduces a new more flexible logic (C bit of the RP = object has been removed).

7) The logic of the P-flag and I-Flag (in common = header) has been rewritten.

8) The structure of the OPEN object has been changed = (reduced). R-flag removed.

9) NO-PATH object: section has been reworded for the = sake of clarity. Ability to suggest a value instead of just reporting = the unsatisfied constraint. Example added.
10) We clarified that the IP = address in the END-POINTS object does not have to be the = source/destination addresses of the TE LSP since this was discussed on = the list.

11) = SVEC object: added to ability to send=A0synchronized path computations = in multiple PCReq messages (new PCEP variable added).

12) The B and N bits of the LSPA object have been = removed.

13) PCRep = message=A0structure has been updated

Of course, = comments are more than welcome !


Date: March 3, 2006 6:50:02 PM = EST
To: i-d-announce@ietf.org
Subject: = [Pce] I-D ACTION:draft-ietf-pce-pcep-01.txt=A0

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the = Path Computation Element Working Group of the IETF.

= Title = = : Path Computation Element (PCE) communication=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Protocol (PCEP) - Version 1
Author(s) : J. = Vasseur, et al.
Filename : = draft-ietf-pce-pcep-01.txt
= Pages = = : 57
Date : 2006-3-3


This document = specifies the Path Computation Element communication
=A0=A0 = Protocol (PCEP) for communications between a Path Computation = Client
=A0=A0 (PCC) and a Path = Computation Element (PCE), or between two PCEs.
=A0=A0 = Such interactions include path computation requests and = path
=A0=A0 computation replies as = well as notifications of specific states
=A0=A0 related to the use of a = PCE in the context of MPLS and GMPLS Traffic
=A0=A0 = Engineering.=A0 The = PCEP protocol is designed to be flexible and
=A0=A0 = extensible so as to easily allow for the addition of further = messages
=A0=A0 and objects, should = further requirements be expressed in the future.

A URL = for this Internet-Draft is:

To = remove yourself from the I-D Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of the message. =A0
to = change your subscription settings.


Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" = and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get = draft-ietf-pce-pcep-01.txt".

A list of Internet-Drafts = directories can be found in

Internet-Drafts can also be obtained by = e-mail.

Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-pce-pcep-01.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

= =


Below is the = data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.
Content-Type: text/plain


= --Apple-Mail-17-310171001-- --===============0793238747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0793238747==-- From pce-bounces@lists.ietf.org Wed Mar 08 09:29:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzfq-0002D0-K8; Wed, 08 Mar 2006 09:29:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzfo-0002Cv-OK for pce@ietf.org; Wed, 08 Mar 2006 09:29:56 -0500 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGzfo-0003MO-Af for pce@ietf.org; Wed, 08 Mar 2006 09:29:56 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k28ETojb030367; Wed, 8 Mar 2006 15:29:50 +0100 Received: from [172.25.80.62] ([172.25.80.62]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006030815294806:4361 ; Wed, 8 Mar 2006 15:29:48 +0100 Message-ID: <440EEA5F.3070702@alcatel.fr> Date: Wed, 08 Mar 2006 15:29:51 +0100 From: Richard.Douville@alcatel.fr Organization: Alcatel User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] clarification on draft-ietf-pce-pcecp-01.txt References: <440EE15A.6060303@alcatel.fr> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/08/2006 15:29:48, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/08/2006 15:29:49, Serialize complete at 03/08/2006 15:29:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Thanks, I forget also to ask you how in a PCReq the PCE can distinguish between the two BANDWIDTH Objects which one represent the existing LSP and the other one the requested bandwidth ? JP Vasseur wrote: > Hi, > > On Mar 8, 2006, at 8:51 AM, Richard.Douville@alcatel.fr wrote: > >> Dear authors, >> >> I noticed in part 7.3.2. "Handling of the RP object", that the line >> "If the C bit of the RP message carried within a PCReq message is >> set..." is confusing even if I think the C bit refer to the C bit of >> the optional METRIC object. Maybe a simple modification of that line >> can enhance the comprehension. >> > > Thanks Richard, this will be clarified in the next revision. > > JP. > >> Regards, >> Richard >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce > > -- Richard Douville Alcatel Research & Innovation Center System and Architecture of Transport Networks, SART Route de Nozay F-91460 Marcoussis, France. Phone : 33 1.69.63.44.31 Fax : 33 1.69.63.18.65 Email : Richard.Douville@alcatel.fr _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 08 09:36:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzlp-0004z2-Bw; Wed, 08 Mar 2006 09:36:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzln-0004q1-JU for pce@ietf.org; Wed, 08 Mar 2006 09:36:07 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGzln-0003aD-9q for pce@ietf.org; Wed, 08 Mar 2006 09:36:07 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2006 06:36:07 -0800 X-IronPort-AV: i="4.02,175,1139212800"; d="scan'208"; a="312592786:sNHT31970620" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k28Ea6Gv013653; Wed, 8 Mar 2006 06:36:06 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 09:36:04 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 09:36:03 -0500 In-Reply-To: <440EEA5F.3070702@alcatel.fr> References: <440EE15A.6060303@alcatel.fr> <440EEA5F.3070702@alcatel.fr> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B36D34A-CD71-4C50-BD60-728563F44DD5@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] clarification on draft-ietf-pce-pcecp-01.txt Date: Wed, 8 Mar 2006 09:35:27 -0500 To: Richard.Douville@alcatel.fr X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 08 Mar 2006 14:36:03.0808 (UTC) FILETIME=[A0A55600:01C642BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org On Mar 8, 2006, at 9:29 AM, Richard.Douville@alcatel.fr wrote: > Thanks, > > I forget also to ask you how in a PCReq the PCE can distinguish > between the two BANDWIDTH Objects which one represent the existing > LSP and the other one the requested bandwidth ? > They have different Object-Type: Two Object-Type are defined for the BANDWIDTH object: o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by IANA (recommended value=1) o Bandwidth of an existing TE LSP for which a reoptimization is performed. BANDWIDTH Object-Type is to be assigned by IANA (recommended value=2) JP. > JP Vasseur wrote: >> Hi, >> On Mar 8, 2006, at 8:51 AM, Richard.Douville@alcatel.fr wrote: >>> Dear authors, >>> >>> I noticed in part 7.3.2. "Handling of the RP object", that the >>> line "If the C bit of the RP message carried within a PCReq >>> message is set..." is confusing even if I think the C bit refer >>> to the C bit of the optional METRIC object. Maybe a simple >>> modification of that line can enhance the comprehension. >>> >> Thanks Richard, this will be clarified in the next revision. >> JP. >>> Regards, >>> Richard >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce > > -- > Richard Douville > > Alcatel Research & Innovation Center > System and Architecture of Transport Networks, SART > Route de Nozay > F-91460 Marcoussis, France. > > Phone : 33 1.69.63.44.31 > Fax : 33 1.69.63.18.65 > Email : Richard.Douville@alcatel.fr _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 09 08:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKmu-0005lf-35; Thu, 09 Mar 2006 08:02:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKms-0005la-FP for pce@ietf.org; Thu, 09 Mar 2006 08:02:38 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKms-0000om-22 for pce@ietf.org; Thu, 09 Mar 2006 08:02:38 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 14:02:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-igp-01.txt Date: Thu, 9 Mar 2006 14:02:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-igp-01.txt Thread-Index: AcZA/yy6Ei5YlicrSL+idAZJEamHpwCagFug From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 09 Mar 2006 13:02:36.0473 (UTC) FILETIME=[BCD3AA90:01C64379] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi all, Here are the major changes in this new revision of the IGP-based PCE = discovery ID: -Clarified the definition and applicability of PCE preferences (in the PATH-SCOPE TLV). -Added protocol elements and procedures for discovery of PCE Congestion = Status. A new TLV is defined, the PCES (PCE Status) TLV to be carried = within the ISIS Cap TLV and OSPF RI LSA. It allows advertising when a = PCE enters or leaves a processing congestion state. Procedures to avoid = any impact on the IGP scalability (dampening, hysterisis, congestion = duration) are discussed. -Some rewordings for the sake of clarity -Added a new co-author Your comments on this new revision are required. Regards, JL > -----Message d'origine----- > De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Envoy=E9 : lundi 6 mars 2006 08:50 > =C0 : i-d-announce@ietf.org > Cc : pce@ietf.org > Objet : [Pce] I-D ACTION:draft-ietf-pce-disco-proto-igp-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Path Computation Element=20 > Working Group of the IETF. >=20 > Title : IGP protocol extensions for Path=20 > Computation Element (PCE) Discovery > Author(s) : J. Le Roux, et al. > Filename : draft-ietf-pce-disco-proto-igp-01.txt > Pages : 32 > Date : 2006-3-5 > =09 > There are various circumstances in which it is highly=20 > desirable for a Path Computation Client (PCC) to be able to=20 > dynamically and automatically discover a set of Path=20 > Computation Element(s) (PCE), along with some of information=20 > that can used for PCE selection. When the PCE is an LSR=20 > participating to the IGP, or even a server participating=20 > passively to the IGP, a simple and efficient way for PCE=20 > discovery consists of relying on IGP flooding. For that=20 > purpose this document defines OSPF and ISIS extensions for=20 > the advertisement of PCE Discovery information within an IGP=20 > area or the entire routing domain. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto > -igp-01.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-pce-disco-proto-igp-01.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pce-disco-proto-igp-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Mar 11 07:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI3T2-0007Ra-Tp; Sat, 11 Mar 2006 07:45:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI3T1-0007RJ-Ty; Sat, 11 Mar 2006 07:45:07 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FI3T0-0003KX-JW; Sat, 11 Mar 2006 07:45:07 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 11 Mar 2006 04:45:06 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2BCj57T027788; Sat, 11 Mar 2006 04:45:05 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Mar 2006 07:45:04 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Mar 2006 07:45:04 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Sat, 11 Mar 2006 07:44:25 -0500 To: Alex Zinin , Bill Fenner X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 11 Mar 2006 12:45:04.0179 (UTC) FILETIME=[9E6FD830:01C64509] X-Spam-Score: 1.8 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: pce@ietf.org, iesg@ietf.org Subject: [Pce] Publication Request: draft-ietf-pce-discovery-reqs-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, draft-ietf-pce-discovery-reqs-03.txt has completed Working Group Last Call and is now ready according to the WG chairs' judgement. Please consider it for publication as an Informational RFC. Thanks, JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Mar 13 09:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoKq-0001Ke-KT; Mon, 13 Mar 2006 09:47:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoKp-0001KU-Fx for pce@ietf.org; Mon, 13 Mar 2006 09:47:47 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIoKo-0000G2-4s for pce@ietf.org; Mon, 13 Mar 2006 09:47:47 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Mar 2006 09:47:46 -0500 X-IronPort-AV: i="4.02,187,1139202000"; d="scan'208,217"; a="83998781:sNHT49800316" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2DEljVU020465 for ; Mon, 13 Mar 2006 09:47:45 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 09:47:45 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 09:47:45 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) To: pce@ietf.org Message-Id: References: From: JP Vasseur Date: Mon, 13 Mar 2006 09:47:07 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 13 Mar 2006 14:47:45.0302 (UTC) FILETIME=[16D59360:01C646AD] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Subject: [Pce] PCE WG Agenda and slides X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0198755829==" Errors-To: pce-bounces@lists.ietf.org --===============0198755829== Content-Type: multipart/alternative; boundary=Apple-Mail-20-745270010 --Apple-Mail-20-745270010 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, Final revision of the PCE WG agenda has been published: https:// datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Thanks to send us your slides say before this Thursday so that we can publish them before the meeting. Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: February 28, 2006 12:40:46 PM EST > To: pce@ietf.org > Cc: Adrian Farrel > Subject: Draft PCE WG Agenda > > Hi, > > A draft agenda for our next PCE WG meeting in Dallas can be found > in: https://datatracker.ietf.org/public/meeting_materials.cgi? > meeting_num=65 > > Please let us know if you have any comment. > > Moreover, thanks for sending your slides by March the 12th so that > we could publish them prior to the meeting. > > And the usual note ... please focus on the issues to be discussed > during the meeting, no presentation please. > > Thanks. > > JP. --Apple-Mail-20-745270010 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear WG,

Final revision of the PCE = WG agenda has been published:=A0https://datatracker.ietf.org/public/meeting_materials.cgi?meetin= g_num=3D65

Thanks to send us your = slides say before this Thursday so that we can publish them before the = meeting.

Thanks.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = February 28, 2006 12:40:46 PM EST
Cc: Adrian = Farrel <adrian@olddog.co.uk>
Subject: = Draft PCE WG Agenda


A draft agenda for our next PCE WG meeting in Dallas = can be found in: https://datatracker.ietf.org/public/meeting_materials.cgi?meetin= g_num=3D65

Please let us know if you have any = comment.

Moreover, thanks for sending your slides by March = the 12th so that we could publish them prior to the meeting.

And the = usual note ... please focus on the issues to be discussed during the = meeting, no presentation please.

Thanks.

; Fri, 17 Mar 2006 09:51:07 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Mar 2006 09:51:07 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Mar 2006 09:51:07 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <4014F1CF-6BAE-48A5-89C5-91E3F68B87C6@cisco.com> Content-Type: text/plain To: pce@ietf.org From: JP Vasseur Date: Fri, 17 Mar 2006 09:50:30 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 17 Mar 2006 14:51:07.0215 (UTC) FILETIME=[38D60DF0:01C649D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Cc: Subject: [Pce] Please send your slides. Many thanks. X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Mar 21 08:37:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLh30-00007B-NS; Tue, 21 Mar 2006 08:37:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLh2z-00005r-9N for pce@ietf.org; Tue, 21 Mar 2006 08:37:17 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLh2y-00085K-2R for pce@ietf.org; Tue, 21 Mar 2006 08:37:17 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 21 Mar 2006 08:37:16 -0500 X-IronPort-AV: i="4.03,114,1141621200"; d="scan'208"; a="84602718:sNHT26580032" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2LDbFVU018203 for ; Tue, 21 Mar 2006 08:37:15 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 08:37:15 -0500 Received: from [204.96.114.155] ([10.82.208.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 08:37:15 -0500 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <31026BF2-E105-4B13-B700-4FDDD674B88B@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Tue, 21 Mar 2006 07:36:40 -0600 X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 21 Mar 2006 13:37:15.0298 (UTC) FILETIME=[90DC3020:01C64CEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Pce] PCE WG meeting - slides available X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, All slides presented during the WG meeting yesterday are on-line: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Draft minutes will follow shortly. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce