From pce-bounces@lists.ietf.org Sun Jul 02 22:47:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxESr-00086q-TD; Sun, 02 Jul 2006 22:47:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxESq-00086l-FA for pce@ietf.org; Sun, 02 Jul 2006 22:47:08 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxESn-0002AM-CC for pce@ietf.org; Sun, 02 Jul 2006 22:47:08 -0400 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.13.7/8.13.7) with ESMTP id k632kY4Y014162; Mon, 3 Jul 2006 11:46:34 +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.13.7/8.13.7) with ESMTP id k632kXEK004628; Mon, 3 Jul 2006 11:46:33 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k632kWvs024739; Mon, 3 Jul 2006 11:46:32 +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.13.7/8.13.7) with ESMTP id k632kWfw008881; Mon, 3 Jul 2006 11:46:32 +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 k632kWGW007569; Mon, 3 Jul 2006 11:46:32 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k632kVsW007563; Mon, 3 Jul 2006 11:46:31 +0900 (JST) Received: from [129.60.80.109] ([129.60.80.109]) by imb.m.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k632kUMs019737; Mon, 3 Jul 2006 11:46:31 +0900 (JST) Date: Mon, 03 Jul 2006 11:46:29 +0900 From: Eiji Oki To: Dimitri.Papadimitriou@alcatel.be Subject: Re: [Pce] on draft-oki-pce-vntm-def-00.txt In-Reply-To: References: Message-Id: <20060703114238.D3D9.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: 21c69d3cfc2dd19218717dbe1d974352 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, Thank you for your comments. On Wed, 28 Jun 2006 09:23:06 +0200 Dimitri.Papadimitriou@alcatel.be wrote: > folks > > reading this document the vnt functionality communicates with the pce; > nevertheless it seems the operations the former allows are setup/triggers > (note that the triggers are not exclusively coming from a pce/going toward > a pce as the draft indicates, a simple lsr with could do the job), > resource/ advertisement policing, etc. i.e. functions that are stricto > sensu decoupled from pce ... hence shouldn't this document be not Yes, that is correct. The VNT Manager's job is to manage the VNT. This does not require PCE to be used to provide the trigger/notification and it does not require PCE to be used to compute paths in the lower layer network. > discussed in the context of the ccamp wg (as a vnt operations are > independent of the presence of a pce, presence of the latter wrt to vnt is > similar to the presence of a pce wrt to lsrs) ? > It is not our intention in this draft to provide a full framework and definition for VNT Manager. Instead, as the title of the draft shows, we want to define VNT manager for use in the PCE context. We would be happy to work with you on another draft to provide a definition of VNT manager with a wider scope. Thank you. Eiji > thanks, > - dimitri. > > _______________________________________________ > 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 Jul 03 03:37:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxIzZ-0000kD-V6; Mon, 03 Jul 2006 03:37:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxIzY-0000k6-CI for pce@ietf.org; Mon, 03 Jul 2006 03:37:12 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxIzW-0007Bi-TX for pce@ietf.org; Mon, 03 Jul 2006 03:37:12 -0400 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-3sarge1) with ESMTP id k637b9eB015238; Mon, 3 Jul 2006 09:37:10 +0200 In-Reply-To: <20060703114238.D3D9.OKI.EIJI@lab.ntt.co.jp> To: Eiji Oki Subject: Re: [Pce] on draft-oki-pce-vntm-def-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 3 Jul 2006 09:37:07 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/03/2006 09:37:08, Serialize complete at 07/03/2006 09:37:08 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 i understand your standpoint but this requires for me a broader discussion if i follow your reasoning considering that a VNT is a centralized control point, if PCE would have been there six years ago we would have had also two definitions of GMPLS (controller): one in a restricted scope of PCE, and one in a larger scope in the CCAMP context my question thus to you is "are you specializing the VNT functionality when running with a PCE or not" ? much thanks, - dimitri. Eiji Oki 03/07/2006 04:46 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: pce@ietf.org Subject: Re: [Pce] on draft-oki-pce-vntm-def-00.txt Hi Dimitri, Thank you for your comments. On Wed, 28 Jun 2006 09:23:06 +0200 Dimitri.Papadimitriou@alcatel.be wrote: > folks > > reading this document the vnt functionality communicates with the pce; > nevertheless it seems the operations the former allows are setup/triggers > (note that the triggers are not exclusively coming from a pce/going toward > a pce as the draft indicates, a simple lsr with could do the job), > resource/ advertisement policing, etc. i.e. functions that are stricto > sensu decoupled from pce ... hence shouldn't this document be not Yes, that is correct. The VNT Manager's job is to manage the VNT. This does not require PCE to be used to provide the trigger/notification and it does not require PCE to be used to compute paths in the lower layer network. > discussed in the context of the ccamp wg (as a vnt operations are > independent of the presence of a pce, presence of the latter wrt to vnt is > similar to the presence of a pce wrt to lsrs) ? > It is not our intention in this draft to provide a full framework and definition for VNT Manager. Instead, as the title of the draft shows, we want to define VNT manager for use in the PCE context. We would be happy to work with you on another draft to provide a definition of VNT manager with a wider scope. Thank you. Eiji > thanks, > - dimitri. > > _______________________________________________ > 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 Mon Jul 03 10:00:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOyi-0004nC-G5; Mon, 03 Jul 2006 10:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOyh-0004n6-A4 for pce@ietf.org; Mon, 03 Jul 2006 10:00:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxOSs-0002ut-Da for pce@ietf.org; Mon, 03 Jul 2006 09:27:50 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FxOE4-0004lL-Kn for pce@ietf.org; Mon, 03 Jul 2006 09:12:35 -0400 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.13.7/8.13.7) with ESMTP id k63DCIC3014074; Mon, 3 Jul 2006 22:12:18 +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.13.7/8.13.7) with ESMTP id k63DCG2c007330; Mon, 3 Jul 2006 22:12:16 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k63DCEd3023108; Mon, 3 Jul 2006 22:12:14 +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.13.7/8.13.7) with ESMTP id k63DCEw5007503; Mon, 3 Jul 2006 22:12:14 +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 k63DCDxl015769; Mon, 3 Jul 2006 22:12:13 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k63DCDoq015764; Mon, 3 Jul 2006 22:12:13 +0900 (JST) Received: from [129.60.80.109] ([129.60.80.109]) by imb.m.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k63DCAR1028621; Mon, 3 Jul 2006 22:12:13 +0900 (JST) Date: Mon, 03 Jul 2006 22:12:09 +0900 From: Eiji Oki To: Dimitri.Papadimitriou@alcatel.be Subject: Re: [Pce] on draft-oki-pce-vntm-def-00.txt In-Reply-To: References: <20060703114238.D3D9.OKI.EIJI@lab.ntt.co.jp> Message-Id: <20060703221016.7C1F.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: -2.6 (--) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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, Please see inline. On Mon, 3 Jul 2006 09:37:07 +0200 Dimitri.Papadimitriou@alcatel.be wrote: > hi eiji > > i understand your standpoint but this requires for me a broader discussion > > if i follow your reasoning considering that a VNT is a centralized control > point, if PCE would have been there six years ago we would have had also > two definitions of GMPLS (controller): one in a restricted scope of PCE, > and > one in a larger scope in the CCAMP context I see your point. > > my question thus to you is "are you specializing the VNT functionality > when > running with a PCE or not" ? > Yes. We try to descirbe VNT manager functionality when PCE is involved. Thank you. Eiji > much thanks, > - dimitri. > > > > > > Eiji Oki > 03/07/2006 04:46 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: pce@ietf.org > Subject: Re: [Pce] on draft-oki-pce-vntm-def-00.txt > > > Hi Dimitri, > > Thank you for your comments. > > On Wed, 28 Jun 2006 09:23:06 +0200 > Dimitri.Papadimitriou@alcatel.be wrote: > > > folks > > > > reading this document the vnt functionality communicates with the pce; > > nevertheless it seems the operations the former allows are > setup/triggers > > (note that the triggers are not exclusively coming from a pce/going > toward > > a pce as the draft indicates, a simple lsr with could do the job), > > resource/ advertisement policing, etc. i.e. functions that are stricto > > sensu decoupled from pce ... hence shouldn't this document be not > > Yes, that is correct. The VNT Manager's job is to manage the VNT. This > does not require PCE to be used to provide the trigger/notification and > it does not require PCE to be used to compute paths in the lower layer > network. > > > discussed in the context of the ccamp wg (as a vnt operations are > > independent of the presence of a pce, presence of the latter wrt to vnt > is > > similar to the presence of a pce wrt to lsrs) ? > > > > It is not our intention in this draft to provide a full framework and > definition for VNT Manager. Instead, as the title of the draft shows, we > want to define VNT manager for use in the PCE context. > > We would be happy to work with you on another draft to provide a > definition of VNT manager with a wider scope. > > Thank you. > Eiji > > > thanks, > > - dimitri. > > > > _______________________________________________ > > 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 Mon Jul 03 11:08:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQ2W-00056J-B3; Mon, 03 Jul 2006 11:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQ2V-00056E-0X for pce@ietf.org; Mon, 03 Jul 2006 11:08:43 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQ2U-0004uq-JD for pce@ietf.org; Mon, 03 Jul 2006 11:08:42 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 17:08:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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-pcecp-interarea-reqs-02.txt Date: Mon, 3 Jul 2006 17:08:34 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-02.txt Thread-Index: AcabFd7GLynwKcd9TrmYwm7Q/DnjIwDmqMQQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 03 Jul 2006 15:08:41.0003 (UTC) FILETIME=[918E57B0:01C69EB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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, There are no major changes in this new version. As required in Dallas, authors of this draft and authors of the policy = framework draft discussed together to see whether the inter-area path = computation application had an impact on the policy framework and = whether there were additional policy requirements for the PCECP. It = resulted that no new element needs to be added in this requirement = draft. But we reformulated the policy section (section 5.7) to clarify = the requirements. We are waiting for your comments on this new version. Best Regards, JL > -----Message d'origine----- > De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Envoy=E9 : jeudi 29 juin 2006 00:50 > =C0 : i-d-announce@ietf.org > Cc : pce@ietf.org > Objet : [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-02.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 : PCE Communication Protocol (PCECP)=20 > Specific Requirements for Inter-Area (G)MPLS Traffic Engineering > Author(s) : J. Le Roux > Filename : draft-ietf-pce-pcecp-interarea-reqs-02.txt > Pages : 10 > Date : 2006-6-28 > =09 > For scalability purposes a network may comprise multiple IGP areas.=20 > An inter-area TE-LSP is an LSP that transits through at least=20 > two IGP areas. In a multi-area network, topology visibility=20 > remains local to a given area, and a head-end LSR cannot=20 > compute alone an inter-area shortest constrained path. One=20 > key application of the Path Computation Element (PCE) based=20 > architecture is the computation of inter-area TE-LSP paths.=20 > This document lists a detailed set of PCE Communication=20 > Protocol (PCECP) specific requirements for support of=20 > inter-area TE-LSP path computation. It complements generic=20 > requirements for a PCE Communication Protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-inter > area-reqs-02.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-pcecp-interarea-reqs-02.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=20 > /internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-02.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 Mon Jul 03 11:30:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQNz-0006Ie-RA; Mon, 03 Jul 2006 11:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQNy-0006AL-9n for pce@ietf.org; Mon, 03 Jul 2006 11:30:54 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQNx-0005V9-Rf for pce@ietf.org; Mon, 03 Jul 2006 11:30:54 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 17:30:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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-02.txt Date: Mon, 3 Jul 2006 17:30:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-igp-02.txt Thread-Index: AcaaLi0x9wMlLMtPTk2rHihkEYznWAEhGs4Q From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 03 Jul 2006 15:30:51.0421 (UTC) FILETIME=[AA8C04D0:01C69EB5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 version: -A new bit in the path computation capabilities flag has been defined: = The P bit that indicates whether the PCE can handle path constraints = (e.g. max hop count, path metric bound). -Three optional sub-TLVs for the PATH-COMP-CAP TLV defined to encode = more complex capabilities: The Objective Functions sub-TLV that carries = a list of supported objective functions, the Opaque Objective Function = sub-TLV that allows the user to encode a specific=20 objective function in any appropriate language, and the Switch Caps = sub-TLV that carries a list of supported switching capabilities.=20 -OSPFv3 procedures added (scope control with S1/S2 bits) -The text related to the procedures to limit the impact on the IGP = (dampening, hysteresis) has been updated, it is now normative (SHOULD) = as requested in Dallas. -Procedures for the PCE address TLV have been clarified: This TLV MUST = be carried either once (v4 or V6) or twice (v4 & v6) within the PCED = TLV. -Removed PCED/PCES redundant elements of procedures. -Also some edits for the sake of clarity. We are waiting for your comments on this new version. Regards, JL=20 > -----Message d'origine----- > De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Envoy=E9 : mardi 27 juin 2006 21:50 > =C0 : i-d-announce@ietf.org > Cc : pce@ietf.org > Objet : [Pce] I-D ACTION:draft-ietf-pce-disco-proto-igp-02.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-02.txt > Pages : 37 > Date : 2006-6-27 > =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 be used for PCE selection.=20 > When the PCE is an LSR participating to the IGP, or even a=20 > server participating passively to the IGP, a simple and=20 > efficient way for PCE discovery consists of relying on IGP=20 > flooding. For that purpose this document defines OSPF and=20 > ISIS extensions for the advertisement of PCE Discovery=20 > information within an IGP area or within the entire routing domain. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto > -igp-02.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-02.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-02.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 Tue Jul 04 10:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxmEX-0007ot-VD; Tue, 04 Jul 2006 10:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxmEW-0007on-PP for pce@ietf.org; Tue, 04 Jul 2006 10:50:36 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxmEW-0000x1-Cx for pce@ietf.org; Tue, 04 Jul 2006 10:50:36 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Jul 2006 07:21:47 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,204,1149490800"; d="scan'208,217"; a="31082970:sNHT42112300" 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 k64ELkno020050; Tue, 4 Jul 2006 10:21:46 -0400 (EDT) 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, 4 Jul 2006 10:21:46 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jul 2006 10:21:46 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <3622DA6E-6673-44A8-A58D-F7C58CACBC89@cisco.com> From: JP Vasseur Date: Tue, 4 Jul 2006 10:21:43 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Jul 2006 14:21:46.0107 (UTC) FILETIME=[2E290CB0:01C69F75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com Subject: [Pce] Resolution of comments raised on the list on the BRPC procedure 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="===============1268187889==" Errors-To: pce-bounces@lists.ietf.org --===============1268187889== Content-Type: multipart/alternative; boundary=Apple-Mail-8--230472121 --Apple-Mail-8--230472121 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, We just wanted to make a quick summary of where we stand with the BRPC procedure ID. Since Dallas, we received a number of comments that have been addressed in the latest revision of the BRPC ID (rev -01). Special thanks again to Adrian for the detailed review. Since then, we have received new comments for which we managed to quickly find a resolution. They will be addressed in the next revision posted next week (rev -02). Main changes are summarized below. * Abstract The ability to compute constrained shortest Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. * Step i: - For i=n-1 to 2: PCE(i) concatenates the topology of domain (i) (using its TED) with the received VSPT(i+1). In the case of Inter-AS TE LSP computation, this requires to also add the inter-AS TE links connecting the domain (i) to the domain (i+1). Then PCE(i) computes VSPT(i) (P2MP tree made of the shortest constrained paths between each BN-en(j,i) and the TE LSP destination). We also agreed to cover the following items in a further revision: * Support of Bi-directional LSP support * Manageability section * More on path diversity and ECMPs Thanks. JP, Nabil, Raymond and Jean-Louis. --Apple-Mail-8--230472121 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Dear = WG,

We just = wanted to make a quick summary of where we stand with the BRPC procedure = ID.

Since Dallas, = we received a number of comments that have been addressed in the latest = revision of the BRPC ID (rev -01). Special thanks again to Adrian for = the detailed review. Since then, we have received new comments for which = we managed to quickly find a resolution. They will be addressed in the = next revision posted next week (rev -02). Main changes are summarized = below.

* Abstract

=A0=A0 The ability to compute constrained = shortest Traffic Engineering (TE)
=A0=A0 = Label Switched Paths (LSPs) in Multiprotocol Label Switching = (MPLS)
=A0=A0 and Generalized MPLS = (GMPLS) networks across multiple domains (where
=A0=A0 a domain is referred to as a collection of = network elements within a
=A0=A0 = common sphere of address management or path computational
=A0=A0 responsibility such as IGP areas and = Autonomous Systems) has been
=A0=A0 = identified as a key requirement .=A0 This document specifies = a
=A0=A0 procedure relying on = the use of multiple Path Computation Elements
=A0=A0 (PCEs) in order to compute such = inter-domain shortest constraint
=A0=A0 paths along a determined = sequence of domains, using a backward
=A0=A0 recursive path computation technique while = preserving confidentiality
=A0=A0 = across domains, which is sometimes required when domains = are
=A0=A0 managed by different = Service Providers.
* Step i:

=A0=A0 - For i=3Dn-1 to 2:

=A0=A0 PCE(i) concatenates the topology of domain = (i) (using its TED)
=A0=A0 = with the received VSPT(i+1). In the case of Inter-AS TE = LSP
=A0=A0 computation, this = requires to also add the inter-AS TE links
=A0=A0 connecting the domain (i) to the domain = (i+1).
=A0=A0 Then PCE(i) computes = VSPT(i) (P2MP tree made of the shortest
=A0=A0= constrained paths between each BN-en(j,i) and the TE LSP = destination).

We also agreed to cover the = following items in a further revision:

* = Support of=A0Bi-directional LSP support
*=A0Manageability = section
* More on=A0path diversity and ECMPs

Thanks.

JP, Nabil, Raymond and = Jean-Louis.



= --Apple-Mail-8--230472121-- --===============1268187889== 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 --===============1268187889==-- From pce-bounces@lists.ietf.org Wed Jul 05 11:42:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9WA-0004dL-0K; Wed, 05 Jul 2006 11:42:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9W9-0004cv-0W; Wed, 05 Jul 2006 11:42:21 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8y2-0002nj-PW; Wed, 05 Jul 2006 11:07:06 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy8Xe-0002KX-S2; Wed, 05 Jul 2006 10:39:52 -0400 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 k65Ecnjx005658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Jul 2006 14:38:49 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fy8Wf-00038O-Bp; Wed, 05 Jul 2006 10:38:49 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 05 Jul 2006 10:38:49 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Internet Architecture Board , pce mailing list , pce chair , RFC Editor Subject: [Pce] Document Action: 'Requirements for Path Computation Element (PCE) Discovery' to Informational RFC 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 IESG has approved the following document: - 'Requirements for Path Computation Element (PCE) Discovery ' as an Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-05.txt Technical Summary This document specifies a set of requirements for a path computation element discovery mechanism that allow a path computation client to discover dynamically and automatically a set of PCEs along with information relevant to PCE selection. Working Group Summary No dissent. Protocol Quality Ross Callon reviewed this for the IESG, and sent a very short list of comments to the authors who have updated the draft accordingly (the list of changes is very short). The document was subsequently updated based on IESG comments. Note to RFC Editor none IESG Note The most recent update includes responses to IESG DISCUSS comments. IANA Note No IANA implications. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 05 18:01:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFQw-0007AJ-6i; Wed, 05 Jul 2006 18:01:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFQu-0007AD-W3 for pce@ietf.org; Wed, 05 Jul 2006 18:01:20 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyFQr-0003Dw-Dy for pce@ietf.org; Wed, 05 Jul 2006 18:01:20 -0400 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-3sarge1) with ESMTP id k65M1ELk029506; Thu, 6 Jul 2006 00:01:14 +0200 In-Reply-To: <1471D6A2-CD1F-42F7-85FF-6C9782625AE5@cisco.com> To: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 6 Jul 2006 00:01:08 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/06/2006 00:01:13, Serialize complete at 07/06/2006 00:01:13 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 82399e64b40cc35c75057a238056f806 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 from the below exchange "> Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to > each BR-ex(i-1), but in order to build the tree we need the paths > to be computed from each BR-en(i-1) to each BR-en(i). These paths > include the inter-domain TE links (where they exist). This is actually not needed - see below > > So.... > > Either there is an assumption that this TE link information is > available, or there is a step missing in the process. > > Perhaps the authors could clarify here and in the I-D. OK let's clarify then. The text in the draft says: Step i: - For i=n-1 to 2: PCE(i) concatenates the ASi topology (using its TED) with the received VSPT(i+1) and computes VSPT(i). And this is where we could elaborate if you will. What PCE(i) has to do is to concatenate the received VSPT from PCE(i+1) to its ASi topology (by the way, there's a typo there, it should read "domain" rather than "AS") including the inter-AS TE links (in the case of Inter-AS). Once such operation is performed, it is quite easy to compute the new VSPT (MP2P tree) from each BN(j,i) and return it to the upstream PCE." i read - assumption is that we need inter-AS link knowledge - response: no we don't don't but once explanations are provided we notice that "including the inter-AS TE links" knowledge is required so i am not sure that author's of this document clarified the real issue that was initial pointed thanks, - dimitri. JP Vasseur 29/06/2006 16:09 To: Adrian Farrel cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, pce@ietf.org Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Hi Adrian, Let me do this: 1) Reply to several emails individually 2) Send a summary to the list to make sure that all comments have been captured and will be addressed in the next revision. See below, On Jun 26, 2006, at 11:01 AM, Adrian Farrel wrote: > Thanks Dimitri, > > This is converging nicely. > >> ok (nice summary) - i think the whole debate is on point 2) since >> last >> meeting discussions - if one agrees that we don't solve this issue >> - then >> being aware upfront/descriptive of limitations, conditions and >> workability >> is really appropriated - let's assume this is (hopefully) the case > > Then that is an action for the authors to make points 1 and 2 > *very* clear in the I-D (at the top!) No problem to move some statement at the top ;-) Will do. Here is the proposed new abstract: Abstract The ability to compute constrained shortest Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. > >> the more important implication is point 3) - if this inter-domain >> link is >> not provided - de facto - as part of the method what does this method >> really provides ? i mean section 7. reads as if you can not flood >> just >> makes PCE aware of that TE data; however, point on whether this >> info is >> flooded or passed to the PCE or not the main issue is how this >> information >> is locally obtained ? what does happen if this information is only >> partially or not known, changing conditions, a unidirectional LSP >> reserves >> bandwidth downstream how accounting occurs (edges need to be aware of >> forward and reverse bandwidth), etc. > > I suspect you do not mean section 7? > > So, if I may rephrase.... > You are concerned about how the brpc process would operate if there > is an inter-domain link (e.g. inter-AS) and the TE information for > this link is not fully known. > > Let's quickly look at who needs to know. > > The downstream PCE provides paths from entry points to its domain > (BR-en(i)) to the destination. So the downstream PCE is not > interested in the TE links entering the domain. > > The upstream PCE provides paths from the entry points to its domain > (BR-en(i-1)) to the destination. It computes these by computing > 'optimal' paths from each BR-en(i-1) to the destination [says the I- > D in step 2]. But this is highly unclear! > > Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to > each BR-ex(i-1), but in order to build the tree we need the paths > to be computed from each BR-en(i-1) to each BR-en(i). These paths > include the inter-domain TE links (where they exist). This is actually not needed - see below > > So.... > > Either there is an assumption that this TE link information is > available, or there is a step missing in the process. > > Perhaps the authors could clarify here and in the I-D. OK let's clarify then. The text in the draft says: Step i: - For i=n-1 to 2: PCE(i) concatenates the ASi topology (using its TED) with the received VSPT(i+1) and computes VSPT(i). And this is where we could elaborate if you will. What PCE(i) has to do is to concatenate the received VSPT from PCE(i+1) to its ASi topology (by the way, there's a typo there, it should read "domain" rather than "AS") including the inter-AS TE links (in the case of Inter-AS). Once such operation is performed, it is quite easy to compute the new VSPT (MP2P tree) from each BN(j,i) and return it to the upstream PCE. So I propose to rephrase as follows: Step i: - For i=n-1 to 2: PCE(i) concatenates the topology of domain (i) (using its TED) with the received VSPT(i+1). In the case of Inter-AS TE LSP computation, this requires to also add the inter-AS TE links connecting the domain (i) to the domain (i+1). Then PCE(i) computes VSPT(i) (P2MP tree made of the shortest constrained paths between each BN-en(j,i) and the TE LSP destination). Does that clarify ? Thanks. JP. > > Thanks, > Adrian > > > > > > >> "Adrian Farrel" >> 26/06/2006 15:14 >> Please respond to "Adrian Farrel" >> >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >> cc: >> Subject: Re: [Pce] Re: Comments on >> draft-vasseur-pce-brpc-00.txt >> >> >> Hi, >> >> I'm trying to parse something out of this thread. >> >> 1. It is clear that brpc *demands* that the sequence of domains >> is already known before brpc is executed. >> In my opinion, this is clear in the I-D, but it would not hurt to >> make it clearer. >> A statement in the Abstract and Introduction would achieve >> this. >> >> 2. The mechanism by which the sequence of domains is known >> is out of scope for the procedure. >> It is not clear whether this is a limitation of the process, or >> not. But in my opinion this is consistent with the guidance >> that the WG received from the IAB when we were chartered. >> We are not trying to 'solve the Internet', so selection of >> domains is out of scope. >> >> 3. brpc *does* include mechanisms for the selection of interdomain >> links and/or nodes. This is more complex than the simple selection >> of these points of attachment because the connection to use may >> depend on the TE paths within the domains. >> IMO, brpc is constructed specifically for this purpose. If we did >> not need this function, we could use pd-path computation with >> visibility of the inter-domain TE links. >> >> 4. The discussion is not helped by debate about the precise wording >> around 'constraint'. >> Let us say that "the sequence of domains to be traversed is >> provided by an external source as a limiting factor to the >> computation >> or choice of paths." >> >> Do we all agree with these statements? >> >> Cheers, >> Adrian >> >> ----- Original Message ----- From: >> To: "JP Vasseur" >> Cc: ; ; >> >> Sent: Monday, June 26, 2006 7:51 AM >> Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >> >> >>> hi j-p - see in-line >>> >>> >>> >>> >>> JP Vasseur >>> 26/06/2006 02:42 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: nabil.n.bitar@verizon.com, pce@ietf.org, >>> raymond_zhang@bt.infonet.com >>> Subject: Re: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> hi dimitri, >>> >>> On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: >>> >>> hi j-p - see in-line >>> >>> >>> >>> >>> JP Vasseur >>> 26/06/2006 01:14 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: "Adrian Farrel" , >>> nabil.n.bitar@verizon.com, pce@ietf.org, >>> raymond_zhang@bt.infonet.com >>> Subject: Re: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> hi dimitiri, >>> >>> On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: >>> >>> the following comment was also discussed during last meeting >>> >>> "== >>> Section 5.1 >>> I like the simplicity of section 5.1, but I think you need to point >>> out >>> that >>> if the sequence of domains is known a priori (can you determine it a >>> priori?) then the path computed might not be 'optimal' in the usual >>> sense >>> of >>> the word, but that this is OK because the ordered list of domains >>> constitutes an additional constraint on the computation so the >>> resultant >>> path *is* optimal within the constraints applied. >>> >>> Can't agree more. Good suggestion, thanks. >>> >>> Updated text: "The PCE-based BRPC procedure applies to the >>> computation of >>> an optimal constrained inter-domain TE LSP. The sequence of domains >>> to be >>> traversed can either be determined a priori or during the path >>> computation >>> procedure. The BRPC procedure guarantees to compute the optimal path >>> across a specific set of traversed domains (which constitutes >>> an additional constraint). In the case of an arbitrary set of meshed >>> domains, the BRPC procedure can be used to compute the optimal path >>> across >>> each domain set in order to get to optimal constrained path between >>> the >>> source and the destination of the TE LSP." >>> >>> => in brief, how to determine the sequence through which path >>> computation >>> has to be performed because if this sequence was known there is no >>> need >>> for such procedure (only inter-domain link selection would be >>> required) - >>> >>> Not correct; even if you know the sequence you still need the BRPC >>> procedure to figure out the set of BN (boundary Nodes) to >>> traverse to >>> get the shortest inter-domain TE LSP: this is the whole issue with >>> inter-domain, otherwise per-domain path computation would be >>> sufficient. >>> >>> [dp] inter-domain link selection (as i mentioned) implies what >>> you mean >>> with boundary nodes selection - you could rephrase by access/exit >>> point >>> selection exact same business >>> >>> but again even if you know the sequence you still need BRPC to >>> determine >>> the set of BN (or exit point - same thing) that will give you the >> shortest >>> inter-domain path. Look you wrote "in brief, how to determine the >> sequence >>> through which path computation has to be performed because if this >>> sequence was known there is no need for such procedure", which is >>> not >>> correct. Even if you know the sequence of domains, you still need >>> the >>> procedure to get the exit/entry point (named BN) that provide you >>> the >>> shortest inter-domain path. >>> >>> >>> now adrian mentions that pre- determination becomes a new >>> constraint - >>> well actually this is not a constraint for the TE LSP itself but a >>> restriction on the domain set known to be (a-priori) supportive >>> of the >>> method such as to make the method not returning an error message >>> >>> >>> No, this is a constraint: "Give me the shortest path (potentially >>> made of loose hops (the BNs)) that provides the shortest end to end >>> path, considering that the additional constraint is to traverse the >>> following set of domains . >>> >>> [dp] incorrect, this is not a "TE LSP" constraint - >>> >>> Who said that this was a TE LSP constraint ? This is *a* >>> constraint. If >>> you impose the set of domain, this is a constraint. >>> >>> Please read the text: "The BRPC procedure guarantees to compute the >>> optimal path across a specific set of traversed domains (which >> constitutes >>> an additional constraint)." >>> >>> [dp] i read this, mind you, my point is that this is not a >>> "constraint" >> of >>> the same nature as the one you're making use such as minimize >>> delays or >>> whatsover - this constraint is introduced from the computation >>> technique >>> and mechanism of this proposed method >>> >>> Note that at this point, I still do not see the point that you're >>> trying >>> to make here ? >>> >>> since so far when >>> a set of domains do not support/or support a given computation >>> has not >>> yet become a constraint >>> >>> hence sentence "The BRPC procedure guarantees to compute the >>> optimal path >>> across a specific set of traversed domains (which constitutes >>> an additional constraint). In the case of an arbitrary set of meshed >>> domains, the BRPC procedure can be used to compute the optimal path >>> across >>> each domain set in order to get to optimal constrained path between >>> the >>> source and the destination of the TE LSP." >>> >>> should as far as i understand the method fulfill the following >>> >>> a) this method provides a result iff all domains traversed by the >>> request >>> support the proposed method >>> >>> BRPC is a multi-PCE based approach where you need at least one PCE >>> per-domain. >>> >>> [dp] indeed, but one PCE supporting that method and having FULL >>> visibility of the domain >>> >>> So what is your point here ? >>> >>> [dp] that the set of conditions to have this method workable is >>> larger >>> than the one listed in this doc. >>> >>> b) this method provides an "optimal" result iff >>> >>> b1) all possible sequences of domains have been traversed (starting >>> from >>> the root) and are supportive of that method - as there might be an >>> optimal >>> path through a domain not supporting this method - >>> >>> >>> heu ... yes indeed. If a domain does not support the method, the >>> method cannot be used to compute the path. >>> >>> b2) there is no discontinuity in the availability of the inter-AS >>> link >>> information on each PCE performing a given selection - indeed a >>> domain >>> might be supportive of the method without supporting inter-AS link >>> flooding >>> >>> No this is not a requirement, just an optimization. The only >>> requirement is for the PCE to get the TE-related data about the >>> Inter- >>> AS links. I'll detail a bit more in the next revision. >>> >>> [dp] then you can never achieve - >>> >>> You can never achieve what ? >>> >>> Sorry Dimitri, I'd love to accommodate your comment but I do not see >> your >>> point ... hopefully we'll have a bit of time in Montreal to >>> discuss if >>> that does not work by email. >>> >>> [dp] my point is that without this additional information you can >>> not >>> achieve the expected result - i pointed to your own text to indicate >> that >>> this information is a must have in order to achieve this objective >>> >>> using your own words to make it more >>> straighforward - >>> >>> "you still need the BRPC procedure to figure out the set of BN >>> (boundary >>> Nodes) to traverse to get the shortest inter-domain TE LSP: this >>> is the >>> whole issue with inter-domain, otherwise per-domain path computation >>> would >>> >>> be sufficient." >>> >>> b3) at each step there is no PCE that has partial visibility of a >>> given >>> domain >>> >>> >>> This is not specific to BRPC. Even with intra-domain if you want to >>> compute the path for a TE LSP, you cannot always use the PCE if it >>> has a partial visibility. Note that this also applies to the case of >>> co-located PCE (when the path is computed by the head-end). >>> >>> [dp] hence, to BRPC as well >>> >>> b4) during the selection process no network conditions changes >>> (that would >>> make the returned result void) >>> >>> >>> Again, this applies to other cases as well. >>> >>> [dp] ditto >>> >>> >>> Ah so we agree here :-) >>> >>> What was your comment then ? >>> >>> [dp] that you need to include these set of working conditions in the >>> document itself, the document looks like quite simple in terms of >>> conditions for having the proposed method working as expected >>> while when >>> you take a closer look at it this is not the case >>> >>> Thanks. >>> >>> JP. >>> >>> >>> >>> thanks. >>> >>> JP. >>> >>> >>> >>> >>> >>> >>> JP Vasseur >>> 23/06/2006 16:11 >>> >>> To: "Adrian Farrel" >>> cc: raymond_zhang@bt.infonet.com, pce@ietf.org, >>> nabil.n.bitar@verizon.com >>> Subject: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> Many Thanks Adrian for the comments. >>> >>> We incorporated the vast majority of them in the new revision (just >>> posted). >>> >>> See below for the comments requesting some clarification. >>> >>> On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >>> >>> Hi, >>> >>> Thanks for keeping these ideas alive. >>> >>> Here are some picky thoughts that you may want to include in the >>> next >>> revision to make it more robust as a document. I don't have any >>> issues >>> with >>> the basic process. >>> >>> Thanks, >>> Adrian >>> >>> == >>> Is this I-D likely to be Informational or Standards Track? From >>> Appendix >>> A, >>> this looks like Standards Track. Can you remove Appendix A and >>> put the >>> status in the usual place in the header? >>> == >>> >>> Status has been updated (Informational) but let's discuss this >>> later on. >>> FYI, it does not appear on the front page when using the xml2rfc >>> editor >>> (which by the way is excellent), thus the appendix addition. >>> >>> It would be nice if the Abstract contained a pithy summary of brpc >>> and/or >>> gave the motivation for the draft. For example, what is the method >>> trying >>> to >>> achieve that isn't achievable by other methods? Or, what is the >>> fundamental >>> element of brpc that is not in other methods? >>> >>> Agree. Here is the new Abstract: >>> "The ability to compute constrained shortest Traffic Engineering >>> (TE) >>> Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) >>> and >>> Generalized MPLS (GMPLS) networks across multiple domains (where a >>> domain >>> is referred to as a collection of network elements within a common >>> sphere >>> of address management or path computational responsibility such >>> as IGP >>> areas and Autonomous Systems) has been identified as a key >>> requirement . >>> This document specifies a procedure relying on the use of multiple >>> Path >>> Computation Elements (PCEs) in order to compute such inter-domain >>> shortest >>> constraint paths, using a backward recursive path computation >>> technique >>> while fully preserving confidentiality requirements across >>> domains. " >>> >>> >>> == >>> I'm assuming that section 1 is for short term information only and >>> will be >>> deleted (in the next revision?) >>> == >>> >>> Indeed, just to provide a bit of history for the ones who have been >>> following inter-domain path computation for a while. >>> >>> == >>> Section 4 >>> - No topology or resource information is distributed between >>> domains >>> (as mandated per [RFC4105] and [RFC4216]), which is critical to >>> preserve IGP/BGP scalability and confidentiality in the case of TE >>> LSPs spanning multiple domains. >>> You should clarify what you are saying here, because many would >>> argue that >>> reachability information (i.e. external routes) constitutes >>> topology and >>> resource information. >>> >>> >>> OK fine >>> >>> == >>> Section 4 >>> - While certain constraints like bandwidth can be used across >>> different domains, certain other TE constraints like resource >>> affinity, color, metric, etc. as listed in [RFC2702] could be >>> translated at domain boundaries. If required, it is assumed >>> that, at >>> the domain boundary LSRs, there will exist some sort of local >>> mapping >>> based on offline policy agreement, in order to translate such >>> constraints across domain boundaries during the inter-PCE >>> communication process. >>> Why does the policy agreement need to be offline? >>> >>> >>> It should actually read "pre-determined". Actually the best thing >>> to do >>> here is to remove "off-line" >>> >>> == >>> Section 5 >>> No assumption is made on the actual path computation algorithm in >>> use >>> by the PCE (it can be any variant of CSPF, algorithm based on >>> linear- >>> programming to solve multi-constraints optimization problems and so >>> on). >>> Suggest that you delete the text in parenthesis because it is making >>> suggestions that border on assumptions! >>> >>> Well I'd suggest to keep it as is since the point is to >>> differentiate the >>> path computation procedure from the algorithm to compute each intra- >>> domain >>> path segment. Furthermore, we'd like to highlight the fact that the >>> BRPC >>> procedure does not mandate for each PCE to use CSPF, could be other >>> algorithm. >>> >>> == >>> Section 5.1 and throughout >>> "BRPC path computation" seems to be tautologous >>> >>> It is actually a double tautology ;-) (fixed). >>> >>> == >>> Section 5.1 >>> I like the simplicity of section 5.1, but I think you need to point >>> out >>> that >>> if the sequence of domains is known a priori (can you determine it a >>> priori?) then the path computed might not be 'optimal' in the usual >>> sense >>> of >>> the word, but that this is OK because the ordered list of domains >>> constitutes an additional constraint on the computation so the >>> resultant >>> path *is* optimal within the constraints applied. >>> >>> Can't agree more. Good suggestion, thanks. >>> >>> Updated text: "The PCE-based BRPC procedure applies to the >>> computation of >>> an optimal constrained inter-domain TE LSP. The sequence of domains >>> to be >>> traversed can either be determined a priori or during the path >>> computation >>> procedure. The BRPC procedure guarantees to compute the optimal path >>> across a specific set of traversed domains (which constitutes >>> an additional constraint). In the case of an arbitrary set of meshed >>> domains, the BRPC procedure can be used to compute the optimal path >>> across >>> each domain set in order to get to optimal constrained path between >>> the >>> source and the destination of the TE LSP." >>> >>> == >>> Section 5.2 >>> The introduction of the term Virtual Shortest Path Tree is hard to >>> parse >>> and >>> to my mind the definition is arse about tit. I think you could >>> usefully >>> add >>> some textual definition of what the VSPT is trying to achieve, >>> before >>> presenting it in pictorial or abstract form. >>> Even more important (I think) is the fact that the tree as presented >>> "represents the shortest path between the destination and BR-en >>> (j,i)..." >>> Frankly, we are building directional paths in exactly the oposite >>> direction! >>> >>> This is an abstract form of representation but see below, >>> >>> So the VSPT is still a tree, but it is an MP2P tree, not a P2MP >>> tree as >>> described. >>> I suspect that this is just a textual descriptive issue rather than >>> anything >>> broken in the process. >>> >>> >>> I clarified the text to avoid any ambiguity (VSPT defined as a MP2P >>> tree). >>> >>> == >>> Section 5.2 >>> I suggest that you pull the note (Note: in term of >>> computation...) out >>> into >>> a separate section. It doesn't belong in the middle of section 5.2. >>> You will probably want to re-write the text as well since the >>> unidirectional >>> limit is not necessary. Also to explain 'flood' - flood to where, >>> and how, >>> and by whom? And you will want to add to pieces of information: >>> - the link to the I-D that defines how to do this >>> - a description of what happens if this process is not used. >>> >>> This only works for unidirectional LSPs: indeed, the exit boundary >>> node >>> can flood TE-related data in its LSA/LSP for the link >>> exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP >>> running on >>> the link but how would a node in domain (i) get the TE-related data >>> for >>> the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the >>> restriction on >>> unidirectional link. Are we in sync ? >>> >>> == >>> Section 5.2 >>> The paragraph that begins "BRPC guarantees to find the optimal..." >>> is a >>> nascent Applicability Statement. I suggest moving this to another >>> Section >>> and significantly beefing it up. You need to describe more fully: >>> - how ECMP works (the PCC has to request the return of more than >>> one path) >>> - how diversity works (i.e. section 9 fits in here) >>> - how some freedom of selection of domains can be offered >>> - how to mix the method with other mechanisms >>> >>> This was (and is) planned for future revision. Note that ECMP and >>> diversity are discussed already but we're planning the flesh out >>> these >>> sections in further revision. >>> >>> == >>> Section 7 >>> If the BRPC procedure cannot be completed because a PCE along the >>> domain path does not support the procedure, a PCErr message is >>> returned by the upstream PCE with a Error-Type "BRPC procedure >>> completion failure". The PCErr message MUST be relayed to the >>> requesting PCC. >>> Not clear to me whether PCE(n) is supposed to know that PCE(n+1) >>> does not >>> support brpc, presumably through capabilities >>> configuration/advertisement/negotiation, or whether PCE(n+1) is >>> supposed >>> to >>> respond to the path computation request saying that it does not >>> support >>> bit-V of the RP object. If the latter, presumably the PCErr comes >>> from >>> PCE(n+1) and not from PCE(n) as documented. >>> >>> Good catch, typo: it should read "a PCErr message is returned to the >>> upstream". >>> The plan is to define a capability bit (IGP) in a further revision. >>> >>> == >>> Section 8 >>> Metric normalisation is a great potential solution, but how does it >>> fit >>> with >>> AS topology confidentiality? What is the solution to providing >>> discretion >>> about what TE connectivity is available within an AS, and operating >>> brpc? >>> >>> Metric normalization is handled locally by the PCE and does not >>> impact the >>> BRPC procedure per-say. As far as confidentiality is concerned, >>> this only >>> requires for the SPs to exchange metric mapping information (nothing >>> related to the network topology or resources); for example >>> SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 >>> SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 >>> >>> A simple metric normalization can then be performed on the PCE >>> thanks to >>> simple cost mapping tables. >>> >>> Section 10 >>> Some of this text has been seen before in this I-D >>> Why do you single out LSP stitching as possibly breaking end-to-end >>> optimality. There is functionally no difference between stitching >>> and >>> nesting in this respect. >>> But further, your statement about stitching is pejorative! If you >>> say that >>> "In the case where a domain has more than one BR-en or more than one >>> BR-ex, >>> optimality after some network change within the domain can only be >>> guaranteed by re-executing the full brpc computation" then I would >>> agree >>> with you. But as phrased, it implies that making a per-domain >>> re-optimisation could make the path *less* optimal. This (of >>> course) is >>> not >>> the case - per-domain optimisation will always improve or leave the >>> same >>> end-to-end optimality (in the case where new resources are made >>> available >>> this is obvious; in the case of a network failure, *any* path is >>> better >>> than >>> no path!) >>> And, lastly, the text about re-optimisation belongs in the next >>> section, >>> not >>> in this section. >>> >>> >>> Yes I wanted to leave that text to keep track of who would read the >>> ID, >>> expecting reaction ;-)) Per-domain reoptimization would always >>> improve the >>> current path *but* in case of stitched LSPs, TE LSP segments are >>> computed >>> by the stitching point; thus in case of failure, they could end up >>> following a non optimal path whereas in the case of contiguous LSP, >>> the >>> BRPC procedure would be called again thus leading to the optimal >>> path >>> again. The point that I was trying to make is "if you have a >>> stitched LSP >>> and rely on BRPC when first signaled in an attempt to get an >>> optimal path, >>> you need to consider the interaction between the local reopt mode >>> and BRPC >>> if the goal is to preserve an optimal path at any given time". >>> Anyway, >>> we're on the same page and I agree and the text should be reworded >>> according to your proposal to avoid any misunderstanding. >>> >>> == >>> Section 13 >>> I would like you to discuss the issues of confidentiality of >>> topology >>> information at greater length. It seems that you would possibly use >>> this >>> technique in conjunction with path cookies, which is fine. But, are >>> there >>> two things you cannot escape from? >>> - indicating which BR-en provides best connectivity >>> - indicating the metric for multiple BR-ens >>> Maybe there are some things that can be done here based on policy, >>> including >>> not reporting all of the BR-ens, ranking rather than giving absolute >>> metrics, etc. But these would compromise optimality. >>> >>> Indeed. >>> >>> Maybe the PCE(n+1) should carefully monitor and limit >>> (statistically and >>> by >>> policy) brpc requests so that excessive information is not divulged? >>> >>> Since one of objectives for using the BRPC procedure is to >>> compute an >>> optimal path, we need to know at least the BN (Boundary Nodes) >>> and the >>> cost. >>> >>> == >>> I wouldn't mind seeing a Management Considerations section. >>> Do we need to be able to examine the pruned pieces of VSPT at >>> transit >>> PCEs? >>> What are the implications of reporting multiple VSPT branches in >>> PCEP to >>> the >>> MIB modules? >>> Is brpc support something that needs to be configured: per PCE?; per >>> PCE-neighbor? >>> What are the implications on existing protocols (IGPs? PCEP?) of >>> using >>> brpc? >>> >>> Absolutely ! I put a placeholder for a further revision. >>> >>> Fully supportive of adding such section. >>> >>> Many Thanks for your comments ! >>> >>> JP. >>> >>> etc. >>> == >>> >>> >>> >>> >>> >>> I think Jean-Louis' email address needs updating >>> >>> >>> == >>> The document would benefit from a little care in the formatting, >>> and you >>> could usefully re-read it for missing words, etc. >>> == >>> _______________________________________________ >>> 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 _______________________________________________ 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 Jul 05 18:22:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFlc-0008Qu-P5; Wed, 05 Jul 2006 18:22:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFat-0007nz-FF for pce@ietf.org; Wed, 05 Jul 2006 18:11:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyFan-0003nU-Sb for pce@ietf.org; Wed, 05 Jul 2006 18:11:39 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 05 Jul 2006 15:11:34 -0700 X-BrightmailFiltered: true X-IronPort-AV: i="4.06,210,1149490800"; d="scan'208,217"; a="31217484:sNHT164265460" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k65MBWno016422; Wed, 5 Jul 2006 18:11:32 -0400 (EDT) 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); Wed, 5 Jul 2006 18:11:32 -0400 Received: from [161.44.71.253] ([161.44.71.253]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 18:11:32 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <9C489CBA-94A5-4A38-B04B-4959571A535D@cisco.com> From: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Wed, 5 Jul 2006 18:11:30 -0400 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 05 Jul 2006 22:11:32.0302 (UTC) FILETIME=[F8DAD6E0:01C6A07F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 59c22c88e95a5e2bf7dd583988c90693 X-Mailman-Approved-At: Wed, 05 Jul 2006 18:22:43 -0400 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="===============1306607418==" Errors-To: pce-bounces@lists.ietf.org --===============1306607418== Content-Type: multipart/alternative; boundary=Apple-Mail-18--115884741 --Apple-Mail-18--115884741 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed hi, On Jul 5, 2006, at 6:01 PM, Dimitri.Papadimitriou@alcatel.be wrote: > hi > > from the below exchange > > "> Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to >> each BR-ex(i-1), but in order to build the tree we need the paths >> to be computed from each BR-en(i-1) to each BR-en(i). These paths >> include the inter-domain TE links (where they exist). > > This is actually not needed - see below > >> >> So.... >> >> Either there is an assumption that this TE link information is >> available, or there is a step missing in the process. >> >> Perhaps the authors could clarify here and in the I-D. > > OK let's clarify then. > > The text in the draft says: > > Step i: > > - For i=n-1 to 2: > > PCE(i) concatenates the ASi topology (using its TED) with the > received VSPT(i+1) and computes VSPT(i). > > And this is where we could elaborate if you will. What PCE(i) has to > do is to concatenate the received VSPT from PCE(i+1) to its ASi > topology (by the way, there's a typo there, it should read "domain" > rather than "AS") including the inter-AS TE links (in the case of > Inter-AS). Once such operation is performed, it is quite easy to > compute the new VSPT (MP2P tree) from each BN(j,i) and return it to > the upstream PCE." > > i read - assumption is that we need inter-AS link knowledge - > > response: no we don't don't but once explanations are provided we > notice that "including the inter-AS TE links" knowledge is required > > so i am not sure that author's of this document clarified the real > issue that was initial pointed Several requests for clarifications were added. The new text reads: Step i: - For i=n-1 to 2: PCE(i) concatenates the topology of domain (i) (using its TED) with the received VSPT(i+1). In the case of Inter-AS TE LSP computation, this requires to also add the inter-AS TE links connecting the domain (i) to the domain (i+1). Then PCE(i) computes VSPT(i) (P2MP tree made of the shortest constrained paths between each BN-en(j,i) and the TE LSP destination). In the case of Inter-AS TE, this operation also includes the links connecting ASBRs of ASi and ASi+1. The text clearly explains that Inter-AS TE link knowledge is required. Is there something that you don't find clear enough ? Thanks. JP. > > thanks, > - dimitri. > > > > > > > JP Vasseur > 29/06/2006 16:09 > > To: Adrian Farrel > cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, pce@ietf.org > Subject: Re: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > Hi Adrian, > > Let me do this: > 1) Reply to several emails individually > 2) Send a summary to the list to make sure that all comments have > been captured and will be addressed in the next revision. > > See below, > > On Jun 26, 2006, at 11:01 AM, Adrian Farrel wrote: > >> Thanks Dimitri, >> >> This is converging nicely. >> >>> ok (nice summary) - i think the whole debate is on point 2) since >>> last >>> meeting discussions - if one agrees that we don't solve this issue >>> - then >>> being aware upfront/descriptive of limitations, conditions and >>> workability >>> is really appropriated - let's assume this is (hopefully) the case >> >> Then that is an action for the authors to make points 1 and 2 >> *very* clear in the I-D (at the top!) > > No problem to move some statement at the top ;-) Will do. > > Here is the proposed new abstract: > > Abstract > > The ability to compute constrained shortest Traffic Engineering > (TE) > Label Switched Paths (LSPs) in Multiprotocol Label Switching > (MPLS) > and Generalized MPLS (GMPLS) networks across multiple domains > (where > a domain is referred to as a collection of network elements > within a > common sphere of address management or path computational > responsibility such as IGP areas and Autonomous Systems) has been > identified as a key requirement . This document specifies a > procedure relying on the use of multiple Path Computation Elements > (PCEs) in order to compute such inter-domain shortest constraint > paths along a determined sequence of domains, using a backward > recursive path computation technique while preserving > confidentiality > across domains, which is sometimes required when domains are > managed by different Service Providers. > >> >>> the more important implication is point 3) - if this inter-domain >>> link is >>> not provided - de facto - as part of the method what does this >>> method >>> really provides ? i mean section 7. reads as if you can not flood >>> just >>> makes PCE aware of that TE data; however, point on whether this >>> info is >>> flooded or passed to the PCE or not the main issue is how this >>> information >>> is locally obtained ? what does happen if this information is only >>> partially or not known, changing conditions, a unidirectional LSP >>> reserves >>> bandwidth downstream how accounting occurs (edges need to be >>> aware of >>> forward and reverse bandwidth), etc. >> >> I suspect you do not mean section 7? >> >> So, if I may rephrase.... >> You are concerned about how the brpc process would operate if there >> is an inter-domain link (e.g. inter-AS) and the TE information for >> this link is not fully known. >> >> Let's quickly look at who needs to know. >> >> The downstream PCE provides paths from entry points to its domain >> (BR-en(i)) to the destination. So the downstream PCE is not >> interested in the TE links entering the domain. >> >> The upstream PCE provides paths from the entry points to its domain >> (BR-en(i-1)) to the destination. It computes these by computing >> 'optimal' paths from each BR-en(i-1) to the destination [says the I- >> D in step 2]. But this is highly unclear! >> >> Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to >> each BR-ex(i-1), but in order to build the tree we need the paths >> to be computed from each BR-en(i-1) to each BR-en(i). These paths >> include the inter-domain TE links (where they exist). > > This is actually not needed - see below > >> >> So.... >> >> Either there is an assumption that this TE link information is >> available, or there is a step missing in the process. >> >> Perhaps the authors could clarify here and in the I-D. > > OK let's clarify then. > > The text in the draft says: > > Step i: > > - For i=n-1 to 2: > > PCE(i) concatenates the ASi topology (using its TED) with the > received VSPT(i+1) and computes VSPT(i). > > And this is where we could elaborate if you will. What PCE(i) has to > do is to concatenate the received VSPT from PCE(i+1) to its ASi > topology (by the way, there's a typo there, it should read "domain" > rather than "AS") including the inter-AS TE links (in the case of > Inter-AS). Once such operation is performed, it is quite easy to > compute the new VSPT (MP2P tree) from each BN(j,i) and return it to > the upstream PCE. > > So I propose to rephrase as follows: > > Step i: > > - For i=n-1 to 2: > > PCE(i) concatenates the topology of domain (i) (using its TED) > with the received VSPT(i+1). In the case of Inter-AS TE LSP > computation, this requires to also add the inter-AS TE links > connecting the domain (i) to the domain (i+1). > Then PCE(i) computes VSPT(i) (P2MP tree made of the shortest > constrained paths between each BN-en(j,i) and the TE LSP > destination). > > Does that clarify ? > > Thanks. > > JP. > >> >> Thanks, >> Adrian >> >> >> >> >> >> >>> "Adrian Farrel" >>> 26/06/2006 15:14 >>> Please respond to "Adrian Farrel" >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: >>> Subject: Re: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> Hi, >>> >>> I'm trying to parse something out of this thread. >>> >>> 1. It is clear that brpc *demands* that the sequence of domains >>> is already known before brpc is executed. >>> In my opinion, this is clear in the I-D, but it would not hurt to >>> make it clearer. >>> A statement in the Abstract and Introduction would achieve >>> this. >>> >>> 2. The mechanism by which the sequence of domains is known >>> is out of scope for the procedure. >>> It is not clear whether this is a limitation of the process, or >>> not. But in my opinion this is consistent with the guidance >>> that the WG received from the IAB when we were chartered. >>> We are not trying to 'solve the Internet', so selection of >>> domains is out of scope. >>> >>> 3. brpc *does* include mechanisms for the selection of interdomain >>> links and/or nodes. This is more complex than the simple >>> selection >>> of these points of attachment because the connection to use may >>> depend on the TE paths within the domains. >>> IMO, brpc is constructed specifically for this purpose. If we did >>> not need this function, we could use pd-path computation with >>> visibility of the inter-domain TE links. >>> >>> 4. The discussion is not helped by debate about the precise wording >>> around 'constraint'. >>> Let us say that "the sequence of domains to be traversed is >>> provided by an external source as a limiting factor to the >>> computation >>> or choice of paths." >>> >>> Do we all agree with these statements? >>> >>> Cheers, >>> Adrian >>> >>> ----- Original Message ----- From: >>> >>> To: "JP Vasseur" >>> Cc: ; ; >>> >>> Sent: Monday, June 26, 2006 7:51 AM >>> Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >>> >>> >>>> hi j-p - see in-line >>>> >>>> >>>> >>>> >>>> JP Vasseur >>>> 26/06/2006 02:42 >>>> >>>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>>> cc: nabil.n.bitar@verizon.com, pce@ietf.org, >>>> raymond_zhang@bt.infonet.com >>>> Subject: Re: [Pce] Re: Comments on >>>> draft-vasseur-pce-brpc-00.txt >>>> >>>> >>>> hi dimitri, >>>> >>>> On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be >>>> wrote: >>>> >>>> hi j-p - see in-line >>>> >>>> >>>> >>>> >>>> JP Vasseur >>>> 26/06/2006 01:14 >>>> >>>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>>> cc: "Adrian Farrel" , >>>> nabil.n.bitar@verizon.com, pce@ietf.org, >>>> raymond_zhang@bt.infonet.com >>>> Subject: Re: [Pce] Re: Comments on >>>> draft-vasseur-pce-brpc-00.txt >>>> >>>> >>>> hi dimitiri, >>>> >>>> On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be >>>> wrote: >>>> >>>> the following comment was also discussed during last meeting >>>> >>>> "== >>>> Section 5.1 >>>> I like the simplicity of section 5.1, but I think you need to point >>>> out >>>> that >>>> if the sequence of domains is known a priori (can you determine >>>> it a >>>> priori?) then the path computed might not be 'optimal' in the usual >>>> sense >>>> of >>>> the word, but that this is OK because the ordered list of domains >>>> constitutes an additional constraint on the computation so the >>>> resultant >>>> path *is* optimal within the constraints applied. >>>> >>>> Can't agree more. Good suggestion, thanks. >>>> >>>> Updated text: "The PCE-based BRPC procedure applies to the >>>> computation of >>>> an optimal constrained inter-domain TE LSP. The sequence of domains >>>> to be >>>> traversed can either be determined a priori or during the path >>>> computation >>>> procedure. The BRPC procedure guarantees to compute the optimal >>>> path >>>> across a specific set of traversed domains (which constitutes >>>> an additional constraint). In the case of an arbitrary set of >>>> meshed >>>> domains, the BRPC procedure can be used to compute the optimal path >>>> across >>>> each domain set in order to get to optimal constrained path between >>>> the >>>> source and the destination of the TE LSP." >>>> >>>> => in brief, how to determine the sequence through which path >>>> computation >>>> has to be performed because if this sequence was known there is no >>>> need >>>> for such procedure (only inter-domain link selection would be >>>> required) - >>>> >>>> Not correct; even if you know the sequence you still need the BRPC >>>> procedure to figure out the set of BN (boundary Nodes) to >>>> traverse to >>>> get the shortest inter-domain TE LSP: this is the whole issue with >>>> inter-domain, otherwise per-domain path computation would be >>>> sufficient. >>>> >>>> [dp] inter-domain link selection (as i mentioned) implies what >>>> you mean >>>> with boundary nodes selection - you could rephrase by access/exit >>>> point >>>> selection exact same business >>>> >>>> but again even if you know the sequence you still need BRPC to >>>> determine >>>> the set of BN (or exit point - same thing) that will give you the >>> shortest >>>> inter-domain path. Look you wrote "in brief, how to determine the >>> sequence >>>> through which path computation has to be performed because if this >>>> sequence was known there is no need for such procedure", which is >>>> not >>>> correct. Even if you know the sequence of domains, you still need >>>> the >>>> procedure to get the exit/entry point (named BN) that provide you >>>> the >>>> shortest inter-domain path. >>>> >>>> >>>> now adrian mentions that pre- determination becomes a new >>>> constraint - >>>> well actually this is not a constraint for the TE LSP itself but a >>>> restriction on the domain set known to be (a-priori) supportive >>>> of the >>>> method such as to make the method not returning an error message >>>> >>>> >>>> No, this is a constraint: "Give me the shortest path (potentially >>>> made of loose hops (the BNs)) that provides the shortest end to end >>>> path, considering that the additional constraint is to traverse the >>>> following set of domains . >>>> >>>> [dp] incorrect, this is not a "TE LSP" constraint - >>>> >>>> Who said that this was a TE LSP constraint ? This is *a* >>>> constraint. If >>>> you impose the set of domain, this is a constraint. >>>> >>>> Please read the text: "The BRPC procedure guarantees to compute the >>>> optimal path across a specific set of traversed domains (which >>> constitutes >>>> an additional constraint)." >>>> >>>> [dp] i read this, mind you, my point is that this is not a >>>> "constraint" >>> of >>>> the same nature as the one you're making use such as minimize >>>> delays or >>>> whatsover - this constraint is introduced from the computation >>>> technique >>>> and mechanism of this proposed method >>>> >>>> Note that at this point, I still do not see the point that you're >>>> trying >>>> to make here ? >>>> >>>> since so far when >>>> a set of domains do not support/or support a given computation >>>> has not >>>> yet become a constraint >>>> >>>> hence sentence "The BRPC procedure guarantees to compute the >>>> optimal path >>>> across a specific set of traversed domains (which constitutes >>>> an additional constraint). In the case of an arbitrary set of >>>> meshed >>>> domains, the BRPC procedure can be used to compute the optimal path >>>> across >>>> each domain set in order to get to optimal constrained path between >>>> the >>>> source and the destination of the TE LSP." >>>> >>>> should as far as i understand the method fulfill the following >>>> >>>> a) this method provides a result iff all domains traversed by the >>>> request >>>> support the proposed method >>>> >>>> BRPC is a multi-PCE based approach where you need at least one PCE >>>> per-domain. >>>> >>>> [dp] indeed, but one PCE supporting that method and having FULL >>>> visibility of the domain >>>> >>>> So what is your point here ? >>>> >>>> [dp] that the set of conditions to have this method workable is >>>> larger >>>> than the one listed in this doc. >>>> >>>> b) this method provides an "optimal" result iff >>>> >>>> b1) all possible sequences of domains have been traversed (starting >>>> from >>>> the root) and are supportive of that method - as there might be an >>>> optimal >>>> path through a domain not supporting this method - >>>> >>>> >>>> heu ... yes indeed. If a domain does not support the method, the >>>> method cannot be used to compute the path. >>>> >>>> b2) there is no discontinuity in the availability of the inter-AS >>>> link >>>> information on each PCE performing a given selection - indeed a >>>> domain >>>> might be supportive of the method without supporting inter-AS link >>>> flooding >>>> >>>> No this is not a requirement, just an optimization. The only >>>> requirement is for the PCE to get the TE-related data about the >>>> Inter- >>>> AS links. I'll detail a bit more in the next revision. >>>> >>>> [dp] then you can never achieve - >>>> >>>> You can never achieve what ? >>>> >>>> Sorry Dimitri, I'd love to accommodate your comment but I do not >>>> see >>> your >>>> point ... hopefully we'll have a bit of time in Montreal to >>>> discuss if >>>> that does not work by email. >>>> >>>> [dp] my point is that without this additional information you can >>>> not >>>> achieve the expected result - i pointed to your own text to >>>> indicate >>> that >>>> this information is a must have in order to achieve this objective >>>> >>>> using your own words to make it more >>>> straighforward - >>>> >>>> "you still need the BRPC procedure to figure out the set of BN >>>> (boundary >>>> Nodes) to traverse to get the shortest inter-domain TE LSP: this >>>> is the >>>> whole issue with inter-domain, otherwise per-domain path >>>> computation >>>> would >>>> >>>> be sufficient." >>>> >>>> b3) at each step there is no PCE that has partial visibility of a >>>> given >>>> domain >>>> >>>> >>>> This is not specific to BRPC. Even with intra-domain if you want to >>>> compute the path for a TE LSP, you cannot always use the PCE if it >>>> has a partial visibility. Note that this also applies to the >>>> case of >>>> co-located PCE (when the path is computed by the head-end). >>>> >>>> [dp] hence, to BRPC as well >>>> >>>> b4) during the selection process no network conditions changes >>>> (that would >>>> make the returned result void) >>>> >>>> >>>> Again, this applies to other cases as well. >>>> >>>> [dp] ditto >>>> >>>> >>>> Ah so we agree here :-) >>>> >>>> What was your comment then ? >>>> >>>> [dp] that you need to include these set of working conditions in >>>> the >>>> document itself, the document looks like quite simple in terms of >>>> conditions for having the proposed method working as expected >>>> while when >>>> you take a closer look at it this is not the case >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> >>>> >>>> thanks. >>>> >>>> JP. >>>> >>>> >>>> >>>> >>>> >>>> >>>> JP Vasseur >>>> 23/06/2006 16:11 >>>> >>>> To: "Adrian Farrel" >>>> cc: raymond_zhang@bt.infonet.com, pce@ietf.org, >>>> nabil.n.bitar@verizon.com >>>> Subject: [Pce] Re: Comments on >>>> draft-vasseur-pce-brpc-00.txt >>>> >>>> >>>> Many Thanks Adrian for the comments. >>>> >>>> We incorporated the vast majority of them in the new revision (just >>>> posted). >>>> >>>> See below for the comments requesting some clarification. >>>> >>>> On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >>>> >>>> Hi, >>>> >>>> Thanks for keeping these ideas alive. >>>> >>>> Here are some picky thoughts that you may want to include in the >>>> next >>>> revision to make it more robust as a document. I don't have any >>>> issues >>>> with >>>> the basic process. >>>> >>>> Thanks, >>>> Adrian >>>> >>>> == >>>> Is this I-D likely to be Informational or Standards Track? From >>>> Appendix >>>> A, >>>> this looks like Standards Track. Can you remove Appendix A and >>>> put the >>>> status in the usual place in the header? >>>> == >>>> >>>> Status has been updated (Informational) but let's discuss this >>>> later on. >>>> FYI, it does not appear on the front page when using the xml2rfc >>>> editor >>>> (which by the way is excellent), thus the appendix addition. >>>> >>>> It would be nice if the Abstract contained a pithy summary of brpc >>>> and/or >>>> gave the motivation for the draft. For example, what is the method >>>> trying >>>> to >>>> achieve that isn't achievable by other methods? Or, what is the >>>> fundamental >>>> element of brpc that is not in other methods? >>>> >>>> Agree. Here is the new Abstract: >>>> "The ability to compute constrained shortest Traffic Engineering >>>> (TE) >>>> Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) >>>> and >>>> Generalized MPLS (GMPLS) networks across multiple domains (where a >>>> domain >>>> is referred to as a collection of network elements within a common >>>> sphere >>>> of address management or path computational responsibility such >>>> as IGP >>>> areas and Autonomous Systems) has been identified as a key >>>> requirement . >>>> This document specifies a procedure relying on the use of multiple >>>> Path >>>> Computation Elements (PCEs) in order to compute such inter-domain >>>> shortest >>>> constraint paths, using a backward recursive path computation >>>> technique >>>> while fully preserving confidentiality requirements across >>>> domains. " >>>> >>>> >>>> == >>>> I'm assuming that section 1 is for short term information only and >>>> will be >>>> deleted (in the next revision?) >>>> == >>>> >>>> Indeed, just to provide a bit of history for the ones who have been >>>> following inter-domain path computation for a while. >>>> >>>> == >>>> Section 4 >>>> - No topology or resource information is distributed between >>>> domains >>>> (as mandated per [RFC4105] and [RFC4216]), which is critical to >>>> preserve IGP/BGP scalability and confidentiality in the case of TE >>>> LSPs spanning multiple domains. >>>> You should clarify what you are saying here, because many would >>>> argue that >>>> reachability information (i.e. external routes) constitutes >>>> topology and >>>> resource information. >>>> >>>> >>>> OK fine >>>> >>>> == >>>> Section 4 >>>> - While certain constraints like bandwidth can be used across >>>> different domains, certain other TE constraints like resource >>>> affinity, color, metric, etc. as listed in [RFC2702] could be >>>> translated at domain boundaries. If required, it is assumed >>>> that, at >>>> the domain boundary LSRs, there will exist some sort of local >>>> mapping >>>> based on offline policy agreement, in order to translate such >>>> constraints across domain boundaries during the inter-PCE >>>> communication process. >>>> Why does the policy agreement need to be offline? >>>> >>>> >>>> It should actually read "pre-determined". Actually the best thing >>>> to do >>>> here is to remove "off-line" >>>> >>>> == >>>> Section 5 >>>> No assumption is made on the actual path computation algorithm in >>>> use >>>> by the PCE (it can be any variant of CSPF, algorithm based on >>>> linear- >>>> programming to solve multi-constraints optimization problems >>>> and so >>>> on). >>>> Suggest that you delete the text in parenthesis because it is >>>> making >>>> suggestions that border on assumptions! >>>> >>>> Well I'd suggest to keep it as is since the point is to >>>> differentiate the >>>> path computation procedure from the algorithm to compute each >>>> intra- >>>> domain >>>> path segment. Furthermore, we'd like to highlight the fact that the >>>> BRPC >>>> procedure does not mandate for each PCE to use CSPF, could be other >>>> algorithm. >>>> >>>> == >>>> Section 5.1 and throughout >>>> "BRPC path computation" seems to be tautologous >>>> >>>> It is actually a double tautology ;-) (fixed). >>>> >>>> == >>>> Section 5.1 >>>> I like the simplicity of section 5.1, but I think you need to point >>>> out >>>> that >>>> if the sequence of domains is known a priori (can you determine >>>> it a >>>> priori?) then the path computed might not be 'optimal' in the usual >>>> sense >>>> of >>>> the word, but that this is OK because the ordered list of domains >>>> constitutes an additional constraint on the computation so the >>>> resultant >>>> path *is* optimal within the constraints applied. >>>> >>>> Can't agree more. Good suggestion, thanks. >>>> >>>> Updated text: "The PCE-based BRPC procedure applies to the >>>> computation of >>>> an optimal constrained inter-domain TE LSP. The sequence of domains >>>> to be >>>> traversed can either be determined a priori or during the path >>>> computation >>>> procedure. The BRPC procedure guarantees to compute the optimal >>>> path >>>> across a specific set of traversed domains (which constitutes >>>> an additional constraint). In the case of an arbitrary set of >>>> meshed >>>> domains, the BRPC procedure can be used to compute the optimal path >>>> across >>>> each domain set in order to get to optimal constrained path between >>>> the >>>> source and the destination of the TE LSP." >>>> >>>> == >>>> Section 5.2 >>>> The introduction of the term Virtual Shortest Path Tree is hard to >>>> parse >>>> and >>>> to my mind the definition is arse about tit. I think you could >>>> usefully >>>> add >>>> some textual definition of what the VSPT is trying to achieve, >>>> before >>>> presenting it in pictorial or abstract form. >>>> Even more important (I think) is the fact that the tree as >>>> presented >>>> "represents the shortest path between the destination and BR-en >>>> (j,i)..." >>>> Frankly, we are building directional paths in exactly the oposite >>>> direction! >>>> >>>> This is an abstract form of representation but see below, >>>> >>>> So the VSPT is still a tree, but it is an MP2P tree, not a P2MP >>>> tree as >>>> described. >>>> I suspect that this is just a textual descriptive issue rather than >>>> anything >>>> broken in the process. >>>> >>>> >>>> I clarified the text to avoid any ambiguity (VSPT defined as a MP2P >>>> tree). >>>> >>>> == >>>> Section 5.2 >>>> I suggest that you pull the note (Note: in term of >>>> computation...) out >>>> into >>>> a separate section. It doesn't belong in the middle of section 5.2. >>>> You will probably want to re-write the text as well since the >>>> unidirectional >>>> limit is not necessary. Also to explain 'flood' - flood to where, >>>> and how, >>>> and by whom? And you will want to add to pieces of information: >>>> - the link to the I-D that defines how to do this >>>> - a description of what happens if this process is not used. >>>> >>>> This only works for unidirectional LSPs: indeed, the exit boundary >>>> node >>>> can flood TE-related data in its LSA/LSP for the link >>>> exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP >>>> running on >>>> the link but how would a node in domain (i) get the TE-related data >>>> for >>>> the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the >>>> restriction on >>>> unidirectional link. Are we in sync ? >>>> >>>> == >>>> Section 5.2 >>>> The paragraph that begins "BRPC guarantees to find the optimal..." >>>> is a >>>> nascent Applicability Statement. I suggest moving this to another >>>> Section >>>> and significantly beefing it up. You need to describe more fully: >>>> - how ECMP works (the PCC has to request the return of more than >>>> one path) >>>> - how diversity works (i.e. section 9 fits in here) >>>> - how some freedom of selection of domains can be offered >>>> - how to mix the method with other mechanisms >>>> >>>> This was (and is) planned for future revision. Note that ECMP and >>>> diversity are discussed already but we're planning the flesh out >>>> these >>>> sections in further revision. >>>> >>>> == >>>> Section 7 >>>> If the BRPC procedure cannot be completed because a PCE along the >>>> domain path does not support the procedure, a PCErr message is >>>> returned by the upstream PCE with a Error-Type "BRPC procedure >>>> completion failure". The PCErr message MUST be relayed to the >>>> requesting PCC. >>>> Not clear to me whether PCE(n) is supposed to know that PCE(n+1) >>>> does not >>>> support brpc, presumably through capabilities >>>> configuration/advertisement/negotiation, or whether PCE(n+1) is >>>> supposed >>>> to >>>> respond to the path computation request saying that it does not >>>> support >>>> bit-V of the RP object. If the latter, presumably the PCErr comes >>>> from >>>> PCE(n+1) and not from PCE(n) as documented. >>>> >>>> Good catch, typo: it should read "a PCErr message is returned to >>>> the >>>> upstream". >>>> The plan is to define a capability bit (IGP) in a further revision. >>>> >>>> == >>>> Section 8 >>>> Metric normalisation is a great potential solution, but how does it >>>> fit >>>> with >>>> AS topology confidentiality? What is the solution to providing >>>> discretion >>>> about what TE connectivity is available within an AS, and operating >>>> brpc? >>>> >>>> Metric normalization is handled locally by the PCE and does not >>>> impact the >>>> BRPC procedure per-say. As far as confidentiality is concerned, >>>> this only >>>> requires for the SPs to exchange metric mapping information >>>> (nothing >>>> related to the network topology or resources); for example >>>> SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 >>>> SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 >>>> >>>> A simple metric normalization can then be performed on the PCE >>>> thanks to >>>> simple cost mapping tables. >>>> >>>> Section 10 >>>> Some of this text has been seen before in this I-D >>>> Why do you single out LSP stitching as possibly breaking end-to-end >>>> optimality. There is functionally no difference between stitching >>>> and >>>> nesting in this respect. >>>> But further, your statement about stitching is pejorative! If you >>>> say that >>>> "In the case where a domain has more than one BR-en or more than >>>> one >>>> BR-ex, >>>> optimality after some network change within the domain can only be >>>> guaranteed by re-executing the full brpc computation" then I would >>>> agree >>>> with you. But as phrased, it implies that making a per-domain >>>> re-optimisation could make the path *less* optimal. This (of >>>> course) is >>>> not >>>> the case - per-domain optimisation will always improve or leave the >>>> same >>>> end-to-end optimality (in the case where new resources are made >>>> available >>>> this is obvious; in the case of a network failure, *any* path is >>>> better >>>> than >>>> no path!) >>>> And, lastly, the text about re-optimisation belongs in the next >>>> section, >>>> not >>>> in this section. >>>> >>>> >>>> Yes I wanted to leave that text to keep track of who would read the >>>> ID, >>>> expecting reaction ;-)) Per-domain reoptimization would always >>>> improve the >>>> current path *but* in case of stitched LSPs, TE LSP segments are >>>> computed >>>> by the stitching point; thus in case of failure, they could end up >>>> following a non optimal path whereas in the case of contiguous LSP, >>>> the >>>> BRPC procedure would be called again thus leading to the optimal >>>> path >>>> again. The point that I was trying to make is "if you have a >>>> stitched LSP >>>> and rely on BRPC when first signaled in an attempt to get an >>>> optimal path, >>>> you need to consider the interaction between the local reopt mode >>>> and BRPC >>>> if the goal is to preserve an optimal path at any given time". >>>> Anyway, >>>> we're on the same page and I agree and the text should be reworded >>>> according to your proposal to avoid any misunderstanding. >>>> >>>> == >>>> Section 13 >>>> I would like you to discuss the issues of confidentiality of >>>> topology >>>> information at greater length. It seems that you would possibly use >>>> this >>>> technique in conjunction with path cookies, which is fine. But, are >>>> there >>>> two things you cannot escape from? >>>> - indicating which BR-en provides best connectivity >>>> - indicating the metric for multiple BR-ens >>>> Maybe there are some things that can be done here based on policy, >>>> including >>>> not reporting all of the BR-ens, ranking rather than giving >>>> absolute >>>> metrics, etc. But these would compromise optimality. >>>> >>>> Indeed. >>>> >>>> Maybe the PCE(n+1) should carefully monitor and limit >>>> (statistically and >>>> by >>>> policy) brpc requests so that excessive information is not >>>> divulged? >>>> >>>> Since one of objectives for using the BRPC procedure is to >>>> compute an >>>> optimal path, we need to know at least the BN (Boundary Nodes) >>>> and the >>>> cost. >>>> >>>> == >>>> I wouldn't mind seeing a Management Considerations section. >>>> Do we need to be able to examine the pruned pieces of VSPT at >>>> transit >>>> PCEs? >>>> What are the implications of reporting multiple VSPT branches in >>>> PCEP to >>>> the >>>> MIB modules? >>>> Is brpc support something that needs to be configured: per PCE?; >>>> per >>>> PCE-neighbor? >>>> What are the implications on existing protocols (IGPs? PCEP?) of >>>> using >>>> brpc? >>>> >>>> Absolutely ! I put a placeholder for a further revision. >>>> >>>> Fully supportive of adding such section. >>>> >>>> Many Thanks for your comments ! >>>> >>>> JP. >>>> >>>> etc. >>>> == >>>> >>>> >>>> >>>> >>>> >>>> I think Jean-Louis' email address needs updating >>>> >>>> >>>> == >>>> The document would benefit from a little care in the formatting, >>>> and you >>>> could usefully re-read it for missing words, etc. >>>> == >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-18--115884741 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi,

On Jul 5, = 2006, at 6:01 PM, Dimitri.Papadimitriou@alc= atel.be wrote:

hi=A0

from the = below exchange

"> Obviously, PCE(i-1) can compute the paths from = each BR-en(i-1) to=A0
=
each BR-ex(i-1), but in = order to build the tree we need the paths=A0
to be = computed from each BR-en(i-1) to each BR-en(i). These paths=A0
include = the inter-domain TE links (where they exist).

This is = actually not needed - see below



Either there is an assumption that this TE link = information is=A0
available, or there is a step missing in the = process.

Perhaps the authors could clarify here and in the = I-D.
OK let's clarify then.

The text = in the draft says:
=A0 Step i:

=A0 =A0 - For i=3Dn-1 to = 2:

=A0 =A0 = PCE(i) concatenates the ASi topology (using its TED) with = the
=A0 =A0 received VSPT(i+1) and = computes VSPT(i).

And this is where we could elaborate if you will. = What PCE(i) has to=A0
do is to concatenate the received VSPT from PCE(i+1) = to its ASi=A0
topology (by the way, there's a typo there, it = should read "domain"=A0
rather = than "AS") including the inter-AS TE links (in the case of=A0
=A0
compute = the new VSPT (MP2P tree) from each BN(j,i) and return it to=A0
the = upstream PCE."

i read - assumption is that we need inter-AS link = knowledge -=A0

notice that "including the inter-AS TE links" = knowledge is required
so i am not sure that author's = of this document clarified the real
issue that = was initial pointed=A0

Several requests for = clarifications were added.=A0

The new text = reads:=A0

Step = i:
- For i=3Dn-1 to 2: PCE(i) concatenates the topology = of domain (i) (using its TED) with the received VSPT(i+1). In the case = of Inter-AS TE LSP computation, this requires to also add the inter-AS = TE links connecting the domain (i) to the domain (i+1). Then PCE(i) = computes VSPT(i) (P2MP tree made of the shortest constrained paths = between each BN-en(j,i) and the TE LSP = destination).

In the case of = Inter-AS TE, this operation also includes the links connecting ASBRs of = ASi and ASi+1.

The text clearly explains = that Inter-AS TE link knowledge is required.

Is there something that you = don't find clear enough ?

Thanks.

JP.


- dimitri.






JP Vasseur = <jvasseur@cisco.com>
29/06/2006 16:09

=A0 =A0 =A0 =A0 To: =A0 =A0 Adrian Farrel <adrian@olddog.co.uk>
=A0 =A0 =A0 =A0 = cc: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL, pce@ietf.org
=A0 =A0 =A0 =A0 = Subject:=A0 =A0 =A0 =A0 = Re: [Pce] Re: Comments on=A0


Hi Adrian,

Let me do this:
1) Reply to several emails individually
2) Send a summary to the list to make sure that all = comments have=A0
been captured and will be addressed in the next = revision.

See below,

On Jun 26, 2006, at 11:01 AM, = Adrian Farrel wrote:
Thanks = Dimitri,

This is converging nicely.

ok (nice summary) - i think the = whole debate is on point 2) since=A0
meeting discussions - if one = agrees that we don't solve this issue=A0
- = then
being aware upfront/descriptive = of limitations, conditions and=A0
is really appropriated - let's = assume this is (hopefully) the case

Then = that is an action for the authors to make points 1 and 2=A0
*very* = clear in the I-D (at the top!)

No = problem to move some statement at the top ;-) Will do.

Here is = the proposed new abstract:

Abstract

=A0 =A0 The ability to compute = constrained shortest Traffic Engineering (TE)
=A0 =A0 = Label Switched Paths (LSPs) in Multiprotocol Label Switching = (MPLS)
=A0 =A0 and Generalized MPLS = (GMPLS) networks across multiple domains (where
=A0 =A0 = a domain is referred to as a collection of network elements = within a
=A0 =A0 common sphere of address = management or path computational
=A0 =A0 responsibility such as = IGP areas and Autonomous Systems) has been
=A0 =A0 identified as a key = requirement .=A0 This = document specifies a
=A0 =A0 procedure relying on the = use of multiple Path Computation Elements
=A0 =A0 (PCEs) in order to = compute such inter-domain shortest constraint
=A0 =A0 = paths along a determined sequence of domains, using a = backward
=A0 =A0 recursive path = computation technique while preserving=A0
=A0 =A0 across domains, which is = sometimes required when domains are
=A0 =A0 managed by different = Service Providers.

the more = important implication is point 3) - if this inter-domain=A0
link = is
not provided - de facto - as part of the method = what does this method
really provides ? i mean = section 7. reads as if you can not flood=A0
makes PCE aware of that TE data; = however, point on whether this=A0
info = is
flooded or passed to the PCE or not the main = issue is how this=A0
information
is locally = obtained ? what does happen if this information is only
partially or not known, changing conditions, a = unidirectional LSP=A0
reserves
bandwidth = downstream how accounting occurs (edges need to be aware of
forward and reverse bandwidth), etc.
=

I suspect you do not mean section 7?

So, if I = may rephrase....
You are concerned about how the = brpc process would operate if there=A0
is an = inter-domain link (e.g. inter-AS) and the TE information for=A0
this = link is not fully known.

Let's quickly look at who needs = to know.

The downstream PCE provides paths from entry points = to its domain=A0
(BR-en(i)) to the destination. So the downstream PCE = is not=A0
interested in the TE links entering the = domain.

The upstream PCE provides paths from the entry = points to its domain=A0
=A0
=A0
D in step 2]. But this is highly unclear!

=A0
each = BR-ex(i-1), but in order to build the tree we need the paths=A0
to be = computed from each BR-en(i-1) to each BR-en(i). These paths=A0
include = the inter-domain TE links (where they exist).

This is = actually not needed - see below



Either there is an assumption that this TE link = information is=A0
available, or there is a step missing in the = process.

Perhaps the authors could clarify here and in the = I-D.
OK let's clarify then.

The text = in the draft says:
=A0 Step i:

=A0 =A0 - For i=3Dn-1 to = 2:

=A0 =A0 = PCE(i) concatenates the ASi topology (using its TED) with = the
=A0 =A0 received VSPT(i+1) and = computes VSPT(i).

And this is where we could elaborate if you will. = What PCE(i) has to=A0
do is to concatenate the received VSPT from PCE(i+1) = to its ASi=A0
topology (by the way, there's a typo there, it = should read "domain"=A0
rather = than "AS") including the inter-AS TE links (in the case of=A0
=A0
compute = the new VSPT (MP2P tree) from each BN(j,i) and return it to=A0
the = upstream PCE.

So I propose to rephrase as follows:

Step = i:

=A0 =A0 = - For i=3Dn-1 to 2:

=A0 =A0 PCE(i) concatenates the = topology of domain (i) (using its TED)
=A0 =A0 with the received = VSPT(i+1). In the case of Inter-AS TE LSP
=A0 =A0 computation, this = requires to also add the inter-AS TE links
=A0 =A0 connecting the domain (i) = to the domain (i+1).
=A0 =A0 Then PCE(i) computes = VSPT(i) (P2MP tree made of the shortest
=A0 =A0 constrained paths between = each BN-en(j,i) and the TE LSP=A0

Does that clarify ?


JP.


Adrian






"Adrian Farrel" <adrian@olddog.co.uk>
26/06/2006 15:14
Please = respond to "Adrian Farrel"

=A0=A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0=A0 =A0 =A0 cc: =A0 =A0 <pce@ietf.org>
=A0=A0 =A0 =A0 = Subject:=A0 =A0 =A0 =A0 = Re: [Pce] Re: Comments on


Hi,

I'm trying to parse something = out of this thread.
1. It is clear that brpc = *demands* that the sequence of domains
=A0=A0 is already known before = brpc is executed.
=A0=A0 In my opinion, this is = clear in the I-D, but it would not hurt to
=A0=A0 make it clearer.
=A0=A0 = A statement in the Abstract and Introduction would = achieve
=A0=A0 this.

2. The = mechanism by which the sequence of domains is known
=A0=A0 = is out of scope for the procedure.
=A0=A0 It is not clear whether = this is a limitation of the process, or
=A0=A0 not. But in my opinion = this is consistent with the guidance
=A0=A0 that the WG received from = the IAB when we were chartered.
=A0=A0 We are not trying to = 'solve the Internet', so selection of
=A0 =A0 domains is out of = scope.

3. brpc *does* include mechanisms for the selection = of interdomain
=A0=A0 links and/or nodes. This = is more complex than the simple selection
=A0=A0 of these points of = attachment because the connection to use may
=A0=A0 = depend on the TE paths within the domains.
=A0=A0 = IMO, brpc is constructed specifically for this purpose. If we = did
=A0=A0 not need this function, we = could use pd-path computation with
=A0=A0 visibility of the = inter-domain TE links.
4. The discussion is not helped = by debate about the precise wording
=A0 around = 'constraint'.
=A0 Let us say that "the sequence = of domains to be traversed is
=A0 provided by an external = source as a limiting factor to the=A0
=A0 or choice of = paths."

Do we all agree with these statements?

Adrian

----- = Original Message ----- From: <Dimitri.Papadimitriou@alc= atel.be>
To: "JP Vasseur" <jvasseur@cisco.com>
Sent: Monday, June 26, 2006 7:51 AM
Subject: Re: [Pce] Re: Comments on = draft-vasseur-pce-brpc-00.txt


=
hi j-p - see = in-line




JP Vasseur <jvasseur@cisco.com>
26/06/2006 02:42

=A0=A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0=A0 =A0 =A0 cc: =A0 =A0 nabil.n.bitar@verizon.com, = pce@ietf.org,



hi j-p - see in-line




JP Vasseur <jvasseur@cisco.com>
26/06/2006 01:14

=A0=A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0=A0 =A0 =A0 cc: =A0 =A0 "Adrian Farrel" <adrian@olddog.co.uk>,
nabil.n.bitar@verizon.com, = pce@ietf.org,=A0



the following comment was also = discussed during last meeting

"=3D=3D
Section 5.1
I like the = simplicity of section 5.1, but I think you need to point
out
if the sequence of domains is = known a priori (can you determine it a
priori?) = then the path computed might not be 'optimal' in the usual
sense
of
the word, but that this is OK because the ordered = list of domains
constitutes an additional = constraint on the computation so the
path *is* optimal within the = constraints applied.
Can't agree more. Good = suggestion, thanks.
Updated text: "The PCE-based = BRPC procedure applies to the
computation = of
an optimal constrained inter-domain TE LSP. The = sequence of domains
to be
traversed can either be determined a priori or = during the path
computation
procedure. The BRPC procedure guarantees to compute = the optimal path
across a specific set of = traversed domains (which constitutes
an additional = constraint). In the case of an arbitrary set of meshed
domains, the BRPC procedure can be used to compute = the optimal path
across
each domain set in order to get to optimal = constrained path between
the
source and the destination of the TE LSP."

=3D> = in brief, how to determine the sequence through which path
computation
has to be = performed because if this sequence was known there is no
need
for such = procedure (only inter-domain link selection would be
required) -

Not correct; even if you know = the sequence you still need the BRPC
procedure to = figure out the set of BN (boundary Nodes) to=A0
traverse = to
get the shortest inter-domain TE LSP: this is = the whole issue with
inter-domain, otherwise = per-domain path computation would be=A0

[dp] inter-domain link selection (as i mentioned) = implies what=A0
you mean
with boundary = nodes selection - you could rephrase by access/exit=A0
selection exact same = business

but again even if you know the sequence you still = need BRPC to=A0
determine
the set of BN = (or exit point - same thing) that will give you the
=
shortest
inter-domain path. Look you = wrote "in brief, how to determine the
sequence
through which path computation has to be performed = because if this
sequence was known there is no = need for such procedure", which is=A0
correct. Even if you know the = sequence of domains, you still need=A0
procedure to get the exit/entry = point (named BN) that provide you=A0
shortest inter-domain = path.


now = adrian mentions that pre- determination becomes a new=A0
well actually this is not a = constraint for the TE LSP itself but a
=A0
of = the
method such as to make the = method not returning an error message


No, this is a constraint: "Give = me the shortest path (potentially
made of loose = hops (the BNs)) that provides the shortest end to end
path, considering that the additional constraint is = to traverse the
following set of domains <D1, = D2, ....>.

[dp] incorrect, this is not a "TE LSP" constraint = -

Who said that this was a TE LSP constraint ? This is = *a*=A0
constraint. If
you impose = the set of domain, this is a constraint.

Please read = the text: "The BRPC procedure guarantees to compute the
optimal path across a specific set of traversed = domains (which
an = additional constraint)."

[dp] i read this, mind you, my = point is that this is not a=A0
of
=
the same nature as the one = you're making use such as minimize=A0
delays = or
whatsover - this constraint is introduced from = the computation=A0
technique
and mechanism = of this proposed method

Note that at this point, I still = do not see the point that you're=A0
to make here ?

since so = far when
a set of domains do not = support/or support a given computation=A0
has = not
yet become a = constraint

hence sentence "The BRPC procedure guarantees to = compute the
optimal path
across a specific set of traversed domains (which = constitutes
an additional constraint). In = the case of an arbitrary set of meshed
domains, = the BRPC procedure can be used to compute the optimal path
across
each domain = set in order to get to optimal constrained path between
the
source and = the destination of the TE LSP."

should as far as i understand = the method fulfill the following

a) this method provides a result = iff all domains traversed by the
support the proposed = method

BRPC is a multi-PCE based approach where you need at = least one PCE
per-domain.

[dp] = indeed, but one PCE supporting that method and having FULL
visibility of the domain

So what = is your point here ?
[dp] that the set of conditions = to have this method workable is=A0
than the one listed in this = doc.

b) this method provides an "optimal" result = iff

b1) all possible sequences of domains have been = traversed (starting
from
the root) and are supportive of that method - as = there might be an
optimal
path through a domain not supporting this method = -


heu ... = yes indeed. If a domain does not support the method, the
method cannot be used to compute the path.

b2) = there is no discontinuity in the availability of the inter-AS=A0
information on each PCE = performing a given selection - indeed a=A0
might be supportive of the = method without supporting inter-AS link

No this is not a requirement, just an optimization. = The only
requirement is for the PCE to = get the TE-related data about the=A0
AS links. I'll detail a bit more = in the next revision.
[dp] then you can never achieve = -

You can never achieve what ?

Sorry = Dimitri, I'd love to accommodate your comment but I do not see
=
your
point ... hopefully we'll have a = bit of time in Montreal to=A0
discuss = if
that does not work by email.

[dp] my = point is that without this additional information you can=A0
achieve the expected result - i = pointed to your own text to indicate
that
this information is a must have in order to achieve = this objective

using your own words to make it more
straighforward -

"you still need the BRPC = procedure to figure out the set of BN=A0
Nodes) to traverse to get the = shortest inter-domain TE LSP: this=A0
is = the
whole issue with inter-domain, = otherwise per-domain path computation

be sufficient."

b3) at each step there is no PCE = that has partial visibility of a
domain


This is not = specific to BRPC. Even with intra-domain if you want to
compute the path for a TE LSP, you cannot always use = the PCE if it
has a partial visibility. Note = that this also applies to the case of

[dp] = hence, to BRPC as well
b4) during the selection process = no network conditions changes
(that = would
make the returned result = void)


Again, = this applies to other cases as well.

[dp] ditto


Ah so we = agree here :-)

What was your comment then ?

[dp] = that you need to include these set of working conditions in = the
document itself, the document = looks like quite simple in terms of
conditions = for having the proposed method working as expected=A0
while = when
you take a closer look at it = this is not the case
Thanks.





JP.






JP Vasseur <jvasseur@cisco.com>
23/06/2006 16:11

=A0=A0 =A0 =A0 To: =A0 =A0 "Adrian Farrel" <adrian@olddog.co.uk>
nabil.n.bitar@verizon.com
=A0=A0 =A0 =A0 = Subject:=A0 =A0 =A0 =A0 = [Pce] Re: Comments on


Many Thanks Adrian for the comments.

We = incorporated the vast majority of them in the new revision = (just
posted).

See = below for the comments requesting some clarification.

On Jun = 10, 2006, at 8:49 AM, Adrian Farrel wrote:

Hi,

Thanks = for keeping these ideas alive.

Here are some picky thoughts = that you may want to include in the=A0
revision to make it more robust = as a document. I don't have any=A0
with
the basic process.

Adrian

Is this I-D likely to be = Informational or Standards Track? From
A,
this = looks like Standards Track. Can you remove Appendix A and=A0
put = the
status in the usual place in the = header?
=3D=3D

Status = has been updated (Informational) but let's discuss this
later on.
FYI, it does = not appear on the front page when using the xml2rfc
editor
(which by the = way is excellent), thus the appendix addition.

It would = be nice if the Abstract contained a pithy summary of brpc
and/or
gave the = motivation for the draft. For example, what is the method
trying
to
achieve that isn't achievable by other methods? Or, = what is the
fundamental
element of brpc that is not in other = methods?

Agree. Here is the new Abstract:
"The ability to compute constrained shortest Traffic = Engineering=A0
(TE)
Label = Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS)
and
Generalized = MPLS (GMPLS) networks across multiple domains (where a
domain
is referred = to as a collection of network elements within a common
sphere
of address = management or path computational responsibility such=A0
as = IGP
areas and Autonomous Systems) = has been identified as a key
requirement = .
This document specifies a procedure relying on = the use of multiple
Path
Computation Elements (PCEs) in order to compute such = inter-domain
shortest
constraint paths, using a backward recursive path = computation
technique
while fully preserving confidentiality requirements = across=A0
domains. "


=3D=3D
I'm assuming = that section 1 is for short term information only and
will be
deleted (in = the next revision?)
=3D=3D

Indeed, = just to provide a bit of history for the ones who have been
following inter-domain path computation for a = while.

=3D=3D
Section = 4
=A0-= No topology or resource information is distributed between=A0
=A0(as mandated per [RFC4105] and = [RFC4216]), which is critical to
=A0preserve IGP/BGP scalability = and confidentiality in the case of TE
=A0LSPs spanning multiple = domains.
You should clarify what you are = saying here, because many would
argue = that
reachability information (i.e. = external routes) constitutes
topology = and
resource information.


OK = fine

=3D=3D
Section = 4
=A0-= While certain constraints like bandwidth can be used across
=A0different domains, certain = other TE constraints like resource
=A0affinity, color, metric, etc. = as listed in [RFC2702] could be
=A0translated at domain = boundaries.=A0 If required, = it is assumed
that, at
=A0the = domain boundary LSRs, there will exist some sort of local
mapping
=A0based on offline policy = agreement, in order to translate such
=A0constraints across domain = boundaries during the inter-PCE
=A0communication = process.
Why does the policy agreement = need to be offline?

It should actually read "pre-determined". Actually = the best thing
to do
here is to remove "off-line"

Section 5
=A0No = assumption is made on the actual path computation algorithm in
use
=A0by the PCE (it can be any = variant of CSPF, algorithm based on
=A0programming to solve = multi-constraints optimization problems and so
=A0on).
Suggest that you delete the text in parenthesis = because it is making
suggestions that border on = assumptions!

Well I'd suggest to keep it as is since the point is = to
differentiate the
path = computation procedure from the algorithm to compute each = intra-
domain
path segment. Furthermore, we'd like to highlight = the fact that the
BRPC
procedure does not mandate for each PCE to use CSPF, = could be other
algorithm.

Section 5.1 and = throughout
"BRPC path computation" seems to = be tautologous

It is actually a double tautology ;-) = (fixed).

=3D=3D
Section = 5.1
I like the simplicity of section = 5.1, but I think you need to point
out
that
if the = sequence of domains is known a priori (can you determine it a
priori?) then the path computed might not be = 'optimal' in the usual
sense
of
the word, but that this is = OK because the ordered list of domains
resultant
path *is* optimal within the constraints = applied.

Can't agree more. Good suggestion, thanks.

Updated = text: "The PCE-based BRPC procedure applies to the
computation of
an optimal = constrained inter-domain TE LSP. The sequence of domains
to be
traversed can = either be determined a priori or during the path
computation
procedure. = The BRPC procedure guarantees to compute the optimal path
across a specific set of traversed domains (which = constitutes
an additional constraint). In = the case of an arbitrary set of meshed
domains, = the BRPC procedure can be used to compute the optimal path
across
each domain = set in order to get to optimal constrained path between
the
source and = the destination of the TE LSP."

=3D=3D
Section 5.2
The = introduction of the term Virtual Shortest Path Tree is hard to
parse
and
to my mind the definition is arse about tit. I think = you could
usefully
add
some textual = definition of what the VSPT is trying to achieve,=A0
presenting it in pictorial or = abstract form.
Even more important (I think) is = the fact that the tree as presented
"represents = the shortest path between the destination and BR-en
(j,i)..."
Frankly, we = are building directional paths in exactly the oposite
direction!

This is an abstract form of = representation but see below,

So the VSPT is still a tree, but = it is an MP2P tree, not a P2MP
tree = as
described.
I suspect = that this is just a textual descriptive issue rather than
anything
broken in the = process.


I = clarified the text to avoid any ambiguity (VSPT defined as a = MP2P
tree).

Section 5.2
I suggest that you pull the note (Note: in term = of=A0
computation...) out
a separate section. It doesn't = belong in the middle of section 5.2.
You will = probably want to re-write the text as well since the
unidirectional
limit is not = necessary. Also to explain 'flood' - flood to where,
and how,
and by whom? = And you will want to add to pieces of information:
- the link to the I-D that defines how to do = this
- a description of what happens = if this process is not used.

This only works for = unidirectional LSPs: indeed, the exit boundary
node
can flood = TE-related data in its LSA/LSP for the link
running on
the link but how would a node in domain (i) get the = TE-related data
for
the = link entry(i+1,k')->exit-BN(i,k) ? I can't thus the=A0
unidirectional link. Are we in = sync ?

=3D=3D
Section = 5.2
The paragraph that begins "BRPC = guarantees to find the optimal..."
is = a
nascent Applicability Statement. I suggest = moving this to another
Section
and significantly beefing it up. You need to = describe more fully:
- how ECMP works (the PCC = has to request the return of more than
one = path)
- how diversity works (i.e. = section 9 fits in here)
- how some = freedom of selection of domains can be offered
- how to mix the method with other = mechanisms

This was (and is) planned for future revision. Note = that ECMP and
diversity are discussed already = but we're planning the flesh out=A0
sections in further = revision.

=3D=3D
Section = 7
=A0I= f the BRPC procedure cannot be completed because a PCE along = the
=A0domain path does not support = the procedure, a PCErr message is
=A0returned by the upstream PCE = with a Error-Type "BRPC procedure
=A0completion failure".=A0 The PCErr message MUST be = relayed to the
=A0requesting PCC.
Not clear to me whether PCE(n) is supposed to know = that PCE(n+1)
does not
support brpc, presumably through = capabilities
supposed
to
respond to the path computation request saying that = it does not
support
bit-V of the RP object. If the latter, presumably = the PCErr comes=A0
from
PCE(n+1) and = not from PCE(n) as documented.

Good catch, typo: it should read = "a PCErr message is returned to the
The plan is to define a = capability bit (IGP) in a further revision.

=3D=3D
Section 8
Metric = normalisation is a great potential solution, but how does it
fit
AS topology confidentiality? = What is the solution to providing
about what TE connectivity is = available within an AS, and operating

Metric normalization is handled locally by the PCE = and does not
impact the
BRPC procedure per-say. As far as confidentiality is = concerned,
this only
requires for the SPs to exchange metric mapping = information (nothing
related to the network = topology or resources); for example
SP 1 Links = Cost =3D F (link_bandwidth) with F (OC192)=3D1
SP 2 Links Cost =3D F (link_bandwidth) with F = (OC192)=3D10

A simple metric normalization can then be performed = on the PCE
thanks to
simple cost mapping tables.

Section = 10
Some of this text has been seen before in this = I-D
Why do you single out LSP = stitching as possibly breaking end-to-end
=A0
nesting in this = respect.
But further, your statement = about stitching is pejorative! If you
say = that
"In the case where a domain has = more than one BR-en or more than one
optimality after some network = change within the domain can only be
guaranteed by = re-executing the full brpc computation" then I would
agree
with you. But = as phrased, it implies that making a per-domain
re-optimisation could make the path *less* optimal. = This (of
course) is
not
the case - = per-domain optimisation will always improve or leave the
same
end-to-end = optimality (in the case where new resources are made
available
this is = obvious; in the case of a network failure, *any* path is
better
no path!)
And, lastly, the text about re-optimisation belongs = in the next
section,
not
in this = section.


Yes I = wanted to leave that text to keep track of who would read the
ID,
expecting = reaction ;-)) Per-domain reoptimization would always
improve the
current path = *but* in case of stitched LSPs, TE LSP segments are
computed
by the = stitching point; thus in case of failure, they could end up
following a non optimal path whereas in the case of = contiguous LSP,
the
BRPC = procedure would be called again thus leading to the optimal=A0
again. The point that I was = trying to make is "if you have a
stitched = LSP
and rely on BRPC when first = signaled in an attempt to get an
optimal = path,
you need to consider the = interaction between the local reopt mode
and = BRPC
if the goal is to preserve an = optimal path at any given time".=A0
we're on the same page and I = agree and the text should be reworded

Section 13
I would like you to discuss the issues of = confidentiality of=A0
topology
information = at greater length. It seems that you would possibly use
this
technique in = conjunction with path cookies, which is fine. But, are
there
two things = you cannot escape from?
- indicating = which BR-en provides best connectivity
- = indicating the metric for multiple BR-ens
Maybe = there are some things that can be done here based on policy,
including
not reporting = all of the BR-ens, ranking rather than giving absolute
metrics, etc. But these would compromise = optimality.

Indeed.

Maybe the PCE(n+1) should = carefully monitor and limit
by
policy) brpc requests so that excessive information = is not divulged?

Since one of objectives for using the BRPC procedure = is to=A0
compute an
optimal path, = we need to know at least the BN (Boundary Nodes)=A0
and = the
cost.

I wouldn't mind seeing a = Management Considerations section.
Do we need to = be able to examine the pruned pieces of VSPT at=A0
PCEs?
What are the implications of reporting multiple VSPT = branches in
PCEP to
the
MIB = modules?
Is brpc support something that = needs to be configured: per PCE?; per
What are the implications on = existing protocols (IGPs? PCEP?) of=A0
brpc?


Fully = supportive of adding such section.

Many Thanks for your comments = !

JP.

etc.
=3D=3D





I think Jean-Louis' email = address needs updating

=3D=3D
The document = would benefit from a little care in the formatting,
and you
could = usefully re-read it for missing words, etc.
Pce mailing list
Pce mailing list



Pce mailing list












Pce mailing list

Pce mailing list
=
= --Apple-Mail-18--115884741-- --===============1306607418== 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 --===============1306607418==-- From pce-bounces@lists.ietf.org Wed Jul 05 18:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFlp-0008UW-7j; Wed, 05 Jul 2006 18:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyF64-0001NH-GT; Wed, 05 Jul 2006 17:39:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyF64-0000bi-Ev; Wed, 05 Jul 2006 17:39:48 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyF61-0008AF-G6; Wed, 05 Jul 2006 17:39:48 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k65LcSjx015981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Jul 2006 21:38:28 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1FyF4m-0003b2-7b; Wed, 05 Jul 2006 17:38:28 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Adrian Farrel , JP Vasseur From: Greg Jones(ITU-T SG 15) Message-Id: Date: Wed, 05 Jul 2006 17:38:28 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Wed, 05 Jul 2006 18:22:55 -0400 Cc: Steve Trowbridge , Greg Jones , Bill Fenner , Hing-Kam Lam , Scott Bradner , Yoichi Maeda , pce@ietf.org, Ross Callon , ITU-T SG15 Subject: [Pce] New Liaison Statement, "Liaison Statement to IETF pce WG on draft new G.7715.2 on remote path query" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ITU-T SG15 , Greg Jones List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Title: Liaison Statement to IETF pce WG on draft new G.7715.2 on remote path query Submission Date: 2006-07-05 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=243 From: Greg Jones(ITU-T SG 15) To: IETF pce WG(Adrian Farrel , JP Vasseur ) Cc: Scott Bradner Ross Callon Bill Fenner pce@ietf.org Yoichi Maeda Steve Trowbridge Reponse Contact: ITU-T SG15 Greg Jones Technical Contact: Hing-Kam Lam Purpose: For information Body: An electronic copy of this liaison statement is attached and is also available at: ftp://ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html Attachment(s): Liaison Statement to IETF pce WG on draft new G.7715.2 on remote path query - body text (https://datatracker.ietf.org/documents/LIAISON/file335.doc) _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 05 18:32:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFv1-0000gf-Hi; Wed, 05 Jul 2006 18:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFv0-0000ga-CJ for pce@ietf.org; Wed, 05 Jul 2006 18:32:26 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyFuy-0004iv-Ru for pce@ietf.org; Wed, 05 Jul 2006 18:32:26 -0400 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-3sarge1) with ESMTP id k65MWMF1005828; Thu, 6 Jul 2006 00:32:22 +0200 In-Reply-To: <9C489CBA-94A5-4A38-B04B-4959571A535D@cisco.com> To: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 6 Jul 2006 00:32:17 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/06/2006 00:32:22, Serialize complete at 07/06/2006 00:32:22 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 1d58e27742db87c7abc0e01ab23e3334 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 j-p the question boils down to how the receiving domain deduces the correct TE links to perform the concatenation operation you are describing thanks, -dimitri. JP Vasseur 06/07/2006 00:11 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: pce@ietf.org Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt hi, On Jul 5, 2006, at 6:01 PM, Dimitri.Papadimitriou@alcatel.be wrote: hi from the below exchange "> Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to each BR-ex(i-1), but in order to build the tree we need the paths to be computed from each BR-en(i-1) to each BR-en(i). These paths include the inter-domain TE links (where they exist). This is actually not needed - see below So.... Either there is an assumption that this TE link information is available, or there is a step missing in the process. Perhaps the authors could clarify here and in the I-D. OK let's clarify then. The text in the draft says: Step i: - For i=n-1 to 2: PCE(i) concatenates the ASi topology (using its TED) with the received VSPT(i+1) and computes VSPT(i). And this is where we could elaborate if you will. What PCE(i) has to do is to concatenate the received VSPT from PCE(i+1) to its ASi topology (by the way, there's a typo there, it should read "domain" rather than "AS") including the inter-AS TE links (in the case of Inter-AS). Once such operation is performed, it is quite easy to compute the new VSPT (MP2P tree) from each BN(j,i) and return it to the upstream PCE." i read - assumption is that we need inter-AS link knowledge - response: no we don't don't but once explanations are provided we notice that "including the inter-AS TE links" knowledge is required so i am not sure that author's of this document clarified the real issue that was initial pointed Several requests for clarifications were added. The new text reads: Step i: - For i=n-1 to 2: PCE(i) concatenates the topology of domain (i) (using its TED) with the received VSPT(i+1). In the case of Inter-AS TE LSP computation, this requires to also add the inter-AS TE links connecting the domain (i) to the domain (i+1). Then PCE(i) computes VSPT(i) (P2MP tree made of the shortest constrained paths between each BN-en(j,i) and the TE LSP destination). In the case of Inter-AS TE, this operation also includes the links connecting ASBRs of ASi and ASi+1. The text clearly explains that Inter-AS TE link knowledge is required. Is there something that you don't find clear enough ? Thanks. JP. thanks, - dimitri. JP Vasseur 29/06/2006 16:09 To: Adrian Farrel cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, pce@ietf.org Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Hi Adrian, Let me do this: 1) Reply to several emails individually 2) Send a summary to the list to make sure that all comments have been captured and will be addressed in the next revision. See below, On Jun 26, 2006, at 11:01 AM, Adrian Farrel wrote: Thanks Dimitri, This is converging nicely. ok (nice summary) - i think the whole debate is on point 2) since last meeting discussions - if one agrees that we don't solve this issue - then being aware upfront/descriptive of limitations, conditions and workability is really appropriated - let's assume this is (hopefully) the case Then that is an action for the authors to make points 1 and 2 *very* clear in the I-D (at the top!) No problem to move some statement at the top ;-) Will do. Here is the proposed new abstract: Abstract The ability to compute constrained shortest Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. the more important implication is point 3) - if this inter-domain link is not provided - de facto - as part of the method what does this method really provides ? i mean section 7. reads as if you can not flood just makes PCE aware of that TE data; however, point on whether this info is flooded or passed to the PCE or not the main issue is how this information is locally obtained ? what does happen if this information is only partially or not known, changing conditions, a unidirectional LSP reserves bandwidth downstream how accounting occurs (edges need to be aware of forward and reverse bandwidth), etc. I suspect you do not mean section 7? So, if I may rephrase.... You are concerned about how the brpc process would operate if there is an inter-domain link (e.g. inter-AS) and the TE information for this link is not fully known. Let's quickly look at who needs to know. The downstream PCE provides paths from entry points to its domain (BR-en(i)) to the destination. So the downstream PCE is not interested in the TE links entering the domain. The upstream PCE provides paths from the entry points to its domain (BR-en(i-1)) to the destination. It computes these by computing 'optimal' paths from each BR-en(i-1) to the destination [says the I- D in step 2]. But this is highly unclear! Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to each BR-ex(i-1), but in order to build the tree we need the paths to be computed from each BR-en(i-1) to each BR-en(i). These paths include the inter-domain TE links (where they exist). This is actually not needed - see below So.... Either there is an assumption that this TE link information is available, or there is a step missing in the process. Perhaps the authors could clarify here and in the I-D. OK let's clarify then. The text in the draft says: Step i: - For i=n-1 to 2: PCE(i) concatenates the ASi topology (using its TED) with the received VSPT(i+1) and computes VSPT(i). And this is where we could elaborate if you will. What PCE(i) has to do is to concatenate the received VSPT from PCE(i+1) to its ASi topology (by the way, there's a typo there, it should read "domain" rather than "AS") including the inter-AS TE links (in the case of Inter-AS). Once such operation is performed, it is quite easy to compute the new VSPT (MP2P tree) from each BN(j,i) and return it to the upstream PCE. So I propose to rephrase as follows: Step i: - For i=n-1 to 2: PCE(i) concatenates the topology of domain (i) (using its TED) with the received VSPT(i+1). In the case of Inter-AS TE LSP computation, this requires to also add the inter-AS TE links connecting the domain (i) to the domain (i+1). Then PCE(i) computes VSPT(i) (P2MP tree made of the shortest constrained paths between each BN-en(j,i) and the TE LSP destination). Does that clarify ? Thanks. JP. Thanks, Adrian "Adrian Farrel" 26/06/2006 15:14 Please respond to "Adrian Farrel" To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Hi, I'm trying to parse something out of this thread. 1. It is clear that brpc *demands* that the sequence of domains is already known before brpc is executed. In my opinion, this is clear in the I-D, but it would not hurt to make it clearer. A statement in the Abstract and Introduction would achieve this. 2. The mechanism by which the sequence of domains is known is out of scope for the procedure. It is not clear whether this is a limitation of the process, or not. But in my opinion this is consistent with the guidance that the WG received from the IAB when we were chartered. We are not trying to 'solve the Internet', so selection of domains is out of scope. 3. brpc *does* include mechanisms for the selection of interdomain links and/or nodes. This is more complex than the simple selection of these points of attachment because the connection to use may depend on the TE paths within the domains. IMO, brpc is constructed specifically for this purpose. If we did not need this function, we could use pd-path computation with visibility of the inter-domain TE links. 4. The discussion is not helped by debate about the precise wording around 'constraint'. Let us say that "the sequence of domains to be traversed is provided by an external source as a limiting factor to the computation or choice of paths." Do we all agree with these statements? Cheers, Adrian ----- Original Message ----- From: To: "JP Vasseur" Cc: ; ; Sent: Monday, June 26, 2006 7:51 AM Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt hi j-p - see in-line JP Vasseur 26/06/2006 02:42 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt hi dimitri, On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: hi j-p - see in-line JP Vasseur 26/06/2006 01:14 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Adrian Farrel" , nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt hi dimitiri, On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: the following comment was also discussed during last meeting "== Section 5.1 I like the simplicity of section 5.1, but I think you need to point out that if the sequence of domains is known a priori (can you determine it a priori?) then the path computed might not be 'optimal' in the usual sense of the word, but that this is OK because the ordered list of domains constitutes an additional constraint on the computation so the resultant path *is* optimal within the constraints applied. Can't agree more. Good suggestion, thanks. Updated text: "The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined a priori or during the path computation procedure. The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." => in brief, how to determine the sequence through which path computation has to be performed because if this sequence was known there is no need for such procedure (only inter-domain link selection would be required) - Not correct; even if you know the sequence you still need the BRPC procedure to figure out the set of BN (boundary Nodes) to traverse to get the shortest inter-domain TE LSP: this is the whole issue with inter-domain, otherwise per-domain path computation would be sufficient. [dp] inter-domain link selection (as i mentioned) implies what you mean with boundary nodes selection - you could rephrase by access/exit point selection exact same business but again even if you know the sequence you still need BRPC to determine the set of BN (or exit point - same thing) that will give you the shortest inter-domain path. Look you wrote "in brief, how to determine the sequence through which path computation has to be performed because if this sequence was known there is no need for such procedure", which is not correct. Even if you know the sequence of domains, you still need the procedure to get the exit/entry point (named BN) that provide you the shortest inter-domain path. now adrian mentions that pre- determination becomes a new constraint - well actually this is not a constraint for the TE LSP itself but a restriction on the domain set known to be (a-priori) supportive of the method such as to make the method not returning an error message No, this is a constraint: "Give me the shortest path (potentially made of loose hops (the BNs)) that provides the shortest end to end path, considering that the additional constraint is to traverse the following set of domains . [dp] incorrect, this is not a "TE LSP" constraint - Who said that this was a TE LSP constraint ? This is *a* constraint. If you impose the set of domain, this is a constraint. Please read the text: "The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint)." [dp] i read this, mind you, my point is that this is not a "constraint" of the same nature as the one you're making use such as minimize delays or whatsover - this constraint is introduced from the computation technique and mechanism of this proposed method Note that at this point, I still do not see the point that you're trying to make here ? since so far when a set of domains do not support/or support a given computation has not yet become a constraint hence sentence "The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." should as far as i understand the method fulfill the following a) this method provides a result iff all domains traversed by the request support the proposed method BRPC is a multi-PCE based approach where you need at least one PCE per-domain. [dp] indeed, but one PCE supporting that method and having FULL visibility of the domain So what is your point here ? [dp] that the set of conditions to have this method workable is larger than the one listed in this doc. b) this method provides an "optimal" result iff b1) all possible sequences of domains have been traversed (starting from the root) and are supportive of that method - as there might be an optimal path through a domain not supporting this method - heu ... yes indeed. If a domain does not support the method, the method cannot be used to compute the path. b2) there is no discontinuity in the availability of the inter-AS link information on each PCE performing a given selection - indeed a domain might be supportive of the method without supporting inter-AS link flooding No this is not a requirement, just an optimization. The only requirement is for the PCE to get the TE-related data about the Inter- AS links. I'll detail a bit more in the next revision. [dp] then you can never achieve - You can never achieve what ? Sorry Dimitri, I'd love to accommodate your comment but I do not see your point ... hopefully we'll have a bit of time in Montreal to discuss if that does not work by email. [dp] my point is that without this additional information you can not achieve the expected result - i pointed to your own text to indicate that this information is a must have in order to achieve this objective using your own words to make it more straighforward - "you still need the BRPC procedure to figure out the set of BN (boundary Nodes) to traverse to get the shortest inter-domain TE LSP: this is the whole issue with inter-domain, otherwise per-domain path computation would be sufficient." b3) at each step there is no PCE that has partial visibility of a given domain This is not specific to BRPC. Even with intra-domain if you want to compute the path for a TE LSP, you cannot always use the PCE if it has a partial visibility. Note that this also applies to the case of co-located PCE (when the path is computed by the head-end). [dp] hence, to BRPC as well b4) during the selection process no network conditions changes (that would make the returned result void) Again, this applies to other cases as well. [dp] ditto Ah so we agree here :-) What was your comment then ? [dp] that you need to include these set of working conditions in the document itself, the document looks like quite simple in terms of conditions for having the proposed method working as expected while when you take a closer look at it this is not the case Thanks. JP. thanks. JP. JP Vasseur 23/06/2006 16:11 To: "Adrian Farrel" cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com Subject: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Many Thanks Adrian for the comments. We incorporated the vast majority of them in the new revision (just posted). See below for the comments requesting some clarification. On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: Hi, Thanks for keeping these ideas alive. Here are some picky thoughts that you may want to include in the next revision to make it more robust as a document. I don't have any issues with the basic process. Thanks, Adrian == Is this I-D likely to be Informational or Standards Track? From Appendix A, this looks like Standards Track. Can you remove Appendix A and put the status in the usual place in the header? == Status has been updated (Informational) but let's discuss this later on. FYI, it does not appear on the front page when using the xml2rfc editor (which by the way is excellent), thus the appendix addition. It would be nice if the Abstract contained a pithy summary of brpc and/or gave the motivation for the draft. For example, what is the method trying to achieve that isn't achievable by other methods? Or, what is the fundamental element of brpc that is not in other methods? Agree. Here is the new Abstract: "The ability to compute constrained shortest Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths, using a backward recursive path computation technique while fully preserving confidentiality requirements across domains. " == I'm assuming that section 1 is for short term information only and will be deleted (in the next revision?) == Indeed, just to provide a bit of history for the ones who have been following inter-domain path computation for a while. == Section 4 - No topology or resource information is distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple domains. You should clarify what you are saying here, because many would argue that reachability information (i.e. external routes) constitutes topology and resource information. OK fine == Section 4 - While certain constraints like bandwidth can be used across different domains, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] could be translated at domain boundaries. If required, it is assumed that, at the domain boundary LSRs, there will exist some sort of local mapping based on offline policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process. Why does the policy agreement need to be offline? It should actually read "pre-determined". Actually the best thing to do here is to remove "off-line" == Section 5 No assumption is made on the actual path computation algorithm in use by the PCE (it can be any variant of CSPF, algorithm based on linear- programming to solve multi-constraints optimization problems and so on). Suggest that you delete the text in parenthesis because it is making suggestions that border on assumptions! Well I'd suggest to keep it as is since the point is to differentiate the path computation procedure from the algorithm to compute each intra- domain path segment. Furthermore, we'd like to highlight the fact that the BRPC procedure does not mandate for each PCE to use CSPF, could be other algorithm. == Section 5.1 and throughout "BRPC path computation" seems to be tautologous It is actually a double tautology ;-) (fixed). == Section 5.1 I like the simplicity of section 5.1, but I think you need to point out that if the sequence of domains is known a priori (can you determine it a priori?) then the path computed might not be 'optimal' in the usual sense of the word, but that this is OK because the ordered list of domains constitutes an additional constraint on the computation so the resultant path *is* optimal within the constraints applied. Can't agree more. Good suggestion, thanks. Updated text: "The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined a priori or during the path computation procedure. The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." == Section 5.2 The introduction of the term Virtual Shortest Path Tree is hard to parse and to my mind the definition is arse about tit. I think you could usefully add some textual definition of what the VSPT is trying to achieve, before presenting it in pictorial or abstract form. Even more important (I think) is the fact that the tree as presented "represents the shortest path between the destination and BR-en (j,i)..." Frankly, we are building directional paths in exactly the oposite direction! This is an abstract form of representation but see below, So the VSPT is still a tree, but it is an MP2P tree, not a P2MP tree as described. I suspect that this is just a textual descriptive issue rather than anything broken in the process. I clarified the text to avoid any ambiguity (VSPT defined as a MP2P tree). == Section 5.2 I suggest that you pull the note (Note: in term of computation...) out into a separate section. It doesn't belong in the middle of section 5.2. You will probably want to re-write the text as well since the unidirectional limit is not necessary. Also to explain 'flood' - flood to where, and how, and by whom? And you will want to add to pieces of information: - the link to the I-D that defines how to do this - a description of what happens if this process is not used. This only works for unidirectional LSPs: indeed, the exit boundary node can flood TE-related data in its LSA/LSP for the link exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP running on the link but how would a node in domain (i) get the TE-related data for the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on unidirectional link. Are we in sync ? == Section 5.2 The paragraph that begins "BRPC guarantees to find the optimal..." is a nascent Applicability Statement. I suggest moving this to another Section and significantly beefing it up. You need to describe more fully: - how ECMP works (the PCC has to request the return of more than one path) - how diversity works (i.e. section 9 fits in here) - how some freedom of selection of domains can be offered - how to mix the method with other mechanisms This was (and is) planned for future revision. Note that ECMP and diversity are discussed already but we're planning the flesh out these sections in further revision. == Section 7 If the BRPC procedure cannot be completed because a PCE along the domain path does not support the procedure, a PCErr message is returned by the upstream PCE with a Error-Type "BRPC procedure completion failure". The PCErr message MUST be relayed to the requesting PCC. Not clear to me whether PCE(n) is supposed to know that PCE(n+1) does not support brpc, presumably through capabilities configuration/advertisement/negotiation, or whether PCE(n+1) is supposed to respond to the path computation request saying that it does not support bit-V of the RP object. If the latter, presumably the PCErr comes from PCE(n+1) and not from PCE(n) as documented. Good catch, typo: it should read "a PCErr message is returned to the upstream". The plan is to define a capability bit (IGP) in a further revision. == Section 8 Metric normalisation is a great potential solution, but how does it fit with AS topology confidentiality? What is the solution to providing discretion about what TE connectivity is available within an AS, and operating brpc? Metric normalization is handled locally by the PCE and does not impact the BRPC procedure per-say. As far as confidentiality is concerned, this only requires for the SPs to exchange metric mapping information (nothing related to the network topology or resources); for example SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 A simple metric normalization can then be performed on the PCE thanks to simple cost mapping tables. Section 10 Some of this text has been seen before in this I-D Why do you single out LSP stitching as possibly breaking end-to-end optimality. There is functionally no difference between stitching and nesting in this respect. But further, your statement about stitching is pejorative! If you say that "In the case where a domain has more than one BR-en or more than one BR-ex, optimality after some network change within the domain can only be guaranteed by re-executing the full brpc computation" then I would agree with you. But as phrased, it implies that making a per-domain re-optimisation could make the path *less* optimal. This (of course) is not the case - per-domain optimisation will always improve or leave the same end-to-end optimality (in the case where new resources are made available this is obvious; in the case of a network failure, *any* path is better than no path!) And, lastly, the text about re-optimisation belongs in the next section, not in this section. Yes I wanted to leave that text to keep track of who would read the ID, expecting reaction ;-)) Per-domain reoptimization would always improve the current path *but* in case of stitched LSPs, TE LSP segments are computed by the stitching point; thus in case of failure, they could end up following a non optimal path whereas in the case of contiguous LSP, the BRPC procedure would be called again thus leading to the optimal path again. The point that I was trying to make is "if you have a stitched LSP and rely on BRPC when first signaled in an attempt to get an optimal path, you need to consider the interaction between the local reopt mode and BRPC if the goal is to preserve an optimal path at any given time". Anyway, we're on the same page and I agree and the text should be reworded according to your proposal to avoid any misunderstanding. == Section 13 I would like you to discuss the issues of confidentiality of topology information at greater length. It seems that you would possibly use this technique in conjunction with path cookies, which is fine. But, are there two things you cannot escape from? - indicating which BR-en provides best connectivity - indicating the metric for multiple BR-ens Maybe there are some things that can be done here based on policy, including not reporting all of the BR-ens, ranking rather than giving absolute metrics, etc. But these would compromise optimality. Indeed. Maybe the PCE(n+1) should carefully monitor and limit (statistically and by policy) brpc requests so that excessive information is not divulged? Since one of objectives for using the BRPC procedure is to compute an optimal path, we need to know at least the BN (Boundary Nodes) and the cost. == I wouldn't mind seeing a Management Considerations section. Do we need to be able to examine the pruned pieces of VSPT at transit PCEs? What are the implications of reporting multiple VSPT branches in PCEP to the MIB modules? Is brpc support something that needs to be configured: per PCE?; per PCE-neighbor? What are the implications on existing protocols (IGPs? PCEP?) of using brpc? Absolutely ! I put a placeholder for a further revision. Fully supportive of adding such section. Many Thanks for your comments ! JP. etc. == I think Jean-Louis' email address needs updating == The document would benefit from a little care in the formatting, and you could usefully re-read it for missing words, etc. == _______________________________________________ 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 _______________________________________________ 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 Fri Jul 07 07:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyoe8-00015H-QF; Fri, 07 Jul 2006 07:37:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyoe7-00015C-3o for pce@ietf.org; Fri, 07 Jul 2006 07:37:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyoe5-0003Kn-R6 for pce@ietf.org; Fri, 07 Jul 2006 07:37:19 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 07 Jul 2006 04:37:17 -0700 X-IronPort-AV: i="4.06,216,1149490800"; d="scan'208"; a="303815051:sNHT27771440" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k67BbHbD016689 for ; Fri, 7 Jul 2006 04:37:17 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k67BbGfr013420 for ; Fri, 7 Jul 2006 04:37:17 -0700 (PDT) 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, 7 Jul 2006 07:37:16 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 07:37:16 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <859A0BF0-8780-44DF-A0C8-73EAB580D67E@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: pce@ietf.org From: JP Vasseur Date: Fri, 7 Jul 2006 07:37:14 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Jul 2006 11:37:16.0195 (UTC) FILETIME=[B2793F30:01C6A1B9] DKIM-Signature: a=rsa-sha1; q=dns; l=107; t=1152272237; x=1153136237; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Gentle=20Reminder=3A=20slides; X=v=3Dcisco.com=3B=20h=3DeGv1shBhO9/2EdrSHDO31OGBaCE=3D; b=DRtgNzBuGaUNwXa6SBr4YkhlRf4w/H9uxuNbslUaKUBbVWZqCAO4s6+hAjv2Dxw6Jv8hjlkA pehPuJBCu3uI1DWKDI72kcoNWQbmcrYFxDlAAki16iw9iVPiNqvuohRQ; Authentication-Results: sj-dkim-8.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Pce] Gentle Reminder: 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: , Errors-To: pce-bounces@lists.ietf.org Dear WG, It would be very nice if you could send us your slides by today. Thanks. JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 14 08:37:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1MvH-00048T-Or; Fri, 14 Jul 2006 08:37:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1MvG-00046K-Qw for pce@ietf.org; Fri, 14 Jul 2006 08:37:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1MlS-000334-EW for pce@ietf.org; Fri, 14 Jul 2006 08:27:26 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1MVQ-00045r-WF for pce@ietf.org; Fri, 14 Jul 2006 08:10:56 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1MVN-000AoZ-Uy for pce@ietf.org; Fri, 14 Jul 2006 12:10:50 +0000 Message-ID: <44B789D3.1070902@psg.com> Date: Fri, 14 Jul 2006 14:10:59 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pce@ietf.org Content-Type: multipart/mixed; boundary="------------020302070506060404030301" X-Spam-Score: -2.6 (--) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 Cc: Subject: [Pce] path key and brpc X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------020302070506060404030301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit the draft speaks about inter-as comp methods in introduction e.g brpc but how the latter can be used in conjunction with pks ? the draft mentions it may result into two documents (one in ccamp and the other in pce wg) -> good idea because path key technique can be used independently of the presence of a initial pcc-/pce- pce exchange the latter would result in the possibility to make use of pks with pd pc --------------020302070506060404030301 Content-Type: text/plain; charset=UTF-8; name="www.ietf.org/internet-drafts/draft-bradford-pce-path-key-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="www.ietf.org/internet-drafts/draft-bradford-pce-path-key-00.txt" Networking Working Group Rich Bradford (Ed) IETF Internet Draft JP Vasseur Cisco Systems, Inc. Adrian Farrel Old Dog Consulting Proposed Status: Standard Expires: December 2006 June 2006 draft-bradford-pce-path-key-00.txt Preserving Topology Confidentiality in Inter-Domain Path Computation and Signaling Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Bradford, Vasseur and Farrel 1 draft-bradford-pce-path-key-00.txt June 2006 Abstract Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE 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, thus disclosing internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary LSR during TE LSP setup as the LSP enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol (RSVP) explicit route object. Table of contents To be Added Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 1. Note It must be noted that this document proposes RSVP-TE and PCEP protocol extensions and may eventually result in two separate documents to be discussed in the CCAMP and PCE Working Groups respectively. 2. Terminology ASBR Routers: border routers used to connect to another AS of a different or the same Service Provider via one or more links inter-connecting between ASs. Bradford, Vasseur, and Farrel 2 draft-bradford-pce-path-key-00.txt June 2006 CPS: Confidential Path Segment. A segment of a path that contains nodes and links that the AS policy requires to not be disclosed outside the AS. Inter-AS TE LSP: A TE LSP that crosses an AS boundary. LSR: Label Switching Router. LSP: Label Switched Path. PCC: Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element: an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. TE LSP: Traffic Engineering Label Switched Path 3. Introduction Path computation techniques using the Path Computation Element (PCE) have been described in [PCE-ARCH] and allow for path computation of inter-domain Multiprotocol Label Switching (MPLS) traffic engineering (TE) Label Switched Paths (LSPs). An important element of inter-domain TE is that TE information is not usually shared between domains for scalability and confidentiality reasons ([RFC4105] and [RFC4216]). Therefore, a single PCE is unlikely to be able to compute a full inter-domain path. Two routing scenarios can be used for inter-domain TE LSPs: one using per-domain path computation (defined in [PD-PATH-COMP]), and the other using a PCE-based path computation technique with cooperation between PCEs (as described in [PCE-ARCH]). In this second case, paths for inter-domain LSPs are computed by cooperation between PCEs each of which computes a segment of the path across one domain. Such a path computation procedure is described in [BRPC]. If confidentiality is required between domains (such as would very likely be the case between ASs belonging to different service providers) then cooperating PCEs cannot exchange path segments or else the receiving PCE and the Path Computation Client (PCC) will be able to see the individual hops through another domain. We define the part of the path which we wish to keep confidential as the Confidential Path Segment (CPS). Bradford, Vasseur, and Farrel 3 draft-bradford-pce-path-key-00.txt June 2006 One mechanism for preserving the confidentiality of the CPS is for the PCE to return a path containing a loose hop for the segment internal to a domain that must be kept confidential. The concept of loose hops for the route of an LSP is described in [RFC3209]. The Path Computation Element Communication Protocol (PCEP) supports the use of paths with loose hops, and it is a local policy decision at a PCE whether it returns a full explicit path or uses loose hops. If loose hops are used, the TE LSPs are signaled as normal ([RFC3209]), and when a loose hop is encountered in the explicit route it is resolved by performing a secondary path computation. Given the nature of the cooperation between PCEs in computing the original path, this secondary computation occurs at a Label Switching Router (LSR) at a domain boundary and the route is expanded as described in [PD-PATH-COMP]. The PCE-based computation model is particularly useful for determining mutually disjoint inter-domain paths such as might be required for service protection. A single path computation request is used. However, if loose hops are returned, the path of each LSP must be recomputed at the domain boundaries as the LSPs are signaled, and since the LSP signaling proceeds independently for each LSP, disjoint paths cannot be guaranteed since the LSRs in charge of expanding the EROs are not synchronized. Therefore, using the loose hop technique, path segment confidentiality and path diversity are mutually incompatible requirements. This document defines the notion of a Path Key that is a token that replaces a path segment in an explicit route. The Path Key can be encoded as a Path Key Sub-object (PKS) which can be exchanged in PCEP [PCEP] for PCE path computation results and subsequent computation requests, and in RSVP-TE [RFC3209] for signaling of explicit paths. The PKS may also, optionally, be used in recorded routes in RSVP-TE. The next section provides the details for this solution. 4. Path-Key Solution The Path-Key solution may be applied in the PCE-based path computation context as follows. A PCE computes a path segment and replaces it in the path reported to the PCC (or another PCE) by one or more sub-objects referred to as the PKS. The entry and boundary LSR of each CPS SHOULD be specified as hops in the Bradford, Vasseur, and Farrel 4 draft-bradford-pce-path-key-00.txt June 2006 returned path immediately preceding the PKS, but where two PKSs are supplied in sequence the entry node to the second MAY be encoded within the first. The exit node of a CPS MAY be present as a strict hop immediately following the PKS, but MAY also be hidden as part of the PKS and through the use of a subsequent loose hop. The PKS, itself, MAY be supplied as a loose hop, but is RECOMMENDED to be used as a strict hop immediately following the hop that indicates the boundary LSR. 4.1. Mode of Operation During path computation, when local policy dictates that confidentiality must be preserved for all or part of the path segment being computed, the PCE associates a path-key with the computed path for the CPS, places its own identifier (its PCE-ID) along with the path-key in a PKS, and inserts the PKS in the path returned to the PCC or the collaborating PCE immediately after the sub-object that identifies the LSR that will expand the PKS into a explicit path hops. This will usually be the LSR that is the start point of the CPS. The PCE that generates a PKS MUST store the computed path segment and the path-key for later retrieval. A local policy SHOULD be used to determine for how long to retain such stored information, and whether to discard the information after it has been queried using the procedures described below. TBD: Need to define the scope of the PKS and spell out the restrictions on Path Key re-use. A head-end LSR that is a PCC converts the path returned by a PCE into an explicit route object (ERO) that it includes in the Resource Reservation Protocol (RSVP) Path message. If the path returned by the PCE contains PKSs these are included in the ERO. Like any other sub-objects, the PKS is passed transparently from hop to hop, until it becomes the first sub-object in the ERO. This will occur at the start of the CPS which will usually be the domain boundary. The PKS MUST be preceded by an ERO sub-object that identifies the LSR that must expand the PKS, so the PKS will not be encountered in ERO processing until the LSR that can process it. An LSR that encounters a PKS when trying to identify the next-hop retrieves the PCE-ID from the PKS and sends the path-key to the PCE in a PCEP query the details of which will be described in a further revision of this document. Upon receiving the path query, the PCE identifies the computed path segment using the supplied path-key, and returns the previously computed path segment in the form of explicit hops to Bradford, Vasseur, and Farrel 5 draft-bradford-pce-path-key-00.txt June 2006 the requesting node. The requesting node inserts the explicit hops into the ERO and continues to process the LSP setup as per [RFC3209]. Note that if a PCE fails to expand a PKS, the requesting LSR MUST fail the LSP setup and SHOULD use the procedures associated with loose hop expansion failure [RFC3209]. 5. PCEP/RSVP-TE Path Key Sub-object The Path Key sub-object (PKS) may be carried in the Explicit Route Object (ERO) of a PCEP PCRep message [PCEP] or an RSVP-TE Path message [RFC3209]. The PKS is a fixed-length sub-object containing a Path-Key and a PCE-ID. The Path Key is an identifier, or token used to represent the CPS within the context of the PCE identified by the PCE-ID. The PCE-ID identifies the PCE that can decode the Path Key using a reachable IPv4 or IPv6 address of the PCE. Because of the IPv4 and IPv6 variants, two subobjects are defined as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Path Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L The L bit SHOULD NOT be set, so that the sub-object represents a strict hop in the explicit route. Type TBD Path Key with IPv4 address Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8. IPv4 address An IPv4 address of the PCE that can decode this key. The address used SHOULD be an address of the PCE that is always Bradford, Vasseur, and Farrel 6 draft-bradford-pce-path-key-00.txt June 2006 reachable, and MAY be an address that is restricted to the domain in which the LSR that is called upon to expand the CPS lies. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Path Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (16 bytes) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L As above. Type TBD Path Key with IPv6 address Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 20. IPv6 address An IPv6 address of the PCE that can decode this key. The address used SHOULD be an address of the PCE that is always reachable, but MAY be an address that is restricted to the domain in which the LSR that is called upon to expand the CPS lies. 6. Security Considerations This document proposes tunneling secure topology information across an untrusted AS, so the security considerations are many and apply to PCEP and RSVP-TE. Issues include: - Security of the CPS (can other network elements probe for expansion of path-keys, possibly at random?). - Authenticity of the path-key (resilience to alteration by intermediaries, resilience to fake expansion of path-keys). - Resilience from DNS attacks (insertion of spurious path-keys; flooding of bogus path-key expansion requests). Bradford, Vasseur, and Farrel 7 draft-bradford-pce-path-key-00.txt June 2006 7. Manageability Considerations TBD 8. IANA considerations The IANA section will be detailed in further revision of this document. For RSVP, it will include code point requests for the three new ERO sub-objects, and a new ErrorSpec Error Code. For PCEP, it will include code point requests for the three new computed path sub-objects. 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Bradford, Vasseur, and Farrel 8 draft-bradford-pce-path-key-00.txt June 2006 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element (PCE) communication Protocol (PCEP)", draft-vasseur-pce-pcep, work in progress. 10.2. Informational References [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture, work in progress. [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path- comp, work in progress. [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Path", draft-vasseur-pce-brpc, work in progress. [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic Engineering requirements", RFC 4216, November 2005. 11. Authors' Addresses: Rich Bradford (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough , MA - 01719 USA Email: rbradfor@cisco.com J.-P Vasseur Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough , MA - 01719 Bradford, Vasseur, and Farrel 9 draft-bradford-pce-path-key-00.txt June 2006 USA Email: jpv@cisco.com Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Bradford, Vasseur, and Farrel 10 --------------020302070506060404030301 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 --------------020302070506060404030301-- From pce-bounces@lists.ietf.org Fri Jul 14 09:13:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NUJ-0007RN-OF; Fri, 14 Jul 2006 09:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NUH-0007R3-Ta for pce@ietf.org; Fri, 14 Jul 2006 09:13:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1NTu-0004Cc-Nm for pce@ietf.org; Fri, 14 Jul 2006 09:13:26 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2006 06:13:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,242,1149490800"; d="scan'208"; a="32217420:sNHT30669340" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EDDLg8019262; Fri, 14 Jul 2006 09:13:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6EDDLdW017616; Fri, 14 Jul 2006 09:13:21 -0400 (EDT) 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.1830); Fri, 14 Jul 2006 09:13:21 -0400 Received: from [132.219.17.214] ([10.86.243.100]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 09:13:20 -0400 In-Reply-To: <44B789D3.1070902@psg.com> References: <44B789D3.1070902@psg.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30DD16B4-4F39-4B0E-86AF-DEDCDEC705DC@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] path key and brpc Date: Fri, 14 Jul 2006 09:13:22 -0400 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Jul 2006 13:13:20.0610 (UTC) FILETIME=[47396C20:01C6A747] DKIM-Signature: a=rsa-sha1; q=dns; l=22704; t=1152882801; x=1153746801; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20[Pce]=20path=20key=20and=20brpc |To:dpapadimitriou@psg.com,=20dimitri.papadimitriou@alcatel.be; X=v=3Dcisco.com=3B=20h=3DaaQHz+g+ACDH/UrLMQnhPYSgwbQ=3D; b=WaBJcXtKC9DGl2jX6rQvsYPWJY0REB9ltMKno4tcJybcRnu5UcI+uDl32PE9+lPdJKYWvU09 AIgupat+yLjfX0huz9OlTU5z4VJBUS2fqoiJC51IogKKwMnQwKG1yv8e; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ed37b243475b9c4ffb6a3f90050819d 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, On Jul 14, 2006, at 8:10 AM, dimitri papadimitriou wrote: > the draft speaks about inter-as comp methods in introduction e.g =20 > brpc but how the latter can be used in conjunction with pks ? > BRPC can be used in conjunction with PKS since the set of returned =20 paths by a downstream PCE can be made of loose hops. Path-Keys are =20 then accumulate along the computed path. > the draft mentions it may result into two documents (one in ccamp =20 > and the other in pce wg) -> good idea because path key technique =20 > can be used independently of the presence of a initial pcc-/pce- =20 > pce exchange > > the latter would result in the possibility to make use of pks with =20 > pd pc > Indeed. Thanks. JP. > key-00.txt> > > > > Networking Working Group Rich Bradford (Ed) > IETF Internet Draft JP Vasseur > Cisco Systems, Inc. > Adrian Farrel > Old Dog Consulting > > > > Proposed Status: Standard > Expires: December 2006 > June 2006 > > > > draft-bradford-pce-path-key-00.txt > > > Preserving Topology Confidentiality in Inter-Domain Path > Computation and Signaling > > Status of this Memo > > By submitting this Internet-Draft, each author represents that > any applicable patent or other IPR claims of which he or she is > aware have been or will be disclosed, and any of which he or she > becomes aware will be disclosed, in accordance with Section 6 of > BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet-Drafts > as reference material or to cite them other than as "work in > progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > > > > > > > Bradford, Vasseur and Farrel 1 > > > draft-bradford-pce-path-key-00.txt June 2006 > > Abstract > > Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) > Label Switched Paths (LSPs) may be computed by Path Computation > Elements (PCEs). Where the TE 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, > thus disclosing internal topology information. This issue may be > circumvented by returning a loose hop and by invoking a new path > computation from the domain boundary LSR during TE LSP setup as > the LSP enters the second domain, but this technique has several > issues including the problem of maintaining path diversity. > > This document defines a mechanism to hide the contents of a > segment of a path, called the Confidential Path Segment (CPS). The > CPS may be replaced by a path key that can be conveyed in the PCE > Communication Protocol (PCEP) and signaled within in a Resource > Reservation Protocol (RSVP) explicit route object. > > > > Table of contents > To be Added > > Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > RFC-2119 [RFC2119]. > > 1. Note > > It must be noted that this document proposes RSVP-TE and PCEP > protocol extensions and may eventually result in two separate > documents to be discussed in the CCAMP and PCE Working Groups > respectively. > > 2. Terminology > > ASBR Routers: border routers used to connect to another AS of a > different or the same Service Provider via one or more links > inter-connecting between ASs. > > > Bradford, Vasseur, and Farrel 2 > > > draft-bradford-pce-path-key-00.txt June 2006 > > CPS: Confidential Path Segment. A segment of a path that contains > nodes and links that the AS policy requires to not be disclosed > outside the AS. > > Inter-AS TE LSP: A TE LSP that crosses an AS boundary. > > LSR: Label Switching Router. > > LSP: Label Switched Path. > > PCC: Path Computation Client: any client application requesting a > path computation to be performed by a Path Computation Element. > > PCE: Path Computation Element: an entity (component, application > or > network node) that is capable of computing a network path or route > based on a network graph and applying computational constraints. > > TE LSP: Traffic Engineering Label Switched Path > > 3. Introduction > > Path computation techniques using the Path Computation Element > (PCE) have been described in [PCE-ARCH] and allow for path > computation of inter-domain Multiprotocol Label Switching (MPLS) > traffic engineering (TE) Label Switched Paths (LSPs). > > An important element of inter-domain TE is that TE information is > not usually shared between domains for scalability and > confidentiality reasons ([RFC4105] and [RFC4216]). Therefore, a > single PCE is unlikely to be able to compute a full inter-domain > path. > > Two routing scenarios can be used for inter-domain TE LSPs: one > using per-domain path computation (defined in [PD-PATH-COMP]), and > the other using a PCE-based path computation technique with > cooperation between PCEs (as described in [PCE-ARCH]). In this > second case, paths for inter-domain LSPs are computed by > cooperation between PCEs each of which computes a segment of the > path across one domain. Such a path computation procedure is > described in [BRPC]. > > If confidentiality is required between domains (such as would very > likely be the case between ASs belonging to different service > providers) then cooperating PCEs cannot exchange path segments or > else the receiving PCE and the Path Computation Client (PCC) will > be able to see the individual hops through another domain. We > define the part of the path which we wish to keep confidential as > the Confidential Path Segment (CPS). > > Bradford, Vasseur, and Farrel 3 > > > draft-bradford-pce-path-key-00.txt June 2006 > > > One mechanism for preserving the confidentiality of the CPS is for > the PCE to return a path containing a loose hop for the segment > internal to a domain that must be kept confidential. The concept > of loose hops for the route of an LSP is described in [RFC3209]. > The Path Computation Element Communication Protocol (PCEP) > supports the use of paths with loose hops, and it is a local > policy decision at a PCE whether it returns a full explicit path > or uses loose hops. > > If loose hops are used, the TE LSPs are signaled as normal > ([RFC3209]), and when a loose hop is encountered in the explicit > route it is resolved by performing a secondary path computation. > Given the nature of the cooperation between PCEs in computing the > original path, this secondary computation occurs at a Label > Switching Router (LSR) at a domain boundary and the route is > expanded as described in [PD-PATH-COMP]. > > The PCE-based computation model is particularly useful for > determining mutually disjoint inter-domain paths such as might be > required for service protection. A single path computation request > is used. However, if loose hops are returned, the path of each LSP > must be recomputed at the domain boundaries as the LSPs are > signaled, and since the LSP signaling proceeds independently for > each LSP, disjoint paths cannot be guaranteed since the LSRs in > charge of expanding the EROs are not synchronized. > > Therefore, using the loose hop technique, path segment > confidentiality and path diversity are mutually incompatible > requirements. > > This document defines the notion of a Path Key that is a token > that replaces a path segment in an explicit route. The Path Key > can be encoded as a Path Key Sub-object (PKS) which can be > exchanged in PCEP [PCEP] for PCE path computation results and > subsequent computation requests, and in RSVP-TE [RFC3209] for > signaling of explicit paths. The PKS may also, optionally, be used > in recorded routes in RSVP-TE. > > The next section provides the details for this solution. > > 4. Path-Key Solution > > The Path-Key solution may be applied in the PCE-based path > computation context as follows. A PCE computes a path segment and > replaces it in the path reported to the PCC (or another PCE) by > one or more sub-objects referred to as the PKS. The entry and > boundary LSR of each CPS SHOULD be specified as hops in the > > > Bradford, Vasseur, and Farrel 4 > > > draft-bradford-pce-path-key-00.txt June 2006 > > returned path immediately preceding the PKS, but where two PKSs > are supplied in sequence the entry node to the second MAY be > encoded within the first. The exit node of a CPS MAY be present as > a strict hop immediately following the PKS, but MAY also be hidden > as part of the PKS and through the use of a subsequent loose hop. > > The PKS, itself, MAY be supplied as a loose hop, but is > RECOMMENDED to be used as a strict hop immediately following the > hop that indicates the boundary LSR. > > 4.1. Mode of Operation > > During path computation, when local policy dictates that > confidentiality must be preserved for all or part of the path > segment being computed, the PCE associates a path-key with the > computed path for the CPS, places its own identifier (its PCE-ID) > along with the path-key in a PKS, and inserts the PKS in the path > returned to the PCC or the collaborating PCE immediately after the > sub-object that identifies the LSR that will expand the PKS into a > explicit path hops. This will usually be the LSR that is the start > point of the CPS. The PCE that generates a PKS MUST store the > computed path segment and the path-key for later retrieval. A > local policy SHOULD be used to determine for how long to retain > such stored information, and whether to discard the information > after it has been queried using the procedures described below. > TBD: Need to define the scope of the PKS and spell out the > restrictions on Path Key re-use. > > A head-end LSR that is a PCC converts the path returned by a PCE > into an explicit route object (ERO) that it includes in the > Resource Reservation Protocol (RSVP) Path message. If the path > returned by the PCE contains PKSs these are included in the ERO. > Like any other sub-objects, the PKS is passed transparently from > hop to hop, until it becomes the first sub-object in the ERO. This > will occur at the start of the CPS which will usually be the > domain boundary. The PKS MUST be preceded by an ERO sub-object > that identifies the LSR that must expand the PKS, so the PKS will > not be encountered in ERO processing until the LSR that can > process it. > > An LSR that encounters a PKS when trying to identify the next-hop > retrieves the PCE-ID from the PKS and sends the path-key to the > PCE in a PCEP query the details of which will be described in a > further revision of this document. > > Upon receiving the path query, the PCE identifies the computed > path segment using the supplied path-key, and returns the > previously computed path segment in the form of explicit hops to > > Bradford, Vasseur, and Farrel 5 > > > draft-bradford-pce-path-key-00.txt June 2006 > > the requesting node. The requesting node inserts the explicit hops > into the ERO and continues to process the LSP setup as per > [RFC3209]. > > Note that if a PCE fails to expand a PKS, the requesting LSR MUST > fail the LSP setup and SHOULD use the procedures associated with > loose hop expansion failure [RFC3209]. > > 5. PCEP/RSVP-TE Path Key Sub-object > > > The Path Key sub-object (PKS) may be carried in the Explicit Route > Object (ERO) of a PCEP PCRep message [PCEP] or an RSVP-TE Path > message [RFC3209]. The PKS is a fixed-length sub-object containing > a Path-Key and a PCE-ID. The Path Key is an identifier, or token > used to represent the CPS within the context of the PCE identified > by the PCE-ID. The PCE-ID identifies the PCE that can decode the > Path Key using a reachable IPv4 or IPv6 address of the PCE. > Because of the IPv4 and IPv6 variants, two subobjects are defined > as follows. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |L| Type | Length | Path Key | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 address (4 bytes) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > L > > The L bit SHOULD NOT be set, so that the sub-object > represents a strict hop in the explicit route. > > Type > > TBD Path Key with IPv4 address > > Length > > The Length contains the total length of the subobject in > bytes, including the Type and Length fields. The Length is always > 8. > > IPv4 address > > An IPv4 address of the PCE that can decode this key. The > address used SHOULD be an address of the PCE that is always > > > Bradford, Vasseur, and Farrel 6 > > > draft-bradford-pce-path-key-00.txt June 2006 > > reachable, and MAY be an address that is restricted to the domain > in which the LSR that is called upon to expand the CPS lies. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |L| Type | Length | Path Key | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 address (16 bytes) | > | | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > L > > As above. > > Type > > TBD Path Key with IPv6 address > > Length > > The Length contains the total length of the subobject in > bytes, including the Type and Length fields. The Length is always > 20. > > IPv6 address > > An IPv6 address of the PCE that can decode this key. The > address used SHOULD be an address of the PCE that is always > reachable, but MAY be an address that is restricted to the domain > in which the LSR that is called upon to expand the CPS lies. > > > 6. Security Considerations > > This document proposes tunneling secure topology information > across an untrusted AS, so the security considerations are many > and apply to PCEP and RSVP-TE. > Issues include: > - Security of the CPS (can other network elements probe for > expansion of path-keys, possibly at random?). > - Authenticity of the path-key (resilience to alteration by > intermediaries, resilience to fake expansion of path-keys). > - Resilience from DNS attacks (insertion of spurious path-keys; > flooding of bogus path-key expansion requests). > > > Bradford, Vasseur, and Farrel 7 > > > draft-bradford-pce-path-key-00.txt June 2006 > > 7. Manageability Considerations > > TBD > > 8. IANA considerations > > The IANA section will be detailed in further revision of this > document. > > For RSVP, it will include code point requests for the three new > ERO sub-objects, and a new ErrorSpec Error Code. > > For PCEP, it will include code point requests for the three new > computed path sub-objects. > > > 9. Intellectual Property Considerations > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed > to pertain to the implementation or use of the technology > described in this document or the extent to which any license > under such rights might or might not be available; nor does it > represent that it has made any independent effort to identify any > such rights. Information on the procedures with respect to rights > in RFC documents can be found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use > of such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository > at http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention > any copyrights, patents or patent applications, or other > proprietary rights that may cover technology that may be required > to implement this standard. Please address the information to the > IETF at ietf-ipr@ietf.org. > > 10. References > > 10.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > > > Bradford, Vasseur, and Farrel 8 > > > draft-bradford-pce-path-key-00.txt June 2006 > > [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. > and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC > 3209, December 2001. > > [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., > Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element > (PCE) communication Protocol (PCEP)", draft-vasseur-pce-pcep, > work in progress. > > 10.2. Informational References > > [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation > Element (PCE) Architecture", draft-ietf-pce-architecture, work in > progress. > > [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation > method for establishing Inter-domain Traffic Engineering (TE) > Label > Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path- > comp, work in progress. > > [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based > Computation > (BRPC) procedure to compute shortest inter-domain Traffic > Engineering Label Switched Path", draft-vasseur-pce-brpc, work in > progress. > > [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements > for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", > RFC 4105, June 2005. > > [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS > Traffic Engineering requirements", RFC 4216, November 2005. > > > > 11. Authors' Addresses: > > Rich Bradford (Editor) > Cisco Systems, Inc. > 1414 Massachusetts Avenue > Boxborough , MA - 01719 > USA > Email: rbradfor@cisco.com > > J.-P Vasseur > Cisco Systems, Inc. > 1414 Massachusetts Avenue > Boxborough , MA - 01719 > > Bradford, Vasseur, and Farrel 9 > > > draft-bradford-pce-path-key-00.txt June 2006 > > USA > Email: jpv@cisco.com > > Adrian Farrel > Old Dog Consulting > EMail: adrian@olddog.co.uk > > > > > > > > > > > > > > Full Copyright Statement > > Copyright (C) The Internet Society (2006). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT > THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR > ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE. > > > > > > > > > > > > > > > > Bradford, Vasseur, and Farrel 10 > > =0C_______________________________________________ > 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 Fri Jul 14 09:43:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Nx1-00015J-KI; Fri, 14 Jul 2006 09:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Nwz-00014y-Qe for pce@ietf.org; Fri, 14 Jul 2006 09:43:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Nwy-0007Mc-IB for pce@ietf.org; Fri, 14 Jul 2006 09:43:25 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Nwx-000K0X-Vm for pce@ietf.org; Fri, 14 Jul 2006 13:43:24 +0000 Message-ID: <44B79F86.3050804@psg.com> Date: Fri, 14 Jul 2006 15:43:34 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Pce] P & I flags X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org the comments around the P and I flags are o) we have two levels of optionality in listing the protocol object and usage level of the protocol object - however it is much more appropriate to be sure that mandatory constraints have been taken rather than having the optional having been taken into account P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify in a PCReq message sent to a PCE whether the object must be taken into account by the PCE during path computation or is just optional. When the P flag is set, the object MUST be taken into account by the PCE. Conversely, when the P flag is cleared, the object is optional and the PCE is free to ignore it if not supported. o) on the I flag issue is identical why include an object which has not considered during computation ? there are so many things that the PCE has not taken into account during computation so why bother ? it is imho more important to include the mandatory object not taken into account I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep message to indicate to a PCC whether or not an optional object was processed. The PCE MAY include the ignored optional object in its reply and set the I flag to indicate that the optional object was ignored during path computation. When the I flag is cleared, the PCE indicates that the optional object was processed during the path computation. The setting of the I flag for optional objects is purely indicative and optional. The I flag MUST be cleared if the P flag is set. o) the result of all these flags is that a PCC can be wrapping around unknown constraints create processing churn on the PCE; If the PCE does not understand an object with the P Flag set or understands the object but decides to ignore the object, the entire PCEP message MUST be rejected and the PCE MUST send a PCErr message with Error-Type="Unknown Object" or "Not supported Object". _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 14 10:43:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OtJ-00010D-0O; Fri, 14 Jul 2006 10:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OtI-0000zs-3l for pce@ietf.org; Fri, 14 Jul 2006 10:43:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OlY-0007HX-HH for pce@ietf.org; Fri, 14 Jul 2006 10:35:40 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1NgQ-0005SN-Nf for pce@ietf.org; Fri, 14 Jul 2006 09:26:22 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1NgP-000IKa-7F; Fri, 14 Jul 2006 13:26:17 +0000 Message-ID: <44B79B83.9060203@psg.com> Date: Fri, 14 Jul 2006 15:26:27 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] path key and brpc References: <44B789D3.1070902@psg.com> <30DD16B4-4F39-4B0E-86AF-DEDCDEC705DC@cisco.com> In-Reply-To: <30DD16B4-4F39-4B0E-86AF-DEDCDEC705DC@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 3b3673afe71d94a7551c8fbc5adb8948 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi jp JP Vasseur wrote: > Hi Dimitri, > > On Jul 14, 2006, at 8:10 AM, dimitri papadimitriou wrote: > >> the draft speaks about inter-as comp methods in introduction e.g brpc >> but how the latter can be used in conjunction with pks ? >> > > BRPC can be used in conjunction with PKS since the set of returned > paths by a downstream PCE can be made of loose hops. Path-Keys are then > accumulate along the computed path. as far as my understanding goes on brpc, it says Step 2: PCE(n) computes VSPT(n) made of the list of shortest constrained path(s) between every BR-en(j,n) and the TE LSP destination using a suitable path computation algorithm (e.g. CSPF) and returns the computed VSPT(n) to PCE(n-1). => do you mean that you are going to send back a list of asbr's that are the head-end of these constraint sp's ? please detail in your draft add also the overhead increase in maintaining a set of keys that the enitity as to potentially maintain and how long - thx, -d. >> the draft mentions it may result into two documents (one in ccamp and >> the other in pce wg) -> good idea because path key technique can be >> used independently of the presence of a initial pcc-/pce- pce exchange >> >> the latter would result in the possibility to make use of pks with pd pc >> > > Indeed. > > Thanks. > > JP. > >> >> >> >> >> Networking Working Group Rich Bradford (Ed) >> IETF Internet Draft JP Vasseur >> Cisco Systems, Inc. >> Adrian Farrel >> Old Dog Consulting >> >> >> >> Proposed Status: Standard >> Expires: December 2006 >> June 2006 >> >> >> >> draft-bradford-pce-path-key-00.txt >> >> >> Preserving Topology Confidentiality in Inter-Domain Path >> Computation and Signaling >> >> Status of this Memo >> >> By submitting this Internet-Draft, each author represents that >> any applicable patent or other IPR claims of which he or she is >> aware have been or will be disclosed, and any of which he or she >> becomes aware will be disclosed, in accordance with Section 6 of >> BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF), its areas, and its working groups. Note that >> other groups may also distribute working documents as Internet- >> Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six >> months and may be updated, replaced, or obsoleted by other >> documents at any time. It is inappropriate to use Internet-Drafts >> as reference material or to cite them other than as "work in >> progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >> >> >> >> >> >> >> Bradford, Vasseur and Farrel 1 >> >> >> draft-bradford-pce-path-key-00.txt June 2006 >> >> Abstract >> >> Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) >> Label Switched Paths (LSPs) may be computed by Path Computation >> Elements (PCEs). Where the TE 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, >> thus disclosing internal topology information. This issue may be >> circumvented by returning a loose hop and by invoking a new path >> computation from the domain boundary LSR during TE LSP setup as >> the LSP enters the second domain, but this technique has several >> issues including the problem of maintaining path diversity. >> >> This document defines a mechanism to hide the contents of a >> segment of a path, called the Confidential Path Segment (CPS). The >> CPS may be replaced by a path key that can be conveyed in the PCE >> Communication Protocol (PCEP) and signaled within in a Resource >> Reservation Protocol (RSVP) explicit route object. >> >> >> >> Table of contents >> To be Added >> >> Conventions used in this document >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in >> RFC-2119 [RFC2119]. >> >> 1. Note >> >> It must be noted that this document proposes RSVP-TE and PCEP >> protocol extensions and may eventually result in two separate >> documents to be discussed in the CCAMP and PCE Working Groups >> respectively. >> >> 2. Terminology >> >> ASBR Routers: border routers used to connect to another AS of a >> different or the same Service Provider via one or more links >> inter-connecting between ASs. >> >> >> Bradford, Vasseur, and Farrel 2 >> >> >> draft-bradford-pce-path-key-00.txt June 2006 >> >> CPS: Confidential Path Segment. A segment of a path that contains >> nodes and links that the AS policy requires to not be disclosed >> outside the AS. >> >> Inter-AS TE LSP: A TE LSP that crosses an AS boundary. >> >> LSR: Label Switching Router. >> >> LSP: Label Switched Path. >> >> PCC: Path Computation Client: any client application requesting a >> path computation to be performed by a Path Computation Element. >> >> PCE: Path Computation Element: an entity (component, application >> or >> network node) that is capable of computing a network path or route >> based on a network graph and applying computational constraints. >> >> TE LSP: Traffic Engineering Label Switched Path >> >> 3. Introduction >> >> Path computation techniques using the Path Computation Element >> (PCE) have been described in [PCE-ARCH] and allow for path >> computation of inter-domain Multiprotocol Label Switching (MPLS) >> traffic engineering (TE) Label Switched Paths (LSPs). >> >> An important element of inter-domain TE is that TE information is >> not usually shared between domains for scalability and >> confidentiality reasons ([RFC4105] and [RFC4216]). Therefore, a >> single PCE is unlikely to be able to compute a full inter-domain >> path. >> >> Two routing scenarios can be used for inter-domain TE LSPs: one >> using per-domain path computation (defined in [PD-PATH-COMP]), and >> the other using a PCE-based path computation technique with >> cooperation between PCEs (as described in [PCE-ARCH]). In this >> second case, paths for inter-domain LSPs are computed by >> cooperation between PCEs each of which computes a segment of the >> path across one domain. Such a path computation procedure is >> described in [BRPC]. >> >> If confidentiality is required between domains (such as would very >> likely be the case between ASs belonging to different service >> providers) then cooperating PCEs cannot exchange path segments or >> else the receiving PCE and the Path Computation Client (PCC) will >> be able to see the individual hops through another domain. We >> define the part of the path which we wish to keep confidential as >> the Confidential Path Segment (CPS). >> >> Bradford, Vasseur, and Farrel 3 >> >> >> draft-bradford-pce-path-key-00.txt June 2006 >> >> >> One mechanism for preserving the confidentiality of the CPS is for >> the PCE to return a path containing a loose hop for the segment >> internal to a domain that must be kept confidential. The concept >> of loose hops for the route of an LSP is described in [RFC3209]. >> The Path Computation Element Communication Protocol (PCEP) >> supports the use of paths with loose hops, and it is a local >> policy decision at a PCE whether it returns a full explicit path >> or uses loose hops. >> >> If loose hops are used, the TE LSPs are signaled as normal >> ([RFC3209]), and when a loose hop is encountered in the explicit >> route it is resolved by performing a secondary path computation. >> Given the nature of the cooperation between PCEs in computing the >> original path, this secondary computation occurs at a Label >> Switching Router (LSR) at a domain boundary and the route is >> expanded as described in [PD-PATH-COMP]. >> >> The PCE-based computation model is particularly useful for >> determining mutually disjoint inter-domain paths such as might be >> required for service protection. A single path computation request >> is used. However, if loose hops are returned, the path of each LSP >> must be recomputed at the domain boundaries as the LSPs are >> signaled, and since the LSP signaling proceeds independently for >> each LSP, disjoint paths cannot be guaranteed since the LSRs in >> charge of expanding the EROs are not synchronized. >> >> Therefore, using the loose hop technique, path segment >> confidentiality and path diversity are mutually incompatible >> requirements. >> >> This document defines the notion of a Path Key that is a token >> that replaces a path segment in an explicit route. The Path Key >> can be encoded as a Path Key Sub-object (PKS) which can be >> exchanged in PCEP [PCEP] for PCE path computation results and >> subsequent computation requests, and in RSVP-TE [RFC3209] for >> signaling of explicit paths. The PKS may also, optionally, be used >> in recorded routes in RSVP-TE. >> >> The next section provides the details for this solution. >> >> 4. Path-Key Solution >> >> The Path-Key solution may be applied in the PCE-based path >> computation context as follows. A PCE computes a path segment and >> replaces it in the path reported to the PCC (or another PCE) by >> one or more sub-objects referred to as the PKS. The entry and >> boundary LSR of each CPS SHOULD be specified as hops in the >> >> >> Bradford, Vasseur, and Farrel 4 >> >> >> draft-bradford-pce-path-key-00.txt June 2006 >> >> returned path immediately preceding the PKS, but where two PKSs >> are supplied in sequence the entry node to the second MAY be >> encoded within the first. The exit node of a CPS MAY be present as >> a strict hop immediately following the PKS, but MAY also be hidden >> as part of the PKS and through the use of a subsequent loose hop. >> >> The PKS, itself, MAY be supplied as a loose hop, but is >> RECOMMENDED to be used as a strict hop immediately following the >> hop that indicates the boundary LSR. >> >> 4.1. Mode of Operation >> >> During path computation, when local policy dictates that >> confidentiality must be preserved for all or part of the path >> segment being computed, the PCE associates a path-key with the >> computed path for the CPS, places its own identifier (its PCE-ID) >> along with the path-key in a PKS, and inserts the PKS in the path >> returned to the PCC or the collaborating PCE immediately after the >> sub-object that identifies the LSR that will expand the PKS into a >> explicit path hops. This will usually be the LSR that is the start >> point of the CPS. The PCE that generates a PKS MUST store the >> computed path segment and the path-key for later retrieval. A >> local policy SHOULD be used to determine for how long to retain >> such stored information, and whether to discard the information >> after it has been queried using the procedures described below. >> TBD: Need to define the scope of the PKS and spell out the >> restrictions on Path Key re-use. >> >> A head-end LSR that is a PCC converts the path returned by a PCE >> into an explicit route object (ERO) that it includes in the >> Resource Reservation Protocol (RSVP) Path message. If the path >> returned by the PCE contains PKSs these are included in the ERO. >> Like any other sub-objects, the PKS is passed transparently from >> hop to hop, until it becomes the first sub-object in the ERO. This >> will occur at the start of the CPS which will usually be the >> domain boundary. The PKS MUST be preceded by an ERO sub-object >> that identifies the LSR that must expand the PKS, so the PKS will >> not be encountered in ERO processing until the LSR that can >> process it. >> >> An LSR that encounters a PKS when trying to identify the next-hop >> retrieves the PCE-ID from the PKS and sends the path-key to the >> PCE in a PCEP query the details of which will be described in a >> further revision of this document. >> >> Upon receiving the path query, the PCE identifies the computed >> path segment using the supplied path-key, and returns the >> previously computed path segment in the form of explicit hops to >> >> Bradford, Vasseur, and Farrel 5 >> >> >> draft-bradford-pce-path-key-00.txt June 2006 >> >> the requesting node. The requesting node inserts the explicit hops >> into the ERO and continues to process the LSP setup as per >> [RFC3209]. >> >> Note that if a PCE fails to expand a PKS, the requesting LSR MUST >> fail the LSP setup and SHOULD use the procedures associated with >> loose hop expansion failure [RFC3209]. >> >> 5. PCEP/RSVP-TE Path Key Sub-object >> >> >> The Path Key sub-object (PKS) may be carried in the Explicit Route >> Object (ERO) of a PCEP PCRep message [PCEP] or an RSVP-TE Path >> message [RFC3209]. The PKS is a fixed-length sub-object containing >> a Path-Key and a PCE-ID. The Path Key is an identifier, or token >> used to represent the CPS within the context of the PCE identified >> by the PCE-ID. The PCE-ID identifies the PCE that can decode the >> Path Key using a reachable IPv4 or IPv6 address of the PCE. >> Because of the IPv4 and IPv6 variants, two subobjects are defined >> as follows. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |L| Type | Length | Path Key | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IPv4 address (4 bytes) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> L >> >> The L bit SHOULD NOT be set, so that the sub-object >> represents a strict hop in the explicit route. >> >> Type >> >> TBD Path Key with IPv4 address >> >> Length >> >> The Length contains the total length of the subobject in >> bytes, including the Type and Length fields. The Length is always >> 8. >> >> IPv4 address >> >> An IPv4 address of the PCE that can decode this key. The >> address used SHOULD be an address of the PCE that is always >> >> >> Bradford, Vasseur, and Farrel 6 >> >> >> draft-bradford-pce-path-key-00.txt June 2006 >> >> reachable, and MAY be an address that is restricted to the domain >> in which the LSR that is called upon to expand the CPS lies. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |L| Type | Length | Path Key | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IPv6 address (16 bytes) | >> | | >> | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> L >> >> As above. >> >> Type >> >> TBD Path Key with IPv6 address >> >> Length >> >> The Length contains the total length of the subobject in >> bytes, including the Type and Length fields. The Length is always >> 20. >> >> IPv6 address >> >> An IPv6 address of the PCE that can decode this key. The >> address used SHOULD be an address of the PCE that is always >> reachable, but MAY be an address that is restricted to the domain >> in which the LSR that is called upon to expand the CPS lies. >> >> >> 6. Security Considerations >> >> This document proposes tunneling secure topology information >> across an untrusted AS, so the security considerations are many >> and apply to PCEP and RSVP-TE. >> Issues include: >> - Security of the CPS (can other network elements probe for >> expansion of path-keys, possibly at random?). >> - Authenticity of the path-key (resilience to alteration by >> intermediaries, resilience to fake expansion of path-keys). >> - Resilience from DNS attacks (insertion of spurious path-keys; >> flooding of bogus path-key expansion requests). >> >> >> Bradford, Vasseur, and Farrel 7 >> >> >> draft-bradford-pce-path-key-00.txt June 2006 >> >> 7. Manageability Considerations >> >> TBD >> >> 8. IANA considerations >> >> The IANA section will be detailed in further revision of this >> document. >> >> For RSVP, it will include code point requests for the three new >> ERO sub-objects, and a new ErrorSpec Error Code. >> >> For PCEP, it will include code point requests for the three new >> computed path sub-objects. >> >> >> 9. Intellectual Property Considerations >> >> The IETF takes no position regarding the validity or scope of any >> Intellectual Property Rights or other rights that might be claimed >> to pertain to the implementation or use of the technology >> described in this document or the extent to which any license >> under such rights might or might not be available; nor does it >> represent that it has made any independent effort to identify any >> such rights. Information on the procedures with respect to rights >> in RFC documents can be found in BCP 78 and BCP 79. >> >> Copies of IPR disclosures made to the IETF Secretariat and any >> assurances of licenses to be made available, or the result of an >> attempt made to obtain a general license or permission for the use >> of such proprietary rights by implementers or users of this >> specification can be obtained from the IETF on-line IPR repository >> at http://www.ietf.org/ipr. >> >> The IETF invites any interested party to bring to its attention >> any copyrights, patents or patent applications, or other >> proprietary rights that may cover technology that may be required >> to implement this standard. Please address the information to the >> IETF at ietf-ipr@ietf.org. >> >> 10. References >> >> 10.1. Normative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> >> >> >> Bradford, Vasseur, and Farrel 8 >> >> >> draft-bradford-pce-path-key-00.txt June 2006 >> >> [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. >> and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC >> 3209, December 2001. >> >> [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., >> Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element >> (PCE) communication Protocol (PCEP)", draft-vasseur-pce-pcep, >> work in progress. >> >> 10.2. Informational References >> >> [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation >> Element (PCE) Architecture", draft-ietf-pce-architecture, work in >> progress. >> >> [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation >> method for establishing Inter-domain Traffic Engineering (TE) >> Label >> Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path- >> comp, work in progress. >> >> [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based >> Computation >> (BRPC) procedure to compute shortest inter-domain Traffic >> Engineering Label Switched Path", draft-vasseur-pce-brpc, work in >> progress. >> >> [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements >> for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", >> RFC 4105, June 2005. >> >> [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS >> Traffic Engineering requirements", RFC 4216, November 2005. >> >> >> >> 11. Authors' Addresses: >> >> Rich Bradford (Editor) >> Cisco Systems, Inc. >> 1414 Massachusetts Avenue >> Boxborough , MA - 01719 >> USA >> Email: rbradfor@cisco.com >> >> J.-P Vasseur >> Cisco Systems, Inc. >> 1414 Massachusetts Avenue >> Boxborough , MA - 01719 >> >> Bradford, Vasseur, and Farrel 9 >> >> >> draft-bradford-pce-path-key-00.txt June 2006 >> >> USA >> Email: jpv@cisco.com >> >> Adrian Farrel >> Old Dog Consulting >> EMail: adrian@olddog.co.uk >> >> >> >> >> >> >> >> >> >> >> >> >> >> Full Copyright Statement >> >> Copyright (C) The Internet Society (2006). >> >> This document is subject to the rights, licenses and restrictions >> contained in BCP 78, and except as set forth therein, the authors >> retain all their rights. >> >> This document and the information contained herein are provided >> on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND >> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, >> EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT >> THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR >> ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A >> PARTICULAR PURPOSE. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Bradford, Vasseur, and Farrel 10 >> >> _______________________________________________ >> 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 Fri Jul 14 10:46:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Ovp-0001d1-9h; Fri, 14 Jul 2006 10:46:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Ovo-0001cD-Cj for pce@ietf.org; Fri, 14 Jul 2006 10:46:16 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Ovl-0001y6-Ug for pce@ietf.org; Fri, 14 Jul 2006 10:46:16 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 16:46:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] P & I flags Date: Fri, 14 Jul 2006 16:46:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] P & I flags Thread-Index: AcanS4IcTRpPngHrR9exxlrn16m7nQABWxTw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , X-OriginalArrivalTime: 14 Jul 2006 14:46:11.0375 (UTC) FILETIME=[3FA8B3F0:01C6A754] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Dimitri,=20 > -----Message d'origine----- > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Envoy=E9 : vendredi 14 juillet 2006 15:44 > =C0 : pce@ietf.org > Objet : [Pce] P & I flags >=20 > the comments around the P and I flags are >=20 > o) we have two levels of optionality in listing the protocol=20 > object and usage level of the protocol object - however it is=20 > much more appropriate to be sure that mandatory constraints=20 > have been taken rather than having the optional having been=20 > taken into account As clearly pointed out in the same setion of the draft, if a mandatory = constraint cannot be handled the PCE replies with PCErr message "If the PCE does not understand an object with the P Flag set or understands the object but decides to ignore the object, the entire PCEP message MUST be rejected and the PCE MUST send a PCErr message with Error-Type=3D"Unknown Object" or "Not supported Object". If the PCE can handle all mandatory constraints it replies with a PCRep = message (either positive or negative if there is no path), else it sends = a PCErr message. Hence the PCC knows whether mandatory constraints have been taken into = account. >=20 > P flag (Processing-Rule - 1-bit): the P flag allows a PCC=20 > to specify > in a PCReq message sent to a PCE whether the object must be taken > into account by the PCE during path computation or is=20 > just optional. > When the P flag is set, the object MUST be taken into=20 > account by the > PCE. Conversely, when the P flag is cleared, the object=20 > is optional > and the PCE is free to ignore it if not supported. >=20 > o) on the I flag issue is identical why include an object=20 > which has not considered during computation ?=20 I don't catch your point, the PCC may want to know the constraints that = were not taken into account during path computation, this sounds quite = important isn'it? there are so=20 > many things that the PCE has not taken into account during=20 > computation so why bother ? Hum I don't follow you here "there are so many things...", What do you = mean? > it is imho > more important to include the mandatory object not taken=20 > into account If a mandatory object is not taken into account, you cannot compute the = path and you send an error message. I agree with you that this would be = useful to include within the PCErr the set of objects not supported, = this can be clarified in next revision. >=20 > I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep > message to indicate to a PCC whether or not an optional object was > processed. The PCE MAY include the ignored optional object in its > reply and set the I flag to indicate that the optional object was > ignored during path computation. When the I flag is=20 > cleared, the PCE > indicates that the optional object was processed during the path > computation. The setting of the I flag for optional objects is > purely indicative and optional. The I flag MUST be=20 > cleared if the P > flag is set. >=20 > o) the result of all these flags is that a PCC can be=20 > wrapping around unknown constraints create processing churn=20 > on the PCE; OK, if you mean that we should include the unsupported object(s) within = the PCErr, then we are in sync Thanks for the comment Regards JL >=20 > If the PCE does not understand an object with the P Flag set or > understands the object but decides to ignore the object,=20 > the entire > PCEP message MUST be rejected and the PCE MUST send a=20 > PCErr message > with Error-Type=3D"Unknown Object" or "Not supported Object". >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 14 12:14:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QJe-0007ub-0Z; Fri, 14 Jul 2006 12:14:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QJd-0007uN-Ev for pce@ietf.org; Fri, 14 Jul 2006 12:14:57 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1QJc-0000vo-54 for pce@ietf.org; Fri, 14 Jul 2006 12:14:57 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G1QJY-0000XJ-00 for pce@ietf.org; Fri, 14 Jul 2006 17:14:52 +0100 Received: from your029b8cecfe ([132.219.31.133] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 17:14:54 +0100 Message-ID: <005d01c6a760$a30e9a20$851fdb84@your029b8cecfe> From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" , , , References: Subject: Re: [Pce] P & I flags Date: Fri, 14 Jul 2006 17:14:14 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 14 Jul 2006 16:14:54.0844 (UTC) FILETIME=[A4B19BC0:01C6A760] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 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 >> o) on the I flag issue is identical why include an object >> which has not considered during computation ? > > I don't catch your point, the PCC may want to know the > constraints that were not taken into account during path > computation, this sounds quite important isn'it? > >> there are so >> many things that the PCE has not taken into account during >> computation so why bother ? > > Hum I don't follow you here "there are so many things...", > What do you mean? I think the disconnect is that the I flag is only used in constraints *returned* to the PCC. I.e. in constraints that formed part of the original request, but were ignored. There is no requirement (or desire?) for the PCE to randomly report other things it did not take into account (such as weather, shoe-size of operator, etc.) Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jul 14 14:51:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SlO-0001Hj-Hc; Fri, 14 Jul 2006 14:51:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SlM-0001He-Ho for pce@ietf.org; Fri, 14 Jul 2006 14:51:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1SlM-0002C3-4E for pce@ietf.org; Fri, 14 Jul 2006 14:51:44 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1SlJ-000O3n-Lo; Fri, 14 Jul 2006 18:51:42 +0000 Message-ID: <44B7E7C6.1050309@psg.com> Date: Fri, 14 Jul 2006 20:51:50 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN Subject: Re: [Pce] P & I flags References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-l LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri, > > >> -----Message d'origine----- De : dimitri papadimitriou >> [mailto:dpapadimitriou@psg.com] Envoyé : vendredi 14 juillet 2006 >> 15:44 À : pce@ietf.org Objet : [Pce] P & I flags >> >> the comments around the P and I flags are >> >> o) we have two levels of optionality in listing the protocol object >> and usage level of the protocol object - however it is much more >> appropriate to be sure that mandatory constraints have been taken >> rather than having the optional having been taken into account > > As clearly pointed out in the same setion of the draft, if a > mandatory constraint cannot be handled the PCE replies with PCErr > message i restate you have two levels of indirection optional objects and optional usage of the constraint during pc now the important thing is not that you have a "PCE deciding to ignore" but a PCC that performs a sort on constraint it wants to see as part of its comp request p flag can be used when the pce can't compute with that constraint(s) and sends a negative answer with the P flag on the constraints that can not be taken into account in the reply the P flag should be such that the requestor receives a confirmation of constraints taken into account during PCE pc - since this is the only thing PCC cares about and return an error if the object is not supported or decision with "Policy Control failure" or even "AC failure" in case of PCE overload > "If the PCE does not understand an object with the P Flag set or > understands the object but decides to ignore the object, the entire > PCEP message MUST be rejected and the PCE MUST send a PCErr message > with Error-Type="Unknown Object" or "Not supported Object". my point is that you can not return "unknown object" from the P flag but from the unsupport of an object > If the PCE can handle all mandatory constraints it replies with a > PCRep message (either positive or negative if there is no path), else > it sends a PCErr message. Hence the PCC knows whether mandatory > constraints have been taken into account. you have also a third level of indirection in the reply because one assumes that >> P flag (Processing-Rule - 1-bit): the P flag allows a PCC to >> specify in a PCReq message sent to a PCE whether the object must be >> taken into account by the PCE during path computation or is just >> optional. When the P flag is set, the object MUST be taken into >> account by the PCE. Conversely, when the P flag is cleared, the >> object is optional and the PCE is free to ignore it if not >> supported. >> >> o) on the I flag issue is identical why include an object which has >> not considered during computation ? > > I don't catch your point, the PCC may want to know the constraints > that were not taken into account during path computation, this sounds > quite important isn'it? > > > there are so > >> many things that the PCE has not taken into account during >> computation so why bother ? > > Hum I don't follow you here "there are so many things...", What do > you mean? see adrian's reply thanks, - dimitri. >> it is imho more important to include the mandatory object not taken >> into account > > > If a mandatory object is not taken into account, you cannot compute > the path and you send an error message. I agree with you that this > would be useful to include within the PCErr the set of objects not > supported, this can be clarified in next revision. > > > >> I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep >> message to indicate to a PCC whether or not an optional object was >> processed. The PCE MAY include the ignored optional object in its >> reply and set the I flag to indicate that the optional object was >> ignored during path computation. When the I flag is cleared, the >> PCE indicates that the optional object was processed during the >> path computation. The setting of the I flag for optional objects >> is purely indicative and optional. The I flag MUST be cleared if >> the P flag is set. >> >> o) the result of all these flags is that a PCC can be wrapping >> around unknown constraints create processing churn on the PCE; > > > OK, if you mean that we should include the unsupported object(s) > within the PCErr, then we are in sync > > Thanks for the comment > > Regards > > JL > > >> If the PCE does not understand an object with the P Flag set or >> understands the object but decides to ignore the object, the entire >> PCEP message MUST be rejected and the PCE MUST send a PCErr >> message with Error-Type="Unknown Object" or "Not supported Object". >> >> >> >> >> _______________________________________________ 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 Fri Jul 14 15:03:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SwK-0002gR-Od; Fri, 14 Jul 2006 15:03:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SwI-0002gM-Rq for pce@ietf.org; Fri, 14 Jul 2006 15:03:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1SwH-0004Jm-Pl for pce@ietf.org; Fri, 14 Jul 2006 15:03:02 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1SwD-000P3I-P1; Fri, 14 Jul 2006 19:02:58 +0000 Message-ID: <44B7EA6C.8070504@psg.com> Date: Fri, 14 Jul 2006 21:03:08 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] path key and brpc References: <44B789D3.1070902@psg.com> <30DD16B4-4F39-4B0E-86AF-DEDCDEC705DC@cisco.com> <44B79B83.9060203@psg.com> <30D9037B-D733-4CBB-BF47-E24817441CB3@cisco.com> In-Reply-To: <30D9037B-D733-4CBB-BF47-E24817441CB3@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f9c0d585568a86447c98453afdf94aa0 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-p JP Vasseur wrote: > Hi Dimitri, > > On Jul 14, 2006, at 9:26 AM, dimitri papadimitriou wrote: > >> hi jp >> >> JP Vasseur wrote: >> >>> Hi Dimitri, >>> On Jul 14, 2006, at 8:10 AM, dimitri papadimitriou wrote: >>> >>>> the draft speaks about inter-as comp methods in introduction e.g >>>> brpc but how the latter can be used in conjunction with pks ? >>>> >>> BRPC can be used in conjunction with PKS since the set of returned >>> paths by a downstream PCE can be made of loose hops. Path-Keys are >>> then accumulate along the computed path. >> >> >> as far as my understanding goes on brpc, it says >> >> Step 2: PCE(n) computes VSPT(n) made of the list of shortest >> constrained path(s) between every BR-en(j,n) and the TE LSP >> destination using a suitable path computation algorithm (e.g. CSPF) >> and returns the computed VSPT(n) to PCE(n-1). >> >> => do you mean that you are going to send back a list of asbr's that >> are the head-end of these constraint sp's ? please detail in your draft >> > > This is already explicitly mentioned in the ID: > > Each branch of the VSPT tree (path) may be returned in the form of an > explicit path (in which case all the hops along the path segment are > listed) or a loose path (in which case only the BR is specified) so > as to preserve confidentiality along with the respective cost. but there is a specific point here if you refer to that section - what "loose path" means when stating only the "BR" is listed i.e. it is not only a list including the set of BR's facing the upstream domain but also the BR's of the downstream domain otherwise i don't see how the "complete" loose path can be returned to the head-end LSR > I'll add a short section pointing to the Path-key ID (after the split > of the Path-key ID). > >> add also the overhead increase in maintaining a set of keys that the >> enitity as to potentially maintain and how long - > > Yes as pointed out by Adrian yesterday this will be discussed in a > further revision of the Path-key ID. ok - thanks, - dimitri. > Thanks. > > JP. > >> thx, >> -d. >> >>>> the draft mentions it may result into two documents (one in ccamp >>>> and the other in pce wg) -> good idea because path key technique >>>> can be used independently of the presence of a initial pcc-/pce- >>>> pce exchange >>>> >>>> the latter would result in the possibility to make use of pks with >>>> pd pc >>>> >>> Indeed. >>> Thanks. >>> JP. >>> >>>> >>> key-00.txt> >>>> >>>> >>>> >>>> Networking Working Group Rich Bradford (Ed) >>>> IETF Internet Draft JP Vasseur >>>> Cisco Systems, Inc. >>>> Adrian Farrel >>>> Old Dog Consulting >>>> >>>> >>>> >>>> Proposed Status: Standard >>>> Expires: December 2006 >>>> June 2006 >>>> >>>> >>>> >>>> draft-bradford-pce-path-key-00.txt >>>> >>>> >>>> Preserving Topology Confidentiality in Inter-Domain Path >>>> Computation and Signaling >>>> >>>> Status of this Memo >>>> >>>> By submitting this Internet-Draft, each author represents that >>>> any applicable patent or other IPR claims of which he or she is >>>> aware have been or will be disclosed, and any of which he or she >>>> becomes aware will be disclosed, in accordance with Section 6 of >>>> BCP 79. >>>> >>>> Internet-Drafts are working documents of the Internet Engineering >>>> Task Force (IETF), its areas, and its working groups. Note that >>>> other groups may also distribute working documents as Internet- >>>> Drafts. >>>> >>>> Internet-Drafts are draft documents valid for a maximum of six >>>> months and may be updated, replaced, or obsoleted by other >>>> documents at any time. It is inappropriate to use Internet- Drafts >>>> as reference material or to cite them other than as "work in >>>> progress." >>>> >>>> The list of current Internet-Drafts can be accessed at >>>> http://www.ietf.org/ietf/1id-abstracts.txt. >>>> >>>> The list of Internet-Draft Shadow Directories can be accessed at >>>> http://www.ietf.org/shadow.html. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Bradford, Vasseur and Farrel 1 >>>> >>>> >>>> draft-bradford-pce-path-key-00.txt June 2006 >>>> >>>> Abstract >>>> >>>> Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) >>>> Label Switched Paths (LSPs) may be computed by Path Computation >>>> Elements (PCEs). Where the TE 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, >>>> thus disclosing internal topology information. This issue may be >>>> circumvented by returning a loose hop and by invoking a new path >>>> computation from the domain boundary LSR during TE LSP setup as >>>> the LSP enters the second domain, but this technique has several >>>> issues including the problem of maintaining path diversity. >>>> >>>> This document defines a mechanism to hide the contents of a >>>> segment of a path, called the Confidential Path Segment (CPS). The >>>> CPS may be replaced by a path key that can be conveyed in the PCE >>>> Communication Protocol (PCEP) and signaled within in a Resource >>>> Reservation Protocol (RSVP) explicit route object. >>>> >>>> >>>> >>>> Table of contents >>>> To be Added >>>> >>>> Conventions used in this document >>>> >>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>>> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>>> "OPTIONAL" in this document are to be interpreted as described in >>>> RFC-2119 [RFC2119]. >>>> >>>> 1. Note >>>> >>>> It must be noted that this document proposes RSVP-TE and PCEP >>>> protocol extensions and may eventually result in two separate >>>> documents to be discussed in the CCAMP and PCE Working Groups >>>> respectively. >>>> >>>> 2. Terminology >>>> >>>> ASBR Routers: border routers used to connect to another AS of a >>>> different or the same Service Provider via one or more links >>>> inter-connecting between ASs. >>>> >>>> >>>> Bradford, Vasseur, and Farrel 2 >>>> >>>> >>>> draft-bradford-pce-path-key-00.txt June 2006 >>>> >>>> CPS: Confidential Path Segment. A segment of a path that contains >>>> nodes and links that the AS policy requires to not be disclosed >>>> outside the AS. >>>> >>>> Inter-AS TE LSP: A TE LSP that crosses an AS boundary. >>>> >>>> LSR: Label Switching Router. >>>> >>>> LSP: Label Switched Path. >>>> >>>> PCC: Path Computation Client: any client application requesting a >>>> path computation to be performed by a Path Computation Element. >>>> >>>> PCE: Path Computation Element: an entity (component, application >>>> or >>>> network node) that is capable of computing a network path or route >>>> based on a network graph and applying computational constraints. >>>> >>>> TE LSP: Traffic Engineering Label Switched Path >>>> >>>> 3. Introduction >>>> >>>> Path computation techniques using the Path Computation Element >>>> (PCE) have been described in [PCE-ARCH] and allow for path >>>> computation of inter-domain Multiprotocol Label Switching (MPLS) >>>> traffic engineering (TE) Label Switched Paths (LSPs). >>>> >>>> An important element of inter-domain TE is that TE information is >>>> not usually shared between domains for scalability and >>>> confidentiality reasons ([RFC4105] and [RFC4216]). Therefore, a >>>> single PCE is unlikely to be able to compute a full inter-domain >>>> path. >>>> >>>> Two routing scenarios can be used for inter-domain TE LSPs: one >>>> using per-domain path computation (defined in [PD-PATH-COMP]), and >>>> the other using a PCE-based path computation technique with >>>> cooperation between PCEs (as described in [PCE-ARCH]). In this >>>> second case, paths for inter-domain LSPs are computed by >>>> cooperation between PCEs each of which computes a segment of the >>>> path across one domain. Such a path computation procedure is >>>> described in [BRPC]. >>>> >>>> If confidentiality is required between domains (such as would very >>>> likely be the case between ASs belonging to different service >>>> providers) then cooperating PCEs cannot exchange path segments or >>>> else the receiving PCE and the Path Computation Client (PCC) will >>>> be able to see the individual hops through another domain. We >>>> define the part of the path which we wish to keep confidential as >>>> the Confidential Path Segment (CPS). >>>> >>>> Bradford, Vasseur, and Farrel 3 >>>> >>>> >>>> draft-bradford-pce-path-key-00.txt June 2006 >>>> >>>> >>>> One mechanism for preserving the confidentiality of the CPS is for >>>> the PCE to return a path containing a loose hop for the segment >>>> internal to a domain that must be kept confidential. The concept >>>> of loose hops for the route of an LSP is described in [RFC3209]. >>>> The Path Computation Element Communication Protocol (PCEP) >>>> supports the use of paths with loose hops, and it is a local >>>> policy decision at a PCE whether it returns a full explicit path >>>> or uses loose hops. >>>> >>>> If loose hops are used, the TE LSPs are signaled as normal >>>> ([RFC3209]), and when a loose hop is encountered in the explicit >>>> route it is resolved by performing a secondary path computation. >>>> Given the nature of the cooperation between PCEs in computing the >>>> original path, this secondary computation occurs at a Label >>>> Switching Router (LSR) at a domain boundary and the route is >>>> expanded as described in [PD-PATH-COMP]. >>>> >>>> The PCE-based computation model is particularly useful for >>>> determining mutually disjoint inter-domain paths such as might be >>>> required for service protection. A single path computation request >>>> is used. However, if loose hops are returned, the path of each LSP >>>> must be recomputed at the domain boundaries as the LSPs are >>>> signaled, and since the LSP signaling proceeds independently for >>>> each LSP, disjoint paths cannot be guaranteed since the LSRs in >>>> charge of expanding the EROs are not synchronized. >>>> >>>> Therefore, using the loose hop technique, path segment >>>> confidentiality and path diversity are mutually incompatible >>>> requirements. >>>> >>>> This document defines the notion of a Path Key that is a token >>>> that replaces a path segment in an explicit route. The Path Key >>>> can be encoded as a Path Key Sub-object (PKS) which can be >>>> exchanged in PCEP [PCEP] for PCE path computation results and >>>> subsequent computation requests, and in RSVP-TE [RFC3209] for >>>> signaling of explicit paths. The PKS may also, optionally, be used >>>> in recorded routes in RSVP-TE. >>>> >>>> The next section provides the details for this solution. >>>> >>>> 4. Path-Key Solution >>>> >>>> The Path-Key solution may be applied in the PCE-based path >>>> computation context as follows. A PCE computes a path segment and >>>> replaces it in the path reported to the PCC (or another PCE) by >>>> one or more sub-objects referred to as the PKS. The entry and >>>> boundary LSR of each CPS SHOULD be specified as hops in the >>>> >>>> >>>> Bradford, Vasseur, and Farrel 4 >>>> >>>> >>>> draft-bradford-pce-path-key-00.txt June 2006 >>>> >>>> returned path immediately preceding the PKS, but where two PKSs >>>> are supplied in sequence the entry node to the second MAY be >>>> encoded within the first. The exit node of a CPS MAY be present as >>>> a strict hop immediately following the PKS, but MAY also be hidden >>>> as part of the PKS and through the use of a subsequent loose hop. >>>> >>>> The PKS, itself, MAY be supplied as a loose hop, but is >>>> RECOMMENDED to be used as a strict hop immediately following the >>>> hop that indicates the boundary LSR. >>>> >>>> 4.1. Mode of Operation >>>> >>>> During path computation, when local policy dictates that >>>> confidentiality must be preserved for all or part of the path >>>> segment being computed, the PCE associates a path-key with the >>>> computed path for the CPS, places its own identifier (its PCE-ID) >>>> along with the path-key in a PKS, and inserts the PKS in the path >>>> returned to the PCC or the collaborating PCE immediately after the >>>> sub-object that identifies the LSR that will expand the PKS into a >>>> explicit path hops. This will usually be the LSR that is the start >>>> point of the CPS. The PCE that generates a PKS MUST store the >>>> computed path segment and the path-key for later retrieval. A >>>> local policy SHOULD be used to determine for how long to retain >>>> such stored information, and whether to discard the information >>>> after it has been queried using the procedures described below. >>>> TBD: Need to define the scope of the PKS and spell out the >>>> restrictions on Path Key re-use. >>>> >>>> A head-end LSR that is a PCC converts the path returned by a PCE >>>> into an explicit route object (ERO) that it includes in the >>>> Resource Reservation Protocol (RSVP) Path message. If the path >>>> returned by the PCE contains PKSs these are included in the ERO. >>>> Like any other sub-objects, the PKS is passed transparently from >>>> hop to hop, until it becomes the first sub-object in the ERO. This >>>> will occur at the start of the CPS which will usually be the >>>> domain boundary. The PKS MUST be preceded by an ERO sub-object >>>> that identifies the LSR that must expand the PKS, so the PKS will >>>> not be encountered in ERO processing until the LSR that can >>>> process it. >>>> >>>> An LSR that encounters a PKS when trying to identify the next-hop >>>> retrieves the PCE-ID from the PKS and sends the path-key to the >>>> PCE in a PCEP query the details of which will be described in a >>>> further revision of this document. >>>> >>>> Upon receiving the path query, the PCE identifies the computed >>>> path segment using the supplied path-key, and returns the >>>> previously computed path segment in the form of explicit hops to >>>> >>>> Bradford, Vasseur, and Farrel 5 >>>> >>>> >>>> draft-bradford-pce-path-key-00.txt June 2006 >>>> >>>> the requesting node. The requesting node inserts the explicit hops >>>> into the ERO and continues to process the LSP setup as per >>>> [RFC3209]. >>>> >>>> Note that if a PCE fails to expand a PKS, the requesting LSR MUST >>>> fail the LSP setup and SHOULD use the procedures associated with >>>> loose hop expansion failure [RFC3209]. >>>> >>>> 5. PCEP/RSVP-TE Path Key Sub-object >>>> >>>> >>>> The Path Key sub-object (PKS) may be carried in the Explicit Route >>>> Object (ERO) of a PCEP PCRep message [PCEP] or an RSVP-TE Path >>>> message [RFC3209]. The PKS is a fixed-length sub-object containing >>>> a Path-Key and a PCE-ID. The Path Key is an identifier, or token >>>> used to represent the CPS within the context of the PCE identified >>>> by the PCE-ID. The PCE-ID identifies the PCE that can decode the >>>> Path Key using a reachable IPv4 or IPv6 address of the PCE. >>>> Because of the IPv4 and IPv6 variants, two subobjects are defined >>>> as follows. >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ >>>> |L| Type | Length | Path Key | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ >>>> | IPv4 address (4 bytes) | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ >>>> >>>> L >>>> >>>> The L bit SHOULD NOT be set, so that the sub-object >>>> represents a strict hop in the explicit route. >>>> >>>> Type >>>> >>>> TBD Path Key with IPv4 address >>>> >>>> Length >>>> >>>> The Length contains the total length of the subobject in >>>> bytes, including the Type and Length fields. The Length is always >>>> 8. >>>> >>>> IPv4 address >>>> >>>> An IPv4 address of the PCE that can decode this key. The >>>> address used SHOULD be an address of the PCE that is always >>>> >>>> >>>> Bradford, Vasseur, and Farrel 6 >>>> >>>> >>>> draft-bradford-pce-path-key-00.txt June 2006 >>>> >>>> reachable, and MAY be an address that is restricted to the domain >>>> in which the LSR that is called upon to expand the CPS lies. >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ >>>> |L| Type | Length | Path Key | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ >>>> | IPv6 address (16 bytes) | >>>> | | >>>> | | >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ >>>> >>>> L >>>> >>>> As above. >>>> >>>> Type >>>> >>>> TBD Path Key with IPv6 address >>>> >>>> Length >>>> >>>> The Length contains the total length of the subobject in >>>> bytes, including the Type and Length fields. The Length is always >>>> 20. >>>> >>>> IPv6 address >>>> >>>> An IPv6 address of the PCE that can decode this key. The >>>> address used SHOULD be an address of the PCE that is always >>>> reachable, but MAY be an address that is restricted to the domain >>>> in which the LSR that is called upon to expand the CPS lies. >>>> >>>> >>>> 6. Security Considerations >>>> >>>> This document proposes tunneling secure topology information >>>> across an untrusted AS, so the security considerations are many >>>> and apply to PCEP and RSVP-TE. >>>> Issues include: >>>> - Security of the CPS (can other network elements probe for >>>> expansion of path-keys, possibly at random?). >>>> - Authenticity of the path-key (resilience to alteration by >>>> intermediaries, resilience to fake expansion of path-keys). >>>> - Resilience from DNS attacks (insertion of spurious path-keys; >>>> flooding of bogus path-key expansion requests). >>>> >>>> >>>> Bradford, Vasseur, and Farrel 7 >>>> >>>> >>>> draft-bradford-pce-path-key-00.txt June 2006 >>>> >>>> 7. Manageability Considerations >>>> >>>> TBD >>>> >>>> 8. IANA considerations >>>> >>>> The IANA section will be detailed in further revision of this >>>> document. >>>> >>>> For RSVP, it will include code point requests for the three new >>>> ERO sub-objects, and a new ErrorSpec Error Code. >>>> >>>> For PCEP, it will include code point requests for the three new >>>> computed path sub-objects. >>>> >>>> >>>> 9. Intellectual Property Considerations >>>> >>>> The IETF takes no position regarding the validity or scope of any >>>> Intellectual Property Rights or other rights that might be claimed >>>> to pertain to the implementation or use of the technology >>>> described in this document or the extent to which any license >>>> under such rights might or might not be available; nor does it >>>> represent that it has made any independent effort to identify any >>>> such rights. Information on the procedures with respect to rights >>>> in RFC documents can be found in BCP 78 and BCP 79. >>>> >>>> Copies of IPR disclosures made to the IETF Secretariat and any >>>> assurances of licenses to be made available, or the result of an >>>> attempt made to obtain a general license or permission for the use >>>> of such proprietary rights by implementers or users of this >>>> specification can be obtained from the IETF on-line IPR repository >>>> at http://www.ietf.org/ipr. >>>> >>>> The IETF invites any interested party to bring to its attention >>>> any copyrights, patents or patent applications, or other >>>> proprietary rights that may cover technology that may be required >>>> to implement this standard. Please address the information to the >>>> IETF at ietf-ipr@ietf.org. >>>> >>>> 10. References >>>> >>>> 10.1. Normative References >>>> >>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>> >>>> >>>> >>>> >>>> Bradford, Vasseur, and Farrel 8 >>>> >>>> >>>> draft-bradford-pce-path-key-00.txt June 2006 >>>> >>>> [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. >>>> and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC >>>> 3209, December 2001. >>>> >>>> [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., >>>> Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element >>>> (PCE) communication Protocol (PCEP)", draft-vasseur-pce-pcep, >>>> work in progress. >>>> >>>> 10.2. Informational References >>>> >>>> [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation >>>> Element (PCE) Architecture", draft-ietf-pce-architecture, work in >>>> progress. >>>> >>>> [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation >>>> method for establishing Inter-domain Traffic Engineering (TE) >>>> Label >>>> Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path- >>>> comp, work in progress. >>>> >>>> [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based >>>> Computation >>>> (BRPC) procedure to compute shortest inter-domain Traffic >>>> Engineering Label Switched Path", draft-vasseur-pce-brpc, work in >>>> progress. >>>> >>>> [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements >>>> for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", >>>> RFC 4105, June 2005. >>>> >>>> [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS >>>> Traffic Engineering requirements", RFC 4216, November 2005. >>>> >>>> >>>> >>>> 11. Authors' Addresses: >>>> >>>> Rich Bradford (Editor) >>>> Cisco Systems, Inc. >>>> 1414 Massachusetts Avenue >>>> Boxborough , MA - 01719 >>>> USA >>>> Email: rbradfor@cisco.com >>>> >>>> J.-P Vasseur >>>> Cisco Systems, Inc. >>>> 1414 Massachusetts Avenue >>>> Boxborough , MA - 01719 >>>> >>>> Bradford, Vasseur, and Farrel 9 >>>> >>>> >>>> draft-bradford-pce-path-key-00.txt June 2006 >>>> >>>> USA >>>> Email: jpv@cisco.com >>>> >>>> Adrian Farrel >>>> Old Dog Consulting >>>> EMail: adrian@olddog.co.uk >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Full Copyright Statement >>>> >>>> Copyright (C) The Internet Society (2006). >>>> >>>> This document is subject to the rights, licenses and restrictions >>>> contained in BCP 78, and except as set forth therein, the authors >>>> retain all their rights. >>>> >>>> This document and the information contained herein are provided >>>> on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >>>> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND >>>> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, >>>> EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT >>>> THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR >>>> ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A >>>> PARTICULAR PURPOSE. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Bradford, Vasseur, and Farrel 10 >>>> >>>> _______________________________________________ >>>> 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 Jul 15 09:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1kYD-0007UU-0G; Sat, 15 Jul 2006 09:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1kYB-0007SS-Gp for pce@ietf.org; Sat, 15 Jul 2006 09:51:19 -0400 Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1kY9-0002Ha-2m for pce@ietf.org; Sat, 15 Jul 2006 09:51:19 -0400 Received: from ib (unknown [172.16.50.27]) by jera.movaz.com (Postfix) with SMTP id 41297D27; Sat, 15 Jul 2006 09:51:12 -0400 (EDT) Message-ID: <021301c6a815$ba5b8f20$6501a8c0@movaz.com> From: "Igor Bryskin" To: "LE ROUX Jean-Louis RD-CORE-LAN" , , , References: Subject: Re: [Pce] P & I flags Date: Sat, 15 Jul 2006 09:50:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: 21be852dc93f0971708678c18d38c096 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 JL, I have a question. Suppose, a path computation request has two constraints: link colors and link bandwidth. Suppose the path computation fails. The question is how the PCE can figure out what is the reason of this computation failure? As an implementer of a Path Computation Engine I always found it a difficult problem. Normally, presented with a path computation request with link type constraints as in the example I am describing, a PCE would prune out the arcs form the network graph associated with links that do not satisfy at least one of the constraints, and after that run some algorithm. If the algorithm fails the only thing is clear that there are no links with proper colors that have enough bandwidth, that is, entire set of constraints cannot be satisfied. But it is impossible to say which constraint in particular has caused the failure. Even if you start removing constraints one by one and rerunning the algorithm (which would be very unpractical to do), you will find out that it does not help. The path computation of the example may succeed in both these iterations because: a) there are links with proper colors; b) there are links with enough bandwidth. The bottom line is that path computation fails because of the entire set of constraints rather than because of one or several of them, and it is unrealistic to think that PCE in its negative reply would mark constraints which cause the failure. So, I recommend to have two flags (say, P and I). One of them should be used to mark mandatory constraints, while another - optional constraints. Recommend to make an assumption that PCE will run path computation at most two times: 1) trying to accommodate all constraints; 2) in case 1) fails, removing all optional constraints PCE should return: a) successful response without flags when 1) succeeds; b) successful response with flag I when 2) succeeds; 3) negative response with no flags when 2 fails. Igor ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" To: ; ; Sent: Friday, July 14, 2006 10:46 AM Subject: RE: [Pce] P & I flags Hi Dimitri, > -----Message d'origine----- > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > Envoyé : vendredi 14 juillet 2006 15:44 > À : pce@ietf.org > Objet : [Pce] P & I flags > > the comments around the P and I flags are > > o) we have two levels of optionality in listing the protocol > object and usage level of the protocol object - however it is > much more appropriate to be sure that mandatory constraints > have been taken rather than having the optional having been > taken into account As clearly pointed out in the same setion of the draft, if a mandatory constraint cannot be handled the PCE replies with PCErr message "If the PCE does not understand an object with the P Flag set or understands the object but decides to ignore the object, the entire PCEP message MUST be rejected and the PCE MUST send a PCErr message with Error-Type="Unknown Object" or "Not supported Object". If the PCE can handle all mandatory constraints it replies with a PCRep message (either positive or negative if there is no path), else it sends a PCErr message. Hence the PCC knows whether mandatory constraints have been taken into account. > > P flag (Processing-Rule - 1-bit): the P flag allows a PCC > to specify > in a PCReq message sent to a PCE whether the object must be taken > into account by the PCE during path computation or is > just optional. > When the P flag is set, the object MUST be taken into > account by the > PCE. Conversely, when the P flag is cleared, the object > is optional > and the PCE is free to ignore it if not supported. > > o) on the I flag issue is identical why include an object > which has not considered during computation ? I don't catch your point, the PCC may want to know the constraints that were not taken into account during path computation, this sounds quite important isn'it? there are so > many things that the PCE has not taken into account during > computation so why bother ? Hum I don't follow you here "there are so many things...", What do you mean? > it is imho > more important to include the mandatory object not taken > into account If a mandatory object is not taken into account, you cannot compute the path and you send an error message. I agree with you that this would be useful to include within the PCErr the set of objects not supported, this can be clarified in next revision. > > I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep > message to indicate to a PCC whether or not an optional object was > processed. The PCE MAY include the ignored optional object in its > reply and set the I flag to indicate that the optional object was > ignored during path computation. When the I flag is > cleared, the PCE > indicates that the optional object was processed during the path > computation. The setting of the I flag for optional objects is > purely indicative and optional. The I flag MUST be > cleared if the P > flag is set. > > o) the result of all these flags is that a PCC can be > wrapping around unknown constraints create processing churn > on the PCE; OK, if you mean that we should include the unsupported object(s) within the PCErr, then we are in sync Thanks for the comment Regards JL > > If the PCE does not understand an object with the P Flag set or > understands the object but decides to ignore the object, > the entire > PCEP message MUST be rejected and the PCE MUST send a > PCErr message > with Error-Type="Unknown Object" or "Not supported Object". > > > > _______________________________________________ > 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 Sun Jul 16 12:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G29QI-0002pu-4t; Sun, 16 Jul 2006 12:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G29QG-0002l6-Ro for pce@ietf.org; Sun, 16 Jul 2006 12:24:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G29QF-00087t-C7 for pce@ietf.org; Sun, 16 Jul 2006 12:24:48 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G29QB-000GlY-17; Sun, 16 Jul 2006 16:24:43 +0000 Message-ID: <44BA6856.7020100@psg.com> Date: Sun, 16 Jul 2006 18:24:54 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin Subject: Re: [Pce] P & I flags References: <021301c6a815$ba5b8f20$6501a8c0@movaz.com> In-Reply-To: <021301c6a815$ba5b8f20$6501a8c0@movaz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org igor, j-l to indicate optional/non-optional you need one flag like i indicate in my reply to j-l - let's say the P flag in the reply - where you have a third level of indirection since you can send a positive or a negative answer you can have one of the following a) positive response with both optional and non-optional b) positive response with non-optional only c) negative response however, as far as my reading goes, ALL non-optional constraints MUST be taken into account while SOME of the optional constraints MAY be taken into account hence one could consider that list in the reply corresponds to the list of considered constraints and since the requestor knows these are optional or not there is no need for a second flag - this prevents back tracking of optional information - and restrict confirmation to the mandatory constraints ps: are you serious when considering a message length of 2^32 ? thanks, - dimitri. Igor Bryskin wrote: > Hi JL, > > I have a question. Suppose, a path computation request has two constraints: > link colors and link bandwidth. Suppose the path computation fails. The > question is how the PCE can figure out what is the reason of this > computation failure? As an implementer of a Path Computation Engine I > always found it a difficult problem. Normally, presented with a path > computation request with link type constraints as in the example I am > describing, a PCE would prune out the arcs form the network graph associated > with links that do not satisfy at least one of the constraints, and after > that run some algorithm. If the algorithm fails the only thing is clear that > there are no links with proper colors that have enough bandwidth, that is, > entire set of constraints cannot be satisfied. But it is impossible to say > which constraint in particular has caused the failure. Even if you start > removing constraints one by one and rerunning the algorithm (which would be > very unpractical to do), you will find out that it does not help. The path > computation of the example may succeed in both these iterations because: > a) there are links with proper colors; > b) there are links with enough bandwidth. > > The bottom line is that path computation fails because of the entire set of > constraints rather than because of one or several of them, and it is > unrealistic to think that PCE in its negative reply would mark constraints > which cause the failure. > > So, I recommend to have two flags (say, P and I). One of them should be used > to mark mandatory constraints, while another - optional constraints. > Recommend to make an assumption that PCE will run path computation at most > two times: > > 1) trying to accommodate all constraints; > 2) in case 1) fails, removing all optional constraints > > PCE should return: > > a) successful response without flags when 1) succeeds; > b) successful response with flag I when 2) succeeds; > 3) negative response with no flags when 2 fails. > > Igor > > > > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN" > To: ; ; > > Sent: Friday, July 14, 2006 10:46 AM > Subject: RE: [Pce] P & I flags > > > Hi Dimitri, > > >>-----Message d'origine----- >>De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>Envoyé : vendredi 14 juillet 2006 15:44 >>À : pce@ietf.org >>Objet : [Pce] P & I flags >> >>the comments around the P and I flags are >> >>o) we have two levels of optionality in listing the protocol >>object and usage level of the protocol object - however it is >>much more appropriate to be sure that mandatory constraints >>have been taken rather than having the optional having been >>taken into account > > > As clearly pointed out in the same setion of the draft, if a mandatory > constraint cannot be handled the PCE replies with PCErr message > > "If the PCE does not understand an object with the P Flag set or > understands the object but decides to ignore the object, the entire > PCEP message MUST be rejected and the PCE MUST send a PCErr message > with Error-Type="Unknown Object" or "Not supported Object". > > If the PCE can handle all mandatory constraints it replies with a PCRep > message (either positive or negative if there is no path), else it sends a > PCErr message. > Hence the PCC knows whether mandatory constraints have been taken into > account. > > > > >> P flag (Processing-Rule - 1-bit): the P flag allows a PCC >>to specify >> in a PCReq message sent to a PCE whether the object must be taken >> into account by the PCE during path computation or is >>just optional. >> When the P flag is set, the object MUST be taken into >>account by the >> PCE. Conversely, when the P flag is cleared, the object >>is optional >> and the PCE is free to ignore it if not supported. >> >>o) on the I flag issue is identical why include an object >>which has not considered during computation ? > > > I don't catch your point, the PCC may want to know the constraints that were > not taken into account during path computation, this sounds quite important > isn'it? > > > there are so > >>many things that the PCE has not taken into account during >>computation so why bother ? > > > Hum I don't follow you here "there are so many things...", What do you mean? > > > >>it is imho >> more important to include the mandatory object not taken >>into account > > > If a mandatory object is not taken into account, you cannot compute the path > and you send an error message. I agree with you that this would be useful to > include within the PCErr the set of objects not supported, this can be > clarified in next revision. > > > >> I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep >> message to indicate to a PCC whether or not an optional object was >> processed. The PCE MAY include the ignored optional object in its >> reply and set the I flag to indicate that the optional object was >> ignored during path computation. When the I flag is >>cleared, the PCE >> indicates that the optional object was processed during the path >> computation. The setting of the I flag for optional objects is >> purely indicative and optional. The I flag MUST be >>cleared if the P >> flag is set. >> >>o) the result of all these flags is that a PCC can be >>wrapping around unknown constraints create processing churn >>on the PCE; > > > OK, if you mean that we should include the unsupported object(s) within the > PCErr, then we are in sync > > Thanks for the comment > > Regards > > JL > > >> If the PCE does not understand an object with the P Flag set or >> understands the object but decides to ignore the object, >>the entire >> PCEP message MUST be rejected and the PCE MUST send a >>PCErr message >> with Error-Type="Unknown Object" or "Not supported Object". >> >> >> >>_______________________________________________ >>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 Sun Jul 16 15:29:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2CJ7-00074g-Mv; Sun, 16 Jul 2006 15:29:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2CJ6-00074b-4c for pce@ietf.org; Sun, 16 Jul 2006 15:29:36 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2CJ4-0006N3-Ju for pce@ietf.org; Sun, 16 Jul 2006 15:29:36 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Jul 2006 21:29:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] P & I flags Date: Sun, 16 Jul 2006 21:29:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] P & I flags Thread-Index: Acando0NTJ3rWYM4RB67IM+PViDf+QBkfsYQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 16 Jul 2006 19:29:32.0646 (UTC) FILETIME=[2A084860:01C6A90E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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,=20 > -----Message d'origine----- > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Envoy=E9 : vendredi 14 juillet 2006 20:52 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : dimitri.papadimitriou@alcatel.be; pce@ietf.org > Objet : Re: [Pce] P & I flags >=20 > hi j-l >=20 > LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi Dimitri, > >=20 > >=20 > >> -----Message d'origine----- De : dimitri papadimitriou=20 > >> [mailto:dpapadimitriou@psg.com] Envoy=E9 : vendredi 14 juillet 2006 > >> 15:44 =C0 : pce@ietf.org Objet : [Pce] P & I flags > >>=20 > >> the comments around the P and I flags are > >>=20 > >> o) we have two levels of optionality in listing the=20 > protocol object=20 > >> and usage level of the protocol object - however it is much more=20 > >> appropriate to be sure that mandatory constraints have been taken=20 > >> rather than having the optional having been taken into account > >=20 > > As clearly pointed out in the same setion of the draft, if=20 > a mandatory=20 > > constraint cannot be handled the PCE replies with PCErr message >=20 > i restate you have two levels of indirection optional objects=20 > and optional usage of the constraint during pc Yes there are two levels, and the P/I flag semantic applies to the first = one.=20 Here is what is currently specified : -If a constraint is not recognized or not supported and P is set a PCErr = is sent -If a constraint is not recognized or not supported and P is not set, = the path is computed without taking into account this constraint, and = this constraint is carried within the PCRep with the I flag is set. -If a constraint is recognized and supported it MUST be taken into = account in path computation whatever the P flag value, and if no path = supporting this constraint can be found a negative PCRep is sent, that = may include the unsatisifed constraint. =20 This notion of "optional usage of constraint" you discuss, is = relevant...but actually related to constraint relaxation that was = largely discussed one year ago on this list, and as agreed by WG = consensus, we decided to remove constraint relaxation from this base = spec... So, here in this spec, if a constraint is recognized and supported it = must be used in Path computation, and, as clealry pointed out in the = draft (section 7.4) if no path satisfiying a given constraint can be = found, the PCE sends a PCRep message with a NO-PATH object that may = include the unsatisfied constraint, then this is up to the PCC to decide = what to do (e.g. it may send a new request by relaxing this constraint). >=20 > now the important thing is not that you have a "PCE deciding=20 > to ignore"=20 > but a PCC that performs a sort on constraint it wants to see=20 > as part of its comp request Yes but as discussed below this is another level, out of the scope of = this document >=20 > p flag can be used when the pce can't compute with that=20 > constraint(s) and sends a negative answer with the P flag on=20 > the constraints that can not be taken into account But this is not the semantic of the P flag, here you refer to a new flag = that would help constraint relaxation on the PCE. By the way, the PCC could send a PCReq including only constraints that = MUST be taken into account during path computation, and then subsequent = requests with additional optional constraints, and it would work as is. = There are many ways to ensure constraint relaxation and this is out of = the scope of this doc. >=20 > in the reply the P flag should be such that the requestor=20 > receives a confirmation of constraints taken into account=20 > during PCE pc - since this is the only thing PCC cares about=20 > and return an error if the object is not supported or=20 > decision with "Policy Control failure" or even "AC failure"=20 > in case of PCE overload See above >=20 > > "If the PCE does not understand an object with the P Flag set or=20 > > understands the object but decides to ignore the object, the entire=20 > > PCEP message MUST be rejected and the PCE MUST send a PCErr message=20 > > with Error-Type=3D"Unknown Object" or "Not supported Object". >=20 > my point is that you can not return "unknown object" from the=20 > P flag but from the unsupport of an object Why??? >=20 > > If the PCE can handle all mandatory constraints it replies with a=20 > > PCRep message (either positive or negative if there is no=20 > path), else=20 > > it sends a PCErr message. Hence the PCC knows whether mandatory=20 > > constraints have been taken into account. >=20 > you have also a third level of indirection in the reply=20 > because one assumes that >=20 > >> P flag (Processing-Rule - 1-bit): the P flag allows a PCC=20 > to specify=20 > >> in a PCReq message sent to a PCE whether the object must be taken=20 > >> into account by the PCE during path computation or is just=20 > optional.=20 > >> When the P flag is set, the object MUST be taken into=20 > account by the=20 > >> PCE. Conversely, when the P flag is cleared, the object=20 > is optional=20 > >> and the PCE is free to ignore it if not supported. > >>=20 > >> o) on the I flag issue is identical why include an object=20 > which has=20 > >> not considered during computation ? > >=20 > > I don't catch your point, the PCC may want to know the constraints=20 > > that were not taken into account during path computation,=20 > this sounds=20 > > quite important isn'it? > >=20 > >=20 > > there are so > >=20 > >> many things that the PCE has not taken into account during=20 > >> computation so why bother ? > >=20 > > Hum I don't follow you here "there are so many things...",=20 > What do you=20 > > mean? >=20 > see adrian's reply Ah, thanks! JL >=20 > thanks, > - dimitri. >=20 > >> it is imho more important to include the mandatory object=20 > not taken =20 > >> into account > >=20 > >=20 > > If a mandatory object is not taken into account, you cannot compute=20 > > the path and you send an error message. I agree with you that this=20 > > would be useful to include within the PCErr the set of objects not=20 > > supported, this can be clarified in next revision. > >=20 > >=20 > >=20 > >> I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep=20 > >> message to indicate to a PCC whether or not an optional object was=20 > >> processed. The PCE MAY include the ignored optional object in its=20 > >> reply and set the I flag to indicate that the optional object was=20 > >> ignored during path computation. When the I flag is=20 > cleared, the PCE=20 > >> indicates that the optional object was processed during the path=20 > >> computation. The setting of the I flag for optional objects is=20 > >> purely indicative and optional. The I flag MUST be=20 > cleared if the P=20 > >> flag is set. > >>=20 > >> o) the result of all these flags is that a PCC can be=20 > wrapping around=20 > >> unknown constraints create processing churn on the PCE; > >=20 > >=20 > > OK, if you mean that we should include the unsupported object(s)=20 > > within the PCErr, then we are in sync > >=20 > > Thanks for the comment > >=20 > > Regards > >=20 > > JL > >=20 > >=20 > >> If the PCE does not understand an object with the P Flag set or=20 > >> understands the object but decides to ignore the object,=20 > the entire =20 > >> PCEP message MUST be rejected and the PCE MUST send a=20 > PCErr message=20 > >> with Error-Type=3D"Unknown Object" or "Not supported Object". > >>=20 > >>=20 > >>=20 > >>=20 > >> _______________________________________________ Pce mailing list=20 > >> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce > >>=20 > >=20 > >=20 > > . > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Jul 16 15:56:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Ciq-0004e6-H6; Sun, 16 Jul 2006 15:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Cip-0004dy-6D for pce@ietf.org; Sun, 16 Jul 2006 15:56:11 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Cio-0008RR-LQ for pce@ietf.org; Sun, 16 Jul 2006 15:56:11 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Jul 2006 21:56:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] P & I flags Date: Sun, 16 Jul 2006 21:56:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] P & I flags Thread-Index: AcaoFb4S5ztPL6MQQRCApH3/kOCCbgA+H+AQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , , , X-OriginalArrivalTime: 16 Jul 2006 19:56:09.0417 (UTC) FILETIME=[E1C83390:01C6A911] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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 Igor, See inline, =20 > -----Message d'origine----- > De : Igor Bryskin [mailto:ibryskin@movaz.com]=20 > Envoy=E9 : samedi 15 juillet 2006 15:51 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; pce@ietf.org > Objet : Re: [Pce] P & I flags >=20 > Hi JL, >=20 > I have a question. Suppose, a path computation request has=20 > two constraints: > link colors and link bandwidth. Suppose the path computation=20 > fails. The question is how the PCE can figure out what is the=20 > reason of this computation failure?=20 > As an implementer of a=20 > Path Computation Engine I always found it a difficult=20 > problem. Normally, presented with a path computation request=20 > with link type constraints as in the example I am describing,=20 > a PCE would prune out the arcs form the network graph=20 > associated with links that do not satisfy at least one of the=20 > constraints, and after that run some algorithm. If the=20 > algorithm fails the only thing is clear that there are no=20 > links with proper colors that have enough bandwidth, that is,=20 > entire set of constraints cannot be satisfied. But it is=20 > impossible to say which constraint in particular has caused=20 > the failure. Even if you start removing constraints one by=20 > one and rerunning the algorithm (which would be very=20 > unpractical to do), you will find out that it does not help.=20 > The path computation of the example may succeed in both these=20 > iterations because: > a) there are links with proper colors; > b) there are links with enough bandwidth. >=20 > The bottom line is that path computation fails because of the=20 > entire set of constraints rather than because of one or=20 > several of them, and it is unrealistic to think that PCE in=20 > its negative reply would mark constraints which cause the failure. I don't think this is unrealistic, there are cases in your example = where the bandwidth alone as a single constraint cannot be fit while = color as a single constraint can be fit (and vice versa). In this case = this makes sense IMO to send a negative reply indicating that the = bandwidth cannot be fit. Anyway in the case you mention the PCE can send a negative reply = indicating bandwidth and color as unsatisifed constraints, and may even = suggest values that could be satisfied=20 (shall we consider that a PCE may be a bit more clever??) >=20 > So, I recommend to have two flags (say, P and I). One of them=20 > should be used to mark mandatory constraints, while another -=20 > optional constraints. As already commented to Dimitri, this is related to constraint = relaxation and is completely beyond the scope of this document as agreed = one year ago on this list. There are various solutions for constraints = relaxation that need to be discussed. By the way it could work as is by = sending two requests, one with mandatory constraints and the other with = all (mandatory + optional) constraints... > Recommend to make an assumption that PCE will run path=20 > computation at most two times: We will never make such recommendation, this is definitely a local = implementation issue. Regards, JL >=20 > 1) trying to accommodate all constraints; > 2) in case 1) fails, removing all optional constraints >=20 > PCE should return: >=20 > a) successful response without flags when 1) succeeds; > b) successful response with flag I when 2) succeeds; > 3) negative response with no flags when 2 fails. >=20 > Igor >=20 >=20 >=20 > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > To: ; ; > > Sent: Friday, July 14, 2006 10:46 AM > Subject: RE: [Pce] P & I flags >=20 >=20 > Hi Dimitri, >=20 > > -----Message d'origine----- > > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > Envoy=E9 : vendredi 14 juillet 2006 15:44 > > =C0 : pce@ietf.org > > Objet : [Pce] P & I flags > > > > the comments around the P and I flags are > > > > o) we have two levels of optionality in listing the protocol > > object and usage level of the protocol object - however it is > > much more appropriate to be sure that mandatory constraints > > have been taken rather than having the optional having been > > taken into account >=20 > As clearly pointed out in the same setion of the draft, if a mandatory > constraint cannot be handled the PCE replies with PCErr message >=20 > "If the PCE does not understand an object with the P Flag set or > understands the object but decides to ignore the object, the entire > PCEP message MUST be rejected and the PCE MUST send a PCErr message > with Error-Type=3D"Unknown Object" or "Not supported Object". >=20 > If the PCE can handle all mandatory constraints it replies=20 > with a PCRep > message (either positive or negative if there is no path),=20 > else it sends a > PCErr message. > Hence the PCC knows whether mandatory constraints have been taken into > account. >=20 >=20 >=20 > > > > P flag (Processing-Rule - 1-bit): the P flag allows a PCC > > to specify > > in a PCReq message sent to a PCE whether the object=20 > must be taken > > into account by the PCE during path computation or is > > just optional. > > When the P flag is set, the object MUST be taken into > > account by the > > PCE. Conversely, when the P flag is cleared, the object > > is optional > > and the PCE is free to ignore it if not supported. > > > > o) on the I flag issue is identical why include an object > > which has not considered during computation ? >=20 > I don't catch your point, the PCC may want to know the=20 > constraints that were > not taken into account during path computation, this sounds=20 > quite important > isn'it? >=20 >=20 > there are so > > many things that the PCE has not taken into account during > > computation so why bother ? >=20 > Hum I don't follow you here "there are so many things...",=20 > What do you mean? >=20 >=20 > > it is imho > > more important to include the mandatory object not taken > > into account >=20 > If a mandatory object is not taken into account, you cannot=20 > compute the path > and you send an error message. I agree with you that this=20 > would be useful to > include within the PCErr the set of objects not supported, this can be > clarified in next revision. >=20 >=20 > > > > I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep > > message to indicate to a PCC whether or not an optional=20 > object was > > processed. The PCE MAY include the ignored optional=20 > object in its > > reply and set the I flag to indicate that the optional=20 > object was > > ignored during path computation. When the I flag is > > cleared, the PCE > > indicates that the optional object was processed during the path > > computation. The setting of the I flag for optional objects is > > purely indicative and optional. The I flag MUST be > > cleared if the P > > flag is set. > > > > o) the result of all these flags is that a PCC can be > > wrapping around unknown constraints create processing churn > > on the PCE; >=20 > OK, if you mean that we should include the unsupported=20 > object(s) within the > PCErr, then we are in sync >=20 > Thanks for the comment >=20 > Regards >=20 > JL >=20 > > > > If the PCE does not understand an object with the P Flag set or > > understands the object but decides to ignore the object, > > the entire > > PCEP message MUST be rejected and the PCE MUST send a > > PCErr message > > with Error-Type=3D"Unknown Object" or "Not supported Object". > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Jul 16 16:25:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2DAh-0007lo-K6; Sun, 16 Jul 2006 16:24:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2DAg-0007lj-HD for pce@ietf.org; Sun, 16 Jul 2006 16:24:58 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2DAf-0002zc-5p for pce@ietf.org; Sun, 16 Jul 2006 16:24:58 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Jul 2006 22:24:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] P & I flags Date: Sun, 16 Jul 2006 22:25:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] P & I flags Thread-Index: AcanYKVvoHipAvKpQP2VdAJ7gw1sZQBs7Xjw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , , X-OriginalArrivalTime: 16 Jul 2006 20:24:55.0697 (UTC) FILETIME=[E6B9A010:01C6A915] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Adrian,=20 > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Envoy=E9 : vendredi 14 juillet 2006 18:14 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; pce@ietf.org > Objet : Re: [Pce] P & I flags >=20 > >> o) on the I flag issue is identical why include an object=20 > which has=20 > >> not considered during computation ? > > > > I don't catch your point, the PCC may want to know the constraints=20 > > that were not taken into account during path computation,=20 > this sounds=20 > > quite important isn'it? > > > >> there are so > >> many things that the PCE has not taken into account during=20 > >> computation so why bother ? > > > > Hum I don't follow you here "there are so many things...",=20 > What do you=20 > > mean? >=20 > I think the disconnect is that the I flag is only used in constraints > *returned* to the PCC. I.e. in constraints that formed part=20 > of the original request, but were ignored. Yes, of course and then what is the point? > There is no=20 > requirement (or desire?) for the PCE to randomly report other=20 > things it did not take into account (such as weather,=20 > shoe-size of operator, etc.) Hum, who knows...One may want a cold path (as transmission may become = bad when temperature goes beyond a threshold), the temperature may be = used as a link METRIC and the PCE may access a wheather server to = compute the path :-))=20 Regards, JL >=20 > Adrian >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Jul 16 17:38:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2EJT-0003Hz-9l; Sun, 16 Jul 2006 17:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2EJR-0003Hu-FQ for pce@ietf.org; Sun, 16 Jul 2006 17:38:05 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2EJQ-0003Ru-UO for pce@ietf.org; Sun, 16 Jul 2006 17:38:05 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Jul 2006 22:08:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] P & I flags Date: Sun, 16 Jul 2006 22:08:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] P & I flags Thread-Index: Acao9Fml1/adMHz5QnmKLYkqyKLwcgAHZRdQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , "Igor Bryskin" X-OriginalArrivalTime: 16 Jul 2006 20:08:01.0035 (UTC) FILETIME=[89F07DB0:01C6A913] X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 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,=20 > -----Message d'origine----- > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Envoy=E9 : dimanche 16 juillet 2006 18:25 > =C0 : Igor Bryskin > Cc : LE ROUX Jean-Louis RD-CORE-LAN;=20 > dimitri.papadimitriou@alcatel.be; pce@ietf.org > Objet : Re: [Pce] P & I flags >=20 > igor, j-l >=20 > to indicate optional/non-optional you need one flag like i=20 > indicate in my reply to j-l - let's say the P flag NO, why do you want to change the semantic if the P flag? this semantic = is required... >=20 > in the reply - where you have a third level of indirection=20 > since you can send a positive or a negative answer you can=20 > have one of the following >=20 > a) positive response with both optional and non-optional > b) positive response with non-optional only > c) negative response >=20 > however, as far as my reading goes, ALL non-optional=20 > constraints MUST be taken into account while SOME of the=20 > optional constraints MAY be taken into account No, all recognized and supported constraints MUST be taken into account = during path computation, whatever the P flag value.=20 The P flag simply indicates what to do when a constraint is not = recognized/unsupported. >=20 > hence one could consider that list in the reply corresponds=20 > to the list of considered constraints and since the requestor=20 > knows these are optional or not there is no need for a second=20 > flag - this prevents back tracking of optional information -=20 > and restrict confirmation to the mandatory constraints >=20 > ps: are you serious when considering a message length of 2^32 ? Yes, 2^16 may not be enought, think about an NMS that would send a = request for tens of thousands of LSPs. Thanks,=20 JL >=20 > thanks, > - dimitri. >=20 >=20 >=20 >=20 > Igor Bryskin wrote: > > Hi JL, > >=20 > > I have a question. Suppose, a path computation request has=20 > two constraints: > > link colors and link bandwidth. Suppose the path computation fails.=20 > > The question is how the PCE can figure out what is the=20 > reason of this=20 > > computation failure? As an implementer of a Path=20 > Computation Engine I=20 > > always found it a difficult problem. Normally, presented=20 > with a path=20 > > computation request with link type constraints as in the=20 > example I am=20 > > describing, a PCE would prune out the arcs form the network graph=20 > > associated with links that do not satisfy at least one of the=20 > > constraints, and after that run some algorithm. If the=20 > algorithm fails=20 > > the only thing is clear that there are no links with proper colors=20 > > that have enough bandwidth, that is, entire set of=20 > constraints cannot=20 > > be satisfied. But it is impossible to say which constraint in=20 > > particular has caused the failure. Even if you start removing=20 > > constraints one by one and rerunning the algorithm (which would be=20 > > very unpractical to do), you will find out that it does not=20 > help. The path computation of the example may succeed in both=20 > these iterations because: > > a) there are links with proper colors; > > b) there are links with enough bandwidth. > >=20 > > The bottom line is that path computation fails because of=20 > the entire=20 > > set of constraints rather than because of one or several of=20 > them, and=20 > > it is unrealistic to think that PCE in its negative reply=20 > would mark=20 > > constraints which cause the failure. > >=20 > > So, I recommend to have two flags (say, P and I). One of=20 > them should=20 > > be used to mark mandatory constraints, while another -=20 > optional constraints. > > Recommend to make an assumption that PCE will run path=20 > computation at=20 > > most two times: > >=20 > > 1) trying to accommodate all constraints; > > 2) in case 1) fails, removing all optional constraints > >=20 > > PCE should return: > >=20 > > a) successful response without flags when 1) succeeds; > > b) successful response with flag I when 2) succeeds; > > 3) negative response with no flags when 2 fails. > >=20 > > Igor > >=20 > >=20 > >=20 > > ----- Original Message ----- > > From: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > > > To: ; ; > > > > Sent: Friday, July 14, 2006 10:46 AM > > Subject: RE: [Pce] P & I flags > >=20 > >=20 > > Hi Dimitri, > >=20 > >=20 > >>-----Message d'origine----- > >>De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] Envoy=E9 = :=20 > >>vendredi 14 juillet 2006 15:44 =C0 : pce@ietf.org Objet : [Pce] P & = I=20 > >>flags > >> > >>the comments around the P and I flags are > >> > >>o) we have two levels of optionality in listing the protocol object=20 > >>and usage level of the protocol object - however it is much more=20 > >>appropriate to be sure that mandatory constraints have been taken=20 > >>rather than having the optional having been taken into account > >=20 > >=20 > > As clearly pointed out in the same setion of the draft, if=20 > a mandatory=20 > > constraint cannot be handled the PCE replies with PCErr message > >=20 > > "If the PCE does not understand an object with the P Flag set or > > understands the object but decides to ignore the object,=20 > the entire > > PCEP message MUST be rejected and the PCE MUST send a=20 > PCErr message > > with Error-Type=3D"Unknown Object" or "Not supported Object". > >=20 > > If the PCE can handle all mandatory constraints it replies with a=20 > > PCRep message (either positive or negative if there is no=20 > path), else=20 > > it sends a PCErr message. > > Hence the PCC knows whether mandatory constraints have been=20 > taken into=20 > > account. > >=20 > >=20 > >=20 > >=20 > >> P flag (Processing-Rule - 1-bit): the P flag allows a PCC to=20 > >>specify > >> in a PCReq message sent to a PCE whether the object=20 > must be taken > >> into account by the PCE during path computation or is just=20 > >>optional. > >> When the P flag is set, the object MUST be taken into=20 > account by=20 > >>the > >> PCE. Conversely, when the P flag is cleared, the object is=20 > >>optional > >> and the PCE is free to ignore it if not supported. > >> > >>o) on the I flag issue is identical why include an object which has=20 > >>not considered during computation ? > >=20 > >=20 > > I don't catch your point, the PCC may want to know the constraints=20 > > that were not taken into account during path computation,=20 > this sounds=20 > > quite important isn'it? > >=20 > >=20 > > there are so > >=20 > >>many things that the PCE has not taken into account during=20 > computation=20 > >>so why bother ? > >=20 > >=20 > > Hum I don't follow you here "there are so many things...",=20 > What do you mean? > >=20 > >=20 > >=20 > >>it is imho > >> more important to include the mandatory object not taken into=20 > >>account > >=20 > >=20 > > If a mandatory object is not taken into account, you cannot compute=20 > > the path and you send an error message. I agree with you that this=20 > > would be useful to include within the PCErr the set of objects not=20 > > supported, this can be clarified in next revision. > >=20 > >=20 > >=20 > >> I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep > >> message to indicate to a PCC whether or not an optional=20 > object was > >> processed. The PCE MAY include the ignored optional=20 > object in its > >> reply and set the I flag to indicate that the optional=20 > object was > >> ignored during path computation. When the I flag is=20 > cleared, the=20 > >>PCE > >> indicates that the optional object was processed during the path > >> computation. The setting of the I flag for optional objects is > >> purely indicative and optional. The I flag MUST be=20 > cleared if the=20 > >>P > >> flag is set. > >> > >>o) the result of all these flags is that a PCC can be=20 > wrapping around=20 > >>unknown constraints create processing churn on the PCE; > >=20 > >=20 > > OK, if you mean that we should include the unsupported object(s)=20 > > within the PCErr, then we are in sync > >=20 > > Thanks for the comment > >=20 > > Regards > >=20 > > JL > >=20 > >=20 > >> If the PCE does not understand an object with the P Flag set or > >> understands the object but decides to ignore the object, the=20 > >>entire > >> PCEP message MUST be rejected and the PCE MUST send a PCErr=20 > >>message > >> with Error-Type=3D"Unknown Object" or "Not supported Object". > >> > >> > >> > >>_______________________________________________ > >>Pce mailing list > >>Pce@lists.ietf.org > >>https://www1.ietf.org/mailman/listinfo/pce > >> > >=20 > >=20 > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > >=20 > >=20 > > . > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Jul 16 17:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2EW5-0002JR-BY; Sun, 16 Jul 2006 17:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2EW3-0002JL-9D for pce@ietf.org; Sun, 16 Jul 2006 17:51:07 -0400 Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2EW2-0005MM-Pv for pce@ietf.org; Sun, 16 Jul 2006 17:51:07 -0400 Received: from ib (unknown [172.16.50.20]) by jera.movaz.com (Postfix) with SMTP id 0579AD27; Sun, 16 Jul 2006 17:50:57 -0400 (EDT) Message-ID: <035401c6a921$ea5a01e0$6501a8c0@movaz.com> From: "Igor Bryskin" To: "LE ROUX Jean-Louis RD-CORE-LAN" , , , References: Subject: Re: [Pce] P & I flags Date: Sun, 16 Jul 2006 17:50:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: 71f780ffdd80c541d3e75aa5f2710d3d 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 JL. Please, see in line. Igor ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" ; ; ; Sent: Sunday, July 16, 2006 3:56 PM Subject: RE: [Pce] P & I flags Hi Igor, See inline, > -----Message d'origine----- > De : Igor Bryskin [mailto:ibryskin@movaz.com] > Envoyé : samedi 15 juillet 2006 15:51 > À : LE ROUX Jean-Louis RD-CORE-LAN; dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; pce@ietf.org > Objet : Re: [Pce] P & I flags > > Hi JL, > > I have a question. Suppose, a path computation request has > two constraints: > link colors and link bandwidth. Suppose the path computation > fails. The question is how the PCE can figure out what is the > reason of this computation failure? > As an implementer of a > Path Computation Engine I always found it a difficult > problem. Normally, presented with a path computation request > with link type constraints as in the example I am describing, > a PCE would prune out the arcs form the network graph > associated with links that do not satisfy at least one of the > constraints, and after that run some algorithm. If the > algorithm fails the only thing is clear that there are no > links with proper colors that have enough bandwidth, that is, > entire set of constraints cannot be satisfied. But it is > impossible to say which constraint in particular has caused > the failure. Even if you start removing constraints one by > one and rerunning the algorithm (which would be very > unpractical to do), you will find out that it does not help. > The path computation of the example may succeed in both these > iterations because: > a) there are links with proper colors; > b) there are links with enough bandwidth. > > The bottom line is that path computation fails because of the > entire set of constraints rather than because of one or > several of them, and it is unrealistic to think that PCE in > its negative reply would mark constraints which cause the failure. I don't think this is unrealistic, there are cases in your example where the bandwidth alone as a single constraint cannot be fit while color as a single constraint can be fit (and vice versa). In this case this makes sense IMO to send a negative reply indicating that the bandwidth cannot be fit. Anyway in the case you mention the PCE can send a negative reply indicating bandwidth and color as unsatisifed constraints, and may even suggest values that could be satisfied (shall we consider that a PCE may be a bit more clever??) IB>> This is the whole my point. If there is a set of mandatory constraints, there is no way for a PCE to tell because of which particular constraint(s) the computation has failed, let alone recommend other values for the constraints to make the computation successful. I'd like to hear from PCE developers whether they share my view. The only reasons to mark the constraints in the PC reply IMO are: a) for a mandatory constraint either when it was not recognized or could not be otherwise supported (e.g. an unknown color was specified) b) for an optional constraint when it was removed according to a signaled or policed constraint relaxation strategy which made the computation successful. Regards, Igor > > So, I recommend to have two flags (say, P and I). One of them > should be used to mark mandatory constraints, while another - > optional constraints. As already commented to Dimitri, this is related to constraint relaxation and is completely beyond the scope of this document as agreed one year ago on this list. There are various solutions for constraints relaxation that need to be discussed. By the way it could work as is by sending two requests, one with mandatory constraints and the other with all (mandatory + optional) constraints... > Recommend to make an assumption that PCE will run path > computation at most two times: We will never make such recommendation, this is definitely a local implementation issue. Regards, JL > > 1) trying to accommodate all constraints; > 2) in case 1) fails, removing all optional constraints > > PCE should return: > > a) successful response without flags when 1) succeeds; > b) successful response with flag I when 2) succeeds; > 3) negative response with no flags when 2 fails. > > Igor > > > > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > To: ; ; > > Sent: Friday, July 14, 2006 10:46 AM > Subject: RE: [Pce] P & I flags > > > Hi Dimitri, > > > -----Message d'origine----- > > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > Envoyé : vendredi 14 juillet 2006 15:44 > > À : pce@ietf.org > > Objet : [Pce] P & I flags > > > > the comments around the P and I flags are > > > > o) we have two levels of optionality in listing the protocol > > object and usage level of the protocol object - however it is > > much more appropriate to be sure that mandatory constraints > > have been taken rather than having the optional having been > > taken into account > > As clearly pointed out in the same setion of the draft, if a mandatory > constraint cannot be handled the PCE replies with PCErr message > > "If the PCE does not understand an object with the P Flag set or > understands the object but decides to ignore the object, the entire > PCEP message MUST be rejected and the PCE MUST send a PCErr message > with Error-Type="Unknown Object" or "Not supported Object". > > If the PCE can handle all mandatory constraints it replies > with a PCRep > message (either positive or negative if there is no path), > else it sends a > PCErr message. > Hence the PCC knows whether mandatory constraints have been taken into > account. > > > > > > > P flag (Processing-Rule - 1-bit): the P flag allows a PCC > > to specify > > in a PCReq message sent to a PCE whether the object > must be taken > > into account by the PCE during path computation or is > > just optional. > > When the P flag is set, the object MUST be taken into > > account by the > > PCE. Conversely, when the P flag is cleared, the object > > is optional > > and the PCE is free to ignore it if not supported. > > > > o) on the I flag issue is identical why include an object > > which has not considered during computation ? > > I don't catch your point, the PCC may want to know the > constraints that were > not taken into account during path computation, this sounds > quite important > isn'it? > > > there are so > > many things that the PCE has not taken into account during > > computation so why bother ? > > Hum I don't follow you here "there are so many things...", > What do you mean? > > > > it is imho > > more important to include the mandatory object not taken > > into account > > If a mandatory object is not taken into account, you cannot > compute the path > and you send an error message. I agree with you that this > would be useful to > include within the PCErr the set of objects not supported, this can be > clarified in next revision. > > > > > > I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep > > message to indicate to a PCC whether or not an optional > object was > > processed. The PCE MAY include the ignored optional > object in its > > reply and set the I flag to indicate that the optional > object was > > ignored during path computation. When the I flag is > > cleared, the PCE > > indicates that the optional object was processed during the path > > computation. The setting of the I flag for optional objects is > > purely indicative and optional. The I flag MUST be > > cleared if the P > > flag is set. > > > > o) the result of all these flags is that a PCC can be > > wrapping around unknown constraints create processing churn > > on the PCE; > > OK, if you mean that we should include the unsupported > object(s) within the > PCErr, then we are in sync > > Thanks for the comment > > Regards > > JL > > > > > If the PCE does not understand an object with the P Flag set or > > understands the object but decides to ignore the object, > > the entire > > PCEP message MUST be rejected and the PCE MUST send a > > PCErr message > > with Error-Type="Unknown Object" or "Not supported Object". > > > > > > > > _______________________________________________ > > 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 Sun Jul 16 18:04:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2EiY-0002oz-QK; Sun, 16 Jul 2006 18:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2EiX-0002or-9x for pce@ietf.org; Sun, 16 Jul 2006 18:04:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2EiW-0007wE-Ox for pce@ietf.org; Sun, 16 Jul 2006 18:04:01 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2EiS-000839-Q3; Sun, 16 Jul 2006 22:03:57 +0000 Message-ID: <44BAB7D8.5000107@psg.com> Date: Mon, 17 Jul 2006 00:04:08 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN Subject: Re: [Pce] P & I flags References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-l LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri, > > >> -----Message d'origine----- De : dimitri papadimitriou >> [mailto:dpapadimitriou@psg.com] Envoyé : dimanche 16 juillet 2006 >> 18:25 À : Igor Bryskin Cc : LE ROUX Jean-Louis RD-CORE-LAN; >> dimitri.papadimitriou@alcatel.be; pce@ietf.org Objet : Re: [Pce] P >> & I flags >> >> igor, j-l >> >> to indicate optional/non-optional you need one flag like i indicate >> in my reply to j-l - let's say the P flag > > > NO, why do you want to change the semantic if the P flag? this > semantic is required... call it I flag if you want the point is that the Error should be generated once an object (from its class or type) is not recognized if you have that a too high rejection rate could result from optional constraints such behaviour should be inferred by no further looking into the object >> in the reply - where you have a third level of indirection since >> you can send a positive or a negative answer you can have one of >> the following >> >> a) positive response with both optional and non-optional b) >> positive response with non-optional only c) negative response >> >> however, as far as my reading goes, ALL non-optional constraints >> MUST be taken into account while SOME of the optional constraints >> MAY be taken into account > > No, all recognized and supported constraints MUST be taken into > account during path computation, whatever the P flag value. The P > flag simply indicates what to do when a constraint is not > recognized/unsupported. again call it I flag, point remains, a negative answer shall come only from not finding a result from mandatory constraints and a positive result may include more than the set of mandatory constraints the fact that an error is issued should then be the result of the non-support of a mandatory constraint all together this makes one flag - and this only because there is a difference between optional object support and optional processing >> hence one could consider that list in the reply corresponds to the >> list of considered constraints and since the requestor knows these >> are optional or not there is no need for a second flag - this >> prevents back tracking of optional information - and restrict >> confirmation to the mandatory constraints >> >> ps: are you serious when considering a message length of 2^32 ? > > Yes, 2^16 may not be enought, think about an NMS that would send a > request for tens of thousands of LSPs. what does make the NMS PCC different from an LSR ? i think there is a difference between the set of command issued to the NMS and the resulting set of PCC requests an NMS will generate thanks, - dimitri. > Thanks, > > JL > > >> thanks, - dimitri. >> >> >> >> >> Igor Bryskin wrote: >> >>> Hi JL, >>> >>> I have a question. Suppose, a path computation request has >> >> two constraints: >> >>> link colors and link bandwidth. Suppose the path computation >>> fails. The question is how the PCE can figure out what is the >> >> reason of this >> >>> computation failure? As an implementer of a Path >> >> Computation Engine I >> >>> always found it a difficult problem. Normally, presented >> >> with a path >> >>> computation request with link type constraints as in the >> >> example I am >> >>> describing, a PCE would prune out the arcs form the network graph >>> associated with links that do not satisfy at least one of the >>> constraints, and after that run some algorithm. If the >> >> algorithm fails >> >>> the only thing is clear that there are no links with proper >>> colors that have enough bandwidth, that is, entire set of >> >> constraints cannot >> >>> be satisfied. But it is impossible to say which constraint in >>> particular has caused the failure. Even if you start removing >>> constraints one by one and rerunning the algorithm (which would >>> be very unpractical to do), you will find out that it does not >> >> help. The path computation of the example may succeed in both these >> iterations because: >> >>> a) there are links with proper colors; b) there are links with >>> enough bandwidth. >>> >>> The bottom line is that path computation fails because of >> >> the entire >> >>> set of constraints rather than because of one or several of >> >> them, and >> >>> it is unrealistic to think that PCE in its negative reply >> >> would mark >> >>> constraints which cause the failure. >>> >>> So, I recommend to have two flags (say, P and I). One of >> >> them should >> >>> be used to mark mandatory constraints, while another - >> >> optional constraints. >> >>> Recommend to make an assumption that PCE will run path >> >> computation at >> >>> most two times: >>> >>> 1) trying to accommodate all constraints; 2) in case 1) fails, >>> removing all optional constraints >>> >>> PCE should return: >>> >>> a) successful response without flags when 1) succeeds; b) >>> successful response with flag I when 2) succeeds; 3) negative >>> response with no flags when 2 fails. >>> >>> Igor >>> >>> >>> >>> ----- Original Message ----- From: "LE ROUX Jean-Louis >>> RD-CORE-LAN" To: >>> ; ; >>> Sent: Friday, July 14, 2006 10:46 AM Subject: RE: >>> [Pce] P & I flags >>> >>> >>> Hi Dimitri, >>> >>> >>> >>>> -----Message d'origine----- De : dimitri papadimitriou >>>> [mailto:dpapadimitriou@psg.com] Envoyé : vendredi 14 juillet >>>> 2006 15:44 À : pce@ietf.org Objet : [Pce] P & I flags >>>> >>>> the comments around the P and I flags are >>>> >>>> o) we have two levels of optionality in listing the protocol >>>> object and usage level of the protocol object - however it is >>>> much more appropriate to be sure that mandatory constraints >>>> have been taken rather than having the optional having been >>>> taken into account >>> >>> >>> As clearly pointed out in the same setion of the draft, if >> >> a mandatory >> >>> constraint cannot be handled the PCE replies with PCErr message >>> >>> "If the PCE does not understand an object with the P Flag set or >>> understands the object but decides to ignore the object, >> >> the entire >> >>> PCEP message MUST be rejected and the PCE MUST send a >> >> PCErr message >> >>> with Error-Type="Unknown Object" or "Not supported Object". >>> >>> If the PCE can handle all mandatory constraints it replies with a >>> PCRep message (either positive or negative if there is no >> >> path), else >> >>> it sends a PCErr message. Hence the PCC knows whether mandatory >>> constraints have been >> >> taken into >> >>> account. >>> >>> >>> >>> >>> >>>> P flag (Processing-Rule - 1-bit): the P flag allows a PCC to >>>> specify in a PCReq message sent to a PCE whether the object >> >> must be taken >> >>>> into account by the PCE during path computation or is just >>>> optional. When the P flag is set, the object MUST be taken into >>>> >> >> account by >> >>>> the PCE. Conversely, when the P flag is cleared, the object is >>>> optional and the PCE is free to ignore it if not supported. >>>> >>>> o) on the I flag issue is identical why include an object which >>>> has not considered during computation ? >>> >>> >>> I don't catch your point, the PCC may want to know the >>> constraints that were not taken into account during path >>> computation, >> >> this sounds >> >>> quite important isn'it? >>> >>> >>> there are so >>> >>> >>>> many things that the PCE has not taken into account during >> >> computation >> >>>> so why bother ? >>> >>> >>> Hum I don't follow you here "there are so many things...", >> >> What do you mean? >> >>> >>> >>>> it is imho more important to include the mandatory object not >>>> taken into account >>> >>> >>> If a mandatory object is not taken into account, you cannot >>> compute the path and you send an error message. I agree with you >>> that this would be useful to include within the PCErr the set of >>> objects not supported, this can be clarified in next revision. >>> >>> >>> >>> >>>> I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep >>>> message to indicate to a PCC whether or not an optional >> >> object was >> >>>> processed. The PCE MAY include the ignored optional >> >> object in its >> >>>> reply and set the I flag to indicate that the optional >> >> object was >> >>>> ignored during path computation. When the I flag is >> >> cleared, the >> >>>> PCE indicates that the optional object was processed during the >>>> path computation. The setting of the I flag for optional >>>> objects is purely indicative and optional. The I flag MUST be >>>> >> >> cleared if the >> >>>> P flag is set. >>>> >>>> o) the result of all these flags is that a PCC can be >> >> wrapping around >> >>>> unknown constraints create processing churn on the PCE; >>> >>> >>> OK, if you mean that we should include the unsupported object(s) >>> within the PCErr, then we are in sync >>> >>> Thanks for the comment >>> >>> Regards >>> >>> JL >>> >>> >>> >>>> If the PCE does not understand an object with the P Flag set or >>>> understands the object but decides to ignore the object, the >>>> entire PCEP message MUST be rejected and the PCE MUST send a >>>> PCErr message with Error-Type="Unknown Object" or "Not >>>> supported Object". >>>> >>>> >>>> >>>> _______________________________________________ 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 Sun Jul 16 18:28:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2F6d-0007op-PI; Sun, 16 Jul 2006 18:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2F6c-0007oB-BB for pce@ietf.org; Sun, 16 Jul 2006 18:28:54 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2F6Z-0002AX-Ku for pce@ietf.org; Sun, 16 Jul 2006 18:28:54 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 00:28:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] P & I flags Date: Mon, 17 Jul 2006 00:28:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] P & I flags Thread-Index: AcapIe3ZKELPbcT9QaqmXV0u8NzbIAABJ39Q From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , , , X-OriginalArrivalTime: 16 Jul 2006 22:28:49.0947 (UTC) FILETIME=[35E226B0:01C6A927] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f 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 Igor,=20 > -----Message d'origine----- > De : Igor Bryskin [mailto:ibryskin@movaz.com]=20 > Envoy=E9 : dimanche 16 juillet 2006 23:50 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; dpapadimitriou@psg.com;=20 > dimitri.papadimitriou@alcatel.be; pce@ietf.org > Objet : Re: [Pce] P & I flags >=20 > Hi JL. >=20 > Please, see in line. >=20 > Igor >=20 > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > To: "Igor Bryskin" ;=20 > ; ;=20 > > Sent: Sunday, July 16, 2006 3:56 PM > Subject: RE: [Pce] P & I flags >=20 >=20 > Hi Igor, >=20 > See inline, >=20 >=20 >=20 > > -----Message d'origine----- > > De : Igor Bryskin [mailto:ibryskin@movaz.com] > > Envoy=E9 : samedi 15 juillet 2006 15:51 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; pce@ietf.org > > Objet : Re: [Pce] P & I flags > > > > Hi JL, > > > > I have a question. Suppose, a path computation request has > > two constraints: > > link colors and link bandwidth. Suppose the path computation > > fails. The question is how the PCE can figure out what is the > > reason of this computation failure? > > As an implementer of a > > Path Computation Engine I always found it a difficult > > problem. Normally, presented with a path computation request > > with link type constraints as in the example I am describing, > > a PCE would prune out the arcs form the network graph > > associated with links that do not satisfy at least one of the > > constraints, and after that run some algorithm. If the > > algorithm fails the only thing is clear that there are no > > links with proper colors that have enough bandwidth, that is, > > entire set of constraints cannot be satisfied. But it is > > impossible to say which constraint in particular has caused > > the failure. Even if you start removing constraints one by > > one and rerunning the algorithm (which would be very > > unpractical to do), you will find out that it does not help. > > The path computation of the example may succeed in both these > > iterations because: > > a) there are links with proper colors; > > b) there are links with enough bandwidth. > > > > The bottom line is that path computation fails because of the > > entire set of constraints rather than because of one or > > several of them, and it is unrealistic to think that PCE in > > its negative reply would mark constraints which cause the failure. >=20 > I don't think this is unrealistic, there are cases in your=20 > example where > the bandwidth alone as a single constraint cannot be fit=20 > while color as a > single constraint can be fit (and vice versa). In this case=20 > this makes sense > IMO to send a negative reply indicating that the bandwidth=20 > cannot be fit. > Anyway in the case you mention the PCE can send a negative=20 > reply indicating > bandwidth and color as unsatisifed constraints, and may even=20 > suggest values > that could be satisfied > (shall we consider that a PCE may be a bit more clever??) >=20 > IB>> This is the whole my point. If there is a set of=20 > mandatory constraints, > there is no way for a PCE to tell because of which particular=20 > constraint(s) > the computation has failed,=20 Why, if it is clever enough to detect a blocking constraint? >let alone recommend other values for the > constraints to make the computation successful. I'd like to=20 > hear from PCE > developers whether they share my view. Ah, OK let discuss with PCE developpers! I don't share your view... Best Regards, JL >=20 > The only reasons to mark the constraints in the PC reply IMO are: >=20 > a) for a mandatory constraint either when it was not=20 > recognized or could not > be otherwise supported (e.g. an unknown color was specified) > b) for an optional constraint when it was removed according=20 > to a signaled or > policed constraint relaxation strategy which made the computation > successful. >=20 > Regards, > Igor >=20 >=20 > > > > So, I recommend to have two flags (say, P and I). One of them > > should be used to mark mandatory constraints, while another - > > optional constraints. >=20 > As already commented to Dimitri, this is related to=20 > constraint relaxation > and is completely beyond the scope of this document as agreed=20 > one year ago > on this list. There are various solutions for constraints=20 > relaxation that > need to be discussed. By the way it could work as is by sending two > requests, one with mandatory constraints and the other with=20 > all (mandatory + > optional) constraints... >=20 >=20 > > Recommend to make an assumption that PCE will run path > > computation at most two times: >=20 > We will never make such recommendation, this is definitely a local > implementation issue. >=20 > Regards, >=20 > JL >=20 > > > > 1) trying to accommodate all constraints; > > 2) in case 1) fails, removing all optional constraints > > > > PCE should return: > > > > a) successful response without flags when 1) succeeds; > > b) successful response with flag I when 2) succeeds; > > 3) negative response with no flags when 2 fails. > > > > Igor > > > > > > > > ----- Original Message ----- > > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > > > To: ; ; > > > > Sent: Friday, July 14, 2006 10:46 AM > > Subject: RE: [Pce] P & I flags > > > > > > Hi Dimitri, > > > > > -----Message d'origine----- > > > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > Envoy=E9 : vendredi 14 juillet 2006 15:44 > > > =C0 : pce@ietf.org > > > Objet : [Pce] P & I flags > > > > > > the comments around the P and I flags are > > > > > > o) we have two levels of optionality in listing the protocol > > > object and usage level of the protocol object - however it is > > > much more appropriate to be sure that mandatory constraints > > > have been taken rather than having the optional having been > > > taken into account > > > > As clearly pointed out in the same setion of the draft, if=20 > a mandatory > > constraint cannot be handled the PCE replies with PCErr message > > > > "If the PCE does not understand an object with the P Flag set or > > understands the object but decides to ignore the object,=20 > the entire > > PCEP message MUST be rejected and the PCE MUST send a=20 > PCErr message > > with Error-Type=3D"Unknown Object" or "Not supported Object". > > > > If the PCE can handle all mandatory constraints it replies > > with a PCRep > > message (either positive or negative if there is no path), > > else it sends a > > PCErr message. > > Hence the PCC knows whether mandatory constraints have been=20 > taken into > > account. > > > > > > > > > > > > P flag (Processing-Rule - 1-bit): the P flag allows a PCC > > > to specify > > > in a PCReq message sent to a PCE whether the object > > must be taken > > > into account by the PCE during path computation or is > > > just optional. > > > When the P flag is set, the object MUST be taken into > > > account by the > > > PCE. Conversely, when the P flag is cleared, the object > > > is optional > > > and the PCE is free to ignore it if not supported. > > > > > > o) on the I flag issue is identical why include an object > > > which has not considered during computation ? > > > > I don't catch your point, the PCC may want to know the > > constraints that were > > not taken into account during path computation, this sounds > > quite important > > isn'it? > > > > > > there are so > > > many things that the PCE has not taken into account during > > > computation so why bother ? > > > > Hum I don't follow you here "there are so many things...", > > What do you mean? > > > > > > > it is imho > > > more important to include the mandatory object not taken > > > into account > > > > If a mandatory object is not taken into account, you cannot > > compute the path > > and you send an error message. I agree with you that this > > would be useful to > > include within the PCErr the set of objects not supported,=20 > this can be > > clarified in next revision. > > > > > > > > > > I flag (Ignore - 1 bit): the I flag is used by a PCE=20 > in a PCRep > > > message to indicate to a PCC whether or not an optional > > object was > > > processed. The PCE MAY include the ignored optional > > object in its > > > reply and set the I flag to indicate that the optional > > object was > > > ignored during path computation. When the I flag is > > > cleared, the PCE > > > indicates that the optional object was processed=20 > during the path > > > computation. The setting of the I flag for optional=20 > objects is > > > purely indicative and optional. The I flag MUST be > > > cleared if the P > > > flag is set. > > > > > > o) the result of all these flags is that a PCC can be > > > wrapping around unknown constraints create processing churn > > > on the PCE; > > > > OK, if you mean that we should include the unsupported > > object(s) within the > > PCErr, then we are in sync > > > > Thanks for the comment > > > > Regards > > > > JL > > > > > > > > If the PCE does not understand an object with the P=20 > Flag set or > > > understands the object but decides to ignore the object, > > > the entire > > > PCEP message MUST be rejected and the PCE MUST send a > > > PCErr message > > > with Error-Type=3D"Unknown Object" or "Not supported Object". > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Jul 16 19:27:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2G0q-0008BR-L6; Sun, 16 Jul 2006 19:27:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2G0p-00089d-Bz for pce@ietf.org; Sun, 16 Jul 2006 19:26:59 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2G0n-00065H-Ks for pce@ietf.org; Sun, 16 Jul 2006 19:26:59 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 01:26:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] P & I flags Date: Mon, 17 Jul 2006 01:27:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] P & I flags Thread-Index: AcapI72VwWl9ocbeRhSPfnZU09Ww+gAA4sCA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 16 Jul 2006 23:26:55.0496 (UTC) FILETIME=[536EB880:01C6A92F] 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: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri,=20 > -----Message d'origine----- > De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 > Envoy=E9 : lundi 17 juillet 2006 00:04 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : dimitri.papadimitriou@alcatel.be; Igor Bryskin; pce@ietf.org > Objet : Re: [Pce] P & I flags >=20 > hi j-l >=20 > LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi Dimitri, > >=20 > >=20 > >> -----Message d'origine----- De : dimitri papadimitriou=20 > >> [mailto:dpapadimitriou@psg.com] Envoy=E9 : dimanche 16 juillet 2006 > >> 18:25 =C0 : Igor Bryskin Cc : LE ROUX Jean-Louis RD-CORE-LAN;=20 > >> dimitri.papadimitriou@alcatel.be; pce@ietf.org Objet : Re:=20 > [Pce] P &=20 > >> I flags > >>=20 > >> igor, j-l > >>=20 > >> to indicate optional/non-optional you need one flag like i=20 > indicate=20 > >> in my reply to j-l - let's say the P flag > >=20 > >=20 > > NO, why do you want to change the semantic if the P flag? this=20 > > semantic is required... >=20 > call it I flag if you want the point is that the Error should=20 > be generated once an object (from its class or type) is not recognized Humm no, I flag is already used!=20 Call it O flag if you like=20 >=20 > if you have that a too high rejection rate could result from=20 > optional constraints such behaviour should be inferred by no=20 > further looking into the object >=20 > >> in the reply - where you have a third level of indirection=20 > since you=20 > >> can send a positive or a negative answer you can have one of the=20 > >> following > >>=20 > >> a) positive response with both optional and non-optional=20 > b) positive=20 > >> response with non-optional only c) negative response > >>=20 > >> however, as far as my reading goes, ALL non-optional=20 > constraints MUST=20 > >> be taken into account while SOME of the optional=20 > constraints MAY be=20 > >> taken into account > >=20 > > No, all recognized and supported constraints MUST be taken into=20 > > account during path computation, whatever the P flag value.=20 > The P flag=20 > > simply indicates what to do when a constraint is not=20 > > recognized/unsupported. >=20 > again call it I flag, point remains, a negative answer shall=20 > come only from not finding a result from mandatory constraints Dimitri, please see my previous answer. I understand the semantic you = define, it was discussed one year ago as part of a constraint relaxation = thread (less constrained path), and the result of this thread was that = there there was no consensus, some people were against, hence we removed = the requirement from the generic PCECP req id, and also we removed text = on less constrained path from the PCEP spec, and decided to address it = latter. This should be defined in a separate ID once the requirement is clearly = expressed. By the way there are various options for handling optional constraints = and more generally constraint relaxation. For instance the PCC may also = send two requests, one with only mandatory constraints and another with = optional constraints... >=20 > and a positive result may include more than the set of=20 > mandatory constraints Ah, this is interesting...and what sub-set of optional constraints is = selected if not all optional constaints can be satisfied? Again we are = discussing constraint relaxation here and this is beyond the scope of = this doc... >=20 > the fact that an error is issued should then be the result of=20 > the non-support of a mandatory constraint Yes, indeed this is current P flag processing >=20 > all together this makes one flag - and this only because=20 > there is a difference between optional object support and=20 > optional processing >=20 > >> hence one could consider that list in the reply corresponds to the=20 > >> list of considered constraints and since the requestor knows these=20 > >> are optional or not there is no need for a second flag - this=20 > >> prevents back tracking of optional information - and restrict=20 > >> confirmation to the mandatory constraints > >>=20 > >> ps: are you serious when considering a message length of 2^32 ? > >=20 > > Yes, 2^16 may not be enought, think about an NMS that would send a=20 > > request for tens of thousands of LSPs. >=20 > what does make the NMS PCC different from an LSR ?=20 Please keep it simple, you were asking why do we need 2^32, and I answered that 2^16 may not be enough, and I took, as pure = illustration, the example of an NMS acting as PCC, and sending a PCReq = for a synchronized path computation of tens of K LSPs, ie a PCReq with = tens of K requests (I simply took the example of NMS PCC, as an NMS is = likely to request synchronized path computation of many more LSPs, than = an LSR would do).=20 > i think=20 > there is a difference between the set of command issued to=20 > the NMS and the resulting set of PCC requests an NMS will generate Who says the contrary? And what is the point here? Thanks,=20 JL >=20 > thanks, > - dimitri. >=20 > > Thanks, > >=20 > > JL > >=20 > >=20 > >> thanks, - dimitri. > >>=20 > >>=20 > >>=20 > >>=20 > >> Igor Bryskin wrote: > >>=20 > >>> Hi JL, > >>>=20 > >>> I have a question. Suppose, a path computation request has > >>=20 > >> two constraints: > >>=20 > >>> link colors and link bandwidth. Suppose the path=20 > computation fails.=20 > >>> The question is how the PCE can figure out what is the > >>=20 > >> reason of this > >>=20 > >>> computation failure? As an implementer of a Path > >>=20 > >> Computation Engine I > >>=20 > >>> always found it a difficult problem. Normally, presented > >>=20 > >> with a path > >>=20 > >>> computation request with link type constraints as in the > >>=20 > >> example I am > >>=20 > >>> describing, a PCE would prune out the arcs form the=20 > network graph =20 > >>> associated with links that do not satisfy at least one of the=20 > >>> constraints, and after that run some algorithm. If the > >>=20 > >> algorithm fails > >>=20 > >>> the only thing is clear that there are no links with=20 > proper colors=20 > >>> that have enough bandwidth, that is, entire set of > >>=20 > >> constraints cannot > >>=20 > >>> be satisfied. But it is impossible to say which constraint in=20 > >>> particular has caused the failure. Even if you start removing=20 > >>> constraints one by one and rerunning the algorithm (which=20 > would be=20 > >>> very unpractical to do), you will find out that it does not > >>=20 > >> help. The path computation of the example may succeed in=20 > both these=20 > >> iterations because: > >>=20 > >>> a) there are links with proper colors; b) there are links with=20 > >>> enough bandwidth. > >>>=20 > >>> The bottom line is that path computation fails because of > >>=20 > >> the entire > >>=20 > >>> set of constraints rather than because of one or several of > >>=20 > >> them, and > >>=20 > >>> it is unrealistic to think that PCE in its negative reply > >>=20 > >> would mark > >>=20 > >>> constraints which cause the failure. > >>>=20 > >>> So, I recommend to have two flags (say, P and I). One of > >>=20 > >> them should > >>=20 > >>> be used to mark mandatory constraints, while another - > >>=20 > >> optional constraints. > >>=20 > >>> Recommend to make an assumption that PCE will run path > >>=20 > >> computation at > >>=20 > >>> most two times: > >>>=20 > >>> 1) trying to accommodate all constraints; 2) in case 1) fails,=20 > >>> removing all optional constraints > >>>=20 > >>> PCE should return: > >>>=20 > >>> a) successful response without flags when 1) succeeds; b)=20 > >>> successful response with flag I when 2) succeeds; 3) negative=20 > >>> response with no flags when 2 fails. > >>>=20 > >>> Igor > >>>=20 > >>>=20 > >>>=20 > >>> ----- Original Message ----- From: "LE ROUX Jean-Louis=20 > RD-CORE-LAN"=20 > >>> To: > >>> ; ; > >>> Sent: Friday, July 14, 2006 10:46 AM Subject: RE: > >>> [Pce] P & I flags > >>>=20 > >>>=20 > >>> Hi Dimitri, > >>>=20 > >>>=20 > >>>=20 > >>>> -----Message d'origine----- De : dimitri papadimitriou=20 > >>>> [mailto:dpapadimitriou@psg.com] Envoy=E9 : vendredi 14 juillet > >>>> 2006 15:44 =C0 : pce@ietf.org Objet : [Pce] P & I flags > >>>>=20 > >>>> the comments around the P and I flags are > >>>>=20 > >>>> o) we have two levels of optionality in listing the=20 > protocol object=20 > >>>> and usage level of the protocol object - however it is much more=20 > >>>> appropriate to be sure that mandatory constraints have=20 > been taken=20 > >>>> rather than having the optional having been taken into account > >>>=20 > >>>=20 > >>> As clearly pointed out in the same setion of the draft, if > >>=20 > >> a mandatory > >>=20 > >>> constraint cannot be handled the PCE replies with PCErr message > >>>=20 > >>> "If the PCE does not understand an object with the P Flag set or=20 > >>> understands the object but decides to ignore the object, > >>=20 > >> the entire > >>=20 > >>> PCEP message MUST be rejected and the PCE MUST send a > >>=20 > >> PCErr message > >>=20 > >>> with Error-Type=3D"Unknown Object" or "Not supported Object". > >>>=20 > >>> If the PCE can handle all mandatory constraints it=20 > replies with a =20 > >>> PCRep message (either positive or negative if there is no > >>=20 > >> path), else > >>=20 > >>> it sends a PCErr message. Hence the PCC knows whether mandatory=20 > >>> constraints have been > >>=20 > >> taken into > >>=20 > >>> account. > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>> P flag (Processing-Rule - 1-bit): the P flag allows a PCC to=20 > >>>> specify in a PCReq message sent to a PCE whether the object > >>=20 > >> must be taken > >>=20 > >>>> into account by the PCE during path computation or is just=20 > >>>> optional. When the P flag is set, the object MUST be taken into > >>>>=20 > >>=20 > >> account by > >>=20 > >>>> the PCE. Conversely, when the P flag is cleared, the object is =20 > >>>> optional and the PCE is free to ignore it if not supported. > >>>>=20 > >>>> o) on the I flag issue is identical why include an=20 > object which has=20 > >>>> not considered during computation ? > >>>=20 > >>>=20 > >>> I don't catch your point, the PCC may want to know the=20 > constraints=20 > >>> that were not taken into account during path computation, > >>=20 > >> this sounds > >>=20 > >>> quite important isn'it? > >>>=20 > >>>=20 > >>> there are so > >>>=20 > >>>=20 > >>>> many things that the PCE has not taken into account during > >>=20 > >> computation > >>=20 > >>>> so why bother ? > >>>=20 > >>>=20 > >>> Hum I don't follow you here "there are so many things...", > >>=20 > >> What do you mean? > >>=20 > >>>=20 > >>>=20 > >>>> it is imho more important to include the mandatory=20 > object not taken=20 > >>>> into account > >>>=20 > >>>=20 > >>> If a mandatory object is not taken into account, you=20 > cannot compute=20 > >>> the path and you send an error message. I agree with you=20 > that this=20 > >>> would be useful to include within the PCErr the set of=20 > objects not=20 > >>> supported, this can be clarified in next revision. > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>> I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep =20 > >>>> message to indicate to a PCC whether or not an optional > >>=20 > >> object was > >>=20 > >>>> processed. The PCE MAY include the ignored optional > >>=20 > >> object in its > >>=20 > >>>> reply and set the I flag to indicate that the optional > >>=20 > >> object was > >>=20 > >>>> ignored during path computation. When the I flag is > >>=20 > >> cleared, the > >>=20 > >>>> PCE indicates that the optional object was processed during the=20 > >>>> path computation. The setting of the I flag for=20 > optional objects=20 > >>>> is purely indicative and optional. The I flag MUST be > >>>>=20 > >>=20 > >> cleared if the > >>=20 > >>>> P flag is set. > >>>>=20 > >>>> o) the result of all these flags is that a PCC can be > >>=20 > >> wrapping around > >>=20 > >>>> unknown constraints create processing churn on the PCE; > >>>=20 > >>>=20 > >>> OK, if you mean that we should include the unsupported object(s) =20 > >>> within the PCErr, then we are in sync > >>>=20 > >>> Thanks for the comment > >>>=20 > >>> Regards > >>>=20 > >>> JL > >>>=20 > >>>=20 > >>>=20 > >>>> If the PCE does not understand an object with the P Flag set or =20 > >>>> understands the object but decides to ignore the object,=20 > the entire=20 > >>>> PCEP message MUST be rejected and the PCE MUST send a=20 > PCErr message=20 > >>>> with Error-Type=3D"Unknown Object" or "Not supported Object". > >>>>=20 > >>>>=20 > >>>>=20 > >>>> _______________________________________________ Pce mailing list=20 > >>>> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce > >>>>=20 > >>>=20 > >>>=20 > >>> _______________________________________________ Pce mailing list=20 > >>> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce > >>>=20 > >>>=20 > >>> . > >>>=20 > >>=20 > >=20 > > . > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jul 17 04:27:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ORS-0008AQ-KF; Mon, 17 Jul 2006 04:27:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mGd-0008KJ-Gf for pce@ietf.org; Sat, 15 Jul 2006 11:41:19 -0400 Received: from [12.0.238.162] (helo=mail.wandl.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1mGa-0007OK-LU for pce@ietf.org; Sat, 15 Jul 2006 11:41:19 -0400 Received: from mail.wandl.com (localhost [127.0.0.1]) by mail.wandl.com (8.13.6/8.13.1) with ESMTP id k6FFdc3j005274; Sat, 15 Jul 2006 11:39:38 -0400 (EDT) Received: from localhost (dave@localhost) by mail.wandl.com (8.13.6/8.13.1/Submit) with ESMTP id k6FFdL59005258; Sat, 15 Jul 2006 11:39:21 -0400 (EDT) Date: Sat, 15 Jul 2006 11:39:21 -0400 (EDT) From: Dave Wang To: Igor Bryskin Subject: Re: [Pce] P & I flags In-Reply-To: <021301c6a815$ba5b8f20$6501a8c0@movaz.com> Message-ID: References: <021301c6a815$ba5b8f20$6501a8c0@movaz.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1152977961=:5166" X-Virus-Scanned: clamd / ClamAV version 0.70-rc, clamav-milter version 0.70 X-WANDL-MailScanner-Information: Please contact the ISP for more information X-WANDL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: dave@mail.wandl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 X-Mailman-Approved-At: Mon, 17 Jul 2006 04:27:00 -0400 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1152977961=:5166 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Igor, =09There is also the complexity of setup/holding priority. If you raise the setup priority, you may succeed in path placement, but may also cause many lower holding priority LSP's to re-route or fail. Dave On Sat, 15 Jul 2006, Igor Bryskin wrote: > Hi JL, > > I have a question. Suppose, a path computation request has two constraint= s: > link colors and link bandwidth. Suppose the path computation fails. The > question is how the PCE can figure out what is the reason of this > computation failure? As an implementer of a Path Computation Engine I > always found it a difficult problem. Normally, presented with a path > computation request with link type constraints as in the example I am > describing, a PCE would prune out the arcs form the network graph associa= ted > with links that do not satisfy at least one of the constraints, and after > that run some algorithm. If the algorithm fails the only thing is clear t= hat > there are no links with proper colors that have enough bandwidth, that is= , > entire set of constraints cannot be satisfied. But it is impossible to sa= y > which constraint in particular has caused the failure. Even if you start > removing constraints one by one and rerunning the algorithm (which would = be > very unpractical to do), you will find out that it does not help. The pat= h > computation of the example may succeed in both these iterations because: > a) there are links with proper colors; > b) there are links with enough bandwidth. > > The bottom line is that path computation fails because of the entire set = of > constraints rather than because of one or several of them, and it is > unrealistic to think that PCE in its negative reply would mark constraint= s > which cause the failure. > > So, I recommend to have two flags (say, P and I). One of them should be u= sed > to mark mandatory constraints, while another - optional constraints. > Recommend to make an assumption that PCE will run path computation at mos= t > two times: > > 1) trying to accommodate all constraints; > 2) in case 1) fails, removing all optional constraints > > PCE should return: > > a) successful response without flags when 1) succeeds; > b) successful response with flag I when 2) succeeds; > 3) negative response with no flags when 2 fails. > > Igor > > > > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN" > To: ; ; > > Sent: Friday, July 14, 2006 10:46 AM > Subject: RE: [Pce] P & I flags > > > Hi Dimitri, > >> -----Message d'origine----- >> De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> Envoy=E9 : vendredi 14 juillet 2006 15:44 >> =C0 : pce@ietf.org >> Objet : [Pce] P & I flags >> >> the comments around the P and I flags are >> >> o) we have two levels of optionality in listing the protocol >> object and usage level of the protocol object - however it is >> much more appropriate to be sure that mandatory constraints >> have been taken rather than having the optional having been >> taken into account > > As clearly pointed out in the same setion of the draft, if a mandatory > constraint cannot be handled the PCE replies with PCErr message > > "If the PCE does not understand an object with the P Flag set or > understands the object but decides to ignore the object, the entire > PCEP message MUST be rejected and the PCE MUST send a PCErr message > with Error-Type=3D"Unknown Object" or "Not supported Object". > > If the PCE can handle all mandatory constraints it replies with a PCRep > message (either positive or negative if there is no path), else it sends = a > PCErr message. > Hence the PCC knows whether mandatory constraints have been taken into > account. > > > >> >> P flag (Processing-Rule - 1-bit): the P flag allows a PCC >> to specify >> in a PCReq message sent to a PCE whether the object must be taken >> into account by the PCE during path computation or is >> just optional. >> When the P flag is set, the object MUST be taken into >> account by the >> PCE. Conversely, when the P flag is cleared, the object >> is optional >> and the PCE is free to ignore it if not supported. >> >> o) on the I flag issue is identical why include an object >> which has not considered during computation ? > > I don't catch your point, the PCC may want to know the constraints that w= ere > not taken into account during path computation, this sounds quite importa= nt > isn'it? > > > there are so >> many things that the PCE has not taken into account during >> computation so why bother ? > > Hum I don't follow you here "there are so many things...", What do you me= an? > > >> it is imho >> more important to include the mandatory object not taken >> into account > > If a mandatory object is not taken into account, you cannot compute the p= ath > and you send an error message. I agree with you that this would be useful= to > include within the PCErr the set of objects not supported, this can be > clarified in next revision. > > >> >> I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep >> message to indicate to a PCC whether or not an optional object was >> processed. The PCE MAY include the ignored optional object in its >> reply and set the I flag to indicate that the optional object was >> ignored during path computation. When the I flag is >> cleared, the PCE >> indicates that the optional object was processed during the path >> computation. The setting of the I flag for optional objects is >> purely indicative and optional. The I flag MUST be >> cleared if the P >> flag is set. >> >> o) the result of all these flags is that a PCC can be >> wrapping around unknown constraints create processing churn >> on the PCE; > > OK, if you mean that we should include the unsupported object(s) within t= he > PCErr, then we are in sync > > Thanks for the comment > > Regards > > JL > >> >> If the PCE does not understand an object with the P Flag set or >> understands the object but decides to ignore the object, >> the entire >> PCEP message MUST be rejected and the PCE MUST send a >> PCErr message >> with Error-Type=3D"Unknown Object" or "Not supported Object". >> >> >> >> _______________________________________________ >> 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 > ---559023410-851401618-1152977961=:5166 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 ---559023410-851401618-1152977961=:5166-- From pce-bounces@lists.ietf.org Mon Jul 17 09:08:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Spq-000805-0w; Mon, 17 Jul 2006 09:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PkY-0000Jh-Rh for pce@ietf.org; Fri, 14 Jul 2006 11:38:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OlW-0007HX-8s for pce@ietf.org; Fri, 14 Jul 2006 10:35:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1Nlj-0005ZD-UF for pce@ietf.org; Fri, 14 Jul 2006 09:32:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2006 06:31:45 -0700 X-BrightmailFiltered: true X-IronPort-AV: i="4.06,242,1149490800"; d="scan'208,217"; a="32219645:sNHT110673836" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EDVjcj025846; Fri, 14 Jul 2006 09:31:45 -0400 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 k6EDVidU022416; Fri, 14 Jul 2006 09:31:44 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 09:31:44 -0400 Received: from [132.219.17.214] ([10.86.243.100]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 09:31:42 -0400 In-Reply-To: <44B79B83.9060203@psg.com> References: <44B789D3.1070902@psg.com> <30DD16B4-4F39-4B0E-86AF-DEDCDEC705DC@cisco.com> <44B79B83.9060203@psg.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <30D9037B-D733-4CBB-BF47-E24817441CB3@cisco.com> From: JP Vasseur Subject: Re: [Pce] path key and brpc Date: Fri, 14 Jul 2006 09:31:40 -0400 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Jul 2006 13:31:42.0358 (UTC) FILETIME=[D7EAD360:01C6A749] DKIM-Signature: a=rsa-sha1; q=dns; l=136569; t=1152883905; x=1153747905; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20[Pce]=20path=20key=20and=20brpc |To:dpapadimitriou@psg.com,=20dimitri.papadimitriou@alcatel.be; X=v=3Dcisco.com=3B=20h=3D/O8r3cEcGbBy+qMugOJAXpmKWV0=3D; b=A1TEcggMIRZIrLPo+8wgO2uTT06KrThnyhsXhymSI6PalwSbwbueYTFirOJZCtX3aU/WI0wJ Lk2t6uAZmd5M/ZclFZrCWTt0L8qblAEEZ2NZIl86kWsks/3qCbO4NCSf; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: -2.1 (--) X-Scan-Signature: b6f8716893cf3b34d1cbc77a492ea11f X-Mailman-Approved-At: Mon, 17 Jul 2006 09:08:27 -0400 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="===============0926211463==" Errors-To: pce-bounces@lists.ietf.org --===============0926211463== Content-Type: multipart/alternative; boundary=Apple-Mail-80-630525530 --Apple-Mail-80-630525530 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Dimitri, On Jul 14, 2006, at 9:26 AM, dimitri papadimitriou wrote: > hi jp > > JP Vasseur wrote: > >> Hi Dimitri, >> On Jul 14, 2006, at 8:10 AM, dimitri papadimitriou wrote: >>> the draft speaks about inter-as comp methods in introduction e.g =20= >>> brpc but how the latter can be used in conjunction with pks ? >>> >> BRPC can be used in conjunction with PKS since the set of =20 >> returned paths by a downstream PCE can be made of loose hops. =20 >> Path-Keys are then accumulate along the computed path. > > as far as my understanding goes on brpc, it says > > Step 2: PCE(n) computes VSPT(n) made of the list of shortest > constrained path(s) between every BR-en(j,n) and the TE LSP > destination using a suitable path computation algorithm (e.g. =20 > CSPF) > and returns the computed VSPT(n) to PCE(n-1). > > =3D> do you mean that you are going to send back a list of asbr's =20 > that are the head-end of these constraint sp's ? please detail in =20 > your draft > This is already explicitly mentioned in the ID: Each branch of the VSPT tree (path) may be returned in the form =20 of an explicit path (in which case all the hops along the path segment are listed) or a loose path (in which case only the BR is specified) so as to preserve confidentiality along with the respective cost. I'll add a short section pointing to the Path-key ID (after the split =20= of the Path-key ID). > add also the overhead increase in maintaining a set of keys that =20 > the enitity as to potentially maintain and how long - > Yes as pointed out by Adrian yesterday this will be discussed in a =20 further revision of the Path-key ID. Thanks. JP. > thx, > -d. > >>> the draft mentions it may result into two documents (one in =20 >>> ccamp and the other in pce wg) -> good idea because path key =20 >>> technique can be used independently of the presence of a initial =20= >>> pcc-/pce- pce exchange >>> >>> the latter would result in the possibility to make use of pks =20 >>> with pd pc >>> >> Indeed. >> Thanks. >> JP. >>> >> key-00.txt> >>> >>> >>> >>> Networking Working Group Rich Bradford =20 >>> (Ed) >>> IETF Internet Draft JP Vasseur >>> Cisco Systems, =20 >>> Inc. >>> Adrian =20 >>> Farrel >>> Old Dog =20 >>> Consulting >>> >>> >>> >>> Proposed Status: Standard >>> Expires: December 2006 >>> June 2006 >>> >>> >>> >>> draft-bradford-pce-path-key-00.txt >>> >>> >>> Preserving Topology Confidentiality in Inter-Domain Path >>> Computation and Signaling >>> >>> Status of this Memo >>> >>> By submitting this Internet-Draft, each author represents that >>> any applicable patent or other IPR claims of which he or she is >>> aware have been or will be disclosed, and any of which he or she >>> becomes aware will be disclosed, in accordance with Section 6 of >>> BCP 79. >>> >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF), its areas, and its working groups. Note that >>> other groups may also distribute working documents as Internet- >>> Drafts. >>> >>> Internet-Drafts are draft documents valid for a maximum of six >>> months and may be updated, replaced, or obsoleted by other >>> documents at any time. It is inappropriate to use Internet-=20 >>> Drafts >>> as reference material or to cite them other than as "work in >>> progress." >>> >>> The list of current Internet-Drafts can be accessed at >>> http://www.ietf.org/ietf/1id-abstracts.txt. >>> >>> The list of Internet-Draft Shadow Directories can be accessed at >>> http://www.ietf.org/shadow.html. >>> >>> >>> >>> >>> >>> >>> >>> Bradford, Vasseur and =20 >>> Farrel 1 >>> >>> >>> draft-bradford-pce-path-key-00.txt June 2006 >>> >>> Abstract >>> >>> Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) >>> Label Switched Paths (LSPs) may be computed by Path Computation >>> Elements (PCEs). Where the TE 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 =20 >>> 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, >>> thus disclosing internal topology information. This issue may be >>> circumvented by returning a loose hop and by invoking a new path >>> computation from the domain boundary LSR during TE LSP setup as >>> the LSP enters the second domain, but this technique has several >>> issues including the problem of maintaining path diversity. >>> >>> This document defines a mechanism to hide the contents of a >>> segment of a path, called the Confidential Path Segment (CPS). =20= >>> The >>> CPS may be replaced by a path key that can be conveyed in the PCE >>> Communication Protocol (PCEP) and signaled within in a Resource >>> Reservation Protocol (RSVP) explicit route object. >>> >>> >>> >>> Table of contents >>> To be Added >>> >>> Conventions used in this document >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>> "OPTIONAL" in this document are to be interpreted as described in >>> RFC-2119 [RFC2119]. >>> >>> 1. Note >>> >>> It must be noted that this document proposes RSVP-TE and PCEP >>> protocol extensions and may eventually result in two separate >>> documents to be discussed in the CCAMP and PCE Working Groups >>> respectively. >>> >>> 2. Terminology >>> >>> ASBR Routers: border routers used to connect to another AS of a >>> different or the same Service Provider via one or more links >>> inter-connecting between ASs. >>> >>> >>> Bradford, Vasseur, and =20 >>> Farrel 2 >>> >>> >>> draft-bradford-pce-path-key-00.txt June 2006 >>> >>> CPS: Confidential Path Segment. A segment of a path that contains >>> nodes and links that the AS policy requires to not be disclosed >>> outside the AS. >>> >>> Inter-AS TE LSP: A TE LSP that crosses an AS boundary. >>> >>> LSR: Label Switching Router. >>> >>> LSP: Label Switched Path. >>> >>> PCC: Path Computation Client: any client application requesting a >>> path computation to be performed by a Path Computation Element. >>> >>> PCE: Path Computation Element: an entity (component, application >>> or >>> network node) that is capable of computing a network path or =20 >>> route >>> based on a network graph and applying computational constraints. >>> >>> TE LSP: Traffic Engineering Label Switched Path >>> >>> 3. Introduction >>> >>> Path computation techniques using the Path Computation Element >>> (PCE) have been described in [PCE-ARCH] and allow for path >>> computation of inter-domain Multiprotocol Label Switching (MPLS) >>> traffic engineering (TE) Label Switched Paths (LSPs). >>> >>> An important element of inter-domain TE is that TE information is >>> not usually shared between domains for scalability and >>> confidentiality reasons ([RFC4105] and [RFC4216]). Therefore, a >>> single PCE is unlikely to be able to compute a full inter-domain >>> path. >>> >>> Two routing scenarios can be used for inter-domain TE LSPs: one >>> using per-domain path computation (defined in [PD-PATH-COMP]), =20= >>> and >>> the other using a PCE-based path computation technique with >>> cooperation between PCEs (as described in [PCE-ARCH]). In this >>> second case, paths for inter-domain LSPs are computed by >>> cooperation between PCEs each of which computes a segment of the >>> path across one domain. Such a path computation procedure is >>> described in [BRPC]. >>> >>> If confidentiality is required between domains (such as would =20 >>> very >>> likely be the case between ASs belonging to different service >>> providers) then cooperating PCEs cannot exchange path segments or >>> else the receiving PCE and the Path Computation Client (PCC) will >>> be able to see the individual hops through another domain. We >>> define the part of the path which we wish to keep confidential as >>> the Confidential Path Segment (CPS). >>> >>> Bradford, Vasseur, and =20 >>> Farrel 3 >>> >>> >>> draft-bradford-pce-path-key-00.txt June 2006 >>> >>> >>> One mechanism for preserving the confidentiality of the CPS is =20= >>> for >>> the PCE to return a path containing a loose hop for the segment >>> internal to a domain that must be kept confidential. The concept >>> of loose hops for the route of an LSP is described in [RFC3209]. >>> The Path Computation Element Communication Protocol (PCEP) >>> supports the use of paths with loose hops, and it is a local >>> policy decision at a PCE whether it returns a full explicit path >>> or uses loose hops. >>> >>> If loose hops are used, the TE LSPs are signaled as normal >>> ([RFC3209]), and when a loose hop is encountered in the explicit >>> route it is resolved by performing a secondary path computation. >>> Given the nature of the cooperation between PCEs in computing the >>> original path, this secondary computation occurs at a Label >>> Switching Router (LSR) at a domain boundary and the route is >>> expanded as described in [PD-PATH-COMP]. >>> >>> The PCE-based computation model is particularly useful for >>> determining mutually disjoint inter-domain paths such as might be >>> required for service protection. A single path computation =20 >>> request >>> is used. However, if loose hops are returned, the path of each =20= >>> LSP >>> must be recomputed at the domain boundaries as the LSPs are >>> signaled, and since the LSP signaling proceeds independently for >>> each LSP, disjoint paths cannot be guaranteed since the LSRs in >>> charge of expanding the EROs are not synchronized. >>> >>> Therefore, using the loose hop technique, path segment >>> confidentiality and path diversity are mutually incompatible >>> requirements. >>> >>> This document defines the notion of a Path Key that is a token >>> that replaces a path segment in an explicit route. The Path Key >>> can be encoded as a Path Key Sub-object (PKS) which can be >>> exchanged in PCEP [PCEP] for PCE path computation results and >>> subsequent computation requests, and in RSVP-TE [RFC3209] for >>> signaling of explicit paths. The PKS may also, optionally, be =20 >>> used >>> in recorded routes in RSVP-TE. >>> >>> The next section provides the details for this solution. >>> >>> 4. Path-Key Solution >>> >>> The Path-Key solution may be applied in the PCE-based path >>> computation context as follows. A PCE computes a path segment and >>> replaces it in the path reported to the PCC (or another PCE) by >>> one or more sub-objects referred to as the PKS. The entry and >>> boundary LSR of each CPS SHOULD be specified as hops in the >>> >>> >>> Bradford, Vasseur, and =20 >>> Farrel 4 >>> >>> >>> draft-bradford-pce-path-key-00.txt June 2006 >>> >>> returned path immediately preceding the PKS, but where two PKSs >>> are supplied in sequence the entry node to the second MAY be >>> encoded within the first. The exit node of a CPS MAY be =20 >>> present as >>> a strict hop immediately following the PKS, but MAY also be =20 >>> hidden >>> as part of the PKS and through the use of a subsequent loose hop. >>> >>> The PKS, itself, MAY be supplied as a loose hop, but is >>> RECOMMENDED to be used as a strict hop immediately following the >>> hop that indicates the boundary LSR. >>> >>> 4.1. Mode of Operation >>> >>> During path computation, when local policy dictates that >>> confidentiality must be preserved for all or part of the path >>> segment being computed, the PCE associates a path-key with the >>> computed path for the CPS, places its own identifier (its PCE-ID) >>> along with the path-key in a PKS, and inserts the PKS in the path >>> returned to the PCC or the collaborating PCE immediately after =20= >>> the >>> sub-object that identifies the LSR that will expand the PKS =20 >>> into a >>> explicit path hops. This will usually be the LSR that is the =20 >>> start >>> point of the CPS. The PCE that generates a PKS MUST store the >>> computed path segment and the path-key for later retrieval. A >>> local policy SHOULD be used to determine for how long to retain >>> such stored information, and whether to discard the information >>> after it has been queried using the procedures described below. >>> TBD: Need to define the scope of the PKS and spell out the >>> restrictions on Path Key re-use. >>> >>> A head-end LSR that is a PCC converts the path returned by a PCE >>> into an explicit route object (ERO) that it includes in the >>> Resource Reservation Protocol (RSVP) Path message. If the path >>> returned by the PCE contains PKSs these are included in the ERO. >>> Like any other sub-objects, the PKS is passed transparently from >>> hop to hop, until it becomes the first sub-object in the ERO. =20 >>> This >>> will occur at the start of the CPS which will usually be the >>> domain boundary. The PKS MUST be preceded by an ERO sub-object >>> that identifies the LSR that must expand the PKS, so the PKS will >>> not be encountered in ERO processing until the LSR that can >>> process it. >>> >>> An LSR that encounters a PKS when trying to identify the next-hop >>> retrieves the PCE-ID from the PKS and sends the path-key to the >>> PCE in a PCEP query the details of which will be described in a >>> further revision of this document. >>> >>> Upon receiving the path query, the PCE identifies the computed >>> path segment using the supplied path-key, and returns the >>> previously computed path segment in the form of explicit hops to >>> >>> Bradford, Vasseur, and =20 >>> Farrel 5 >>> >>> >>> draft-bradford-pce-path-key-00.txt June 2006 >>> >>> the requesting node. The requesting node inserts the explicit =20 >>> hops >>> into the ERO and continues to process the LSP setup as per >>> [RFC3209]. >>> >>> Note that if a PCE fails to expand a PKS, the requesting LSR MUST >>> fail the LSP setup and SHOULD use the procedures associated with >>> loose hop expansion failure [RFC3209]. >>> >>> 5. PCEP/RSVP-TE Path Key Sub-object >>> >>> >>> The Path Key sub-object (PKS) may be carried in the Explicit =20 >>> Route >>> Object (ERO) of a PCEP PCRep message [PCEP] or an RSVP-TE Path >>> message [RFC3209]. The PKS is a fixed-length sub-object =20 >>> containing >>> a Path-Key and a PCE-ID. The Path Key is an identifier, or token >>> used to represent the CPS within the context of the PCE =20 >>> identified >>> by the PCE-ID. The PCE-ID identifies the PCE that can decode the >>> Path Key using a reachable IPv4 or IPv6 address of the PCE. >>> Because of the IPv4 and IPv6 variants, two subobjects are defined >>> as follows. >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >>> +-+ >>> |L| Type | Length | Path =20 >>> Key | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >>> +-+ >>> | IPv4 address (4 =20 >>> bytes) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >>> +-+ >>> >>> L >>> >>> The L bit SHOULD NOT be set, so that the sub-object >>> represents a strict hop in the explicit route. >>> >>> Type >>> >>> TBD Path Key with IPv4 address >>> >>> Length >>> >>> The Length contains the total length of the subobject in >>> bytes, including the Type and Length fields. The Length is =20 >>> always >>> 8. >>> >>> IPv4 address >>> >>> An IPv4 address of the PCE that can decode this key. The >>> address used SHOULD be an address of the PCE that is always >>> >>> >>> Bradford, Vasseur, and =20 >>> Farrel 6 >>> >>> >>> draft-bradford-pce-path-key-00.txt June 2006 >>> >>> reachable, and MAY be an address that is restricted to the domain >>> in which the LSR that is called upon to expand the CPS lies. >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >>> +-+ >>> |L| Type | Length | Path =20 >>> Key | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >>> +-+ >>> | IPv6 address (16 =20 >>> bytes) | >>> =20 >>> | | >>> =20 >>> | | >>> =20 >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >>> +-+ >>> >>> L >>> >>> As above. >>> >>> Type >>> >>> TBD Path Key with IPv6 address >>> >>> Length >>> >>> The Length contains the total length of the subobject in >>> bytes, including the Type and Length fields. The Length is =20 >>> always >>> 20. >>> >>> IPv6 address >>> >>> An IPv6 address of the PCE that can decode this key. The >>> address used SHOULD be an address of the PCE that is always >>> reachable, but MAY be an address that is restricted to the domain >>> in which the LSR that is called upon to expand the CPS lies. >>> >>> >>> 6. Security Considerations >>> >>> This document proposes tunneling secure topology information >>> across an untrusted AS, so the security considerations are many >>> and apply to PCEP and RSVP-TE. >>> Issues include: >>> - Security of the CPS (can other network elements probe for >>> expansion of path-keys, possibly at random?). >>> - Authenticity of the path-key (resilience to alteration by >>> intermediaries, resilience to fake expansion of path-keys). >>> - Resilience from DNS attacks (insertion of spurious path-keys; >>> flooding of bogus path-key expansion requests). >>> >>> >>> Bradford, Vasseur, and =20 >>> Farrel 7 >>> >>> >>> draft-bradford-pce-path-key-00.txt June 2006 >>> >>> 7. Manageability Considerations >>> >>> TBD >>> >>> 8. IANA considerations >>> >>> The IANA section will be detailed in further revision of this >>> document. >>> >>> For RSVP, it will include code point requests for the three new >>> ERO sub-objects, and a new ErrorSpec Error Code. >>> >>> For PCEP, it will include code point requests for the three new >>> computed path sub-objects. >>> >>> >>> 9. Intellectual Property Considerations >>> >>> The IETF takes no position regarding the validity or scope of any >>> Intellectual Property Rights or other rights that might be =20 >>> claimed >>> to pertain to the implementation or use of the technology >>> described in this document or the extent to which any license >>> under such rights might or might not be available; nor does it >>> represent that it has made any independent effort to identify any >>> such rights. Information on the procedures with respect to rights >>> in RFC documents can be found in BCP 78 and BCP 79. >>> >>> Copies of IPR disclosures made to the IETF Secretariat and any >>> assurances of licenses to be made available, or the result of an >>> attempt made to obtain a general license or permission for the =20= >>> use >>> of such proprietary rights by implementers or users of this >>> specification can be obtained from the IETF on-line IPR =20 >>> repository >>> at http://www.ietf.org/ipr. >>> >>> The IETF invites any interested party to bring to its attention >>> any copyrights, patents or patent applications, or other >>> proprietary rights that may cover technology that may be required >>> to implement this standard. Please address the information to the >>> IETF at ietf-ipr@ietf.org. >>> >>> 10. References >>> >>> 10.1. Normative References >>> >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>> >>> >>> >>> >>> Bradford, Vasseur, and =20 >>> Farrel 8 >>> >>> >>> draft-bradford-pce-path-key-00.txt June 2006 >>> >>> [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., =20 >>> Srinivasan, V. >>> and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", =20= >>> RFC >>> 3209, December 2001. >>> >>> [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., >>> Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element >>> (PCE) communication Protocol (PCEP)", draft-vasseur-pce-pcep, >>> work in progress. >>> >>> 10.2. Informational References >>> >>> [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation >>> Element (PCE) Architecture", draft-ietf-pce-architecture, work in >>> progress. >>> >>> [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation >>> method for establishing Inter-domain Traffic Engineering (TE) >>> Label >>> Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path- >>> comp, work in progress. >>> >>> [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based >>> Computation >>> (BRPC) procedure to compute shortest inter-domain Traffic >>> Engineering Label Switched Path", draft-vasseur-pce-brpc, work in >>> progress. >>> >>> [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements >>> for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", >>> RFC 4105, June 2005. >>> >>> [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS >>> Traffic Engineering requirements", RFC 4216, November 2005. >>> >>> >>> >>> 11. Authors' Addresses: >>> >>> Rich Bradford (Editor) >>> Cisco Systems, Inc. >>> 1414 Massachusetts Avenue >>> Boxborough , MA - 01719 >>> USA >>> Email: rbradfor@cisco.com >>> >>> J.-P Vasseur >>> Cisco Systems, Inc. >>> 1414 Massachusetts Avenue >>> Boxborough , MA - 01719 >>> >>> Bradford, Vasseur, and =20 >>> Farrel 9 >>> >>> >>> draft-bradford-pce-path-key-00.txt June 2006 >>> >>> USA >>> Email: jpv@cisco.com >>> >>> Adrian Farrel >>> Old Dog Consulting >>> EMail: adrian@olddog.co.uk >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Full Copyright Statement >>> >>> Copyright (C) The Internet Society (2006). >>> >>> This document is subject to the rights, licenses and =20 >>> restrictions >>> contained in BCP 78, and except as set forth therein, the =20 >>> authors >>> retain all their rights. >>> >>> This document and the information contained herein are provided >>> on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >>> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND >>> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, >>> EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY =20 >>> THAT >>> THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR >>> ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A >>> PARTICULAR PURPOSE. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Bradford, Vasseur, and =20 >>> Farrel 10 >>> >>> =0C_______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >> . --Apple-Mail-80-630525530 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Dimitri,

On = Jul 14, 2006, at 9:26 AM, dimitri papadimitriou wrote:

hi jp

JP Vasseur wrote:

Hi Dimitri,
On Jul 14, 2006, at 8:10 AM, dimitri papadimitriou = wrote:
the draft = speaks about inter-as comp methods in introduction e.g=A0 brpc but how the latter can = be used in conjunction with pks ?

BRPC can be = used in conjunction with PKS since the set of returned=A0 paths by a downstream PCE can = be made of loose hops. Path-Keys are=A0 then accumulate along the = computed path.

as far as my understanding goes = on brpc, it says

=A0=A0 = Step 2: PCE(n) computes VSPT(n) made of the list of = shortest
=A0=A0 constrained path(s) = between every BR-en(j,n) and the TE LSP
=A0=A0 destination using a = suitable path computation algorithm (e.g.=A0 CSPF)
=A0=A0 = and returns the computed VSPT(n) to PCE(n-1).

=3D> = do you mean that you are going to send back a list of asbr's that are = the head-end of these constraint sp's ?=A0 please detail in your = draft
This is already explicitly = mentioned in the ID:

=A0 =A0Each branch of the VSPT tree (path) = may be returned in the form of an
=A0=A0 = explicit path (in which case all the hops along the path segment = are
=A0=A0 listed) or a loose path (in which case only = the BR is specified) so
=A0=A0 as to preserve = confidentiality along with the respective cost.

I'll add a short section = pointing to the Path-key ID (after the split of the Path-key = ID).

add also the overhead increase = in maintaining a set of keys that the enitity as to potentially maintain = and how long -
Yes as pointed out by = Adrian yesterday this will be discussed in a further revision of the = Path-key ID.

Thanks.

JP.

thx,
-d.

the draft = mentions it may result into two documents (one in ccamp=A0 and the other in pce wg) = -> good idea because path key technique=A0 can be used independently of = the presence of a initial pcc-/pce-=A0= pce exchange
the latter would result in the = possibility to make use of pks with=A0= pd pc

=
Indeed.
Thanks.
JP.
=


=A0=A0 Networking Working = Group=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Rich Bradford (Ed)
=A0=A0 IETF Internet Draft=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 JP Vasseur
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Cisco Systems, Inc.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Adrian Farrel
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Old = Dog Consulting



=A0=A0 Proposed Status: = Standard
=A0=A0 Expires: December = 2006
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 June 2006


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = draft-bradford-pce-path-key-00.txt


=A0=A0 Preserving Topology = Confidentiality in Inter-Domain Path
=A0=A0 Computation and = Signaling

Status of this Memo

=A0=A0 By submitting this = Internet-Draft, each author represents that
=A0=A0 any applicable patent or = other IPR claims of which he or she is
=A0=A0 aware have been or will be = disclosed, and any of which he or she
=A0=A0 becomes aware will be = disclosed, in accordance with Section 6 of
=A0=A0 BCP 79.

=A0=A0 Internet-Drafts are = working documents of the Internet Engineering
=A0=A0 = Task Force (IETF), its areas, and its working groups. Note = that
=A0=A0 other groups may also = distribute working documents as Internet-
=A0=A0 Drafts.

=A0=A0 Internet-Drafts are draft = documents valid for a maximum of six
=A0=A0 months and may be updated, = replaced, or obsoleted by other
=A0=A0 documents at any = time.=A0 It is = inappropriate to use Internet-Drafts
=A0=A0 as reference material or = to cite them other than as "work in
=A0=A0 progress."

=A0=A0 The list of current = Internet-Drafts can be accessed at

=A0=A0 The list of Internet-Draft = Shadow Directories can be accessed at




































































=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 = |L|=A0 =A0 Type = =A0 =A0 | =A0 =A0 Length=A0 =A0 | =A0 =A0 =A0 =A0 =A0 Path Key=A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 IPv4 address (4 bytes) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0 =A0 =A0 = =A0 L

=A0=A0 =A0 =A0 = =A0 The L bit SHOULD NOT be set, so that the sub-object
=A0=A0 = represents a strict hop in the explicit route.

=A0=A0 =A0 =A0 =A0 Type

=A0=A0 =A0 =A0 =A0 TBD=A0 Path Key with IPv4 = address

=A0=A0 =A0 =A0 = =A0 Length

=A0=A0 =A0 =A0 = =A0 The Length contains the total length of the subobject = in
=A0=A0 = bytes, including the Type and Length fields.=A0 The Length is = always
=A0=A0 8.

=A0=A0 =A0 =A0 =A0 IPv4 = address

=A0=A0 =A0 =A0 = =A0 An IPv4 address of the PCE that can decode this key. = The
=A0=A0 address used SHOULD be an = address of the PCE that is always


Bradford, Vasseur, and Farrel=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 6


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 June 2006

=A0=A0 reachable, and MAY be an = address that is restricted to the domain
=A0=A0 in which the LSR that is = called upon to expand the CPS lies.

=A0=A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 2 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 3
=A0=A0 =A0 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 = |L|=A0 =A0 Type = =A0 =A0 | =A0 =A0 Length=A0 =A0 | =A0 =A0 =A0 =A0 =A0 Path Key=A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 IPv6 address (16 bytes)=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0 =A0 =A0 = L

=A0=A0 =A0 =A0 = =A0 =A0 As above.

=A0=A0 =A0 =A0 Type

=A0 =A0 =A0 =A0 =A0 TBD=A0 Path Key with IPv6 = address

=A0=A0 =A0 =A0 = Length

=A0 =A0 =A0 =A0 = =A0 The Length contains the total length of the subobject = in
=A0=A0 = bytes, including the Type and Length fields.=A0 The Length is = always
=A0=A0 20.

=A0=A0 =A0 =A0 IPv6 = address

=A0 =A0 =A0 =A0 = =A0 An IPv6 address of the PCE that can decode this key. = The
=A0=A0 address used SHOULD be an = address of the PCE that is always
=A0=A0 reachable, but MAY be an = address that is restricted to the domain
=A0=A0 in which the LSR that is = called upon to expand the CPS lies.


6.=A0 =A0 =A0 = Security Considerations

=A0=A0 This document proposes = tunneling secure topology information
=A0=A0 across an untrusted AS, so = the security considerations are many
=A0=A0 and apply to PCEP and = RSVP-TE.
=A0=A0 Issues include:
=A0 - = Security of the CPS (can other network elements probe for
=A0=A0 =A0 = expansion of path-keys, possibly at random?).
=A0 - = Authenticity of the path-key (resilience to alteration by
=A0=A0 =A0 = intermediaries, resilience to fake expansion of = path-keys).
=A0 - Resilience from DNS attacks = (insertion of spurious path-keys;
=A0=A0 =A0 flooding of bogus = path-key expansion requests).


Bradford, Vasseur, and Farrel=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 7


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 June 2006

7.=A0 =A0 =A0 Manageability = Considerations

=A0=A0 = TBD

8.=A0 =A0 =A0 = IANA considerations

=A0=A0 The IANA section will be = detailed in further revision of this
=A0=A0 document.

=A0=A0 For RSVP, it will include = code point requests for the three new
=A0=A0 ERO sub-objects, and a new = ErrorSpec Error Code.
=A0=A0 For PCEP, it will include = code point requests for the three new
=A0=A0 computed path = sub-objects.


9.=A0 =A0 =A0 Intellectual Property = Considerations

=A0=A0 = The IETF takes no position regarding the validity or scope of = any
=A0=A0 Intellectual Property = Rights or other rights that might be claimed
=A0=A0 = to pertain to the implementation or use of the = technology
=A0=A0 described in this document = or the extent to which any license
=A0=A0 under such rights might or = might not be available; nor does it
=A0=A0 represent that it has made = any independent effort to identify any
=A0=A0 such rights. Information = on the procedures with respect to rights
=A0=A0 in RFC documents can be = found in BCP 78 and BCP 79.

=A0=A0 Copies of IPR disclosures = made to the IETF Secretariat and any
=A0=A0 assurances of licenses to = be made available, or the result of an
=A0=A0 attempt made to obtain a = general license or permission for the use
=A0=A0 of such proprietary rights = by implementers or users of this
=A0=A0 specification can be = obtained from the IETF on-line IPR repository

=A0=A0 The IETF invites any = interested party to bring to its attention
=A0=A0 any copyrights, patents or = patent applications, or other
=A0=A0 proprietary rights that = may cover technology that may be required
=A0=A0 to implement this = standard. Please address the information to the
=A0=A0 = IETF at ietf-ipr@ietf.org.

10. = =A0 =A0 = References

10.1.=A0 = Normative References

=A0=A0 [RFC2119] Bradner, S., = "Key words for use in RFCs to Indicate
=A0=A0 Requirement Levels", BCP = 14, RFC 2119, March 1997.




Bradford, = Vasseur, and Farrel=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 8


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 June 2006

=A0=A0 [RFC3209] Awduche, D., = Berger, L., Gan, D., Li, T., Srinivasan, V.
=A0=A0 and G. Swallow, "RSVP-TE: = Extensions to RSVP for LSP Tunnels", RFC
=A0=A0 3209, December = 2001.

=A0=A0 = [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, = E.,
=A0=A0 Ikejiri, A., Atlas, A., = Dolganow, A., "Path Computation Element
=A0=A0 (PCE) communication = Protocol (PCEP)", draft-vasseur-pce-pcep,
=A0=A0 work in = progress.

10.2.=A0 = Informational References

=A0=A0 [PCE-ARCH] Farrel, A., = Vasseur, J.P., Ash, J., "Path Computation
=A0=A0 Element (PCE) = Architecture", draft-ietf-pce-architecture, work in
=A0=A0 = progress.

=A0=A0 = [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path = computation
=A0=A0 method for establishing = Inter-domain Traffic=A0 = Engineering (TE)
=A0=A0 Label
=A0=A0 = Switched Paths (LSPs)", = draft-ietf-ccamp-inter-domain-pd-path-
=A0=A0 comp, work in = progress.

=A0=A0 = [BRPC] Vasseur, J., et al "A Backward Recursive = PCE-based
=A0=A0 Computation
=A0=A0 = (BRPC) procedure to compute shortest inter-domain = Traffic
=A0=A0 Engineering Label Switched = Path", draft-vasseur-pce-brpc, work in
=A0=A0 progress.

=A0=A0 [RFC4105]=A0 =A0 Le Roux, J., Vasseur, JP, = Boyle, J., "Requirements
=A0=A0 for Support of Inter-Area = and Inter-AS MPLS Traffic Engineering",
=A0=A0 RFC 4105, June = 2005.

=A0=A0 = [RFC4216]=A0 =A0 = Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS
=A0=A0 = Traffic Engineering requirements", RFC 4216, November = 2005.



11.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Authors' Addresses:

=A0=A0 Rich Bradford = (Editor)
=A0=A0 Cisco Systems, = Inc.
=A0=A0 1414 Massachusetts = Avenue
=A0=A0 Boxborough , MA - = 01719
=A0=A0 USA
=A0=A0 = Email: rbradfor@cisco.com

=A0=A0 J.-P Vasseur
=A0=A0 = Cisco Systems, Inc.
=A0=A0 1414 Massachusetts = Avenue
=A0=A0 Boxborough , MA - = 01719

Bradford, Vasseur, and Farrel=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 9


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 June 2006

=A0=A0 USA
=A0=A0 = Email: jpv@cisco.com

=A0=A0 Adrian Farrel
=A0=A0 = Old Dog Consulting
=A0=A0 EMail:=A0 adrian@olddog.co.uk













=A0=A0 Full Copyright = Statement

=A0=A0 = Copyright (C) The Internet Society (2006).

=A0 =A0 This document is subject = to the rights, licenses and restrictions
=A0 =A0 contained in BCP 78, and = except as set forth therein, the authors
=A0 =A0 retain all their = rights.

=A0=A0 = This document and the information contained herein are = provided
=A0=A0 on an "AS IS" basis and = THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
=A0=A0 REPRESENTS OR IS SPONSORED = BY (IF ANY), THE INTERNET SOCIETY AND
=A0=A0 THE INTERNET ENGINEERING = TASK FORCE DISCLAIM ALL WARRANTIES,
=A0=A0 EXPRESS OR IMPLIED, = INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
=A0=A0 = THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS = OR
=A0=A0 = ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR = A
=A0=A0 = PARTICULAR PURPOSE.















=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 10

=0C= _______________________________________________
Pce mailing list
.
=

= --Apple-Mail-80-630525530-- --===============0926211463== 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 --===============0926211463==-- From pce-bounces@lists.ietf.org Mon Jul 17 09:25:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2T5s-0004qL-Qm; Mon, 17 Jul 2006 09:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2T5r-0004lH-HS for pce@ietf.org; Mon, 17 Jul 2006 09:25:03 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2T5p-0006o5-6e for pce@ietf.org; Mon, 17 Jul 2006 09:25:03 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Jul 2006 06:25:00 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,250,1149490800"; d="scan'208"; a="32400590:sNHT24549876" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HDP0DE007971; Mon, 17 Jul 2006 09:25:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6HDOudW020341; Mon, 17 Jul 2006 09:24:57 -0400 (EDT) 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.1830); Mon, 17 Jul 2006 09:24:56 -0400 Received: from [10.86.104.180] ([10.86.104.180]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 09:24:56 -0400 In-Reply-To: <005d01c6a760$a30e9a20$851fdb84@your029b8cecfe> References: <005d01c6a760$a30e9a20$851fdb84@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C8449F0-5B52-4548-A245-66006F476067@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] P & I flags Date: Mon, 17 Jul 2006 09:24:54 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Jul 2006 13:24:56.0919 (UTC) FILETIME=[657EFE70:01C6A9A4] DKIM-Signature: a=rsa-sha1; q=dns; l=1219; t=1153142700; x=1154006700; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20[Pce]=20P=20&=20I=20flags |To:Adrian=20Farrel=20; X=v=3Dcisco.com=3B=20h=3DZ880FKewNqDt/KW/PckhzFJYHdg=3D; b=uSbYA33TJZyNjn2qiT0ARE33Ru+BfobEeTjfmtigUAFdBM7sTfoxFfhNDgjXvSlGRvTGL6h5 PvQ/MzvjxUgZ0DVy5mt0TvstKsEaDfoGYriaerMAVQMiy4lWAwevTfgy; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Jul 14, 2006, at 12:14 PM, Adrian Farrel wrote: >>> o) on the I flag issue is identical why include an object >>> which has not considered during computation ? >> >> I don't catch your point, the PCC may want to know the >> constraints that were not taken into account during path >> computation, this sounds quite important isn'it? >> >>> there are so >>> many things that the PCE has not taken into account during >>> computation so why bother ? >> >> Hum I don't follow you here "there are so many things...", >> What do you mean? > > I think the disconnect is that the I flag is only used in > constraints *returned* to the PCC. I.e. in constraints that formed > part of the original request, but were ignored. There is no > requirement (or desire?) for the PCE to randomly report other > things it did not take into account (such as weather, shoe-size of > operator, etc.) Correct (since if the PCE does not support or decided to ignore a mandatory object), it would send a PCErr message. Thanks. JP. > > Adrian > > > > _______________________________________________ > 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 Jul 17 10:36:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2UCy-0006i8-Dm; Mon, 17 Jul 2006 10:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2UCx-0006i3-7M for pce@ietf.org; Mon, 17 Jul 2006 10:36:27 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2UCu-0002EA-FU for pce@ietf.org; Mon, 17 Jul 2006 10:36:27 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 17 Jul 2006 07:36:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HEaNkX030885; Mon, 17 Jul 2006 07:36:23 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6HEaMJi012616; Mon, 17 Jul 2006 07:36:23 -0700 (PDT) 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.1830); Mon, 17 Jul 2006 10:36:07 -0400 Received: from [10.86.104.180] ([10.86.104.180]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 10:36:06 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] P & I flags Date: Mon, 17 Jul 2006 10:36:05 -0400 To: LE ROUX Jean-Louis RD-CORE-LAN X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Jul 2006 14:36:06.0895 (UTC) FILETIME=[56999FF0:01C6A9AE] DKIM-Signature: a=rsa-sha1; q=dns; l=10632; t=1153146983; x=1154010983; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20[Pce]=20P=20&=20I=20flags; X=v=3Dcisco.com=3B=20h=3DmChWld8qMZWisUgO7/iNX+5HLMk=3D; b=XuRhbhr99OKOAYjj+n5KpGv9zyMyL48DQ7avPOz7UUkVUeXvK584G/CNrN8M5O7eI1ZAUH/q SxmWRwtodHNMP+hPL9FHOjdWQJRFuTXFw8n/Mmpvy3L5NYaltQqOd1Wn; Authentication-Results: sj-dkim-3.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad 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 Igor and JL, Comments in line, On Jul 16, 2006, at 6:28 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Igor, > >> -----Message d'origine----- >> De : Igor Bryskin [mailto:ibryskin@movaz.com] >> Envoy=E9 : dimanche 16 juillet 2006 23:50 >> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; dpapadimitriou@psg.com; >> dimitri.papadimitriou@alcatel.be; pce@ietf.org >> Objet : Re: [Pce] P & I flags >> >> Hi JL. >> >> Please, see in line. >> >> Igor >> >> ----- Original Message ----- >> From: "LE ROUX Jean-Louis RD-CORE-LAN" >> >> To: "Igor Bryskin" ; >> ; ; >> >> Sent: Sunday, July 16, 2006 3:56 PM >> Subject: RE: [Pce] P & I flags >> >> >> Hi Igor, >> >> See inline, >> >> >> >>> -----Message d'origine----- >>> De : Igor Bryskin [mailto:ibryskin@movaz.com] >>> Envoy=E9 : samedi 15 juillet 2006 15:51 >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; dpapadimitriou@psg.com; >>> dimitri.papadimitriou@alcatel.be; pce@ietf.org >>> Objet : Re: [Pce] P & I flags >>> >>> Hi JL, >>> >>> I have a question. Suppose, a path computation request has >>> two constraints: >>> link colors and link bandwidth. Suppose the path computation >>> fails. The question is how the PCE can figure out what is the >>> reason of this computation failure? >>> As an implementer of a >>> Path Computation Engine I always found it a difficult >>> problem. Normally, presented with a path computation request >>> with link type constraints as in the example I am describing, >>> a PCE would prune out the arcs form the network graph >>> associated with links that do not satisfy at least one of the >>> constraints, and after that run some algorithm. If the >>> algorithm fails the only thing is clear that there are no >>> links with proper colors that have enough bandwidth, that is, >>> entire set of constraints cannot be satisfied. But it is >>> impossible to say which constraint in particular has caused >>> the failure. Even if you start removing constraints one by >>> one and rerunning the algorithm (which would be very >>> unpractical to do), you will find out that it does not help. >>> The path computation of the example may succeed in both these >>> iterations because: >>> a) there are links with proper colors; >>> b) there are links with enough bandwidth. >>> >>> The bottom line is that path computation fails because of the >>> entire set of constraints rather than because of one or >>> several of them, and it is unrealistic to think that PCE in >>> its negative reply would mark constraints which cause the failure. >> >> I don't think this is unrealistic, there are cases in your >> example where >> the bandwidth alone as a single constraint cannot be fit >> while color as a >> single constraint can be fit (and vice versa). In this case >> this makes sense >> IMO to send a negative reply indicating that the bandwidth >> cannot be fit. >> Anyway in the case you mention the PCE can send a negative >> reply indicating >> bandwidth and color as unsatisifed constraints, and may even >> suggest values >> that could be satisfied >> (shall we consider that a PCE may be a bit more clever??) >> >> IB>> This is the whole my point. If there is a set of >> mandatory constraints, >> there is no way for a PCE to tell because of which particular >> constraint(s) >> the computation has failed, > > Why, if it is clever enough to detect a blocking constraint? > I agree with JL here. There *are* many ways to figure out which =20 constraints could not be satisfied, in which case indicating this =20 information to the PCC is quite useful. > > >> let alone recommend other values for the >> constraints to make the computation successful. I'd like to >> hear from PCE >> developers whether they share my view. > > Ah, OK let discuss with PCE developpers! > > I don't share your view... Thanks. JP. > > Best Regards, > > JL > >> >> The only reasons to mark the constraints in the PC reply IMO are: >> >> a) for a mandatory constraint either when it was not >> recognized or could not >> be otherwise supported (e.g. an unknown color was specified) >> b) for an optional constraint when it was removed according >> to a signaled or >> policed constraint relaxation strategy which made the computation >> successful. >> >> Regards, >> Igor >> >> >>> >>> So, I recommend to have two flags (say, P and I). One of them >>> should be used to mark mandatory constraints, while another - >>> optional constraints. >> >> As already commented to Dimitri, this is related to >> constraint relaxation >> and is completely beyond the scope of this document as agreed >> one year ago >> on this list. There are various solutions for constraints >> relaxation that >> need to be discussed. By the way it could work as is by sending two >> requests, one with mandatory constraints and the other with >> all (mandatory + >> optional) constraints... >> >> >>> Recommend to make an assumption that PCE will run path >>> computation at most two times: >> >> We will never make such recommendation, this is definitely a local >> implementation issue. >> >> Regards, >> >> JL >> >>> >>> 1) trying to accommodate all constraints; >>> 2) in case 1) fails, removing all optional constraints >>> >>> PCE should return: >>> >>> a) successful response without flags when 1) succeeds; >>> b) successful response with flag I when 2) succeeds; >>> 3) negative response with no flags when 2 fails. >>> >>> Igor >>> >>> >>> >>> ----- Original Message ----- >>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>> >>> To: ; ; >>> >>> Sent: Friday, July 14, 2006 10:46 AM >>> Subject: RE: [Pce] P & I flags >>> >>> >>> Hi Dimitri, >>> >>>> -----Message d'origine----- >>>> De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>> Envoy=E9 : vendredi 14 juillet 2006 15:44 >>>> =C0 : pce@ietf.org >>>> Objet : [Pce] P & I flags >>>> >>>> the comments around the P and I flags are >>>> >>>> o) we have two levels of optionality in listing the protocol >>>> object and usage level of the protocol object - however it is >>>> much more appropriate to be sure that mandatory constraints >>>> have been taken rather than having the optional having been >>>> taken into account >>> >>> As clearly pointed out in the same setion of the draft, if >> a mandatory >>> constraint cannot be handled the PCE replies with PCErr message >>> >>> "If the PCE does not understand an object with the P Flag set or >>> understands the object but decides to ignore the object, >> the entire >>> PCEP message MUST be rejected and the PCE MUST send a >> PCErr message >>> with Error-Type=3D"Unknown Object" or "Not supported Object". >>> >>> If the PCE can handle all mandatory constraints it replies >>> with a PCRep >>> message (either positive or negative if there is no path), >>> else it sends a >>> PCErr message. >>> Hence the PCC knows whether mandatory constraints have been >> taken into >>> account. >>> >>> >>> >>>> >>>> P flag (Processing-Rule - 1-bit): the P flag allows a PCC >>>> to specify >>>> in a PCReq message sent to a PCE whether the object >>> must be taken >>>> into account by the PCE during path computation or is >>>> just optional. >>>> When the P flag is set, the object MUST be taken into >>>> account by the >>>> PCE. Conversely, when the P flag is cleared, the object >>>> is optional >>>> and the PCE is free to ignore it if not supported. >>>> >>>> o) on the I flag issue is identical why include an object >>>> which has not considered during computation ? >>> >>> I don't catch your point, the PCC may want to know the >>> constraints that were >>> not taken into account during path computation, this sounds >>> quite important >>> isn'it? >>> >>> >>> there are so >>>> many things that the PCE has not taken into account during >>>> computation so why bother ? >>> >>> Hum I don't follow you here "there are so many things...", >>> What do you mean? >>> >>> >>>> it is imho >>>> more important to include the mandatory object not taken >>>> into account >>> >>> If a mandatory object is not taken into account, you cannot >>> compute the path >>> and you send an error message. I agree with you that this >>> would be useful to >>> include within the PCErr the set of objects not supported, >> this can be >>> clarified in next revision. >>> >>> >>>> >>>> I flag (Ignore - 1 bit): the I flag is used by a PCE >> in a PCRep >>>> message to indicate to a PCC whether or not an optional >>> object was >>>> processed. The PCE MAY include the ignored optional >>> object in its >>>> reply and set the I flag to indicate that the optional >>> object was >>>> ignored during path computation. When the I flag is >>>> cleared, the PCE >>>> indicates that the optional object was processed >> during the path >>>> computation. The setting of the I flag for optional >> objects is >>>> purely indicative and optional. The I flag MUST be >>>> cleared if the P >>>> flag is set. >>>> >>>> o) the result of all these flags is that a PCC can be >>>> wrapping around unknown constraints create processing churn >>>> on the PCE; >>> >>> OK, if you mean that we should include the unsupported >>> object(s) within the >>> PCErr, then we are in sync >>> >>> Thanks for the comment >>> >>> Regards >>> >>> JL >>> >>>> >>>> If the PCE does not understand an object with the P >> Flag set or >>>> understands the object but decides to ignore the object, >>>> the entire >>>> PCEP message MUST be rejected and the PCE MUST send a >>>> PCErr message >>>> with Error-Type=3D"Unknown Object" or "Not supported Object". >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Jul 17 10:45:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2UM2-0006Q2-Fp; Mon, 17 Jul 2006 10:45:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2UM1-0006Pd-2e for pce@ietf.org; Mon, 17 Jul 2006 10:45:49 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2UM0-0002fB-9l for pce@ietf.org; Mon, 17 Jul 2006 10:45:49 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 17 Jul 2006 07:45:48 -0700 X-IronPort-AV: i="4.06,251,1149490800"; d="scan'208"; a="306186762:sNHT84161760" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HEjlpP014196; Mon, 17 Jul 2006 07:45:47 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6HEjkHS007149; Mon, 17 Jul 2006 07:45:46 -0700 (PDT) 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.1830); Mon, 17 Jul 2006 10:45:46 -0400 Received: from [10.86.104.180] ([10.86.104.180]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 10:45:45 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <071D2A01-0FCE-4A4F-AF8D-471E30FF8243@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] P & I flags Date: Mon, 17 Jul 2006 10:45:43 -0400 To: LE ROUX Jean-Louis RD-CORE-LAN , dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Jul 2006 14:45:45.0376 (UTC) FILETIME=[AF66D200:01C6A9AF] DKIM-Signature: a=rsa-sha1; q=dns; l=14029; t=1153147547; x=1154011547; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20[Pce]=20P=20&=20I=20flags; X=v=3Dcisco.com=3B=20h=3DmChWld8qMZWisUgO7/iNX+5HLMk=3D; b=cVpsy+xHc+9d5BW0o0vRnTlrOuC5mwT/7sxggKnFY0H9KPU0Sooera6YnKvTKdYJaBnpFCC2 uDxQEJf4NmJr8Ppq94B1Tp9mbKCPYnuYJzW1Q+VMuXQO80MceF7Rkqxi; Authentication-Results: sj-dkim-8.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab 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, So I think that we're now all in sync wrt to the P & I bits semantic. * The P flag is used by a PCC to indicate to the PCE that a =20 constraint X MUST NOT be ignored. Consequently, if the PCE does not =20 support/understand such constraint X, it MUST send a PCErr (as =20 clearly stated in the document). * The I flag is used by the PCE to indicate to the PCC whether a =20 constraint Y marked as optional in the request has been taken into =20 account, which can be very useful in several cases. Now, the issue discussed in this thread was related to constraint =20 relaxation, which is an important topic and I've personally been =20 supporting such feature for a while but there was no consensus on the =20= list on this topic (see the archives), thus, as pointed out by JL, =20 this was left out of the main PCEP spec. Of course, feel free to =20 continue some discussion on the list on this topic. Thanks. JP. On Jul 16, 2006, at 7:27 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri, > >> -----Message d'origine----- >> De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> Envoy=E9 : lundi 17 juillet 2006 00:04 >> =C0 : LE ROUX Jean-Louis RD-CORE-LAN >> Cc : dimitri.papadimitriou@alcatel.be; Igor Bryskin; pce@ietf.org >> Objet : Re: [Pce] P & I flags >> >> hi j-l >> >> LE ROUX Jean-Louis RD-CORE-LAN wrote: >> >>> Hi Dimitri, >>> >>> >>>> -----Message d'origine----- De : dimitri papadimitriou >>>> [mailto:dpapadimitriou@psg.com] Envoy=E9 : dimanche 16 juillet 2006 >>>> 18:25 =C0 : Igor Bryskin Cc : LE ROUX Jean-Louis RD-CORE-LAN; >>>> dimitri.papadimitriou@alcatel.be; pce@ietf.org Objet : Re: >> [Pce] P & >>>> I flags >>>> >>>> igor, j-l >>>> >>>> to indicate optional/non-optional you need one flag like i >> indicate >>>> in my reply to j-l - let's say the P flag >>> >>> >>> NO, why do you want to change the semantic if the P flag? this >>> semantic is required... >> >> call it I flag if you want the point is that the Error should >> be generated once an object (from its class or type) is not =20 >> recognized > > Humm no, I flag is already used! > Call it O flag if you like > > >> >> if you have that a too high rejection rate could result from >> optional constraints such behaviour should be inferred by no >> further looking into the object >> >>>> in the reply - where you have a third level of indirection >> since you >>>> can send a positive or a negative answer you can have one of the >>>> following >>>> >>>> a) positive response with both optional and non-optional >> b) positive >>>> response with non-optional only c) negative response >>>> >>>> however, as far as my reading goes, ALL non-optional >> constraints MUST >>>> be taken into account while SOME of the optional >> constraints MAY be >>>> taken into account >>> >>> No, all recognized and supported constraints MUST be taken into >>> account during path computation, whatever the P flag value. >> The P flag >>> simply indicates what to do when a constraint is not >>> recognized/unsupported. >> >> again call it I flag, point remains, a negative answer shall >> come only from not finding a result from mandatory constraints > > Dimitri, please see my previous answer. I understand the semantic =20 > you define, it was discussed one year ago as part of a constraint =20 > relaxation thread (less constrained path), and the result of this =20 > thread was that there there was no consensus, some people were =20 > against, hence we removed the requirement from the generic PCECP =20 > req id, and also we removed text on less constrained path from the =20 > PCEP spec, and decided to address it latter. > This should be defined in a separate ID once the requirement is =20 > clearly expressed. > > By the way there are various options for handling optional =20 > constraints and more generally constraint relaxation. For instance =20 > the PCC may also send two requests, one with only mandatory =20 > constraints and another with optional constraints... > >> >> and a positive result may include more than the set of >> mandatory constraints > > Ah, this is interesting...and what sub-set of optional constraints =20 > is selected if not all optional constaints can be satisfied? Again =20 > we are discussing constraint relaxation here and this is beyond the =20= > scope of this doc... > >> >> the fact that an error is issued should then be the result of >> the non-support of a mandatory constraint > > Yes, indeed this is current P flag processing > > >> >> all together this makes one flag - and this only because >> there is a difference between optional object support and >> optional processing >> >>>> hence one could consider that list in the reply corresponds to the >>>> list of considered constraints and since the requestor knows these >>>> are optional or not there is no need for a second flag - this >>>> prevents back tracking of optional information - and restrict >>>> confirmation to the mandatory constraints >>>> >>>> ps: are you serious when considering a message length of 2^32 ? >>> >>> Yes, 2^16 may not be enought, think about an NMS that would send a >>> request for tens of thousands of LSPs. >> >> what does make the NMS PCC different from an LSR ? > > Please keep it simple, you were asking why do we need 2^32, and > I answered that 2^16 may not be enough, and I took, as pure =20 > illustration, the example of an NMS acting as PCC, and sending a =20 > PCReq for a synchronized path computation of tens of K LSPs, ie a =20 > PCReq with tens of K requests (I simply took the example of NMS =20 > PCC, as an NMS is likely to request synchronized path computation =20 > of many more LSPs, than an LSR would do). > >> i think >> there is a difference between the set of command issued to >> the NMS and the resulting set of PCC requests an NMS will generate > > Who says the contrary? And what is the point here? > > Thanks, > > JL > > >> >> thanks, >> - dimitri. >> >>> Thanks, >>> >>> JL >>> >>> >>>> thanks, - dimitri. >>>> >>>> >>>> >>>> >>>> Igor Bryskin wrote: >>>> >>>>> Hi JL, >>>>> >>>>> I have a question. Suppose, a path computation request has >>>> >>>> two constraints: >>>> >>>>> link colors and link bandwidth. Suppose the path >> computation fails. >>>>> The question is how the PCE can figure out what is the >>>> >>>> reason of this >>>> >>>>> computation failure? As an implementer of a Path >>>> >>>> Computation Engine I >>>> >>>>> always found it a difficult problem. Normally, presented >>>> >>>> with a path >>>> >>>>> computation request with link type constraints as in the >>>> >>>> example I am >>>> >>>>> describing, a PCE would prune out the arcs form the >> network graph >>>>> associated with links that do not satisfy at least one of the >>>>> constraints, and after that run some algorithm. If the >>>> >>>> algorithm fails >>>> >>>>> the only thing is clear that there are no links with >> proper colors >>>>> that have enough bandwidth, that is, entire set of >>>> >>>> constraints cannot >>>> >>>>> be satisfied. But it is impossible to say which constraint in >>>>> particular has caused the failure. Even if you start removing >>>>> constraints one by one and rerunning the algorithm (which >> would be >>>>> very unpractical to do), you will find out that it does not >>>> >>>> help. The path computation of the example may succeed in >> both these >>>> iterations because: >>>> >>>>> a) there are links with proper colors; b) there are links with >>>>> enough bandwidth. >>>>> >>>>> The bottom line is that path computation fails because of >>>> >>>> the entire >>>> >>>>> set of constraints rather than because of one or several of >>>> >>>> them, and >>>> >>>>> it is unrealistic to think that PCE in its negative reply >>>> >>>> would mark >>>> >>>>> constraints which cause the failure. >>>>> >>>>> So, I recommend to have two flags (say, P and I). One of >>>> >>>> them should >>>> >>>>> be used to mark mandatory constraints, while another - >>>> >>>> optional constraints. >>>> >>>>> Recommend to make an assumption that PCE will run path >>>> >>>> computation at >>>> >>>>> most two times: >>>>> >>>>> 1) trying to accommodate all constraints; 2) in case 1) fails, >>>>> removing all optional constraints >>>>> >>>>> PCE should return: >>>>> >>>>> a) successful response without flags when 1) succeeds; b) >>>>> successful response with flag I when 2) succeeds; 3) negative >>>>> response with no flags when 2 fails. >>>>> >>>>> Igor >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- From: "LE ROUX Jean-Louis >> RD-CORE-LAN" >>>>> To: >>>>> ; ; >>>>> Sent: Friday, July 14, 2006 10:46 AM Subject: RE: >>>>> [Pce] P & I flags >>>>> >>>>> >>>>> Hi Dimitri, >>>>> >>>>> >>>>> >>>>>> -----Message d'origine----- De : dimitri papadimitriou >>>>>> [mailto:dpapadimitriou@psg.com] Envoy=E9 : vendredi 14 juillet >>>>>> 2006 15:44 =C0 : pce@ietf.org Objet : [Pce] P & I flags >>>>>> >>>>>> the comments around the P and I flags are >>>>>> >>>>>> o) we have two levels of optionality in listing the >> protocol object >>>>>> and usage level of the protocol object - however it is much more >>>>>> appropriate to be sure that mandatory constraints have >> been taken >>>>>> rather than having the optional having been taken into account >>>>> >>>>> >>>>> As clearly pointed out in the same setion of the draft, if >>>> >>>> a mandatory >>>> >>>>> constraint cannot be handled the PCE replies with PCErr message >>>>> >>>>> "If the PCE does not understand an object with the P Flag set or >>>>> understands the object but decides to ignore the object, >>>> >>>> the entire >>>> >>>>> PCEP message MUST be rejected and the PCE MUST send a >>>> >>>> PCErr message >>>> >>>>> with Error-Type=3D"Unknown Object" or "Not supported Object". >>>>> >>>>> If the PCE can handle all mandatory constraints it >> replies with a >>>>> PCRep message (either positive or negative if there is no >>>> >>>> path), else >>>> >>>>> it sends a PCErr message. Hence the PCC knows whether mandatory >>>>> constraints have been >>>> >>>> taken into >>>> >>>>> account. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> P flag (Processing-Rule - 1-bit): the P flag allows a PCC to >>>>>> specify in a PCReq message sent to a PCE whether the object >>>> >>>> must be taken >>>> >>>>>> into account by the PCE during path computation or is just >>>>>> optional. When the P flag is set, the object MUST be taken into >>>>>> >>>> >>>> account by >>>> >>>>>> the PCE. Conversely, when the P flag is cleared, the object is >>>>>> optional and the PCE is free to ignore it if not supported. >>>>>> >>>>>> o) on the I flag issue is identical why include an >> object which has >>>>>> not considered during computation ? >>>>> >>>>> >>>>> I don't catch your point, the PCC may want to know the >> constraints >>>>> that were not taken into account during path computation, >>>> >>>> this sounds >>>> >>>>> quite important isn'it? >>>>> >>>>> >>>>> there are so >>>>> >>>>> >>>>>> many things that the PCE has not taken into account during >>>> >>>> computation >>>> >>>>>> so why bother ? >>>>> >>>>> >>>>> Hum I don't follow you here "there are so many things...", >>>> >>>> What do you mean? >>>> >>>>> >>>>> >>>>>> it is imho more important to include the mandatory >> object not taken >>>>>> into account >>>>> >>>>> >>>>> If a mandatory object is not taken into account, you >> cannot compute >>>>> the path and you send an error message. I agree with you >> that this >>>>> would be useful to include within the PCErr the set of >> objects not >>>>> supported, this can be clarified in next revision. >>>>> >>>>> >>>>> >>>>> >>>>>> I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep >>>>>> message to indicate to a PCC whether or not an optional >>>> >>>> object was >>>> >>>>>> processed. The PCE MAY include the ignored optional >>>> >>>> object in its >>>> >>>>>> reply and set the I flag to indicate that the optional >>>> >>>> object was >>>> >>>>>> ignored during path computation. When the I flag is >>>> >>>> cleared, the >>>> >>>>>> PCE indicates that the optional object was processed during the >>>>>> path computation. The setting of the I flag for >> optional objects >>>>>> is purely indicative and optional. The I flag MUST be >>>>>> >>>> >>>> cleared if the >>>> >>>>>> P flag is set. >>>>>> >>>>>> o) the result of all these flags is that a PCC can be >>>> >>>> wrapping around >>>> >>>>>> unknown constraints create processing churn on the PCE; >>>>> >>>>> >>>>> OK, if you mean that we should include the unsupported object(s) >>>>> within the PCErr, then we are in sync >>>>> >>>>> Thanks for the comment >>>>> >>>>> Regards >>>>> >>>>> JL >>>>> >>>>> >>>>> >>>>>> If the PCE does not understand an object with the P Flag set or >>>>>> understands the object but decides to ignore the object, >> the entire >>>>>> PCEP message MUST be rejected and the PCE MUST send a >> PCErr message >>>>>> with Error-Type=3D"Unknown Object" or "Not supported Object". >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ 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 Mon Jul 17 12:03:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VZU-0006Ii-DX; Mon, 17 Jul 2006 12:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VZS-0006IN-S6 for pce@ietf.org; Mon, 17 Jul 2006 12:03:46 -0400 Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2VZR-0002qw-FW for pce@ietf.org; Mon, 17 Jul 2006 12:03:46 -0400 Received: from ib (unknown [172.16.24.125]) by jera.movaz.com (Postfix) with SMTP id 4899ECF1; Mon, 17 Jul 2006 12:03:37 -0400 (EDT) Message-ID: <043201c6a9ba$8f8ab040$6501a8c0@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" , "LE ROUX Jean-Louis RD-CORE-LAN" References: Subject: Re: [Pce] P & I flags Date: Mon, 17 Jul 2006 12:03:36 -0400 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: 798b2e660f1819ae38035ac1d8d5e3ab 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 JP. >> IB>> This is the whole my point. If there is a set of >> mandatory constraints, >> there is no way for a PCE to tell because of which particular >> constraint(s) >> the computation has failed, > > Why, if it is clever enough to detect a blocking constraint? > I agree with JL here. There *are* many ways to figure out which constraints could not be satisfied, in which case indicating this information to the PCC is quite useful. IB>> I am just curious. Could you (or anybody) describe just one of the ways how PCE can figure out which of mandatory constraints caused the path computation to fail? Thanks, Igor _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 19 10:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DA3-0004gx-Hu; Wed, 19 Jul 2006 10:36:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DA2-0004gs-9G for pce@ietf.org; Wed, 19 Jul 2006 10:36:26 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3DA0-00078Q-Su for pce@ietf.org; Wed, 19 Jul 2006 10:36:26 -0400 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 1G3DAF-00052F-00 for pce@ietf.org; Wed, 19 Jul 2006 15:36:39 +0100 Received: from your029b8cecfe ([217.158.132.68] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 15:36:20 +0100 Message-ID: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 19 Jul 2006 15:08:22 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 19 Jul 2006 14:36:22.0108 (UTC) FILETIME=[B47E71C0:01C6AB40] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Pce] Poll on three new working group I-Ds 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 Hi, Resulting from the discussions in Montreal, we would like to take your opinions on the adoption of three I-Ds as working group drafts. draft-bitar-zhang-interas-pcecp-reqs-01.txt This draft sets out the requirements for PCEP in an inter-AS scenario. It has been refined considerably over the last couple of iterations and is now limited to just the requirements for this situation. We may need to do more work on it as a WG document, but the authors and chairs believe it is in good enough shape to be the basis of the WG work. draft-bryskin-pce-policy-enabled-path-comp-02.txt Policy forms part of the PCE architecture, and this document fleshes out the details of the use of policy in a PCE context. There was some discussion in Montreal about whether to wait to include details of policy for recovery path computation, but the chairs feel that this scenarion (and any other relevant scenarios) can be safely added once the I-D is a working group draft. Further, there was support from the service providers in the room in Montreal for adopting this I-D. draft-vasseur-pce-brpc-00.txt This draft describes an application procedure for PCE in the inter-domain case. There has been some discussion of this draft on the mailing list resulting in the request for a few clarifications of scope and procedure, and also an explicit mention of the Path Key ID option. Since JP is the lead author on this work, I think that the correct procedure is for JP to make a quick update before this becomes a WG I-D, but while we are polling I would like to ask your opinion on this I-D assuming that JP makes the necessary changes. Simple Yes and No answers will do, but reasons are always helpful. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 19 10:43:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DGn-0005Z4-3p; Wed, 19 Jul 2006 10:43:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DGm-0005Yw-7N for pce@ietf.org; Wed, 19 Jul 2006 10:43:24 -0400 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3DGf-0007ax-QV for pce@ietf.org; Wed, 19 Jul 2006 10:43:24 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 16:41:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Poll on three new working group I-Ds Date: Wed, 19 Jul 2006 16:41:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Poll on three new working group I-Ds Thread-Index: AcarQL2kxcj2AUxoRZ2PDCOdkRZFaAAAEcmQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 19 Jul 2006 14:41:23.0830 (UTC) FILETIME=[68559160:01C6AB41] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Adrian, Yes for these three IDs. Regards, JL > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Envoy=E9 : mercredi 19 juillet 2006 16:08 > =C0 : pce@ietf.org > Objet : [Pce] Poll on three new working group I-Ds >=20 > Hi, >=20 > Resulting from the discussions in Montreal, we would like to=20 > take your opinions on the adoption of three I-Ds as working=20 > group drafts. >=20 > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS=20 > scenario. It has been refined considerably over the last=20 > couple of iterations and is now limited to just the=20 > requirements for this situation. We may need to do more work=20 > on it as a WG document, but the authors and chairs believe it=20 > is in good enough shape to be the basis of the WG work. >=20 > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document=20 > fleshes out the details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait=20 > to include details of policy for recovery path computation,=20 > but the chairs feel that this scenarion (and any other=20 > relevant scenarios) can be safely added once the I-D is a=20 > working group draft. Further, there was support from the=20 > service providers in the room in Montreal for adopting this I-D. >=20 > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the=20 > inter-domain case. > There has been some discussion of this draft on the mailing=20 > list resulting in the request for a few clarifications of=20 > scope and procedure, and also an explicit mention of the Path=20 > Key ID option. > Since JP is the lead author on this work, I think that the=20 > correct procedure is for JP to make a quick update before=20 > this becomes a WG I-D, but while we are polling I would like=20 > to ask your opinion on this I-D assuming that JP makes the=20 > necessary changes. >=20 > Simple Yes and No answers will do, but reasons are always helpful. >=20 > Cheers, > Adrian >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 19 15:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HSM-0002Zs-OR; Wed, 19 Jul 2006 15:11:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HSL-0002WI-RE for pce@ietf.org; Wed, 19 Jul 2006 15:11:37 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3HSJ-0003SK-Iq for pce@ietf.org; Wed, 19 Jul 2006 15:11:37 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-121.messagelabs.com!1153336266!9670006!9 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2623 invoked from network); 19 Jul 2006 19:11:34 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-2.tower-121.messagelabs.com with SMTP; 19 Jul 2006 19:11:34 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452002D008B; Wed, 19 Jul 2006 15:11:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Poll on three new working group I-Ds Date: Wed, 19 Jul 2006 14:11:34 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B2A@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Poll on three new working group I-Ds Thread-Index: AcarQMGNlzCn72BRQ1GR3hUIVcy94AAJkb+w From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Yes to all 3. Thanks, Jerry=20 -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Wednesday, July 19, 2006 10:08 AM To: pce@ietf.org Subject: [Pce] Poll on three new working group I-Ds Hi, Resulting from the discussions in Montreal, we would like to take your=20 opinions on the adoption of three I-Ds as working group drafts. draft-bitar-zhang-interas-pcecp-reqs-01.txt This draft sets out the requirements for PCEP in an inter-AS scenario. It=20 has been refined considerably over the last couple of iterations and is now=20 limited to just the requirements for this situation. We may need to do more=20 work on it as a WG document, but the authors and chairs believe it is in good enough shape to be the basis of the WG work. draft-bryskin-pce-policy-enabled-path-comp-02.txt Policy forms part of the PCE architecture, and this document fleshes out the=20 details of the use of policy in a PCE context. There was some discussion in Montreal about whether to wait to include=20 details of policy for recovery path computation, but the chairs feel that=20 this scenarion (and any other relevant scenarios) can be safely added once=20 the I-D is a working group draft. Further, there was support from the=20 service providers in the room in Montreal for adopting this I-D. draft-vasseur-pce-brpc-00.txt This draft describes an application procedure for PCE in the inter-domain=20 case. There has been some discussion of this draft on the mailing list resulting=20 in the request for a few clarifications of scope and procedure, and also an=20 explicit mention of the Path Key ID option. Since JP is the lead author on this work, I think that the correct procedure=20 is for JP to make a quick update before this becomes a WG I-D, but while we=20 are polling I would like to ask your opinion on this I-D assuming that JP=20 makes the necessary changes. Simple Yes and No answers will do, but reasons are always helpful. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 20 04:23:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Toi-0006Er-20; Thu, 20 Jul 2006 04:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Tog-0006Em-3g for pce@ietf.org; Thu, 20 Jul 2006 04:23:30 -0400 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Tod-0007HL-MO for pce@ietf.org; Thu, 20 Jul 2006 04:23:30 -0400 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k6K8NK8S024810; Thu, 20 Jul 2006 10:23:20 +0200 Received: from [172.25.83.36] ([172.25.83.36]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006072010231848:2086 ; Thu, 20 Jul 2006 10:23:18 +0200 Message-ID: <44BF3D76.6060002@alcatel.fr> Date: Thu, 20 Jul 2006 10:23:18 +0200 From: Emmanuel.Dotaro@alcatel.fr Organization: Alcatel CTO/R&I User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Poll on three new working group I-Ds References: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> In-Reply-To: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/20/2006 10:23:18, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/20/2006 10:23:19, Serialize complete at 07/20/2006 10:23:19 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: 50a516d93fd399dc60588708fd9a3002 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Emmanuel.Dotaro@alcatel.fr List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Yes to all Adrian Farrel wrote: > Hi, > > Resulting from the discussions in Montreal, we would like to take your > opinions on the adoption of three I-Ds as working group drafts. > > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS scenario. > It has been refined considerably over the last couple of iterations > and is now limited to just the requirements for this situation. We may > need to do more work on it as a WG document, but the authors and > chairs believe it is in good enough shape to be the basis of the WG work. > > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document fleshes > out the details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait to include > details of policy for recovery path computation, but the chairs feel > that this scenarion (and any other relevant scenarios) can be safely > added once the I-D is a working group draft. Further, there was > support from the service providers in the room in Montreal for > adopting this I-D. > > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the > inter-domain case. > There has been some discussion of this draft on the mailing list > resulting in the request for a few clarifications of scope and > procedure, and also an explicit mention of the Path Key ID option. > Since JP is the lead author on this work, I think that the correct > procedure is for JP to make a quick update before this becomes a WG > I-D, but while we are polling I would like to ask your opinion on this > I-D assuming that JP makes the necessary changes. > > Simple Yes and No answers will do, but reasons are always helpful. > > Cheers, > Adrian > > > > _______________________________________________ > 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 Thu Jul 20 08:10:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XMm-0001H4-02; Thu, 20 Jul 2006 08:10:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XMk-000157-RZ for pce@ietf.org; Thu, 20 Jul 2006 08:10:54 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3WsR-0003mo-8f for pce@ietf.org; Thu, 20 Jul 2006 07:39:38 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2P001NQ9SITW@szxga01-in.huawei.com> for pce@ietf.org; Thu, 20 Jul 2006 19:41:06 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2P0062J9SHTH@szxga01-in.huawei.com> for pce@ietf.org; Thu, 20 Jul 2006 19:41:06 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2P00GOTA7LEM@szxml04-in.huawei.com> for pce@ietf.org; Thu, 20 Jul 2006 19:50:10 +0800 (CST) Date: Thu, 20 Jul 2006 19:38:45 +0800 From: Dan Li Subject: Re: [Pce] Poll on three new working group I-Ds To: Adrian Farrel , pce@ietf.org Message-id: <007601c6abf1$0f5aba30$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Adrian, Yes for all three IDs. Regards, Dan ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, July 19, 2006 10:08 PM Subject: [Pce] Poll on three new working group I-Ds > Hi, > > Resulting from the discussions in Montreal, we would like to take your > opinions on the adoption of three I-Ds as working group drafts. > > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS scenario. It > has been refined considerably over the last couple of iterations and is now > limited to just the requirements for this situation. We may need to do more > work on it as a WG document, but the authors and chairs believe it is in > good enough shape to be the basis of the WG work. > > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document fleshes out the > details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait to include > details of policy for recovery path computation, but the chairs feel that > this scenarion (and any other relevant scenarios) can be safely added once > the I-D is a working group draft. Further, there was support from the > service providers in the room in Montreal for adopting this I-D. > > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the inter-domain > case. > There has been some discussion of this draft on the mailing list resulting > in the request for a few clarifications of scope and procedure, and also an > explicit mention of the Path Key ID option. > Since JP is the lead author on this work, I think that the correct procedure > is for JP to make a quick update before this becomes a WG I-D, but while we > are polling I would like to ask your opinion on this I-D assuming that JP > makes the necessary changes. > > Simple Yes and No answers will do, but reasons are always helpful. > > Cheers, > Adrian > > > > _______________________________________________ > 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 Thu Jul 20 08:29:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Xf8-0005XD-SF; Thu, 20 Jul 2006 08:29:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Xf7-0005Vm-MZ for pce@ietf.org; Thu, 20 Jul 2006 08:29:53 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3XcR-00007o-B0 for pce@ietf.org; Thu, 20 Jul 2006 08:27:08 -0400 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-3sarge1) with ESMTP id k6KCR4NP004528; Thu, 20 Jul 2006 14:27:05 +0200 In-Reply-To: <071D2A01-0FCE-4A4F-AF8D-471E30FF8243@cisco.com> To: JP Vasseur Subject: Re: [Pce] P & I flags MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 20 Jul 2006 14:27:14 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/20/2006 14:27:03, Serialize complete at 07/20/2006 14:27:03 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b 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 j-p JP Vasseur 17/07/2006 16:45 =20 To: LE ROUX Jean-Louis RD-CORE-LAN=20 , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: pce@ietf.org Subject: Re: [Pce] P & I flags Hi, So I think that we're now all in sync wrt to the P & I bits semantic. * The P flag is used by a PCC to indicate to the PCE that a=20 constraint X MUST NOT be ignored. Consequently, if the PCE does not=20 support/understand such constraint X, it MUST send a PCErr (as=20 clearly stated in the document). [dp] would it be possible to differentiate between support/understanding=20 vs processing that may result in positive/negative answer ? from the=20 requirement there is a large set detailed in the req doc. section 6.1.16=20 =3D> PCErr in case of non-support of some of the mandatory constraints, an= d=20 PCRep with no path when no path can be found with full set of mandatory=20 constraints * The I flag is used by the PCE to indicate to the PCC whether a=20 constraint Y marked as optional in the request has been taken into=20 account, which can be very useful in several cases. [dp] ok (since the answer de-facto means that mandatory constraints have=20 been taken into account, and one can keep track of the constraints that=20 lead to a positive answer) Now, the issue discussed in this thread was related to constraint=20 relaxation, which is an important topic and I've personally been=20 supporting such feature for a while but there was no consensus on the=20 list on this topic (see the archives), thus, as pointed out by JL,=20 this was left out of the main PCEP spec. Of course, feel free to=20 continue some discussion on the list on this topic. Thanks. JP. On Jul 16, 2006, at 7:27 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri, > >> -----Message d'origine----- >> De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >> Envoy=E9 : lundi 17 juillet 2006 00:04 >> =C0 : LE ROUX Jean-Louis RD-CORE-LAN >> Cc : dimitri.papadimitriou@alcatel.be; Igor Bryskin; pce@ietf.org >> Objet : Re: [Pce] P & I flags >> >> hi j-l >> >> LE ROUX Jean-Louis RD-CORE-LAN wrote: >> >>> Hi Dimitri, >>> >>> >>>> -----Message d'origine----- De : dimitri papadimitriou >>>> [mailto:dpapadimitriou@psg.com] Envoy=E9 : dimanche 16 juillet 2006 >>>> 18:25 =C0 : Igor Bryskin Cc : LE ROUX Jean-Louis RD-CORE-LAN; >>>> dimitri.papadimitriou@alcatel.be; pce@ietf.org Objet : Re: >> [Pce] P & >>>> I flags >>>> >>>> igor, j-l >>>> >>>> to indicate optional/non-optional you need one flag like i >> indicate >>>> in my reply to j-l - let's say the P flag >>> >>> >>> NO, why do you want to change the semantic if the P flag? this >>> semantic is required... >> >> call it I flag if you want the point is that the Error should >> be generated once an object (from its class or type) is not=20 >> recognized > > Humm no, I flag is already used! > Call it O flag if you like > > >> >> if you have that a too high rejection rate could result from >> optional constraints such behaviour should be inferred by no >> further looking into the object >> >>>> in the reply - where you have a third level of indirection >> since you >>>> can send a positive or a negative answer you can have one of the >>>> following >>>> >>>> a) positive response with both optional and non-optional >> b) positive >>>> response with non-optional only c) negative response >>>> >>>> however, as far as my reading goes, ALL non-optional >> constraints MUST >>>> be taken into account while SOME of the optional >> constraints MAY be >>>> taken into account >>> >>> No, all recognized and supported constraints MUST be taken into >>> account during path computation, whatever the P flag value. >> The P flag >>> simply indicates what to do when a constraint is not >>> recognized/unsupported. >> >> again call it I flag, point remains, a negative answer shall >> come only from not finding a result from mandatory constraints > > Dimitri, please see my previous answer. I understand the semantic=20 > you define, it was discussed one year ago as part of a constraint=20 > relaxation thread (less constrained path), and the result of this=20 > thread was that there there was no consensus, some people were=20 > against, hence we removed the requirement from the generic PCECP=20 > req id, and also we removed text on less constrained path from the=20 > PCEP spec, and decided to address it latter. > This should be defined in a separate ID once the requirement is=20 > clearly expressed. > > By the way there are various options for handling optional=20 > constraints and more generally constraint relaxation. For instance=20 > the PCC may also send two requests, one with only mandatory=20 > constraints and another with optional constraints... > >> >> and a positive result may include more than the set of >> mandatory constraints > > Ah, this is interesting...and what sub-set of optional constraints=20 > is selected if not all optional constaints can be satisfied? Again=20 > we are discussing constraint relaxation here and this is beyond the=20 > scope of this doc... > >> >> the fact that an error is issued should then be the result of >> the non-support of a mandatory constraint > > Yes, indeed this is current P flag processing > > >> >> all together this makes one flag - and this only because >> there is a difference between optional object support and >> optional processing >> >>>> hence one could consider that list in the reply corresponds to the >>>> list of considered constraints and since the requestor knows these >>>> are optional or not there is no need for a second flag - this >>>> prevents back tracking of optional information - and restrict >>>> confirmation to the mandatory constraints >>>> >>>> ps: are you serious when considering a message length of 2^32 ? >>> >>> Yes, 2^16 may not be enought, think about an NMS that would send a >>> request for tens of thousands of LSPs. >> >> what does make the NMS PCC different from an LSR ? > > Please keep it simple, you were asking why do we need 2^32, and > I answered that 2^16 may not be enough, and I took, as pure=20 > illustration, the example of an NMS acting as PCC, and sending a=20 > PCReq for a synchronized path computation of tens of K LSPs, ie a=20 > PCReq with tens of K requests (I simply took the example of NMS=20 > PCC, as an NMS is likely to request synchronized path computation=20 > of many more LSPs, than an LSR would do). > >> i think >> there is a difference between the set of command issued to >> the NMS and the resulting set of PCC requests an NMS will generate > > Who says the contrary? And what is the point here? > > Thanks, > > JL > > >> >> thanks, >> - dimitri. >> >>> Thanks, >>> >>> JL >>> >>> >>>> thanks, - dimitri. >>>> >>>> >>>> >>>> >>>> Igor Bryskin wrote: >>>> >>>>> Hi JL, >>>>> >>>>> I have a question. Suppose, a path computation request has >>>> >>>> two constraints: >>>> >>>>> link colors and link bandwidth. Suppose the path >> computation fails. >>>>> The question is how the PCE can figure out what is the >>>> >>>> reason of this >>>> >>>>> computation failure? As an implementer of a Path >>>> >>>> Computation Engine I >>>> >>>>> always found it a difficult problem. Normally, presented >>>> >>>> with a path >>>> >>>>> computation request with link type constraints as in the >>>> >>>> example I am >>>> >>>>> describing, a PCE would prune out the arcs form the >> network graph >>>>> associated with links that do not satisfy at least one of the >>>>> constraints, and after that run some algorithm. If the >>>> >>>> algorithm fails >>>> >>>>> the only thing is clear that there are no links with >> proper colors >>>>> that have enough bandwidth, that is, entire set of >>>> >>>> constraints cannot >>>> >>>>> be satisfied. But it is impossible to say which constraint in >>>>> particular has caused the failure. Even if you start removing >>>>> constraints one by one and rerunning the algorithm (which >> would be >>>>> very unpractical to do), you will find out that it does not >>>> >>>> help. The path computation of the example may succeed in >> both these >>>> iterations because: >>>> >>>>> a) there are links with proper colors; b) there are links with >>>>> enough bandwidth. >>>>> >>>>> The bottom line is that path computation fails because of >>>> >>>> the entire >>>> >>>>> set of constraints rather than because of one or several of >>>> >>>> them, and >>>> >>>>> it is unrealistic to think that PCE in its negative reply >>>> >>>> would mark >>>> >>>>> constraints which cause the failure. >>>>> >>>>> So, I recommend to have two flags (say, P and I). One of >>>> >>>> them should >>>> >>>>> be used to mark mandatory constraints, while another - >>>> >>>> optional constraints. >>>> >>>>> Recommend to make an assumption that PCE will run path >>>> >>>> computation at >>>> >>>>> most two times: >>>>> >>>>> 1) trying to accommodate all constraints; 2) in case 1) fails, >>>>> removing all optional constraints >>>>> >>>>> PCE should return: >>>>> >>>>> a) successful response without flags when 1) succeeds; b) >>>>> successful response with flag I when 2) succeeds; 3) negative >>>>> response with no flags when 2 fails. >>>>> >>>>> Igor >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- From: "LE ROUX Jean-Louis >> RD-CORE-LAN" >>>>> To: >>>>> ; ; >>>>> Sent: Friday, July 14, 2006 10:46 AM Subject: RE: >>>>> [Pce] P & I flags >>>>> >>>>> >>>>> Hi Dimitri, >>>>> >>>>> >>>>> >>>>>> -----Message d'origine----- De : dimitri papadimitriou >>>>>> [mailto:dpapadimitriou@psg.com] Envoy=E9 : vendredi 14 juillet >>>>>> 2006 15:44 =C0 : pce@ietf.org Objet : [Pce] P & I flags >>>>>> >>>>>> the comments around the P and I flags are >>>>>> >>>>>> o) we have two levels of optionality in listing the >> protocol object >>>>>> and usage level of the protocol object - however it is much more >>>>>> appropriate to be sure that mandatory constraints have >> been taken >>>>>> rather than having the optional having been taken into account >>>>> >>>>> >>>>> As clearly pointed out in the same setion of the draft, if >>>> >>>> a mandatory >>>> >>>>> constraint cannot be handled the PCE replies with PCErr message >>>>> >>>>> "If the PCE does not understand an object with the P Flag set or >>>>> understands the object but decides to ignore the object, >>>> >>>> the entire >>>> >>>>> PCEP message MUST be rejected and the PCE MUST send a >>>> >>>> PCErr message >>>> >>>>> with Error-Type=3D"Unknown Object" or "Not supported Object". >>>>> >>>>> If the PCE can handle all mandatory constraints it >> replies with a >>>>> PCRep message (either positive or negative if there is no >>>> >>>> path), else >>>> >>>>> it sends a PCErr message. Hence the PCC knows whether mandatory >>>>> constraints have been >>>> >>>> taken into >>>> >>>>> account. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> P flag (Processing-Rule - 1-bit): the P flag allows a PCC to >>>>>> specify in a PCReq message sent to a PCE whether the object >>>> >>>> must be taken >>>> >>>>>> into account by the PCE during path computation or is just >>>>>> optional. When the P flag is set, the object MUST be taken into >>>>>> >>>> >>>> account by >>>> >>>>>> the PCE. Conversely, when the P flag is cleared, the object is >>>>>> optional and the PCE is free to ignore it if not supported. >>>>>> >>>>>> o) on the I flag issue is identical why include an >> object which has >>>>>> not considered during computation ? >>>>> >>>>> >>>>> I don't catch your point, the PCC may want to know the >> constraints >>>>> that were not taken into account during path computation, >>>> >>>> this sounds >>>> >>>>> quite important isn'it? >>>>> >>>>> >>>>> there are so >>>>> >>>>> >>>>>> many things that the PCE has not taken into account during >>>> >>>> computation >>>> >>>>>> so why bother ? >>>>> >>>>> >>>>> Hum I don't follow you here "there are so many things...", >>>> >>>> What do you mean? >>>> >>>>> >>>>> >>>>>> it is imho more important to include the mandatory >> object not taken >>>>>> into account >>>>> >>>>> >>>>> If a mandatory object is not taken into account, you >> cannot compute >>>>> the path and you send an error message. I agree with you >> that this >>>>> would be useful to include within the PCErr the set of >> objects not >>>>> supported, this can be clarified in next revision. >>>>> >>>>> >>>>> >>>>> >>>>>> I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep >>>>>> message to indicate to a PCC whether or not an optional >>>> >>>> object was >>>> >>>>>> processed. The PCE MAY include the ignored optional >>>> >>>> object in its >>>> >>>>>> reply and set the I flag to indicate that the optional >>>> >>>> object was >>>> >>>>>> ignored during path computation. When the I flag is >>>> >>>> cleared, the >>>> >>>>>> PCE indicates that the optional object was processed during the >>>>>> path computation. The setting of the I flag for >> optional objects >>>>>> is purely indicative and optional. The I flag MUST be >>>>>> >>>> >>>> cleared if the >>>> >>>>>> P flag is set. >>>>>> >>>>>> o) the result of all these flags is that a PCC can be >>>> >>>> wrapping around >>>> >>>>>> unknown constraints create processing churn on the PCE; >>>>> >>>>> >>>>> OK, if you mean that we should include the unsupported object(s) >>>>> within the PCErr, then we are in sync >>>>> >>>>> Thanks for the comment >>>>> >>>>> Regards >>>>> >>>>> JL >>>>> >>>>> >>>>> >>>>>> If the PCE does not understand an object with the P Flag set or >>>>>> understands the object but decides to ignore the object, >> the entire >>>>>> PCEP message MUST be rejected and the PCE MUST send a >> PCErr message >>>>>> with Error-Type=3D"Unknown Object" or "Not supported Object". >>>>>> >>>>>> >>>>>> >>>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= Pce mailing list >>>>>> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce >>>>>> >>>>> >>>>> >>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Pc= e mailing list >>>>> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce >>>>> >>>>> >>>>> . >>>>> >>>> >>> >>> . >>> >> > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > 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 Thu Jul 20 08:59:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Y7x-0000p3-C3; Thu, 20 Jul 2006 08:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Y7w-0000oy-I1 for pce@ietf.org; Thu, 20 Jul 2006 08:59:40 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3Y7v-0005JS-5G for pce@ietf.org; Thu, 20 Jul 2006 08:59:40 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1153400360!10725461!8 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 12555 invoked from network); 20 Jul 2006 12:59:38 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-120.messagelabs.com with SMTP; 20 Jul 2006 12:59:38 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452002E65D6; Thu, 20 Jul 2006 08:59:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] P & I flags Date: Thu, 20 Jul 2006 07:59:36 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B36@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <02a901c6abee$773c6250$0a23fea9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] P & I flags Thread-Index: Acar9X7jI5gS5u6BQXi4Mg3+b3wamwABPTtQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , "Igor Bryskin" , "JP Vasseur" , "LE ROUX Jean-Louis RD-CORE-LAN" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 Adrian, See below.=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Thursday, July 20, 2006 7:17 AM > To: Igor Bryskin; JP Vasseur; LE ROUX Jean-Louis RD-CORE-LAN > Cc: pce@ietf.org > Subject: Re: [Pce] P & I flags >=20 > Hi, >=20 > This thread went suddenly very quiet in response to Igor's=20 > question which is=20 > a shame because it is a good question. >=20 > When you are doing a path computation how do you know why you=20 > can't reach=20 > the destination with sufficient bandwidth and low enough delay? >=20 > Is it because there is not enough bandwidth on the low delay path? > Or is it because there is too much delay on the high bandwidth path? >=20 > The issue becomes unmanageably complex when there are many=20 > constraints, and=20 > is particularly difficult when those are absolute not=20 > relative constraints. >=20 > Of course, it is always possible to make some guesses, but=20 > usually these are=20 > based on varying the constraints to see what could be=20 > achieved. The choice=20 > of which constraints to vary, by how much, and in what order is very=20 > suspect, and (as when we discussed constraint relaxation)=20 > should be the=20 > subject of policy either at the PCC or the PCE. >=20 > For example, a response that says "If you relaxed the=20 > required bandwidth by=20 > 10% you could get a path" is no use to a PCC that MUST have=20 > the bandwidth,=20 > but that would be happy to relax the delay constraint by 90%. It seems that a option to PCC specified constraints would be one approach to your example (an analogous approach is being used for example in NSIS QoS signaling, see e.g., http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt). =20 If the PCC gave its =3D <90% * Bandwidth, 10% * delay>, that would work in this case. Thanks, Jerry >=20 > Adrian >=20 >=20 > ----- Original Message -----=20 > From: "Igor Bryskin" > To: "JP Vasseur" ; "LE ROUX Jean-Louis=20 > RD-CORE-LAN"=20 > > Cc: > Sent: Monday, July 17, 2006 5:03 PM > Subject: Re: [Pce] P & I flags >=20 > > JP. > > > >>> IB>> This is the whole my point. If there is a set of > >>> mandatory constraints, > >>> there is no way for a PCE to tell because of which particular > >>> constraint(s) > >>> the computation has failed, > >> > >> Why, if it is clever enough to detect a blocking constraint? > >> > > > > I agree with JL here. There *are* many ways to figure out which > > constraints could not be satisfied, in which case indicating this > > information to the PCC is quite useful. > > > > IB>> I am just curious. Could you (or anybody) describe=20 > > just one of the=20 > > ways > > how PCE can figure out which of mandatory constraints=20 > > caused the path > > computation to fail? > > > > Thanks, > > Igor _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 20 10:40:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Zhm-0003Oe-L9; Thu, 20 Jul 2006 10:40:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Zhl-0003Mx-Cf for pce@ietf.org; Thu, 20 Jul 2006 10:40:45 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Zan-00042w-IJ for pce@ietf.org; Thu, 20 Jul 2006 10:33:34 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G3Zaj-0001g2-00 for pce@ietf.org; Thu, 20 Jul 2006 15:33:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Pce] P & I flags MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jul 2006 15:33:40 +0100 Message-ID: <3D1918258E6DE14DAAABBD34D53D293408CD88@cortex.aria-networks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] P & I flags Thread-Index: Acar9X7jI5gS5u6BQXi4Mg3+b3wamwABPTtQAAOWlXA= From: "Daniel King" To: "Ash, Gerald R \(Jerry\), ALABS" , "Adrian Farrel" , "Igor Bryskin" , "JP Vasseur" , "LE ROUX Jean-Louis RD-CORE-LAN" X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Jerry, I like the concept; it could be extended further by specifying that a single or set of constraints might have a value and a value. So the service is computed based an absolute and / or , or just flagged to simply or certain constraints wherever possible. It's also likely that the PCC will want to specify more than one constraint, so maybe it needs to specify the priority / weighting of each constraint when the service is computed. This will allow the minimizing of certain constraints at the expense of others. The PCE might want to flag which of the constraints met their requested value and which simply met the required value. Dan =20 -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 Sent: 20 July 2006 14:00 To: Adrian Farrel; Igor Bryskin; JP Vasseur; LE ROUX Jean-Louis RD-CORE-LAN Cc: pce@ietf.org Subject: RE: [Pce] P & I flags Hi Adrian, See below.=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Thursday, July 20, 2006 7:17 AM > To: Igor Bryskin; JP Vasseur; LE ROUX Jean-Louis RD-CORE-LAN > Cc: pce@ietf.org > Subject: Re: [Pce] P & I flags >=20 > Hi, >=20 > This thread went suddenly very quiet in response to Igor's=20 > question which is=20 > a shame because it is a good question. >=20 > When you are doing a path computation how do you know why you=20 > can't reach=20 > the destination with sufficient bandwidth and low enough delay? >=20 > Is it because there is not enough bandwidth on the low delay path? > Or is it because there is too much delay on the high bandwidth path? >=20 > The issue becomes unmanageably complex when there are many=20 > constraints, and=20 > is particularly difficult when those are absolute not=20 > relative constraints. >=20 > Of course, it is always possible to make some guesses, but=20 > usually these are=20 > based on varying the constraints to see what could be=20 > achieved. The choice=20 > of which constraints to vary, by how much, and in what order is very=20 > suspect, and (as when we discussed constraint relaxation)=20 > should be the=20 > subject of policy either at the PCC or the PCE. >=20 > For example, a response that says "If you relaxed the=20 > required bandwidth by=20 > 10% you could get a path" is no use to a PCC that MUST have=20 > the bandwidth,=20 > but that would be happy to relax the delay constraint by 90%. It seems that a option to PCC specified constraints would be one approach to your example (an analogous approach is being used for example in NSIS QoS signaling, see e.g., http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt). =20 If the PCC gave its =3D <90% * Bandwidth, 10% * delay>, that would work in this case. Thanks, Jerry >=20 > Adrian >=20 >=20 > ----- Original Message -----=20 > From: "Igor Bryskin" > To: "JP Vasseur" ; "LE ROUX Jean-Louis=20 > RD-CORE-LAN"=20 > > Cc: > Sent: Monday, July 17, 2006 5:03 PM > Subject: Re: [Pce] P & I flags >=20 > > JP. > > > >>> IB>> This is the whole my point. If there is a set of > >>> mandatory constraints, > >>> there is no way for a PCE to tell because of which particular > >>> constraint(s) > >>> the computation has failed, > >> > >> Why, if it is clever enough to detect a blocking constraint? > >> > > > > I agree with JL here. There *are* many ways to figure out which > > constraints could not be satisfied, in which case indicating this > > information to the PCC is quite useful. > > > > IB>> I am just curious. Could you (or anybody) describe=20 > > just one of the=20 > > ways > > how PCE can figure out which of mandatory constraints=20 > > caused the path > > computation to fail? > > > > Thanks, > > Igor _______________________________________________ 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 Thu Jul 20 11:34:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3aYD-0006h6-1J; Thu, 20 Jul 2006 11:34:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3aXy-0005gq-9O for pce@ietf.org; Thu, 20 Jul 2006 11:34:42 -0400 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 1G3aTq-0004Bp-2L for pce@ietf.org; Thu, 20 Jul 2006 11:30:27 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 20 Jul 2006 08:30:25 -0700 X-IronPort-AV: i="4.07,163,1151910000"; d="scan'208"; a="435474915:sNHT27402620" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KFUPMH005522; Thu, 20 Jul 2006 08:30:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6KFUP2D006071; Thu, 20 Jul 2006 08:30:25 -0700 (PDT) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 08:30:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Poll on three new working group I-Ds Date: Thu, 20 Jul 2006 08:29:43 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E020282E2@xmb-sjc-234.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Poll on three new working group I-Ds Thread-Index: AcarQMB5IemvZLl8Te+RWkWqoyMf/wA0G/GA From: "Dean Cheng \(dcheng\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 20 Jul 2006 15:30:25.0050 (UTC) FILETIME=[6BD9DFA0:01C6AC11] DKIM-Signature: a=rsa-sha1; q=dns; l=2305; t=1153409425; x=1154273425; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dcheng@cisco.com; z=From:=22Dean=20Cheng=20\(dcheng\)=22=20 |Subject:RE=3A=20[Pce]=20Poll=20on=20three=20new=20working=20group=20I-Ds; X=v=3Dcisco.com=3B=20h=3Dn+S76rPPacCc8ZoVjBz20snzhpI=3D; b=AVVTo+fCTeECWWqf35oN7KBBbfPwnMu54Jzf8r0WI+pIfgkRZ8fILVbdEeVOth4ZFTxC3IlS 4aQ05UAz4Ta26ETHBNan2Pc2T2BHqiLebdN9t48dVTDEHOSrmDn0/iHW; Authentication-Results: sj-dkim-4.cisco.com; header.From=dcheng@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Yes to all. Dean=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Wednesday, July 19, 2006 7:08 AM > To: pce@ietf.org > Subject: [Pce] Poll on three new working group I-Ds >=20 > Hi, >=20 > Resulting from the discussions in Montreal, we would like to=20 > take your opinions on the adoption of three I-Ds as working=20 > group drafts. >=20 > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS=20 > scenario. It has been refined considerably over the last=20 > couple of iterations and is now limited to just the=20 > requirements for this situation. We may need to do more work=20 > on it as a WG document, but the authors and chairs believe it=20 > is in good enough shape to be the basis of the WG work. >=20 > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document=20 > fleshes out the details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait=20 > to include details of policy for recovery path computation,=20 > but the chairs feel that this scenarion (and any other=20 > relevant scenarios) can be safely added once the I-D is a=20 > working group draft. Further, there was support from the=20 > service providers in the room in Montreal for adopting this I-D. >=20 > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the=20 > inter-domain case. > There has been some discussion of this draft on the mailing=20 > list resulting in the request for a few clarifications of=20 > scope and procedure, and also an explicit mention of the Path=20 > Key ID option. > Since JP is the lead author on this work, I think that the=20 > correct procedure is for JP to make a quick update before=20 > this becomes a WG I-D, but while we are polling I would like=20 > to ask your opinion on this I-D assuming that JP makes the=20 > necessary changes. >=20 > Simple Yes and No answers will do, but reasons are always helpful. >=20 > Cheers, > Adrian >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 20 14:12:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3d0G-00052j-OE; Thu, 20 Jul 2006 14:12:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3d0F-0004vx-CE for pce@ietf.org; Thu, 20 Jul 2006 14:12:03 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3czH-00085p-6c for pce@ietf.org; Thu, 20 Jul 2006 14:11:04 -0400 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-3sarge1) with ESMTP id k6KIB2Zn011674; Thu, 20 Jul 2006 20:11:02 +0200 In-Reply-To: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> To: Adrian Farrel Subject: Re: [Pce] Poll on three new working group I-Ds MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 20 Jul 2006 20:11:12 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/20/2006 20:11:01, Serialize complete at 07/20/2006 20:11:01 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 > Resulting from the discussions in Montreal, we would like to take your > opinions on the adoption of three I-Ds as working group drafts. > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS scenario. It > has been refined considerably over the last couple of iterations and is now > limited to just the requirements for this situation. We may need to do more > work on it as a WG document, but the authors and chairs believe it is in > good enough shape to be the basis of the WG work. [dp] agreed, basis is there & more work is needed as part of wg i-d process - note: will send comments after wg i-d release [dp] would like to see more input on section 4.1.2 (expected gain and perf's from user community - if possible of course) > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document fleshes out the > details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait to include > details of policy for recovery path computation, but the chairs feel that > this scenarion (and any other relevant scenarios) can be safely added once > the I-D is a working group draft. Further, there was support from the > service providers in the room in Montreal for adopting this I-D. [dp] ok (but i am a co-author) > draft-vasseur-pce-brpc-00.txt [dp] guess you mean draft-vasseur-pce-brpc-01.txt > This draft describes an application procedure for PCE in the inter-domain > case. > There has been some discussion of this draft on the mailing list resulting > in the request for a few clarifications of scope and procedure, and also an > explicit mention of the Path Key ID option. > Since JP is the lead author on this work, I think that the correct procedure > is for JP to make a quick update before this becomes a WG I-D, but while we > are polling I would like to ask your opinion on this I-D assuming that JP > makes the necessary changes. [dp] agreed > Simple Yes and No answers will do, but reasons are always helpful. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 20 17:19:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fvG-00034K-S1; Thu, 20 Jul 2006 17:19:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fvF-00031V-Jd for pce@ietf.org; Thu, 20 Jul 2006 17:19:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3fvD-0000E6-9k for pce@ietf.org; Thu, 20 Jul 2006 17:19:05 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2006 14:19:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,163,1151910000"; d="scan'208"; a="32847448:sNHT30384812" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KLJ2V9012401; Thu, 20 Jul 2006 17:19:02 -0400 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 k6KLJ17v015720; Thu, 20 Jul 2006 17:19:01 -0400 (EDT) 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.1830); Thu, 20 Jul 2006 17:19:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Poll on three new working group I-Ds Date: Thu, 20 Jul 2006 17:19:00 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D33201B7B3B4@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Poll on three new working group I-Ds Thread-Index: AcarQMF4uPdPeff0SBSQv1CKXg1kvwBAUCjw From: "Rich Bradford \(rbradfor\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 20 Jul 2006 21:19:01.0698 (UTC) FILETIME=[1F251220:01C6AC42] DKIM-Signature: a=rsa-sha1; q=dns; l=2230; t=1153430342; x=1154294342; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rbradfor@cisco.com; z=From:=22Rich=20Bradford=20\(rbradfor\)=22=20 |Subject:RE=3A=20[Pce]=20Poll=20on=20three=20new=20working=20group=20I-Ds |To:=22Adrian=20Farrel=22=20,=20; X=v=3Dcisco.com=3B=20h=3D2T2ZI5sxA4TCpqqlV8D94xTc0+A=3D; b=oCRvKPax0FYh08oxDMXL5nBHpd9Ltol6Is0Q2wCDqpSNc9McKryqLr4OWu1AB+YZOi08NwQ0 THjoXcIamko9Mb4MQ4FH67cR3OCMr0545ryAjeJxDZEA6OXYdP02zvn5; Authentication-Results: rtp-dkim-1.cisco.com; header.From=rbradfor@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Yes to all. -- rich > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, July 19, 2006 10:08 AM > To: pce@ietf.org > Subject: [Pce] Poll on three new working group I-Ds >=20 > Hi, >=20 > Resulting from the discussions in Montreal, we would like to take your > opinions on the adoption of three I-Ds as working group drafts. >=20 > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS scenario. It > has been refined considerably over the last couple of iterations and is now > limited to just the requirements for this situation. We may need to do more > work on it as a WG document, but the authors and chairs believe it is in > good enough shape to be the basis of the WG work. >=20 > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document fleshes out the > details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait to include > details of policy for recovery path computation, but the chairs feel that > this scenarion (and any other relevant scenarios) can be safely added once > the I-D is a working group draft. Further, there was support from the > service providers in the room in Montreal for adopting this I-D. >=20 > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the inter-domain > case. > There has been some discussion of this draft on the mailing list resulting > in the request for a few clarifications of scope and procedure, and also an > explicit mention of the Path Key ID option. > Since JP is the lead author on this work, I think that the correct procedure > is for JP to make a quick update before this becomes a WG I-D, but while we > are polling I would like to ask your opinion on this I-D assuming that JP > makes the necessary changes. >=20 > Simple Yes and No answers will do, but reasons are always helpful. >=20 > Cheers, > Adrian >=20 >=20 >=20 > _______________________________________________ > 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 Thu Jul 20 17:44:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gJg-0005l2-Nk; Thu, 20 Jul 2006 17:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gIQ-0003yf-Bj for pce@ietf.org; Thu, 20 Jul 2006 17:43:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3g6B-0001FJ-AA for pce@ietf.org; Thu, 20 Jul 2006 17:30:24 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Jul 2006 17:30:23 -0400 X-IronPort-AV: i="4.07,163,1151899200"; d="scan'208"; a="93388190:sNHT24962112" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KLUMSM016437; Thu, 20 Jul 2006 17:30:22 -0400 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 k6KLUL7x018841; Thu, 20 Jul 2006 17:30:22 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 17:30:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Poll on three new working group I-Ds Date: Thu, 20 Jul 2006 17:30:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Poll on three new working group I-Ds Thread-Index: AcarQMFFe0303ComQLWua7SyRntRVABAqr3Q From: "Zafar Ali \(zali\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 20 Jul 2006 21:30:22.0039 (UTC) FILETIME=[B4A8DE70:01C6AC43] DKIM-Signature: a=rsa-sha1; q=dns; l=2365; t=1153431022; x=1154295022; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20 |Subject:RE=3A=20[Pce]=20Poll=20on=20three=20new=20working=20group=20I-Ds |To:=22Adrian=20Farrel=22=20,=20; X=v=3Dcisco.com=3B=20h=3DMhA7YqiGtqrsBj5fIaSX8R5mdy8=3D; b=Fok05/bQhHoIKyQOcivYpS0LMj2IVC502zKWyaqBuJKMruX0iKrTrKM0qODQKI4z7o+p7maR QvdX1IBP+taxpsNmTTH6XbX9XJM1+jgSZldiBJ/8UcxLp/yA/lzGChZo; Authentication-Results: rtp-dkim-1.cisco.com; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Wednesday, July 19, 2006 10:08 AM > To: pce@ietf.org > Subject: [Pce] Poll on three new working group I-Ds >=20 > Hi, >=20 > Resulting from the discussions in Montreal, we would like to=20 > take your opinions on the adoption of three I-Ds as working=20 > group drafts. >=20 > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS=20 > scenario. It has been refined considerably over the last=20 > couple of iterations and is now limited to just the=20 > requirements for this situation. We may need to do more work=20 > on it as a WG document, but the authors and chairs believe it=20 > is in good enough shape to be the basis of the WG work. >=20 Yes,=20 > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document=20 > fleshes out the details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait=20 > to include details of policy for recovery path computation,=20 > but the chairs feel that this scenarion (and any other=20 > relevant scenarios) can be safely added once the I-D is a=20 > working group draft. Further, there was support from the=20 > service providers in the room in Montreal for adopting this I-D. >=20 I would like to wait to include details of policy.=20 > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the=20 > inter-domain case. Yes,=20 > There has been some discussion of this draft on the mailing=20 > list resulting in the request for a few clarifications of=20 > scope and procedure, and also an explicit mention of the Path=20 > Key ID option. > Since JP is the lead author on this work, I think that the=20 > correct procedure is for JP to make a quick update before=20 > this becomes a WG I-D, but while we are polling I would like=20 > to ask your opinion on this I-D assuming that JP makes the=20 > necessary changes. >=20 > Simple Yes and No answers will do, but reasons are always helpful. >=20 > Cheers, > Adrian >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 20 18:31:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3h2u-0005Fu-A5; Thu, 20 Jul 2006 18:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3h2s-0005Fm-Cc for pce@ietf.org; Thu, 20 Jul 2006 18:31:02 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3h2r-00072G-6h for pce@ietf.org; Thu, 20 Jul 2006 18:31:02 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1G3h2T-0006m9-Uk; Thu, 20 Jul 2006 18:30:38 -0400 Message-Id: <7.0.1.0.2.20060720181336.063103b0@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 20 Jul 2006 18:30:54 -0400 To: "Zafar Ali \(zali\)" From: Lou Berger Subject: RE: [Pce] Poll on three new working group I-Ds In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 At 05:30 PM 7/20/2006, Zafar Ali \(zali\) wrote: >I would like to wait to include details of policy. Zafar, I'm not sure what you're saying we should wait for. The details of the policy framework are completely documented as published. The next step in details (PC Policy Information Model) is not part of the framework and, as presented to the WG, belongs in a new/separate draft. What was discussed is the possibility of adding a new usage scenario to the framework, but this would simply be an informative section describing a potential use of PCE policy. Additionally, based on the WG discussion and as the text describing the scenario does not yet exist, it isn't clear if there is consensus that this scenario is valid. So again, I'm not sure what you'd like to wait for... Lou _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jul 22 06:21:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4Ebe-0004q1-BQ; Sat, 22 Jul 2006 06:21:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4Ebc-0004jB-EC for pce@ietf.org; Sat, 22 Jul 2006 06:21:08 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4Eba-0002FG-15 for pce@ietf.org; Sat, 22 Jul 2006 06:21:08 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 22 Jul 2006 03:21:05 -0700 X-IronPort-AV: i="4.07,170,1151910000"; d="scan'208"; a="1840824517:sNHT27682678" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6MAL5Ef005120; Sat, 22 Jul 2006 03:21:05 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6MAL479029253; Sat, 22 Jul 2006 03:21:04 -0700 (PDT) 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.1830); Sat, 22 Jul 2006 06:21:03 -0400 Received: from [192.168.1.102] ([10.86.240.64]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Jul 2006 06:21:03 -0400 In-Reply-To: <02a901c6abee$773c6250$0a23fea9@your029b8cecfe> References: <043201c6a9ba$8f8ab040$6501a8c0@movaz.com> <02a901c6abee$773c6250$0a23fea9@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93E87C4A-0964-490C-8BDD-BBFAD2B95507@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Sat, 22 Jul 2006 12:21:00 +0200 To: "Adrian Farrel" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Jul 2006 10:21:03.0470 (UTC) FILETIME=[891D08E0:01C6AD78] DKIM-Signature: a=rsa-sha1; q=dns; l=3199; t=1153563665; x=1154427665; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Subject=20Change=3A=20Constraint=20Relaxation; X=v=3Dcisco.com=3B=20h=3DCoi7dNx6EViYQqLWbbuHLMPjSC8=3D; b=BXUmvTcgibrX8vjB5E1Dl1X9+1Hzijd6F78yIE2aKbGgVwTbJDILj4NoIRp8J8HdI1ZZzKPo jj4PRbTxTPcUZkLfEyOONstbrAVgeQGtQ2rOWmPLK6G58H80OxPDyHXn; Authentication-Results: sj-dkim-6.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] Subject Change: Constraint Relaxation 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, On Jul 20, 2006, at 1:17 PM, Adrian Farrel wrote: > Hi, > > This thread went suddenly very quiet in response to Igor's question > which is a shame because it is a good question. > > When you are doing a path computation how do you know why you can't > reach the destination with sufficient bandwidth and low enough delay? > > Is it because there is not enough bandwidth on the low delay path? > Or is it because there is too much delay on the high bandwidth path? > > The issue becomes unmanageably complex when there are many > constraints, and is particularly difficult when those are absolute > not relative constraints. > > Of course, it is always possible to make some guesses, but usually > these are based on varying the constraints to see what could be > achieved. The choice of which constraints to vary, by how much, and > in what order is very suspect, and (as when we discussed constraint > relaxation) should be the subject of policy either at the PCC or > the PCE. > > For example, a response that says "If you relaxed the required > bandwidth by 10% you could get a path" is no use to a PCC that MUST > have the bandwidth, but that would be happy to relax the delay > constraint by 90%. I think it is ... there are many network designs in which a clear constraint hierarchy can be defined. For example, bandwidth and affinity (and of course the number of such example is quite large). "You can relax the affinity constraint if a path with at least 90% of the required bandwidth can be found". In that particular case, it is quite easy to specify an algorithm capable of satisfying such request. There are also some cases where the issue is NP-hard (most of them) but the number of situations where hierarchical constraint relaxation would be useful is not negligible. Note that we're discussing about constraint relaxation here for which there was a decision to tackle this issue in a separate ID. Cheers. JP. > > Adrian > > > ----- Original Message ----- From: "Igor Bryskin" > To: "JP Vasseur" ; "LE ROUX Jean-Louis RD-CORE- > LAN" > Cc: > Sent: Monday, July 17, 2006 5:03 PM > Subject: Re: [Pce] P & I flags > > >> JP. >> >>>> IB>> This is the whole my point. If there is a set of >>>> mandatory constraints, >>>> there is no way for a PCE to tell because of which particular >>>> constraint(s) >>>> the computation has failed, >>> >>> Why, if it is clever enough to detect a blocking constraint? >>> >> >> I agree with JL here. There *are* many ways to figure out which >> constraints could not be satisfied, in which case indicating this >> information to the PCC is quite useful. >> >> IB>> I am just curious. Could you (or anybody) describe just one >> of the ways >> how PCE can figure out which of mandatory constraints caused the path >> computation to fail? >> >> Thanks, >> Igor >> >> >> _______________________________________________ >> 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 Jul 22 06:33:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4EnE-0003mI-Qx; Sat, 22 Jul 2006 06:33:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4EnC-0003mD-Uj for pce@ietf.org; Sat, 22 Jul 2006 06:33:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4EnC-0003b3-7i for pce@ietf.org; Sat, 22 Jul 2006 06:33:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2006 03:33:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,170,1151910000"; d="scan'208"; a="32999783:sNHT29044948" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6MAX4rd025495; Sat, 22 Jul 2006 06:33:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6MAX3dU027504; Sat, 22 Jul 2006 06:33:03 -0400 (EDT) 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.1830); Sat, 22 Jul 2006 06:33:03 -0400 Received: from [192.168.1.102] ([10.86.240.64]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Jul 2006 06:33:02 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9AC020D8-46E3-436A-817B-76A589BB110E@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] P & I flags Date: Sat, 22 Jul 2006 12:33:00 +0200 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Jul 2006 10:33:02.0935 (UTC) FILETIME=[35F2AE70:01C6AD7A] DKIM-Signature: a=rsa-sha1; q=dns; l=15717; t=1153564384; x=1154428384; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20[Pce]=20P=20&=20I=20flags |To:Dimitri.Papadimitriou@alcatel.be; X=v=3Dcisco.com=3B=20h=3DmChWld8qMZWisUgO7/iNX+5HLMk=3D; b=jSnHVPB6zddigL/VyOIwiRec0yLjccfyn2uVu9dITnskDLTa8cEwrucFFzbmUYV3zIjJ0MIG BSslJgIH2+XTmmz7EschFap/7/SlPbmaLJn7oeh3FekQMBe0ViM78CoY; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 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, On Jul 20, 2006, at 2:27 PM, Dimitri.Papadimitriou@alcatel.be wrote: > hi j-p > > > > > > JP Vasseur > 17/07/2006 16:45 > > To: LE ROUX Jean-Louis RD-CORE-LAN > , Dimitri PAPADIMITRIOU/BE/=20 > ALCATEL@ALCATEL > cc: pce@ietf.org > Subject: Re: [Pce] P & I flags > > > Hi, > > So I think that we're now all in sync wrt to the P & I bits semantic. > > * The P flag is used by a PCC to indicate to the PCE that a > constraint X MUST NOT be ignored. Consequently, if the PCE does not > support/understand such constraint X, it MUST send a PCErr (as > clearly stated in the document). > > > [dp] would it be possible to differentiate between support/=20 > understanding > vs processing that may result in positive/negative answer ? from the > requirement there is a large set detailed in the req doc. section =20 > 6.1.16 > =3D> PCErr in case of non-support of some of the mandatory =20 > constraints, and > PCRep with no path when no path can be found with full set of =20 > mandatory > constraints > Both cases are actually already supported: (1) Case 1: constraint not supported / not understood in which case =20 the PCE sends a PCErr (2) Case 2: constraint supported / understood but No Path found (The =20 PCE sends a negative reply with NO-PATH). > > * The I flag is used by the PCE to indicate to the PCC whether a > constraint Y marked as optional in the request has been taken into > account, which can be very useful in several cases. > > > [dp] ok (since the answer de-facto means that mandatory constraints =20= > have > been taken into account, and one can keep track of the constraints =20 > that > lead to a positive answer) Thanks. JP. > > > Now, the issue discussed in this thread was related to constraint > relaxation, which is an important topic and I've personally been > supporting such feature for a while but there was no consensus on the > list on this topic (see the archives), thus, as pointed out by JL, > this was left out of the main PCEP spec. Of course, feel free to > continue some discussion on the list on this topic. > > Thanks. > > JP. > > On Jul 16, 2006, at 7:27 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > >> Hi Dimitri, >> >>> -----Message d'origine----- >>> De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>> Envoy=E9 : lundi 17 juillet 2006 00:04 >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN >>> Cc : dimitri.papadimitriou@alcatel.be; Igor Bryskin; pce@ietf.org >>> Objet : Re: [Pce] P & I flags >>> >>> hi j-l >>> >>> LE ROUX Jean-Louis RD-CORE-LAN wrote: >>> >>>> Hi Dimitri, >>>> >>>> >>>>> -----Message d'origine----- De : dimitri papadimitriou >>>>> [mailto:dpapadimitriou@psg.com] Envoy=E9 : dimanche 16 juillet = 2006 >>>>> 18:25 =C0 : Igor Bryskin Cc : LE ROUX Jean-Louis RD-CORE-LAN; >>>>> dimitri.papadimitriou@alcatel.be; pce@ietf.org Objet : Re: >>> [Pce] P & >>>>> I flags >>>>> >>>>> igor, j-l >>>>> >>>>> to indicate optional/non-optional you need one flag like i >>> indicate >>>>> in my reply to j-l - let's say the P flag >>>> >>>> >>>> NO, why do you want to change the semantic if the P flag? this >>>> semantic is required... >>> >>> call it I flag if you want the point is that the Error should >>> be generated once an object (from its class or type) is not >>> recognized >> >> Humm no, I flag is already used! >> Call it O flag if you like >> >> >>> >>> if you have that a too high rejection rate could result from >>> optional constraints such behaviour should be inferred by no >>> further looking into the object >>> >>>>> in the reply - where you have a third level of indirection >>> since you >>>>> can send a positive or a negative answer you can have one of the >>>>> following >>>>> >>>>> a) positive response with both optional and non-optional >>> b) positive >>>>> response with non-optional only c) negative response >>>>> >>>>> however, as far as my reading goes, ALL non-optional >>> constraints MUST >>>>> be taken into account while SOME of the optional >>> constraints MAY be >>>>> taken into account >>>> >>>> No, all recognized and supported constraints MUST be taken into >>>> account during path computation, whatever the P flag value. >>> The P flag >>>> simply indicates what to do when a constraint is not >>>> recognized/unsupported. >>> >>> again call it I flag, point remains, a negative answer shall >>> come only from not finding a result from mandatory constraints >> >> Dimitri, please see my previous answer. I understand the semantic >> you define, it was discussed one year ago as part of a constraint >> relaxation thread (less constrained path), and the result of this >> thread was that there there was no consensus, some people were >> against, hence we removed the requirement from the generic PCECP >> req id, and also we removed text on less constrained path from the >> PCEP spec, and decided to address it latter. >> This should be defined in a separate ID once the requirement is >> clearly expressed. >> >> By the way there are various options for handling optional >> constraints and more generally constraint relaxation. For instance >> the PCC may also send two requests, one with only mandatory >> constraints and another with optional constraints... >> >>> >>> and a positive result may include more than the set of >>> mandatory constraints >> >> Ah, this is interesting...and what sub-set of optional constraints >> is selected if not all optional constaints can be satisfied? Again >> we are discussing constraint relaxation here and this is beyond the >> scope of this doc... >> >>> >>> the fact that an error is issued should then be the result of >>> the non-support of a mandatory constraint >> >> Yes, indeed this is current P flag processing >> >> >>> >>> all together this makes one flag - and this only because >>> there is a difference between optional object support and >>> optional processing >>> >>>>> hence one could consider that list in the reply corresponds to the >>>>> list of considered constraints and since the requestor knows these >>>>> are optional or not there is no need for a second flag - this >>>>> prevents back tracking of optional information - and restrict >>>>> confirmation to the mandatory constraints >>>>> >>>>> ps: are you serious when considering a message length of 2^32 ? >>>> >>>> Yes, 2^16 may not be enought, think about an NMS that would send a >>>> request for tens of thousands of LSPs. >>> >>> what does make the NMS PCC different from an LSR ? >> >> Please keep it simple, you were asking why do we need 2^32, and >> I answered that 2^16 may not be enough, and I took, as pure >> illustration, the example of an NMS acting as PCC, and sending a >> PCReq for a synchronized path computation of tens of K LSPs, ie a >> PCReq with tens of K requests (I simply took the example of NMS >> PCC, as an NMS is likely to request synchronized path computation >> of many more LSPs, than an LSR would do). >> >>> i think >>> there is a difference between the set of command issued to >>> the NMS and the resulting set of PCC requests an NMS will generate >> >> Who says the contrary? And what is the point here? >> >> Thanks, >> >> JL >> >> >>> >>> thanks, >>> - dimitri. >>> >>>> Thanks, >>>> >>>> JL >>>> >>>> >>>>> thanks, - dimitri. >>>>> >>>>> >>>>> >>>>> >>>>> Igor Bryskin wrote: >>>>> >>>>>> Hi JL, >>>>>> >>>>>> I have a question. Suppose, a path computation request has >>>>> >>>>> two constraints: >>>>> >>>>>> link colors and link bandwidth. Suppose the path >>> computation fails. >>>>>> The question is how the PCE can figure out what is the >>>>> >>>>> reason of this >>>>> >>>>>> computation failure? As an implementer of a Path >>>>> >>>>> Computation Engine I >>>>> >>>>>> always found it a difficult problem. Normally, presented >>>>> >>>>> with a path >>>>> >>>>>> computation request with link type constraints as in the >>>>> >>>>> example I am >>>>> >>>>>> describing, a PCE would prune out the arcs form the >>> network graph >>>>>> associated with links that do not satisfy at least one of the >>>>>> constraints, and after that run some algorithm. If the >>>>> >>>>> algorithm fails >>>>> >>>>>> the only thing is clear that there are no links with >>> proper colors >>>>>> that have enough bandwidth, that is, entire set of >>>>> >>>>> constraints cannot >>>>> >>>>>> be satisfied. But it is impossible to say which constraint in >>>>>> particular has caused the failure. Even if you start removing >>>>>> constraints one by one and rerunning the algorithm (which >>> would be >>>>>> very unpractical to do), you will find out that it does not >>>>> >>>>> help. The path computation of the example may succeed in >>> both these >>>>> iterations because: >>>>> >>>>>> a) there are links with proper colors; b) there are links with >>>>>> enough bandwidth. >>>>>> >>>>>> The bottom line is that path computation fails because of >>>>> >>>>> the entire >>>>> >>>>>> set of constraints rather than because of one or several of >>>>> >>>>> them, and >>>>> >>>>>> it is unrealistic to think that PCE in its negative reply >>>>> >>>>> would mark >>>>> >>>>>> constraints which cause the failure. >>>>>> >>>>>> So, I recommend to have two flags (say, P and I). One of >>>>> >>>>> them should >>>>> >>>>>> be used to mark mandatory constraints, while another - >>>>> >>>>> optional constraints. >>>>> >>>>>> Recommend to make an assumption that PCE will run path >>>>> >>>>> computation at >>>>> >>>>>> most two times: >>>>>> >>>>>> 1) trying to accommodate all constraints; 2) in case 1) fails, >>>>>> removing all optional constraints >>>>>> >>>>>> PCE should return: >>>>>> >>>>>> a) successful response without flags when 1) succeeds; b) >>>>>> successful response with flag I when 2) succeeds; 3) negative >>>>>> response with no flags when 2 fails. >>>>>> >>>>>> Igor >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- From: "LE ROUX Jean-Louis >>> RD-CORE-LAN" >>>>>> To: >>>>>> ; ; >>>>>> Sent: Friday, July 14, 2006 10:46 AM Subject: RE: >>>>>> [Pce] P & I flags >>>>>> >>>>>> >>>>>> Hi Dimitri, >>>>>> >>>>>> >>>>>> >>>>>>> -----Message d'origine----- De : dimitri papadimitriou >>>>>>> [mailto:dpapadimitriou@psg.com] Envoy=E9 : vendredi 14 juillet >>>>>>> 2006 15:44 =C0 : pce@ietf.org Objet : [Pce] P & I flags >>>>>>> >>>>>>> the comments around the P and I flags are >>>>>>> >>>>>>> o) we have two levels of optionality in listing the >>> protocol object >>>>>>> and usage level of the protocol object - however it is much more >>>>>>> appropriate to be sure that mandatory constraints have >>> been taken >>>>>>> rather than having the optional having been taken into account >>>>>> >>>>>> >>>>>> As clearly pointed out in the same setion of the draft, if >>>>> >>>>> a mandatory >>>>> >>>>>> constraint cannot be handled the PCE replies with PCErr message >>>>>> >>>>>> "If the PCE does not understand an object with the P Flag set or >>>>>> understands the object but decides to ignore the object, >>>>> >>>>> the entire >>>>> >>>>>> PCEP message MUST be rejected and the PCE MUST send a >>>>> >>>>> PCErr message >>>>> >>>>>> with Error-Type=3D"Unknown Object" or "Not supported Object". >>>>>> >>>>>> If the PCE can handle all mandatory constraints it >>> replies with a >>>>>> PCRep message (either positive or negative if there is no >>>>> >>>>> path), else >>>>> >>>>>> it sends a PCErr message. Hence the PCC knows whether mandatory >>>>>> constraints have been >>>>> >>>>> taken into >>>>> >>>>>> account. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> P flag (Processing-Rule - 1-bit): the P flag allows a PCC to >>>>>>> specify in a PCReq message sent to a PCE whether the object >>>>> >>>>> must be taken >>>>> >>>>>>> into account by the PCE during path computation or is just >>>>>>> optional. When the P flag is set, the object MUST be taken into >>>>>>> >>>>> >>>>> account by >>>>> >>>>>>> the PCE. Conversely, when the P flag is cleared, the object is >>>>>>> optional and the PCE is free to ignore it if not supported. >>>>>>> >>>>>>> o) on the I flag issue is identical why include an >>> object which has >>>>>>> not considered during computation ? >>>>>> >>>>>> >>>>>> I don't catch your point, the PCC may want to know the >>> constraints >>>>>> that were not taken into account during path computation, >>>>> >>>>> this sounds >>>>> >>>>>> quite important isn'it? >>>>>> >>>>>> >>>>>> there are so >>>>>> >>>>>> >>>>>>> many things that the PCE has not taken into account during >>>>> >>>>> computation >>>>> >>>>>>> so why bother ? >>>>>> >>>>>> >>>>>> Hum I don't follow you here "there are so many things...", >>>>> >>>>> What do you mean? >>>>> >>>>>> >>>>>> >>>>>>> it is imho more important to include the mandatory >>> object not taken >>>>>>> into account >>>>>> >>>>>> >>>>>> If a mandatory object is not taken into account, you >>> cannot compute >>>>>> the path and you send an error message. I agree with you >>> that this >>>>>> would be useful to include within the PCErr the set of >>> objects not >>>>>> supported, this can be clarified in next revision. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep >>>>>>> message to indicate to a PCC whether or not an optional >>>>> >>>>> object was >>>>> >>>>>>> processed. The PCE MAY include the ignored optional >>>>> >>>>> object in its >>>>> >>>>>>> reply and set the I flag to indicate that the optional >>>>> >>>>> object was >>>>> >>>>>>> ignored during path computation. When the I flag is >>>>> >>>>> cleared, the >>>>> >>>>>>> PCE indicates that the optional object was processed during the >>>>>>> path computation. The setting of the I flag for >>> optional objects >>>>>>> is purely indicative and optional. The I flag MUST be >>>>>>> >>>>> >>>>> cleared if the >>>>> >>>>>>> P flag is set. >>>>>>> >>>>>>> o) the result of all these flags is that a PCC can be >>>>> >>>>> wrapping around >>>>> >>>>>>> unknown constraints create processing churn on the PCE; >>>>>> >>>>>> >>>>>> OK, if you mean that we should include the unsupported object(s) >>>>>> within the PCErr, then we are in sync >>>>>> >>>>>> Thanks for the comment >>>>>> >>>>>> Regards >>>>>> >>>>>> JL >>>>>> >>>>>> >>>>>> >>>>>>> If the PCE does not understand an object with the P Flag set or >>>>>>> understands the object but decides to ignore the object, >>> the entire >>>>>>> PCEP message MUST be rejected and the PCE MUST send a >>> PCErr message >>>>>>> with Error-Type=3D"Unknown Object" or "Not supported Object". >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ 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 Sat Jul 22 07:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4Fc3-0006wj-Q5; Sat, 22 Jul 2006 07:25:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4Fc2-0006wd-FT for pce@ietf.org; Sat, 22 Jul 2006 07:25:38 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4Fc1-0001PJ-7z for pce@ietf.org; Sat, 22 Jul 2006 07:25:38 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2006 07:25:37 -0400 X-IronPort-AV: i="4.07,170,1151899200"; d="scan'208"; a="93540536:sNHT22253008" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6MBPb9a000746; Sat, 22 Jul 2006 07:25:37 -0400 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 k6MBPadU004426; Sat, 22 Jul 2006 07:25:36 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Jul 2006 07:25:36 -0400 Received: from [192.168.1.102] ([10.86.240.64]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Jul 2006 07:25:35 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Sat, 22 Jul 2006 13:25:34 +0200 To: pce@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Jul 2006 11:25:36.0001 (UTC) FILETIME=[8D525F10:01C6AD81] DKIM-Signature: a=rsa-sha1; q=dns; l=114; t=1153567537; x=1154431537; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:IETF-66=20PCE=20WG=20Meeting=20 |To:pce@ietf.org; X=v=3Dcisco.com=3B=20h=3DuEszzro4X8vZ6M6t6gpmCzQMLZA=3D; b=CXpv9pmN1iwsv+1+JT0T9nRA+1zUsGe3zEzzwnjp0S550JGtzhjHMwwAtiCL4DM7CdCFpuU2 EQJa9/5bss1AKgQ1B0Luadpg/sYGoIH3HNodpBJ5Y4x0QXdIr392Uzbh; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Pce] IETF-66 PCE WG Meeting 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 presentations are now uploaded. Draft minutes for review will be published soon. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jul 26 07:48:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hrr-0002c3-P3; Wed, 26 Jul 2006 07:47:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hrp-0002bl-Ln for pce@ietf.org; Wed, 26 Jul 2006 07:47:57 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5hrn-0003MM-IQ for pce@ietf.org; Wed, 26 Jul 2006 07:47:57 -0400 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.13.7/8.13.7) with ESMTP id k6QBlrfK007067; Wed, 26 Jul 2006 20:47:53 +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.13.7/8.13.7) with ESMTP id k6QBlqum024031; Wed, 26 Jul 2006 20:47:52 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k6QBlpMc026668; Wed, 26 Jul 2006 20:47:51 +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.13.7/8.13.7) with ESMTP id k6QBlpME022786; Wed, 26 Jul 2006 20:47:51 +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 k6QBloXR029178; Wed, 26 Jul 2006 20:47:50 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k6QBloC2029175; Wed, 26 Jul 2006 20:47:50 +0900 (JST) Received: from [129.60.80.109] ([129.60.80.109]) by imb.m.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k6QBlo4h018343; Wed, 26 Jul 2006 20:47:50 +0900 (JST) Date: Wed, 26 Jul 2006 20:47:46 +0900 From: Eiji Oki To: Adrian Farrel Subject: Re: [Pce] Poll on three new working group I-Ds In-Reply-To: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> References: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> Message-Id: <20060726204709.501A.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: 8b431ad66d60be2d47c7bfeb879db82c 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 Yes to all. Eiji On Wed, 19 Jul 2006 15:08:22 +0100 "Adrian Farrel" wrote: > Hi, > > Resulting from the discussions in Montreal, we would like to take your > opinions on the adoption of three I-Ds as working group drafts. > > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS scenario. It > has been refined considerably over the last couple of iterations and is now > limited to just the requirements for this situation. We may need to do more > work on it as a WG document, but the authors and chairs believe it is in > good enough shape to be the basis of the WG work. > > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document fleshes out the > details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait to include > details of policy for recovery path computation, but the chairs feel that > this scenarion (and any other relevant scenarios) can be safely added once > the I-D is a working group draft. Further, there was support from the > service providers in the room in Montreal for adopting this I-D. > > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the inter-domain > case. > There has been some discussion of this draft on the mailing list resulting > in the request for a few clarifications of scope and procedure, and also an > explicit mention of the Path Key ID option. > Since JP is the lead author on this work, I think that the correct procedure > is for JP to make a quick update before this becomes a WG I-D, but while we > are polling I would like to ask your opinion on this I-D assuming that JP > makes the necessary changes. > > Simple Yes and No answers will do, but reasons are always helpful. > > Cheers, > Adrian > > > > _______________________________________________ > 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 Jul 26 11:44:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lYL-0008MX-ES; Wed, 26 Jul 2006 11:44:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lYJ-0008J2-Th for pce@ietf.org; Wed, 26 Jul 2006 11:44:03 -0400 Received: from smtp.polymtl.ca ([132.207.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5lYI-00051M-Iy for pce@ietf.org; Wed, 26 Jul 2006 11:44:03 -0400 Received: from localhost (imp-4-3.polymtl.ca [132.207.4.78]) by smtp.polymtl.ca (8.13.6/8.13.6) with ESMTP id k6QFi1Df008198; Wed, 26 Jul 2006 11:44:01 -0400 Received: from lmcprb.ericsson.ca (lmcprb.ericsson.ca [192.75.88.232]) by www.imp.polymtl.ca (IMP) with HTTP for ; Wed, 26 Jul 2006 11:44:00 -0400 Message-ID: <1153928640.44c78dc0c5415@www.imp.polymtl.ca> Date: Wed, 26 Jul 2006 11:44:00 -0400 From: Meral Shirazipour To: Adrian Farrel Subject: Re: [Pce] Poll on three new working group I-Ds References: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> In-Reply-To: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 192.75.88.232 X-Poly-FromMTA: (imp-4-3.polymtl.ca [132.207.4.78]) at Wed, 26 Jul 2006 15:44:01 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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, Yes to all 3 I-Ds. I think the authors of ***.interas-pcecp-reqs-01.txt should work more closely with the work done in ***.pce-policy-enabled-path-comp-02.txt. Cheers, Meral Selon Adrian Farrel : > Hi, > > Resulting from the discussions in Montreal, we would like to take your > opinions on the adoption of three I-Ds as working group drafts. > > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS scenario. It > has been refined considerably over the last couple of iterations and is now > limited to just the requirements for this situation. We may need to do more > work on it as a WG document, but the authors and chairs believe it is in > good enough shape to be the basis of the WG work. > > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document fleshes out the > details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait to include > details of policy for recovery path computation, but the chairs feel that > this scenarion (and any other relevant scenarios) can be safely added once > the I-D is a working group draft. Further, there was support from the > service providers in the room in Montreal for adopting this I-D. > > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the inter-domain > case. > There has been some discussion of this draft on the mailing list resulting > in the request for a few clarifications of scope and procedure, and also an > explicit mention of the Path Key ID option. > Since JP is the lead author on this work, I think that the correct procedure > is for JP to make a quick update before this becomes a WG I-D, but while we > are polling I would like to ask your opinion on this I-D assuming that JP > makes the necessary changes. > > Simple Yes and No answers will do, but reasons are always helpful. > > Cheers, > Adrian > > > > _______________________________________________ > 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 Thu Jul 27 11:21:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67g4-0003Yi-Ne; Thu, 27 Jul 2006 11:21:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67g3-0003Yd-3B for pce@ietf.org; Thu, 27 Jul 2006 11:21:31 -0400 Received: from athena.kddi.com ([210.141.112.39] helo=UTMC1103.kddi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G67g1-0000yl-KU for pce@ietf.org; Thu, 27 Jul 2006 11:21:31 -0400 Received: from usjk1038 (unknown [10.5.16.70]) by UTMC1103.kddi.com (Postfix) with SMTP id 48B8924FD for ; Fri, 28 Jul 2006 00:21:27 +0900 (JST) Received: from UTMC1123.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 294441BB3 for ; Fri, 28 Jul 2006 00:21:20 +0900 (JST) Received: from UTMC1116.kddi.com (unknown [10.5.16.25]) by UTMC1123.kddi.com (Postfix) with ESMTP id 109391B3C for ; Fri, 28 Jul 2006 00:21:20 +0900 (JST) Received: from [127.0.0.1] ([133.128.75.148] [133.128.75.148]) by post-ims.kddi.com with ESMTP; Fri, 28 Jul 2006 00:21:19 +0900 Date: Fri, 28 Jul 2006 00:21:18 +0900 From: Kenji Kumaki To: Subject: Re: [Pce] Poll on three new working group I-Ds In-Reply-To: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> References: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> Message-Id: <20060728002045.54AB.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-WAuditID: 0607280021200000126584 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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, Yes to all 3. Thanks, Kenji On Wed, 19 Jul 2006 15:08:22 +0100 "Adrian Farrel" wrote: > Hi, > > Resulting from the discussions in Montreal, we would like to take your > opinions on the adoption of three I-Ds as working group drafts. > > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS scenario. It > has been refined considerably over the last couple of iterations and is now > limited to just the requirements for this situation. We may need to do more > work on it as a WG document, but the authors and chairs believe it is in > good enough shape to be the basis of the WG work. > > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document fleshes out the > details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait to include > details of policy for recovery path computation, but the chairs feel that > this scenarion (and any other relevant scenarios) can be safely added once > the I-D is a working group draft. Further, there was support from the > service providers in the room in Montreal for adopting this I-D. > > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the inter-domain > case. > There has been some discussion of this draft on the mailing list resulting > in the request for a few clarifications of scope and procedure, and also an > explicit mention of the Path Key ID option. > Since JP is the lead author on this work, I think that the correct procedure > is for JP to make a quick update before this becomes a WG I-D, but while we > are polling I would like to ask your opinion on this I-D assuming that JP > makes the necessary changes. > > Simple Yes and No answers will do, but reasons are always helpful. > > Cheers, > Adrian > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce -- Kenji Kumaki _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jul 27 16:22:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CNj-00088R-U8; Thu, 27 Jul 2006 16:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CNh-00088M-U0 for pce@ietf.org; Thu, 27 Jul 2006 16:22:53 -0400 Received: from fujitsu0.fujitsu.com ([192.240.0.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6CNg-0000D8-H7 for pce@ietf.org; Thu, 27 Jul 2006 16:22:53 -0400 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6RKMp5U022488; Thu, 27 Jul 2006 13:22:51 -0700 (PDT) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6RKMaTs022449; Thu, 27 Jul 2006 13:22:47 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.7/8.13.7) with ESMTP id k6RKMaV6022081; Thu, 27 Jul 2006 13:22:36 -0700 (PDT) Received: from [133.164.4.31] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k6RKMVw00417; Thu, 27 Jul 2006 13:22:35 -0700 (PDT) Message-ID: <44C92085.5070104@us.fujitsu.com> Date: Thu, 27 Jul 2006 13:22:29 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Poll on three new working group I-Ds References: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> In-Reply-To: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Adrian, see inline. Adrian Farrel wrote: > Hi, > > Resulting from the discussions in Montreal, we would like to take your > opinions on the adoption of three I-Ds as working group drafts. > > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS scenario. > It has been refined considerably over the last couple of iterations > and is now limited to just the requirements for this situation. We may > need to do more work on it as a WG document, but the authors and > chairs believe it is in good enough shape to be the basis of the WG work. Yes > > > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document fleshes > out the details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait to include > details of policy for recovery path computation, but the chairs feel > that this scenarion (and any other relevant scenarios) can be safely > added once the I-D is a working group draft. Further, there was > support from the service providers in the room in Montreal for > adopting this I-D. Yes, except that its category should be Informational. This is the first framework document that I've seen that's standards track. > > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the > inter-domain case. > There has been some discussion of this draft on the mailing list > resulting in the request for a few clarifications of scope and > procedure, and also an explicit mention of the Path Key ID option. > Since JP is the lead author on this work, I think that the correct > procedure is for JP to make a quick update before this becomes a WG > I-D, but while we are polling I would like to ask your opinion on this > I-D assuming that JP makes the necessary changes. Yes > > Simple Yes and No answers will do, but reasons are always helpful. > > Cheers, > Adrian > > > > _______________________________________________ > 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 Thu Jul 27 18:48:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Eeu-0008Fl-SF; Thu, 27 Jul 2006 18:48:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hk0-0007aE-Q6 for pce@ietf.org; Wed, 26 Jul 2006 07:39:52 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5hjx-0001D7-5D for pce@ietf.org; Wed, 26 Jul 2006 07:39:52 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 13:39:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Jul 2006 13:39:46 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603AF5448@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: MPLS 2006 International Conference program Thread-Index: AcawqDGfaBwckss6T+GrytZqznUARA== From: "MOIGNARD Renaud RD-CORE-LAN" Bcc: X-OriginalArrivalTime: 26 Jul 2006 11:39:47.0956 (UTC) FILETIME=[32C76340:01C6B0A8] X-Spam-Score: 0.5 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac X-Mailman-Approved-At: Thu, 27 Jul 2006 18:48:47 -0400 Subject: [Pce] MPLS 2006 International Conference program 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="===============0421049361==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0421049361== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C6B0A8.321FF680" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6B0A8.321FF680 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6B0A8.321FF680" ------_=_NextPart_002_01C6B0A8.321FF680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MPLS 2006 International Conference Omni Shoreham Hotel, Washington DC, October 15-18, 2006,=20 http://www.mpls2006.com/ =20 You are cordially invited to attend the MPLS 2006 International Conference to be held in Washington, DC from October 15-18, 2006. The 4-day event consists of highly technical sessions, tutorials, panel discussions, and exhibits. Program details are available at: =20 http://www.mpls2006.com/program.htm =20 Registration for the conference is now open. Early registration discounts are highly attractive and are valid for a limited time only. To register, go to: http://www.mpls2006.com/onlineregis.htm =20 To make reservations at the Omni Shoreham Hotel, please call the Hotel Reservation Desk directly. You must identify yourself as MPLS 2006 conference attendees for discounted rates. Or, go to=20 www.omnishorehamhotle.com and at the bottom of the page enter 12400606975 for the group code. By phone, please call the Hotel Reservation Desk directly (1-800-843-6664 or 202-265-7972). You must identify yourself as MPLS 2006 conference attendee for discounted rates. Please note Reservation may be accepted only subject to space availability. Important Dates: ------------------------ - Early Registration Rates Cut-Off Date: August 1, 2006 - Tutorials: Sunday, October 15, 10:30 am - 6:00 pm - Technical Sessions: Monday-Wednesday, October 16-18, 8:30 am - 6:00 pm - Breaks & Exhibits: Monday, October 16th - Wednesday, October 18th=20 - 7th Public Interoperability Demonstration: October 19th, 11:00 am =20 =20 Renaud Moignard France Telecom R&D Division=20 renaud.moignard@orange-ft.com =20 =20 ------_=_NextPart_002_01C6B0A8.321FF680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MPLS=20 2006 International Conference

Omni Shoreham Hotel, Washington DC, October 15-18, 2006,=20 http://www.mpls2006.com/=

You are cordially invited to = attend the=20 MPLS 2006 International Conference to be held in Washington, DC=20 from October 15-18, 2006. The 4-day event consists of highly technical = sessions,=20 tutorials, panel discussions, and exhibits.  Program details are = available=20 at:  http://www.mpls2006.com/p= rogram.htm

 Registration for the=20 conference is now open. Early registration discounts are highly = attractive and=20 are valid for a limited time only. To register, go to:  http://www.mpls2006.c= om/onlineregis.htm

To make reservations at the Omni = Shoreham Hotel,=20 please call the Hotel Reservation Desk directly. You=20 must identify yourself as MPLS 2006 conference attendees for discounted=20 rates.  Or, go = to www.omnishorehamhotle.com=20 and at the bottom of the page enter 12400606975 = for the=20 group code.  By phone, please call the Hotel Reservation Desk=20 directly (1-800-843-6664 or 202-265-7972). You = must=20 identify yourself as MPLS 2006 conference attendee for discounted rates. = Please=20 note Reservation may be accepted only subject to space=20 availability.

Important Dates:

------------------------

- Early Registration Rates Cut-Off Date: = August 1,=20 2006

- Tutorials: Sunday, October 15, 10:30 am - = 6:00=20 pm

- Technical Sessions: Monday-Wednesday, October 16-18, 8:30 am = - 6:00=20 pm   

-=20 Breaks & Exhibits: = Monday, October 16th – = Wednesday, October=20 18th

-=20 7th Public Interoperability Demonstration: October=20 19th, 11:00 am

 

Renaud=20 Moignard
France Telecom R&D Division
renaud.moignard@orange-ft.c= om

 
------_=_NextPart_002_01C6B0A8.321FF680-- ------_=_NextPart_001_01C6B0A8.321FF680 Content-Type: image/gif; name="orange_logo.gif" Content-Transfer-Encoding: base64 Content-Description: orange_logo.gif Content-Location: http://www.francetelecom.com/sirius/logos_mail/orange_logo.gif R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9ZAP/6 9v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/UuP9xF/+/ lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9lAv+cXf/IpP/8 +v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+ALf9zGv+1h//w5v/u 4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9vEv+zhf9aAP91JP/07P/D nf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9iCv+ocv+QSv/Zwv/AmP+8j/+d Xv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9nA/9eBP/bw//aw//k1P+STf/r3f/n 1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/XvP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/h zv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9lAf9yFv+pcf94KP+xe//Yv/94If9pCv+COf+Z Vf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9oA//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+ K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+XVf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8 kQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgA AAj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQ AQYQCEBAZABOUnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAU INBpABIPqmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBn yQIMClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0WUCUE lMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCHAMEwIcAO OQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhhCQO8THCJDsIU NRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7GFEQhR6yCSQc1HeUR XKSMEKdCAQEAOw== ------_=_NextPart_001_01C6B0A8.321FF680 Content-Type: image/gif; name="ampersand.gif" Content-Transfer-Encoding: base64 Content-Description: ampersand.gif Content-Location: http://www.francetelecom.com/sirius/logos_mail/ampersand.gif R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91AO51 APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x9/7x9vnG k/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P769falofzjyvjB ivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnNnuo0MeszN/e7gP3r 2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxNQ+onK/zm0egaGe5rCvKX OukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvjyvFzdPKQLfCADOgUFPjHkvKN Jv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOklGuszK/rbue9ZW/739uoyMv3w4/jH ju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rKy//8/PKZPO9nZ+5OUf759O9xAPjCi+5R SPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucL C/B/DPrNzvnEu/a2dffBffOEhvaipv738O1RTvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQA AAj/AAEIHDgwlYgsTaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYC R06iMgVLIKUdD7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQc IEJlYSFSpQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUB VAyBUQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAAOw== ------_=_NextPart_001_01C6B0A8.321FF680-- --===============0421049361== 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 --===============0421049361==-- From pce-bounces@lists.ietf.org Thu Jul 27 18:48:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Eev-0008Fq-2O; Thu, 27 Jul 2006 18:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ugJ-0001xm-3W for pce@ietf.org; Wed, 26 Jul 2006 21:28:55 -0400 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ugI-0001tQ-LS for pce@ietf.org; Wed, 26 Jul 2006 21:28:55 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id E18E5ECA02; Thu, 27 Jul 2006 10:28:49 +0900 (JST) Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [2001:200:601:1a00::10]) by mandala.kddilabs.jp (Postfix) with ESMTP id CC3FEECA00; Thu, 27 Jul 2006 10:28:48 +0900 (JST) Received: from [IPv6:2001:200:601:1e02:0:5efe:ac13:5710] (unknown [IPv6:2001:200:601:1e02:0:5efe:ac13:5710]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id BFEDC1E0002; Thu, 27 Jul 2006 10:28:48 +0900 (JST) Message-ID: <44C816D2.7080901@kddilabs.jp> Date: Thu, 27 Jul 2006 10:28:50 +0900 From: Kenji Kumaki User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: pce@ietf.org Subject: Re: [Pce] Poll on three new working group I-Ds References: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> In-Reply-To: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Thu, 27 Jul 2006 18:48:48 -0400 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 Yes to all 3. Kenji Adrian Farrel wrote: > Hi, > > Resulting from the discussions in Montreal, we would like to take your > opinions on the adoption of three I-Ds as working group drafts. > > draft-bitar-zhang-interas-pcecp-reqs-01.txt > This draft sets out the requirements for PCEP in an inter-AS scenario. > It has been refined considerably over the last couple of iterations and > is now limited to just the requirements for this situation. We may need > to do more work on it as a WG document, but the authors and chairs > believe it is in good enough shape to be the basis of the WG work. > > draft-bryskin-pce-policy-enabled-path-comp-02.txt > Policy forms part of the PCE architecture, and this document fleshes out > the details of the use of policy in a PCE context. > There was some discussion in Montreal about whether to wait to include > details of policy for recovery path computation, but the chairs feel > that this scenarion (and any other relevant scenarios) can be safely > added once the I-D is a working group draft. Further, there was support > from the service providers in the room in Montreal for adopting this I-D. > > draft-vasseur-pce-brpc-00.txt > This draft describes an application procedure for PCE in the > inter-domain case. > There has been some discussion of this draft on the mailing list > resulting in the request for a few clarifications of scope and > procedure, and also an explicit mention of the Path Key ID option. > Since JP is the lead author on this work, I think that the correct > procedure is for JP to make a quick update before this becomes a WG I-D, > but while we are polling I would like to ask your opinion on this I-D > assuming that JP makes the necessary changes. > > Simple Yes and No answers will do, but reasons are always helpful. > > Cheers, > Adrian > > > > _______________________________________________ > 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 Fri Jul 28 00:04:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6JaG-0004RX-PP; Fri, 28 Jul 2006 00:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6JaF-0004PB-Cz for pce@ietf.org; Fri, 28 Jul 2006 00:04:19 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6JaD-0007rX-Ia for pce@ietf.org; Fri, 28 Jul 2006 00:04:19 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3300NCEI6I2O@szxga03-in.huawei.com> for pce@ietf.org; Fri, 28 Jul 2006 12:08:43 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J33002UKI6I6X@szxga03-in.huawei.com> for pce@ietf.org; Fri, 28 Jul 2006 12:08:42 +0800 (CST) Received: from z18605 ([10.111.12.103]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3300DA0HUTIT@szxml03-in.huawei.com> for pce@ietf.org; Fri, 28 Jul 2006 12:01:42 +0800 (CST) Date: Fri, 28 Jul 2006 11:58:45 +0800 From: ZhangRenhai Subject: re: [Pce] Poll on three new working group I-Ds In-reply-to: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> To: 'Adrian Farrel' , pce@ietf.org Message-id: <002b01c6b1fa$2023b830$670c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcarQMBZGlZmI2xsSlWxVNwOXX5KpwGuTEwg X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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, Yes to all. Cheers, Zhang Renhai Hi, Resulting from the discussions in Montreal, we would like to take your opinions on the adoption of three I-Ds as working group drafts. draft-bitar-zhang-interas-pcecp-reqs-01.txt This draft sets out the requirements for PCEP in an inter-AS scenario. It has been refined considerably over the last couple of iterations and is now limited to just the requirements for this situation. We may need to do more work on it as a WG document, but the authors and chairs believe it is in good enough shape to be the basis of the WG work. draft-bryskin-pce-policy-enabled-path-comp-02.txt Policy forms part of the PCE architecture, and this document fleshes out the details of the use of policy in a PCE context. There was some discussion in Montreal about whether to wait to include details of policy for recovery path computation, but the chairs feel that this scenarion (and any other relevant scenarios) can be safely added once the I-D is a working group draft. Further, there was support from the service providers in the room in Montreal for adopting this I-D. draft-vasseur-pce-brpc-00.txt This draft describes an application procedure for PCE in the inter-domain case. There has been some discussion of this draft on the mailing list resulting in the request for a few clarifications of scope and procedure, and also an explicit mention of the Path Key ID option. Since JP is the lead author on this work, I think that the correct procedure is for JP to make a quick update before this becomes a WG I-D, but while we are polling I would like to ask your opinion on this I-D assuming that JP makes the necessary changes. Simple Yes and No answers will do, but reasons are always helpful. Cheers, Adrian _______________________________________________ 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 Jul 29 09:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6oWW-0005xS-Nt; Sat, 29 Jul 2006 09:06:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6oWV-0005xN-TH for pce@ietf.org; Sat, 29 Jul 2006 09:06:31 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6oWU-0000Ff-HV for pce@ietf.org; Sat, 29 Jul 2006 09:06:31 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G6oWQ-0002V3-00 for pce@ietf.org; Sat, 29 Jul 2006 14:06:26 +0100 Received: from your029b8cecfe ([217.158.132.152] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Jul 2006 14:06:24 +0100 Message-ID: <06b701c6b30f$a9fe3b50$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: References: <00cb01c6ab40$82498230$0a23fea9@your029b8cecfe> Date: Sat, 29 Jul 2006 11:30:26 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 29 Jul 2006 13:06:27.0524 (UTC) FILETIME=[CD33C040:01C6B30F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Pce] Three new working group I-Dss. 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 Hi, Looks like pretty good support for all three drafts from where I am standing. draft-bitar-zhang-interas-pcecp-reqs-01.txt Authors, please re-submit as draft-ietf-interas-pcecp-reqs-00.txt Please do not make any changes to the draft except for the name and the date draft-bryskin-pce-policy-enabled-path-comp-02.txt Authors, please re-submit as draft-ietf-pce-policy-enabled-path-comp-00.txt Please change the intended status to Informational draft-vasseur-pce-brpc-00.txt We have support for this becoming a WG I-D, but as discussed, JP will first make a quick update (not a WG I-D) to include the clarifications requested on the mailing list to cover scope and procedure, and also an explicit mention of the Path Key ID option. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce