From julien.meuric@orange-ftgroup.com Thu Apr 2 02:08:14 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363133A6A5F for ; Thu, 2 Apr 2009 02:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2WJO8hsMOBF for ; Thu, 2 Apr 2009 02:08:13 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id ACF6D3A6986 for ; Thu, 2 Apr 2009 02:07:54 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 11:07:53 +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 Date: Thu, 2 Apr 2009 11:07:51 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E918@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on WSON Requirements Thread-Index: AcmzcoBzpd1YmUR3RPSdD1xMIDk4sQ== From: To: X-OriginalArrivalTime: 02 Apr 2009 09:07:53.0231 (UTC) FILETIME=[813779F0:01C9B372] Cc: pce@ietf.org Subject: [Pce] Comment on WSON Requirements X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 09:08:14 -0000 Hi Young. This is a try to resume our discussion started during the SF meeting. = Indeed, I still don't get the rationale behind adding the BER as a = requirement for PCEP request. First, I wonder what your intend is when requesting a BER threshold at = computation time while you can't really know it before LSP provisioning. = Obviously, what we look for is a low BER, but the way I see using BER in = routing would be to request a 2nd route *after* a poor BER measurement = on a firstly established LSP. Then, considering what you called a "BER estimation", I don't clearly = see how you intend to estimate (or model?) it. The BER associated to an = LSP is highly dependent on so many parameters: link DGD at measurement = time, performance of the FEC used for the to-be-provisioned LSP , = possible cross-talk and thus impact of potential adjacent channels... = Furthermore, I don't really understand why focusing on the measurable = BER range while a typical PMD (in)accuracy may just move us between an = acceptable route and an unacceptable one, the latter being the very 1st = problem we should try to solve. Finally, I don't get the use of such feature. Even if we could, why = would I request a 10^(-6) maximum BER? I don't see any room for anything = else than "the best one", so do we really need something else? I tend to = see BER as a varying quality feed*back*, not as an indicator that we can = accurately target at routing time. I completely agree that PCEP must support optical requirements, but my = concern is to understand actual needs before loading the protocol. = Therefore, I look forward to reading some clarification on those issues. Best regards, Julien From ylee@huawei.com Thu Apr 2 12:06:07 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD74C3A6D2D for ; Thu, 2 Apr 2009 12:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EAQrUmcdWlh for ; Thu, 2 Apr 2009 12:06:06 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id D02E93A6A47 for ; Thu, 2 Apr 2009 12:06:06 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHH00090MFVPS@usaga02-in.huawei.com> for pce@ietf.org; Thu, 02 Apr 2009 12:07:07 -0700 (PDT) Received: from L73682 ([10.124.12.80]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHH00KORLCPCL@usaga02-in.huawei.com> for pce@ietf.org; Thu, 02 Apr 2009 11:43:37 -0700 (PDT) Date: Thu, 02 Apr 2009 13:43:37 -0500 From: Young Lee In-reply-to: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E918@ftrdmel2> To: julien.meuric@orange-ftgroup.com Message-id: <001c01c9b3c2$ef933880$500c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmzcoBzpd1YmUR3RPSdD1xMIDk4sQATeDYA References: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E918@ftrdmel2> Cc: pce@ietf.org Subject: Re: [Pce] Comment on WSON Requirements X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:06:07 -0000 Hi Julien, The reason why we put the BER threshold in the PCEP request is to "approximate" if the optical path in consideration would be "healthy" enough from the BER perspective. Please note that we have defined two different computation types of IA-PCE functions in the IA-WSON framework draft: (i) approximate approach; (ii) candidate approach. Approximate approach is a quick way of estimating the affects of impairment while the candidate approach is to give a list of acceptable paths with more thorough data/model. The BER can be estimated in various ways given the availability of other impairment parameters. In any IA-RWA (approximate) type computation where we are given impairment parameters to estimate the affects of impairments, we must use some threshold criteria to accept/reject paths. The BER parameter was our first attempt at providing some control over this criterion. Best Regards, Young -----Original Message----- From: julien.meuric@orange-ftgroup.com [mailto:julien.meuric@orange-ftgroup.com] Sent: Thursday, April 02, 2009 4:08 AM To: ylee@huawei.com Cc: pce@ietf.org Subject: Comment on WSON Requirements Hi Young. This is a try to resume our discussion started during the SF meeting. Indeed, I still don't get the rationale behind adding the BER as a requirement for PCEP request. First, I wonder what your intend is when requesting a BER threshold at computation time while you can't really know it before LSP provisioning. Obviously, what we look for is a low BER, but the way I see using BER in routing would be to request a 2nd route *after* a poor BER measurement on a firstly established LSP. Then, considering what you called a "BER estimation", I don't clearly see how you intend to estimate (or model?) it. The BER associated to an LSP is highly dependent on so many parameters: link DGD at measurement time, performance of the FEC used for the to-be-provisioned LSP , possible cross-talk and thus impact of potential adjacent channels... Furthermore, I don't really understand why focusing on the measurable BER range while a typical PMD (in)accuracy may just move us between an acceptable route and an unacceptable one, the latter being the very 1st problem we should try to solve. Finally, I don't get the use of such feature. Even if we could, why would I request a 10^(-6) maximum BER? I don't see any room for anything else than "the best one", so do we really need something else? I tend to see BER as a varying quality feed*back*, not as an indicator that we can accurately target at routing time. I completely agree that PCEP must support optical requirements, but my concern is to understand actual needs before loading the protocol. Therefore, I look forward to reading some clarification on those issues. Best regards, Julien From julien.meuric@orange-ftgroup.com Fri Apr 3 08:17:16 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0193A6A75 for ; Fri, 3 Apr 2009 08:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49Vkl89uVbao for ; Fri, 3 Apr 2009 08:17:16 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 84D983A6862 for ; Fri, 3 Apr 2009 08:17:14 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 17:18:15 +0200 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 Date: Fri, 3 Apr 2009 17:18:15 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026065ABAFB@ftrdmel2> In-Reply-To: <001c01c9b3c2$ef933880$500c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on WSON Requirements Thread-Index: AcmzcoBzpd1YmUR3RPSdD1xMIDk4sQATeDYAACo/F+A= References: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E918@ftrdmel2> <001c01c9b3c2$ef933880$500c7c0a@china.huawei.com> From: To: X-OriginalArrivalTime: 03 Apr 2009 15:18:15.0696 (UTC) FILETIME=[69404900:01C9B46F] Cc: pce@ietf.org Subject: Re: [Pce] Comment on WSON Requirements X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:17:16 -0000 Hi Young. If I understand correctly, your actual requirement is to find a "threshold criteria" to request a route that is "healthy enough" for the PCC. So why have you chosen the BER which more relative to a digital client layer? Why not considering a more optical criteria, like OSNR for instance? Have a good week-end, Julien -----Original Message----- From: Young Lee [mailto:ylee@huawei.com]=20 Hi Julien, The reason why we put the BER threshold in the PCEP request is to "approximate" if the optical path in consideration would be "healthy" enough from the BER perspective. Please note that we have defined two different computation types of IA-PCE functions in the IA-WSON framework draft: (i) approximate approach; (ii) candidate approach. Approximate approach is a quick way of estimating the affects of impairment while the candidate approach is to give a list of acceptable paths with more thorough data/model.=20 The BER can be estimated in various ways given the availability of other impairment parameters. In any IA-RWA (approximate) type computation where we are given impairment parameters to estimate the affects of impairments, we must use some threshold criteria to accept/reject paths. The BER parameter was our first attempt at providing some control over this criterion. Best Regards, Young -----Original Message----- From: julien.meuric@orange-ftgroup.com [mailto:julien.meuric@orange-ftgroup.com]=20 Hi Young. This is a try to resume our discussion started during the SF meeting. Indeed, I still don't get the rationale behind adding the BER as a requirement for PCEP request. First, I wonder what your intend is when requesting a BER threshold at computation time while you can't really know it before LSP provisioning. Obviously, what we look for is a low BER, but the way I see using BER in routing would be to request a 2nd route *after* a poor BER measurement on a firstly established LSP. Then, considering what you called a "BER estimation", I don't clearly see how you intend to estimate (or model?) it. The BER associated to an LSP is highly dependent on so many parameters: link DGD at measurement time, performance of the FEC used for the to-be-provisioned LSP , possible cross-talk and thus impact of potential adjacent channels... Furthermore, I don't really understand why focusing on the measurable BER range while a typical PMD (in)accuracy may just move us between an acceptable route and an unacceptable one, the latter being the very 1st problem we should try to solve. Finally, I don't get the use of such feature. Even if we could, why would I request a 10^(-6) maximum BER? I don't see any room for anything else than "the best one", so do we really need something else? I tend to see BER as a varying quality feed*back*, not as an indicator that we can accurately target at routing time. I completely agree that PCEP must support optical requirements, but my concern is to understand actual needs before loading the protocol. Therefore, I look forward to reading some clarification on those issues. Best regards, Julien From jonas.martensson@acreo.se Fri Apr 3 09:29:31 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372743A680D for ; Fri, 3 Apr 2009 09:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mvj-83jv8mj3 for ; Fri, 3 Apr 2009 09:29:30 -0700 (PDT) Received: from dkcphmx24.softcom.dk (dkcphmx24.softcom.dk [194.192.15.188]) by core3.amsl.com (Postfix) with ESMTP id 177773A6D39 for ; Fri, 3 Apr 2009 09:29:25 -0700 (PDT) Received: (qmail 32151 invoked by uid 74); 3 Apr 2009 16:30:26 -0000 Received: from mail.acreo.se (217.151.195.216) by dkcphmx24.softcom.dk (envelope-from ) with ESMTP. tag msg.1238776226.607275.24458 (Processed in 0.154075 secs); 03 Apr 2009 16:30:26 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by dkcphmx24.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by dkcphmx24.softcom.dk over TLS secured channel with (RC4-MD5 encrypted) ESMTPS; Fri, 03 Apr 2009 18:30:26 +0200 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Fri, 3 Apr 2009 18:30:26 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: "julien.meuric@orange-ftgroup.com" , "ylee@huawei.com" Date: Fri, 3 Apr 2009 18:30:24 +0200 Thread-Topic: Comment on WSON Requirements Thread-Index: AcmzcoBzpd1YmUR3RPSdD1xMIDk4sQATeDYAACo/F+AAAzingA== Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF437870105169F989D@acreoexc01.ad.acreo.se> References: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E918@ftrdmel2> <001c01c9b3c2$ef933880$500c7c0a@china.huawei.com> <7DBAFEC6A76F3E42817DF1EBE64CB026065ABAFB@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026065ABAFB@ftrdmel2> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] Comment on WSON Requirements X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:29:31 -0000 Hi Young and Julien, I missed this discussion in San Francisco but I tend to agree with (most of= ) Julien's comments. But if the PCE is expected to compute paths taking opt= ical impairments into account it makes sense for a PCC to be able to set a = "threshold" constraint, or minimum acceptable signal quality, although I fi= nd it a bit difficult to see under what circumstances anyone would be satis= fied with anything else than "virtually zero" BER (or "error-free") for an = optical path. In addition, some OSNR margin is usually required in order to= allow for aging and other effects. In this case I think it might be better= to specify the pre-FEC BER (or equivalent Q-factor if that sounds more rel= ated to the optical layer) and maybe in addition the desired OSNR margin. Regards, Jonas > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On=20 > Behalf Of julien.meuric@orange-ftgroup.com > Sent: den 3 april 2009 17:18 > To: ylee@huawei.com > Cc: pce@ietf.org > Subject: Re: [Pce] Comment on WSON Requirements >=20 > Hi Young. >=20 > If I understand correctly, your actual requirement is to find=20 > a "threshold criteria" to request a route that is "healthy=20 > enough" for the PCC. So why have you chosen the BER which=20 > more relative to a digital client layer? Why not considering=20 > a more optical criteria, like OSNR for instance? >=20 > Have a good week-end, >=20 > Julien >=20 >=20 > -----Original Message----- > From: Young Lee [mailto:ylee@huawei.com]=20 >=20 > Hi Julien, >=20 > The reason why we put the BER threshold in the PCEP request=20 > is to "approximate" if the optical path in consideration=20 > would be "healthy" > enough > from the BER perspective. Please note that we have defined=20 > two different computation types of IA-PCE functions in the=20 > IA-WSON framework draft: > (i) > approximate approach; (ii) candidate approach. Approximate=20 > approach is a quick way of estimating the affects of=20 > impairment while the candidate approach is to give a list of=20 > acceptable paths with more thorough data/model.=20 >=20 > The BER can be estimated in various ways given the=20 > availability of other impairment parameters. In any IA-RWA=20 > (approximate) type computation where we are given impairment=20 > parameters to estimate the affects of impairments, we must=20 > use some threshold criteria to accept/reject paths. The BER=20 > parameter was our first attempt at providing some control=20 > over this criterion. >=20 > Best Regards, > Young >=20 > -----Original Message----- > From: julien.meuric@orange-ftgroup.com > [mailto:julien.meuric@orange-ftgroup.com]=20 >=20 > Hi Young. >=20 > This is a try to resume our discussion started during the SF meeting. > Indeed, I still don't get the rationale behind adding the BER=20 > as a requirement for PCEP request. >=20 > First, I wonder what your intend is when requesting a BER=20 > threshold at computation time while you can't really know it=20 > before LSP provisioning. > Obviously, what we look for is a low BER, but the way I see=20 > using BER in routing would be to request a 2nd route *after*=20 > a poor BER measurement on a firstly established LSP. > Then, considering what you called a "BER estimation", I don't=20 > clearly see how you intend to estimate (or model?) it. The=20 > BER associated to an LSP is highly dependent on so many=20 > parameters: link DGD at measurement time, performance of the=20 > FEC used for the to-be-provisioned LSP , possible cross-talk=20 > and thus impact of potential adjacent channels... > Furthermore, I > don't really understand why focusing on the measurable BER=20 > range while a typical PMD (in)accuracy may just move us=20 > between an acceptable route and an unacceptable one, the=20 > latter being the very 1st problem we should try to solve. > Finally, I don't get the use of such feature. Even if we=20 > could, why would I request a 10^(-6) maximum BER? I don't see=20 > any room for anything else than "the best one", so do we=20 > really need something else? I tend to see BER as a varying=20 > quality feed*back*, not as an indicator that we can=20 > accurately target at routing time. >=20 > I completely agree that PCEP must support optical=20 > requirements, but my concern is to understand actual needs=20 > before loading the protocol. > Therefore, I look forward to reading some clarification on=20 > those issues. >=20 > Best regards, >=20 > Julien >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >=20 > = From ylee@huawei.com Fri Apr 3 09:59:31 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF183A6921 for ; Fri, 3 Apr 2009 09:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKmO0-rQ27gy for ; Fri, 3 Apr 2009 09:59:30 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id B572C3A6859 for ; Fri, 3 Apr 2009 09:59:30 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHJ00JAQB8W0Q@usaga04-in.huawei.com> for pce@ietf.org; Fri, 03 Apr 2009 12:00:33 -0500 (CDT) Received: from L73682 ([10.124.12.80]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHJ003I5B8VKT@usaga04-in.huawei.com> for pce@ietf.org; Fri, 03 Apr 2009 12:00:32 -0500 (CDT) Date: Fri, 03 Apr 2009 12:00:31 -0500 From: Young Lee In-reply-to: <1EC35EEAF3A9FA439C7D6AE45BF437870105169F989D@acreoexc01.ad.acreo.se> To: =?iso-8859-1?Q?'Jonas_M=E5rtensson'?= , julien.meuric@orange-ftgroup.com Message-id: <001601c9b47d$b2f126b0$500c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcmzcoBzpd1YmUR3RPSdD1xMIDk4sQATeDYAACo/F+AAAzingAABnvmg References: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E918@ftrdmel2> <001c01c9b3c2$ef933880$500c7c0a@china.huawei.com> <7DBAFEC6A76F3E42817DF1EBE64CB026065ABAFB@ftrdmel2> <1EC35EEAF3A9FA439C7D6AE45BF437870105169F989D@acreoexc01.ad.acreo.se> Cc: pce@ietf.org Subject: Re: [Pce] Comment on WSON Requirements X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:59:32 -0000 Hi Jonas and Julien, I was thinking PRE-FEC BER when I mentioned the BER threshold. I also = agree with Julien that we may need to specify other optical parameters such as OSNR margin. Regarding the BER threshold, please refer to G.698.1 and G.698.2 in which to discuss black link definition and optical parameters required. In particular, please read section 7.1.3 that discusses two = cases where Pre-FEC BER requirement.=20 Let's continue on the discussion. Thanks. Regards, Young -----Original Message----- From: Jonas M=E5rtensson [mailto:Jonas.Martensson@acreo.se]=20 Sent: Friday, April 03, 2009 11:30 AM To: julien.meuric@orange-ftgroup.com; ylee@huawei.com Cc: pce@ietf.org Subject: RE: Comment on WSON Requirements Hi Young and Julien, I missed this discussion in San Francisco but I tend to agree with (most = of) Julien's comments. But if the PCE is expected to compute paths taking optical impairments into account it makes sense for a PCC to be able to = set a "threshold" constraint, or minimum acceptable signal quality, although = I find it a bit difficult to see under what circumstances anyone would be satisfied with anything else than "virtually zero" BER (or "error-free") = for an optical path. In addition, some OSNR margin is usually required in = order to allow for aging and other effects. In this case I think it might be better to specify the pre-FEC BER (or equivalent Q-factor if that sounds more related to the optical layer) and maybe in addition the desired = OSNR margin. Regards, Jonas > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On=20 > Behalf Of julien.meuric@orange-ftgroup.com > Sent: den 3 april 2009 17:18 > To: ylee@huawei.com > Cc: pce@ietf.org > Subject: Re: [Pce] Comment on WSON Requirements >=20 > Hi Young. >=20 > If I understand correctly, your actual requirement is to find=20 > a "threshold criteria" to request a route that is "healthy=20 > enough" for the PCC. So why have you chosen the BER which=20 > more relative to a digital client layer? Why not considering=20 > a more optical criteria, like OSNR for instance? >=20 > Have a good week-end, >=20 > Julien >=20 >=20 > -----Original Message----- > From: Young Lee [mailto:ylee@huawei.com]=20 >=20 > Hi Julien, >=20 > The reason why we put the BER threshold in the PCEP request=20 > is to "approximate" if the optical path in consideration=20 > would be "healthy" > enough > from the BER perspective. Please note that we have defined=20 > two different computation types of IA-PCE functions in the=20 > IA-WSON framework draft: > (i) > approximate approach; (ii) candidate approach. Approximate=20 > approach is a quick way of estimating the affects of=20 > impairment while the candidate approach is to give a list of=20 > acceptable paths with more thorough data/model.=20 >=20 > The BER can be estimated in various ways given the=20 > availability of other impairment parameters. In any IA-RWA=20 > (approximate) type computation where we are given impairment=20 > parameters to estimate the affects of impairments, we must=20 > use some threshold criteria to accept/reject paths. The BER=20 > parameter was our first attempt at providing some control=20 > over this criterion. >=20 > Best Regards, > Young >=20 > -----Original Message----- > From: julien.meuric@orange-ftgroup.com > [mailto:julien.meuric@orange-ftgroup.com]=20 >=20 > Hi Young. >=20 > This is a try to resume our discussion started during the SF meeting. > Indeed, I still don't get the rationale behind adding the BER=20 > as a requirement for PCEP request. >=20 > First, I wonder what your intend is when requesting a BER=20 > threshold at computation time while you can't really know it=20 > before LSP provisioning. > Obviously, what we look for is a low BER, but the way I see=20 > using BER in routing would be to request a 2nd route *after*=20 > a poor BER measurement on a firstly established LSP. > Then, considering what you called a "BER estimation", I don't=20 > clearly see how you intend to estimate (or model?) it. The=20 > BER associated to an LSP is highly dependent on so many=20 > parameters: link DGD at measurement time, performance of the=20 > FEC used for the to-be-provisioned LSP , possible cross-talk=20 > and thus impact of potential adjacent channels... > Furthermore, I > don't really understand why focusing on the measurable BER=20 > range while a typical PMD (in)accuracy may just move us=20 > between an acceptable route and an unacceptable one, the=20 > latter being the very 1st problem we should try to solve. > Finally, I don't get the use of such feature. Even if we=20 > could, why would I request a 10^(-6) maximum BER? I don't see=20 > any room for anything else than "the best one", so do we=20 > really need something else? I tend to see BER as a varying=20 > quality feed*back*, not as an indicator that we can=20 > accurately target at routing time. >=20 > I completely agree that PCEP must support optical=20 > requirements, but my concern is to understand actual needs=20 > before loading the protocol. > Therefore, I look forward to reading some clarification on=20 > those issues. >=20 > Best regards, >=20 > Julien >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >=20 >=20 From Jonathan.Sadler@tellabs.com Fri Apr 3 12:14:22 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C56128C15D for ; Fri, 3 Apr 2009 12:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59+6pUVDk-lJ for ; Fri, 3 Apr 2009 12:14:21 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id E15F13A686D for ; Fri, 3 Apr 2009 12:14:20 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.39,320,1235952000"; d="scan'208";a="1280651755" Received: from usnvwwmspht02.hq.tellabs.com (HELO usnvwwmspht02.tellabs-west.tellabsinc.net) ([172.23.211.70]) by mx4-priv.tellabs.com with ESMTP; 03 Apr 2009 19:15:23 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht02.tellabs-west.tellabsinc.net ([172.23.211.70]) with mapi; Fri, 3 Apr 2009 14:15:22 -0500 From: "Sadler, Jonathan B." To: Young Lee , =?iso-8859-1?Q?=27Jonas_M=E5rtensson=27?= , "julien.meuric@orange-ftgroup.com" Date: Fri, 3 Apr 2009 14:14:40 -0500 Thread-Topic: [Pce] Comment on WSON Requirements Thread-Index: AcmzcoBzpd1YmUR3RPSdD1xMIDk4sQATeDYAACo/F+AAAzingAABnvmgAASqaWA= Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2B260FE24009@EX-NAP.tellabs-west.tellabsinc.net> References: <7DBAFEC6A76F3E42817DF1EBE64CB0260656E918@ftrdmel2> <001c01c9b3c2$ef933880$500c7c0a@china.huawei.com> <7DBAFEC6A76F3E42817DF1EBE64CB026065ABAFB@ftrdmel2> <1EC35EEAF3A9FA439C7D6AE45BF437870105169F989D@acreoexc01.ad.acreo.se> <001601c9b47d$b2f126b0$500c7c0a@china.huawei.com> In-Reply-To: <001601c9b47d$b2f126b0$500c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "pce@ietf.org" Subject: Re: [Pce] Comment on WSON Requirements X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 19:14:22 -0000 I agree that being able to specify minimum path "quality" (where the specif= ic quality measure still needs to be specified) is something that needs to = be provided by the PCC to the PCE. That said I'm not certain that PRE-FEC BER is necessarily a good measure fo= r optical path quality as it still is a discussion of the quality seen by t= he client of the modulation scheme in use. The BER can be radically differ= ent for different modulations in the face of the different types of impairm= ents. This feels like an area where the experts in Q6/15 can provide beneficial c= ouncil. Jonathan Sadler -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Young= Lee Sent: Friday, April 03, 2009 12:01 PM To: 'Jonas M=E5rtensson'; julien.meuric@orange-ftgroup.com Cc: pce@ietf.org Subject: Re: [Pce] Comment on WSON Requirements Hi Jonas and Julien, I was thinking PRE-FEC BER when I mentioned the BER threshold. I also agree with Julien that we may need to specify other optical parameters such as OSNR margin. Regarding the BER threshold, please refer to G.698.1 and G=2E698.2 in which to discuss black link definition and optical parameters required. In particular, please read section 7.1.3 that discusses two cases where Pre-FEC BER requirement.=20 Let's continue on the discussion. Thanks. Regards, Young -----Original Message----- From: Jonas M=E5rtensson [mailto:Jonas.Martensson@acreo.se]=20 Sent: Friday, April 03, 2009 11:30 AM To: julien.meuric@orange-ftgroup.com; ylee@huawei.com Cc: pce@ietf.org Subject: RE: Comment on WSON Requirements Hi Young and Julien, I missed this discussion in San Francisco but I tend to agree with (most of) Julien's comments. But if the PCE is expected to compute paths taking optical impairments into account it makes sense for a PCC to be able to set a "threshold" constraint, or minimum acceptable signal quality, although I find it a bit difficult to see under what circumstances anyone would be satisfied with anything else than "virtually zero" BER (or "error-free") for an optical path. In addition, some OSNR margin is usually required in order to allow for aging and other effects. In this case I think it might be better to specify the pre-FEC BER (or equivalent Q-factor if that sounds more related to the optical layer) and maybe in addition the desired OSNR margin. Regards, Jonas > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On=20 > Behalf Of julien.meuric@orange-ftgroup.com > Sent: den 3 april 2009 17:18 > To: ylee@huawei.com > Cc: pce@ietf.org > Subject: Re: [Pce] Comment on WSON Requirements >=20 > Hi Young. >=20 > If I understand correctly, your actual requirement is to find=20 > a "threshold criteria" to request a route that is "healthy=20 > enough" for the PCC. So why have you chosen the BER which=20 > more relative to a digital client layer? Why not considering=20 > a more optical criteria, like OSNR for instance? >=20 > Have a good week-end, >=20 > Julien >=20 >=20 > -----Original Message----- > From: Young Lee [mailto:ylee@huawei.com]=20 >=20 > Hi Julien, >=20 > The reason why we put the BER threshold in the PCEP request=20 > is to "approximate" if the optical path in consideration=20 > would be "healthy" > enough > from the BER perspective. Please note that we have defined=20 > two different computation types of IA-PCE functions in the=20 > IA-WSON framework draft: > (i) > approximate approach; (ii) candidate approach. Approximate=20 > approach is a quick way of estimating the affects of=20 > impairment while the candidate approach is to give a list of=20 > acceptable paths with more thorough data/model.=20 >=20 > The BER can be estimated in various ways given the=20 > availability of other impairment parameters. In any IA-RWA=20 > (approximate) type computation where we are given impairment=20 > parameters to estimate the affects of impairments, we must=20 > use some threshold criteria to accept/reject paths. The BER=20 > parameter was our first attempt at providing some control=20 > over this criterion. >=20 > Best Regards, > Young >=20 > -----Original Message----- > From: julien.meuric@orange-ftgroup.com > [mailto:julien.meuric@orange-ftgroup.com]=20 >=20 > Hi Young. >=20 > This is a try to resume our discussion started during the SF meeting. > Indeed, I still don't get the rationale behind adding the BER=20 > as a requirement for PCEP request. >=20 > First, I wonder what your intend is when requesting a BER=20 > threshold at computation time while you can't really know it=20 > before LSP provisioning. > Obviously, what we look for is a low BER, but the way I see=20 > using BER in routing would be to request a 2nd route *after*=20 > a poor BER measurement on a firstly established LSP. > Then, considering what you called a "BER estimation", I don't=20 > clearly see how you intend to estimate (or model?) it. The=20 > BER associated to an LSP is highly dependent on so many=20 > parameters: link DGD at measurement time, performance of the=20 > FEC used for the to-be-provisioned LSP , possible cross-talk=20 > and thus impact of potential adjacent channels... > Furthermore, I > don't really understand why focusing on the measurable BER=20 > range while a typical PMD (in)accuracy may just move us=20 > between an acceptable route and an unacceptable one, the=20 > latter being the very 1st problem we should try to solve. > Finally, I don't get the use of such feature. Even if we=20 > could, why would I request a 10^(-6) maximum BER? I don't see=20 > any room for anything else than "the best one", so do we=20 > really need something else? I tend to see BER as a varying=20 > quality feed*back*, not as an indicator that we can=20 > accurately target at routing time. >=20 > I completely agree that PCEP must support optical=20 > requirements, but my concern is to understand actual needs=20 > before loading the protocol. > Therefore, I look forward to reading some clarification on=20 > those issues. >=20 > Best regards, >=20 > Julien >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >=20 >=20 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From Black_David@emc.com Fri Apr 3 19:00:43 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083553A6962; Fri, 3 Apr 2009 19:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL-eDbbSGkLn; Fri, 3 Apr 2009 19:00:42 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id D2DD53A68AB; Fri, 3 Apr 2009 19:00:41 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n3421Is5017417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 22:01:18 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 3 Apr 2009 22:01:12 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n34218RS016396; Fri, 3 Apr 2009 22:01:09 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 22:01:08 -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 Date: Fri, 3 Apr 2009 22:01:07 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A024FF24C@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-pce-global-concurrent-optimization-10 Thread-Index: Acm0yTf6A1Uyv+DXSLmW1Y0BiCQELg== To: , , , , X-OriginalArrivalTime: 04 Apr 2009 02:01:08.0719 (UTC) FILETIME=[38907FF0:01C9B4C9] X-EMM-EM: Active X-Mailman-Approved-At: Fri, 03 Apr 2009 19:24:30 -0700 Cc: rcallon@juniper.net, pce@ietf.org, Black_David@emc.com, jpv@cisco.com Subject: [Pce] Gen-ART review of draft-ietf-pce-global-concurrent-optimization-10 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 02:00:43 -0000 I have been selected as the General Area Review Team (Gen-ART)=20 reviewer for this draft (for background on Gen-ART, please see=20 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).=20 Please wait for direction from your document shepherd=20 or AD before posting a new version of the draft.=20 Document: draft-ietf-pce-global-concurrent-optimization-10 Reviewer: David L. Black Review Date: April 3, 2009 IESG Telechat date: April 9, 2009 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: The -10 draft addresses all of the points noted in the Gen-ART review of the -08 version. Unfortunately, idnits 2.11.08 found a few things to complain about: ** You're using the IETF Trust Provisions Section 6.b License Notice from 10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is required now. (See http://trustee.ietf.org/license-info/) ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, = but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.). =3D=3D Missing Reference: 'PCEP' is mentioned on line 565, but not = defined The RFC Editor can take care of the "too long lines" item, but the other three items need attention. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From jvasseur@cisco.com Mon Apr 6 02:37:43 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF57C3A6BC7 for ; Mon, 6 Apr 2009 02:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.284 X-Spam-Level: X-Spam-Status: No, score=-8.284 tagged_above=-999 required=5 tests=[AWL=-1.685, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BluZ-12CFy3W for ; Mon, 6 Apr 2009 02:37:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F3BD53A6945 for ; Mon, 6 Apr 2009 02:37:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,329,1235952000"; d="scan'208";a="280966698" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-6.cisco.com with ESMTP; 06 Apr 2009 09:38:41 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n369cfIE001580; Mon, 6 Apr 2009 11:38:41 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n369cflP006583; Mon, 6 Apr 2009 09:38:41 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 11:38:40 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 11:38:40 +0200 Message-Id: From: JP Vasseur To: pce@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 11:38:37 +0200 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Apr 2009 09:38:40.0662 (UTC) FILETIME=[78061360:01C9B69B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=228; t=1239010721; x=1239874721; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Draft=20PCE=20Working=20Group=20Meeting=20Minut es |Sender:=20; bh=2uWBbL4IuLKWloWclhpZcK0EuP/QkHI44PRn3Xc2VIc=; b=fnJVcFe1k8/XYvIAyhZmtQ2qZnDjmUF85d+hrgvlTgCudFhiixNLOOHyGG XLq2zwOWTGpRZVuOjtncDF1MU3+iVNI5tE8tFDdVGARkkT0YwRWHflZdXsJJ WrMoMqlivG; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Pce] Draft PCE Working Group Meeting Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 09:37:44 -0000 Dear all, The minutes of the PCE WG meeting have been posted. MANY thanks to Dan for the notes. Let us know by April 13 if you have any comment. http://www.ietf.org/proceedings/09mar/minutes/pce.txt Thanks. JP. From rfc-editor@rfc-editor.org Mon Apr 6 16:53:38 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E923A6CA9; Mon, 6 Apr 2009 16:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.927 X-Spam-Level: X-Spam-Status: No, score=-16.927 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrC-LAGqOmce; Mon, 6 Apr 2009 16:53:37 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 4CBA43A6D0F; Mon, 6 Apr 2009 16:53:37 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 1A8D727675D; Mon, 6 Apr 2009 16:53:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090406235340.1A8D727675D@bosco.isi.edu> Date: Mon, 6 Apr 2009 16:53:40 -0700 (PDT) Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] RFC 5441 on A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 23:53:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5441 Title: A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths Author: JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux Status: Standards Track Date: April 2009 Mailbox: jpv@cisco.com, raymond.zhang@bt.com, nabil.n.bitar@verizon.com, jeanlouis.leroux@orange-ftgroup.com Pages: 18 Characters: 39936 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-brpc-09.txt URL: http://www.rfc-editor.org/rfc/rfc5441.txt The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS TRACK] This document is a product of the Path Computation Element Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From ylee@huawei.com Thu Apr 9 11:33:10 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BED3A6AA6 for ; Thu, 9 Apr 2009 11:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLjulkTosRxH for ; Thu, 9 Apr 2009 11:33:09 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id B78383A6CAE for ; Thu, 9 Apr 2009 11:33:09 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHU0087LJL5VK@usaga04-in.huawei.com> for pce@ietf.org; Thu, 09 Apr 2009 13:34:17 -0500 (CDT) Received: from L73682 ([10.124.12.80]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHU008I6JL5Q4@usaga04-in.huawei.com> for pce@ietf.org; Thu, 09 Apr 2009 13:34:17 -0500 (CDT) Date: Thu, 09 Apr 2009 13:34:13 -0500 From: Young Lee In-reply-to: To: pce@ietf.org Message-id: <003901c9b941$ca3f03f0$500c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmtfBzy7zOenMR5SnKVXItJ6VmXxQLxUFsg References: Subject: [Pce] PCE TED work X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 18:33:10 -0000 Dear fellow PCE working group participants, As discussed at the PCE WG meeting at the 74th IETF meeting in San Francisco we'd like to get feedback on the document: "draft-lee-pce-ted-alternatives". This document examines alternative and supplementary approaches to creating and maintaining the Traffic Engineering Database (TED) used by a PCE. In addition, the document examines areas for potential standardization within these alternative approaches. This document does not extend or alter any existing protocols or dictate a particular approach. The benefits of this document to the PCE working group include: (a) Further elaboration with examples of the concepts presented in section 4.3 of the PCE Architecture document (RFC4655). (b) Compares various approaches to achieving the concepts of section 4.3 of RFC4655. (c) Points the way for possible future standardization work. The eventual goal would be for this document to become an informational WG document/RFC. Best Regards Young and Greg ------------------------------ Message: 2 Date: Wed, 25 Mar 2009 10:07:18 -0500 From: "Bardalai, Snigdho" Subject: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt To: Message-ID: Content-Type: text/plain; charset="us-ascii" Hi I believe capturing this information is important in order to attain a consistent behavior for the PCC and PCE implementations. Also, this provides engineering guidelines for system design. Given that I would propose that we either add solution options to this ID or create a separate one. Thanks, Snigdho From dave.mcdysan@verizon.com Fri Apr 10 07:44:11 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303FA3A6EC7 for ; Fri, 10 Apr 2009 07:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqHJtAUy0ffM for ; Fri, 10 Apr 2009 07:44:10 -0700 (PDT) Received: from tpamail4.verizon.com (tpamail4.verizon.com [192.76.82.161]) by core3.amsl.com (Postfix) with ESMTP id 59F0E3A6DCA for ; Fri, 10 Apr 2009 07:44:10 -0700 (PDT) Received: from smtptpa4.verizon.com (smtptpa4.verizon.com [138.83.71.177]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id n3AEZs0p002175 for ; Fri, 10 Apr 2009 10:35:54 -0400 (EDT) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id n3AEjHcc001283 for ; Fri, 10 Apr 2009 10:45:17 -0400 (EDT) Received: from tpaintrmemf3.verizon.com (unknown [127.0.0.1]) by tpaintrmemf3.verizon.com (Symantec Mail Security) with ESMTP id 7EC6A528005 for ; Fri, 10 Apr 2009 10:45:17 -0400 (EDT) X-AuditID: 8a53433a-aae15bb000006ffe-c8-49df5b7d2377 Received: from smtpftw3.verizon.com (unknown [138.83.140.92]) by tpaintrmemf3.verizon.com (EMF) with ESMTP id 53CAB4E4002 for ; Fri, 10 Apr 2009 10:45:17 -0400 (EDT) Received: from FHDP1CCMXCG01.us.one.verizon.com ([166.68.240.33]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id n3AEjGMZ015805 for ; Fri, 10 Apr 2009 10:45:16 -0400 (EDT) Received: from FHDP1LUMXCV14.us.one.verizon.com ([166.68.125.35]) by FHDP1CCMXCG01.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 10:45:16 -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 Date: Fri, 10 Apr 2009 10:45:16 -0400 Message-ID: <793F49BA1FC821409F99F10862A0E4DB0241E4CE@FHDP1LUMXCV14.us.one.verizon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCE-Related MPLS 2009 Conference -- Call for Presentation Abstracts Thread-Index: Acm52sPbaAkStimlQN+jhh3JL8OAFQ== From: "Mcdysan, David E" To: X-OriginalArrivalTime: 10 Apr 2009 14:45:16.0777 (UTC) FILETIME=[F69D7590:01C9B9EA] X-Brightmail-Tracker: AAAAAA== Subject: [Pce] PCE-Related MPLS 2009 Conference -- Call for Presentation Abstracts X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 14:44:11 -0000 The MPLS 2009 International Conference, the 12th Annual International Conference on MPLS and Related Technologies, is scheduled on October 25 - 28, 2009, in Washington, DC. The Technical Program Committee is soliciting abstracts for a proposed presentation representing original/unpublished work covering cutting-edge topics, some of them related to the PCE working .=20 If you want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2009/call_for_papers/cfp.htm A number of these topics have been of interest to members of the PCE working group in the past, and folks active on this list have been presenters at past MPLS conference events covering layer 1 and layer 2 applications of PCE standards and technology. Regards, Dave McDysan From wwwrun@core3.amsl.com Mon Apr 13 08:50:39 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 45EE93A6D92; Mon, 13 Apr 2009 08:50:39 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090413155039.45EE93A6D92@core3.amsl.com> Date: Mon, 13 Apr 2009 08:50:39 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-monitoring (A set of monitoring tools for Path Computation Element based Architecture) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 15:50:39 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'A set of monitoring tools for Path Computation Element based Architecture ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16456&rfc_flag=0 From wwwrun@core3.amsl.com Mon Apr 13 08:51:09 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 159A03A6DEB; Mon, 13 Apr 2009 08:51:08 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090413155109.159A03A6DEB@core3.amsl.com> Date: Mon, 13 Apr 2009 08:51:09 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-p2mp-app (Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)and Generalized MPLS (GMPLS) Traffic Engineering (TE)) to Informational RFC X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 15:51:09 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)and Generalized MPLS (GMPLS) Traffic Engineering (TE) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-p2mp-app-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17670&rfc_flag=0 From wwwrun@core3.amsl.com Mon Apr 13 10:50:55 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id BEB883A6DED; Mon, 13 Apr 2009 10:50:55 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090413175055.BEB883A6DED@core3.amsl.com> Date: Mon, 13 Apr 2009 10:50:55 -0700 (PDT) Cc: Internet Architecture Board , pce mailing list , pce chair , RFC Editor Subject: [Pce] Protocol Action: 'Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization' to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 17:50:55 -0000 The IESG has approved the following document: - 'Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization ' as a Proposed Standard This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and Adrian Farrel. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-global-concurrent-optimization-10.txt Technical Summary The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). When computing or re-optimizing the routes of a set of TE LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. Working Group Summary The WG has good consensus with no disputes or disagreements. Concerns over the impact of this work on network stability (as a result of "churn") have been addressed with suitable text added to describe the concerns and advise the operator about the associated risk (see PROTO writeup by Adrian Farrel). Document Quality There are two known implementations of the protocol extensions described in this document. The document has been updated in response to comments from WG discussions and IETF last call, as well as Gen-Art review and in response to IANA questions. Personnel Adrian Farrel is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. RFC Editor Note Section 5.5, Please delete the one-sentence paragraph which currently reads: Reserved bits (24 bits) of the GLOBAL CONSTRAINTS Object SHOULD be transmitted as zero and SHOULD be ignored upon receipt. Section 5.5, Please update the following text: OLD MU (Max Utilization Percentage: 8 bits) : 8 bits integer that indicates the upper bound utilization percentage by which all link should be bound. Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link Capacity NEW MU (Max Utilization Percentage: 8 bits) : 8 bits integer that indicates the upper bound utilization percentage by which all link should be bound. Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link Capacity. MU is intended to be integer that can only be between 0 and 100. OLD mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that indicates the lower bound utilization percentage by which all link should be bound. NEW mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that indicates the lower bound utilization percentage by which all link should be bound. mU is intended to be integer that can only be between 0 and 100. Throughout Section 4 and Section 5 (several places) Please update the following reference: OLD [PCEP] NEW [RFC5440] From web-usrn@ISI.EDU Tue Apr 14 11:03:11 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8300528C1A0 for ; Tue, 14 Apr 2009 11:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.228 X-Spam-Level: X-Spam-Status: No, score=-17.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j36+DK+wNNi5 for ; Tue, 14 Apr 2009 11:03:10 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 9D28828C1D1 for ; Tue, 14 Apr 2009 11:03:10 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n3EI2lJ7013377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Apr 2009 11:02:47 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n3EI2hkP013359; Tue, 14 Apr 2009 11:02:43 -0700 (PDT) Date: Tue, 14 Apr 2009 11:02:43 -0700 (PDT) Message-Id: <200904141802.n3EI2hkP013359@boreas.isi.edu> To: jpv@cisco.com, raymond.zhang@bt.com, nabil.n.bitar@verizon.com, jeanlouis.leroux@orange-ftgroup.com, rcallon@juniper.net, adrian.farrel@huawei.com, jpv@cisco.com, adrian.farrel@huawei.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Tue, 14 Apr 2009 11:33:14 -0700 Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Technical Errata Reported] RFC5441 (1762) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 18:03:11 -0000 The following errata report has been submitted for RFC5441, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5441&eid=1762 -------------------------------------- Type: Technical Reported by: RFC Editor Section: 15.3 Original Text ------------- IANA has allocated the following allocation value: Bit number Meaning Reference 4 BRPC path computation This document chain unavailable Corrected Text -------------- IANA has allocated the following allocation value: Bit number Meaning Reference 28 BRPC path computation This document chain unavailable Notes ----- The bit number is 28. The error was noted by Pearl Liang of IANA. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5441 (draft-ietf-pce-brpc-09) -------------------------------------- Title : A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths Publication Date : April 2009 Author(s) : JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From fabien.verhaeghe@marben-products.com Tue Apr 14 23:23:17 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A383A6BB8 for ; Tue, 14 Apr 2009 23:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndoJC453kCbK for ; Tue, 14 Apr 2009 23:23:16 -0700 (PDT) Received: from bizpsie3.9services.com (bizpsie3.9services.com [84.96.93.161]) by core3.amsl.com (Postfix) with ESMTP id 2EC2E3A6BB7 for ; Tue, 14 Apr 2009 23:23:15 -0700 (PDT) Received: from pooky.marben-products.com ([86.65.15.130]) by bizpsie3.9services.com with 9services id fiQR1b00A2oN1dS03iQRtJ; Wed, 15 Apr 2009 08:24:26 +0200 X-Biz3: ?? X-VRSPAM-SCORE: -250.00 Received: from AOFR11476 (aofr11476.marben-products.com [192.168.7.180]) by pooky.marben-products.com (8.14.0/8.14.0) with ESMTP id n3F6OOcj005088; Wed, 15 Apr 2009 08:24:24 +0200 From: "Fabien Verhaeghe" To: "'Young Lee'" , Date: Wed, 15 Apr 2009 08:24:18 +0200 Message-ID: <002501c9bd92$d1f29260$b407a8c0@marbenproducts.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: <003901c9b941$ca3f03f0$500c7c0a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmtfBzy7zOenMR5SnKVXItJ6VmXxQLxUFsgARQKWzA= Subject: Re: [Pce] PCE TED work X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 06:23:17 -0000 Hi Young and Greg, Here are some comments on draft-lee-pce-ted-alternatives A) In architecure presented in Figure 3, if one of the PCE fails we = loose information sent by nodes to that PCE. Each node should send information to at least 2 PCEs to avoid single = point of failure. B) section "2.1.1. Nodes Send TE Info to all PCEs" "As the number of PCEs grow we have scaling concerns" Is it really a concern? How many PCEs do you think may be needed? C) section "2.2. Nodes Finding PCEs" In case 3 nodes the selection of the PCE needs to be done so that the = load is correctly balanced among PCEs. D) Not sure what is the advantage of architecture 2 compared to = architecture 1. At first I thought the advantage was that the node only sent information = to one entity instead of N PCEs. But since we also need a backup server for resiliency purpose, = eventually it seems to me both architecture are equivalent. Actually I think my problem is that I do not see what is the purpose of having multiple PCEs for one intermediate server. I thought the goal of having multiple PCEs (in case 1) was for backup purpose. This does not seems to be the case for case 2 since the backup is provided by having 2 intermediate server. E) section "3.2.2. Communication Protocols" One idea: Isn't it possible to meet the presented architecture by using IGP over tunnels. For case 1 for instance. In figure 1 the characters "|", "-", "/", or = "\" represents some (GRE) tunnels. You run OSPF (or ISIS) over those tunnels so that there is an adjacency between each node and the PCE in a dedicated OSPF (or IS-IS) area. You can rely on regular OSPF/ISIS procedure to send TE information from = node to PCE. The only OSPF/ISIS trick needed is at the PCE to prevent LSA received = from one node to be sent to other nodes. I think this it is possible, without having any problem with legacy OSPF/ISIS node though it needs to be check more deeply. The advantage would be that it requires none or few protocol extensions. One drawback is that it offers less flexibilities to target which information are sent to the PCE and which are not. BR Fabien > -----Message d'origine----- > De=A0: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] De la part = de > Young Lee > Envoy=E9=A0: jeudi 9 avril 2009 20:34 > =C0=A0: pce@ietf.org > Objet=A0: [Pce] PCE TED work >=20 >=20 > Dear fellow PCE working group participants, >=20 > As discussed at the PCE WG meeting at the 74th IETF meeting in San > Francisco > we'd like to get feedback on the document: "draft-lee-pce-ted- > alternatives". > This document examines alternative and supplementary approaches to > creating > and maintaining the Traffic Engineering Database (TED) used by a PCE. = In > addition, the document examines areas for potential standardization = within > these alternative approaches. This document does not extend or alter = any > existing protocols or dictate a particular approach. >=20 > The benefits of this document to the PCE working group include: > (a) Further elaboration with examples of the concepts presented in = section > 4.3 of the PCE Architecture document (RFC4655). >=20 > (b) Compares various approaches to achieving the concepts of section = 4.3 > of > RFC4655. >=20 > (c) Points the way for possible future standardization work. >=20 > The eventual goal would be for this document to become an = informational WG > document/RFC. >=20 > Best Regards >=20 > Young and Greg > ------------------------------ >=20 > Message: 2 > Date: Wed, 25 Mar 2009 10:07:18 -0500 > From: "Bardalai, Snigdho" > Subject: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt > To: > Message-ID: > > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi >=20 >=20 >=20 > I believe capturing this information is important in order to attain a > consistent behavior for the PCC and PCE implementations. Also, this > provides engineering guidelines for system design. >=20 >=20 >=20 > Given that I would propose that we either add solution options to this > ID or create a separate one. >=20 >=20 >=20 > Thanks, >=20 > Snigdho >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From ylee@huawei.com Wed Apr 15 08:57:36 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786DB3A6936 for ; Wed, 15 Apr 2009 08:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uNDaJCsEGig for ; Wed, 15 Apr 2009 08:57:35 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 604183A694A for ; Wed, 15 Apr 2009 08:57:35 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI5004E4GDYF3@usaga02-in.huawei.com> for pce@ietf.org; Wed, 15 Apr 2009 08:58:46 -0700 (PDT) Received: from L73682 ([10.124.12.80]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI5002Z8ELD23@usaga02-in.huawei.com> for pce@ietf.org; Wed, 15 Apr 2009 08:20:01 -0700 (PDT) Date: Wed, 15 Apr 2009 10:20:01 -0500 From: Young Lee In-reply-to: <002501c9bd92$d1f29260$b407a8c0@marbenproducts.com> To: 'Fabien Verhaeghe' , pce@ietf.org Message-id: <000c01c9bddd$a5514a80$500c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcmtfBzy7zOenMR5SnKVXItJ6VmXxQLxUFsgARQKWzAAEZ3QkA== References: <003901c9b941$ca3f03f0$500c7c0a@china.huawei.com> <002501c9bd92$d1f29260$b407a8c0@marbenproducts.com> Subject: Re: [Pce] PCE TED work X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 15:57:36 -0000 Hi Fabien, Thanks for your valuable comments. Please see in-line for my response.=20 Best Regards, Young -----Original Message----- From: Fabien Verhaeghe [mailto:fabien.verhaeghe@marben-products.com]=20 Sent: Wednesday, April 15, 2009 1:24 AM To: 'Young Lee'; pce@ietf.org Subject: RE: [Pce] PCE TED work Hi Young and Greg, Here are some comments on draft-lee-pce-ted-alternatives A) In architecure presented in Figure 3, if one of the PCE fails we = loose information sent by nodes to that PCE. Each node should send information to at least 2 PCEs to avoid single = point of failure. Young>> I can see your point. Definitely this would enhance resiliency = in case a PCE fails. Since each PCE only has a partial TED information, = when a PCE fails, we may not be able to maintain the complete TED.=20 =20 B) section "2.1.1. Nodes Send TE Info to all PCEs" "As the number of PCEs grow we have scaling concerns" Is it really a concern? How many PCEs do you think may be needed? Young>> Each node will need to maintain session to each PCE with this architecture and this could be burden to the nodes if there are "too = many" PCEs. If we are talking about 2-3 PCEs, the scaling concern may not be a real issue.=20 C) section "2.2. Nodes Finding PCEs" In case 3 nodes the selection of the PCE needs to be done so that the = load is correctly balanced among PCEs. Young>> Yes. I agree with you.=20 D) Not sure what is the advantage of architecture 2 compared to = architecture 1. At first I thought the advantage was that the node only sent information = to one entity instead of N PCEs. But since we also need a backup server for resiliency purpose, = eventually it seems to me both architecture are equivalent. Young>> Architecture 2 employs publish/subscribe functionality similar = to BGP route reflectors. P/S server needs not be a PCE although it can be collocated with a PCE. We definitely need to consider resiliency of P/S servers as you indicate.=20 Actually I think my problem is that I do not see what is the purpose of having multiple PCEs for one intermediate server. I thought the goal of having multiple PCEs (in case 1) was for backup purpose. This does not seems to be the case for case 2 since the backup is provided by having 2 intermediate server. Young>> You may be right. We are exploring different possibilities in = the draft. We may elaborate advantages/disadvantages for each architecture.=20 E) section "3.2.2. Communication Protocols" One idea: Isn't it possible to meet the presented architecture by using IGP over tunnels. For case 1 for instance. In figure 1 the characters "|", "-", "/", or = "\" represents some (GRE) tunnels. You run OSPF (or ISIS) over those tunnels so that there is an adjacency between each node and the PCE in a dedicated OSPF (or IS-IS) area. You can rely on regular OSPF/ISIS procedure to send TE information from = node to PCE. The only OSPF/ISIS trick needed is at the PCE to prevent LSA received = from one node to be sent to other nodes. I think this it is possible, without having any problem with legacy OSPF/ISIS node though it needs to be check more deeply. The advantage would be that it requires none or few protocol extensions. One drawback is that it offers less flexibilities to target which information are sent to the PCE and which are not. Young>> Sounds a good choice. At this point, we are not proposing any solution. This draft simply illustrates a set of possible communication protocols that can implement the proposed architectures. We can add your tunnels + IGP idea into the text. Ultimately, once this work is = approved, then we can think of implementation details.=20 BR Fabien > -----Message d'origine----- > De=A0: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] De la part = de > Young Lee > Envoy=E9=A0: jeudi 9 avril 2009 20:34 > =C0=A0: pce@ietf.org > Objet=A0: [Pce] PCE TED work >=20 >=20 > Dear fellow PCE working group participants, >=20 > As discussed at the PCE WG meeting at the 74th IETF meeting in San > Francisco > we'd like to get feedback on the document: "draft-lee-pce-ted- > alternatives". > This document examines alternative and supplementary approaches to > creating > and maintaining the Traffic Engineering Database (TED) used by a PCE. = In > addition, the document examines areas for potential standardization = within > these alternative approaches. This document does not extend or alter = any > existing protocols or dictate a particular approach. >=20 > The benefits of this document to the PCE working group include: > (a) Further elaboration with examples of the concepts presented in = section > 4.3 of the PCE Architecture document (RFC4655). >=20 > (b) Compares various approaches to achieving the concepts of section = 4.3 > of > RFC4655. >=20 > (c) Points the way for possible future standardization work. >=20 > The eventual goal would be for this document to become an = informational WG > document/RFC. >=20 > Best Regards >=20 > Young and Greg > ------------------------------ >=20 > Message: 2 > Date: Wed, 25 Mar 2009 10:07:18 -0500 > From: "Bardalai, Snigdho" > Subject: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt > To: > Message-ID: > > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi >=20 >=20 >=20 > I believe capturing this information is important in order to attain a > consistent behavior for the PCC and PCE implementations. Also, this > provides engineering guidelines for system design. >=20 >=20 >=20 > Given that I would propose that we either add solution options to this > ID or create a separate one. >=20 >=20 >=20 > Thanks, >=20 > Snigdho >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From gregb@grotto-networking.com Wed Apr 15 10:12:14 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EAFB3A68C2 for ; Wed, 15 Apr 2009 10:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8cf7rmUdbix for ; Wed, 15 Apr 2009 10:12:13 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id 4E6AE3A6ACB for ; Wed, 15 Apr 2009 10:12:13 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n3FHDEas002919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 10:13:15 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <49E615AD.2060504@grotto-networking.com> Date: Wed, 15 Apr 2009 10:13:17 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Young Lee References: <003901c9b941$ca3f03f0$500c7c0a@china.huawei.com> <002501c9bd92$d1f29260$b407a8c0@marbenproducts.com> <000c01c9bddd$a5514a80$500c7c0a@china.huawei.com> In-Reply-To: <000c01c9bddd$a5514a80$500c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: Re: [Pce] PCE TED work X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 17:12:14 -0000 Hi all a couple more comments on top of Young's and Fabien's. See inline below. Best Regards Greg Young Lee wrote: > -- snip -- > B) section "2.1.1. Nodes Send TE Info to all PCEs" > > "As the number of PCEs grow we have scaling concerns" > > Is it really a concern? How many PCEs do you think may be needed? > > Young>> Each node will need to maintain session to each PCE with this > architecture and this could be burden to the nodes if there are "too many" > PCEs. If we are talking about 2-3 PCEs, the scaling concern may not be a > real issue. > > --->> Agree, initially, this is a good place to start especially for small WSONs. > -- snip -- > D) Not sure what is the advantage of architecture 2 compared to architecture > 1. > At first I thought the advantage was that the node only sent information to > one entity instead of N PCEs. > But since we also need a backup server for resiliency purpose, eventually it > seems to me both architecture > are equivalent. > > Young>> Architecture 2 employs publish/subscribe functionality similar to > BGP route reflectors. P/S server needs not be a PCE although it can be > collocated with a PCE. We definitely need to consider resiliency of P/S > servers as you indicate. > > Actually I think my problem is that I do not see what is the purpose of > having multiple PCEs for one intermediate > server. > I thought the goal of having multiple PCEs (in case 1) was for backup > purpose. This does not seems to be the case for case 2 > since the backup is provided by having 2 intermediate server. > > Young>> You may be right. We are exploring different possibilities in the > draft. We may elaborate advantages/disadvantages for each architecture. > ---- Greg >> This case was trying to cover lots of PCE and the scaling issue of the NEs talking to the PCEs. > E) section "3.2.2. Communication Protocols" > > One idea: > Isn't it possible to meet the presented architecture by using IGP over > tunnels. > For case 1 for instance. In figure 1 the characters "|", "-", "/", or "\" > represents some (GRE) tunnels. > > You run OSPF (or ISIS) over those tunnels so that there is an adjacency > between each node and the PCE in a dedicated OSPF (or IS-IS) area. > You can rely on regular OSPF/ISIS procedure to send TE information from node > to PCE. > > The only OSPF/ISIS trick needed is at the PCE to prevent LSA received from > one node to be sent to other nodes. > I think this it is possible, without having any problem with legacy > OSPF/ISIS node though it needs to be check more deeply. > > The advantage would be that it requires none or few protocol extensions. > One drawback is that it offers less flexibilities to target which > information are sent to the PCE and which are not. > > Young>> Sounds a good choice. At this point, we are not proposing any > solution. This draft simply illustrates a set of possible communication > protocols that can implement the proposed architectures. We can add your > tunnels + IGP idea into the text. Ultimately, once this work is approved, > then we can think of implementation details. > > -- Greg >> The new OSPF multiple-instance drafts could also help in this area. -- snip --- -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From Snigdho.Bardalai@us.fujitsu.com Wed Apr 15 13:39:37 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C096428C267 for ; Wed, 15 Apr 2009 13:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.458 X-Spam-Level: X-Spam-Status: No, score=-105.458 tagged_above=-999 required=5 tests=[AWL=1.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG94Joe6xisx for ; Wed, 15 Apr 2009 13:39:36 -0700 (PDT) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) by core3.amsl.com (Postfix) with ESMTP id B316A28C25A for ; Wed, 15 Apr 2009 13:39:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,194,1238994000"; d="scan'208";a="50527166" Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp01.fnc.fujitsu.com with ESMTP; 15 Apr 2009 15:40:46 -0500 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 Date: Wed, 15 Apr 2009 15:40:45 -0500 Message-ID: In-Reply-To: <49E615AD.2060504@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] PCE TED work Thread-Index: Acm97YEywMSQCJ9aR6i8qB2I1tWYoAAHB7yg References: <003901c9b941$ca3f03f0$500c7c0a@china.huawei.com> <002501c9bd92$d1f29260$b407a8c0@marbenproducts.com><000c01c9bddd$a5514a80$500c7c0a@china.huawei.com> <49E615AD.2060504@grotto-networking.com> From: "Bardalai, Snigdho" To: "Greg Bernstein" , "Young Lee" Cc: pce@ietf.org Subject: Re: [Pce] PCE TED work X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 20:39:37 -0000 Hi all, I agree in terms of a solution this is fairly simple. In addition to the tunnels and LSA filtering (i.e. PCE filters LSAs over an adjacency with a PCC) you also need to identify whether the neighbor is a PCC or a PCE which could be based on the PCE discovery mechanisms. Regards Snigdho -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, April 15, 2009 12:13 PM To: Young Lee Cc: pce@ietf.org Subject: Re: [Pce] PCE TED work Hi all a couple more comments on top of Young's and Fabien's. See inline below. Best Regards Greg Young Lee wrote: > -- snip -- > B) section "2.1.1. Nodes Send TE Info to all PCEs" > > "As the number of PCEs grow we have scaling concerns" > > Is it really a concern? How many PCEs do you think may be needed? > > Young>> Each node will need to maintain session to each PCE with this > architecture and this could be burden to the nodes if there are "too many" > PCEs. If we are talking about 2-3 PCEs, the scaling concern may not be a > real issue.=20 > > =20 --->> Agree, initially, this is a good place to start especially for=20 small WSONs. > -- snip -- > D) Not sure what is the advantage of architecture 2 compared to architecture > 1. > At first I thought the advantage was that the node only sent information to > one entity instead of N PCEs. > But since we also need a backup server for resiliency purpose, eventually it > seems to me both architecture > are equivalent. > > Young>> Architecture 2 employs publish/subscribe functionality similar to > BGP route reflectors. P/S server needs not be a PCE although it can be > collocated with a PCE. We definitely need to consider resiliency of P/S > servers as you indicate.=20 > > Actually I think my problem is that I do not see what is the purpose of > having multiple PCEs for one intermediate > server. > I thought the goal of having multiple PCEs (in case 1) was for backup > purpose. This does not seems to be the case for case 2 > since the backup is provided by having 2 intermediate server. > > Young>> You may be right. We are exploring different possibilities in the > draft. We may elaborate advantages/disadvantages for each architecture.=20 > =20 ---- Greg >> This case was trying to cover lots of PCE and the scaling=20 issue of the NEs talking to the PCEs. > E) section "3.2.2. Communication Protocols" > > One idea: > Isn't it possible to meet the presented architecture by using IGP over > tunnels. > For case 1 for instance. In figure 1 the characters "|", "-", "/", or "\" > represents some (GRE) tunnels. > > You run OSPF (or ISIS) over those tunnels so that there is an adjacency > between each node and the PCE in a dedicated OSPF (or IS-IS) area. > You can rely on regular OSPF/ISIS procedure to send TE information from node > to PCE. > > The only OSPF/ISIS trick needed is at the PCE to prevent LSA received from > one node to be sent to other nodes. > I think this it is possible, without having any problem with legacy > OSPF/ISIS node though it needs to be check more deeply. > > The advantage would be that it requires none or few protocol extensions. > One drawback is that it offers less flexibilities to target which > information are sent to the PCE and which are not. > > Young>> Sounds a good choice. At this point, we are not proposing any > solution. This draft simply illustrates a set of possible communication > protocols that can implement the proposed architectures. We can add your > tunnels + IGP idea into the text. Ultimately, once this work is approved, > then we can think of implementation details.=20 > > =20 -- Greg >> The new OSPF multiple-instance drafts could also help in this area. -- snip --- --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From rcallon@juniper.net Wed Apr 15 14:30:24 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729AA3A6926 for ; Wed, 15 Apr 2009 14:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjcptOxst-ms for ; Wed, 15 Apr 2009 14:30:23 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 436243A67A7 for ; Wed, 15 Apr 2009 14:30:23 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSeZSLPVFkOcUHVMhnQeqI5j4WpqF6fZR@postini.com; Wed, 15 Apr 2009 14:31:36 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Wed, 15 Apr 2009 14:28:01 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 14:28:01 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 14:28:01 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BE11.0D1BF1F1" Date: Wed, 15 Apr 2009 17:27:59 -0400 Message-ID: <3525C9833C09ED418C6FD6CD9514668C061FE4D4@emailwf1.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Change in Co-chairs Thread-Index: Acm+EQyAOJb36lfNQ7ayprnYb6jqVw== From: Ross Callon To: X-OriginalArrivalTime: 15 Apr 2009 21:28:01.0501 (UTC) FILETIME=[0DFA78D0:01C9BE11] Subject: [Pce] Change in Co-chairs X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 21:30:24 -0000 ------_=_NextPart_001_01C9BE11.0D1BF1F1 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Adrian Farrel has stepped down as co-chair of PCE (due to his being appointed as Routing Area Director). Julien Meuric has agreed to take Adrian's place as PCE co-chair. JP Vasseur will continue as the other co-chair of PCE.=20 =20 I would like to thank Adrian Farrel for his great job as co-chair over the years, and also thank Julien for agreeing to take on this task. =20 Thanks, Ross=20 ------_=_NextPart_001_01C9BE11.0D1BF1F1 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Adrian Farrel has stepped down as co-chair of PCE = (due to his being appointed as Routing Area Director). Julien Meuric has agreed = to take Adrian's place as PCE co-chair. JP Vasseur will continue as the other = co-chair of PCE.

 

I would like to thank Adrian Farrel for his great job = as co-chair over the years, and also thank Julien for agreeing to take on = this task.

 

Thanks, Ross

------_=_NextPart_001_01C9BE11.0D1BF1F1-- From i_bryskin@yahoo.com Thu Apr 16 12:13:53 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C223A6D8C for ; Thu, 16 Apr 2009 12:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRcQq5kmFxK2 for ; Thu, 16 Apr 2009 12:13:42 -0700 (PDT) Received: from web36807.mail.mud.yahoo.com (web36807.mail.mud.yahoo.com [209.191.85.58]) by core3.amsl.com (Postfix) with SMTP id 2FDE73A6D41 for ; Thu, 16 Apr 2009 12:13:42 -0700 (PDT) Received: (qmail 10176 invoked by uid 60001); 16 Apr 2009 19:14:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1239909295; bh=5beD/irQPHUwzpkIekXX/XqJ1Bj1c4JN1YB7tduAqjw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=pkAqq0cadkHYVzBr3gu++ACJdo6w6J0X8pqTOw1fxiUGhhwcWTOo+aCypnpvqGPrutkXxGSujqprU550F4OGh0Ph3ALDAG+v042ObOoJKxxU4Zips/0QlS3HlCb9aNJtdj6919Kjpcyh/MVzsebVqiprXhYhlir18XjZCpMOOsA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=zFNxYYmywbo1OXh9VQJZZroEUCtOQ6h8hKzbKjzvo5SvfKjFdKF98NR9dIDTn3l51cQ1QDxjDTrJDD5bnaEiQXStyo+HOHh/lfHZhQDl5cQzzcM/mDrPtY3kR2Gy3EpYh8/dALk+yrpLbh3Bwm6pRhl+QPZozGxU5YNipd6/weE=; Message-ID: <81761.9046.qm@web36807.mail.mud.yahoo.com> X-YMail-OSG: W1xbe64VM1nyTTColilQE83xtkhOpNlrrNdRB5LUyT7YsInJcZTnuBVAYtY7XwwxbYxkMSKMjG7Smkr0VitU4m5eNCoGjzp9QJZG1zh8sYzbJ.E5_k1Vjfou64zLgsUKS9k0JRR1RXCHr5TldyXC3onxn1i7IvJ67Tl1CHjoy.QMm1zKBYEQKLZkdfIIjmnK_7WvzqEx7L7sXl43DmJZcXWiUFL82b.YfWxrJyJDv42lkxR_68XOJE.m00Oz7uOI2b404Z4z9CDh_Kao6sIg.iy1iKXZ7RaYOnVgHxurpJ080UMtysJbMZiXdTddFNDoXhsk Received: from [67.102.145.11] by web36807.mail.mud.yahoo.com via HTTP; Thu, 16 Apr 2009 12:14:54 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> Date: Thu, 16 Apr 2009 12:14:54 -0700 (PDT) From: Igor Bryskin To: Young Lee , pce@ietf.org In-Reply-To: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-578359687-1239909294=:9046" Subject: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:13:53 -0000 --0-578359687-1239909294=:9046 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AHere is my comments on the draft =E2=80=9CAlternative Approaches = to Traffic Engineering Database Creation and Maintenance for Path Computati= on Elements=E2=80=9D http://tools.ietf.org/id/draft-lee-pce-ted-alternative= s-01.txt =0A =0AGeneral comments.=0A =0A1. Everywhere you say IGP you mean,= I am sure, IGP-TE. It is=0Aworth to make it clear. I know that many people= think that IGP-TE is an=0Aextension of IGP for TE purposes, but in fact, t= he two are completely different=0Aprotocols with completely different purpo= ses: one is to dynamically manage IP=0Aforwarding tables, and the other is = to discover network resources of various network=0Alayers and use this info= rmation for constraint based path computations. The=0Aonly thing that the t= wo have in common is that they may share the same instance=0Aof the IGP flo= oding/synchronization machinery (even this becomes increasingly=0Auntrue: t= oday many use separate instances, look for the OSPF transport instance=0Aan= d multi-instance activities in the OSPF WG). Other then that, the two=0Apro= tocols have nothing in common; and this is especially true in the context o= f=0Athis document. It is quite reasonable to imagine, for example, that wit= hin the=0APCE Architecture one can completely eliminate use of IGP-TE by u= sing, say, PCEP instead, to=0Asend local resource updates directly to PCE(s= ). However, one will still need IGP for=0Aforwarding control plane traffic= . So my point here is that we want alternative=0Amethods to IGP-TE and not = to IGP.=0A =0A2. I=E2=80=99d like to see in the draft a discussion on why t= he=0Aflooding of TE information and the PCE architecture is not a good matc= h. And=0Athis is because flooding of any type of information works well on = homogeneous=0Atopologies, where all participants originate, distribute and = use the information.=0AThat=E2=80=99s why IP OSPF, for example, works well:= all OSPF speakers originate LSAs,=0Aflood local and remote LSAs and use th= em in route calculations. The PCE=0Aarchitecture is by definition asymmetri= cal with respect to the information used=0Ain path computations: many eleme= nts originate, but only few use it, and the=0Aflooding under these circumst= ances could be very inefficient for all these=0Areasons that you mentioned:= memory, CPU, bandwidth, etc.=0A =0ASpecific comments:=0A =0A1. You write:= =0A=E2=80=9C This draft does not=0Aadvocate that the alternative methods s= pecified =0A in this draft=0Ashould completely replace the IGP as the met= hod of =0A creating the TED.=E2=80=9D=0A =0AWhy not? I mean there is a va= riety of ways how the=0Aalternative methods could relate to the IGP-TE meth= od of managing TEDs. And I=E2=80=99d=0Alike to see a section describing dif= ferent use cases and examples of IGP-TE and=0Athe alternatives cooperating = with each other. One such use case is, for=0Aexample, a network built of si= mple optical NEs managed by a tiny control plane=0Athat consists of:=0A1) P= CC instance to send updates to remote PCE(s) on local=0Aresources status an= d also request path computations;=0A2) Very limited RSVP-TE instance for si= gnaling fully=0Aexplicit EROs provided by the PCE(s).=0A =0AIn this case I= GP-TE is not involved at all. =0A =0AThere could be different ways how the = alternatives can=0Acooperate with IGP-TE. One such cooperation, as you sugg= ested, could be a split=0Aof what information is distributed by IGP-TE and = what via alternatives. For=0Aexample, it makes sense to distribute =E2=80= =9Cstatic=E2=80=9D (rarely modified) and sizable=0Adata =E2=80=93 e.g. NE s= witching asymmetricity =E2=80=93 via methods other than IGP-TE, while=0Amor= e frequently changed data via IGP-TE. This could significantly decrease the= =0AIGP-TE information and its footprint on all speakers.=0A =0AAnother type= of cooperation between the IGP-TE method and=0Aits alternatives is limitin= g number and type of elements participating in=0AIGP-TE. Your architectural= option #3 requires inter-PCE TED synchronization.=0AHow about interconnect= ing PCEs into one or more rings via IP-IP tunnels and use an instance of = IGP-TE over the tunnels for the=0Asole purpose of TED synchronization betwe= en the PCEs?=0A =0A2. You wrote:=0A =0A=E2=80=9CIn OSPF the information dir= ectly related to IP =0A connectivity (and=0Ahence the control communicati= ons plane for all =0A three technologies)=0Ais kept in the link state dat= abase (LSDB), while =0A additional=0Ainformation related to traffic engin= eering used by MPLS =0A and GMPLS is kept=0Ain a (conceptually) separate = traffic engineering =0A database (TED)=E2=80=9D.=0A =0AThis is not accura= te. All IP and non-IP advertisements are=0Astored in LSDB. Additionally, TE= info is kept in TED.=0A =0A3. In section 2.0 you describe the advantages o= f using=0Aalternative to IGP-TE methods. You also need here to clearly stat= e the=0Adisadvantages, which are:=0Aa) necessity of=0Amechanisms that we t= ake for granted when use IGP-TE: removal of stale=0Ainformation, reliable d= elivery of updates to all participants; recovery after=0Areboots/crashes/up= grades, etc.=0Ab) additional security concerns;=0Ac) protocol to discover P= CEs that are capable and willing to=0Aaccept direct updates;=0Ad) protocol = to send the updates;=0Aetc.=0A =0A4. Why not PCEP?=0A =0AThis is not a requ= irement document. So I think it would be=0Abeneficial to suggest a solution= for the protocol to be used by NEs to send=0Aresource updates to PCE(s). C= onsidering that this protocol is supposed to:=0Aa) discover PCE(s) capable = and willing to receive such=0Aupdates;=0Ab) maintain sessions between NEs a= nd PCE(s);=0Ac) address all the security concerns for PCE(s) to accept suc= h updates;=0Ad) guarantee reliable delivery of the updates;=0A =0Awhy not t= o extend PCEP for this purpose since it is already=0Adoing all these things= ?=0A =0ACheers,=0AIgor=0A=0A=0A --0-578359687-1239909294=:9046 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 
Hi,

Here is my comments on  the draft =E2=80=
=9CAlternative Approaches to Traffic Engineering Database Creation and Main=
tenance for Path Computation Elements=E2=80=9D
http://tools.ietf.org/id/draft-lee-pce-ted-altern= atives-01.txt =0A=0A

 

<= meta name=3D"Generator" content=3D"Microsoft Word 11">=0A=0A

Gene= ral comments.

=0A=0A

 

=0A=0A1. Everywhere you say IGP you mean, I am sure, IGP-TE.= It is=0Aworth to make it clear. I know that many people think that IGP-TE = is an=0Aextension of IGP for TE purposes, but in fact, the two are complete= ly different=0Aprotocols with completely different purposes: one is to dyna= mically manage IP=0Aforwarding tables, and the other is to discover network= resources of various network=0Alayers and use this information for constra= int based path computations. The=0Aonly thing that the two have in common i= s that they may share the same instance=0Aof the IGP flooding/synchronizati= on machinery (even this becomes increasingly=0Auntrue: today many use separ= ate instances, look for the OSPF transport instance=0Aand multi-instance ac= tivities in the OSPF WG). Other then that, the two=0Aprotocols have nothing= in common; and this is especially true in the context of=0Athis document. = It is quite reasonable to imagine, for example, that within the=0APCE Archi= tecture one can completely eliminate use  of I= GP-TE by using, say, PCEP instead, to=0Asend local resource updates directl= y to PCE(s).  However, one will still need IGP= for=0Aforwarding control plane traffic. So my point here is that we want a= lternative=0Amethods to IGP-TE and not to IGP.

=0A=0A

 

=0A=0A

2. I=E2=80=99d like t= o see in the draft a discussion on why the=0Aflooding of TE information and= the PCE architecture is not a good match. And=0Athis is because flooding o= f any type of information works well on homogeneous=0Atopologies, where all= participants originate, distribute and use the information.=0AThat=E2=80= =99s why IP OSPF, for example, works well: all OSPF speakers originate LSAs= ,=0Aflood local and remote LSAs and use them in route calculations. The PCE= =0Aarchitecture is by definition asymmetrical with respect to the informati= on used=0Ain path computations: many elements originate, but only few use i= t, and the=0Aflooding under these circumstances could be very inefficient f= or all these=0Areasons that you mentioned: memory, CPU, bandwidth, etc.

= =0A=0A

 

=0A=0A

Specific comments:

=0A=0A

 =0A=0A

1. You write:

=0A=0A

=E2=80=9C  This draft does not=0Aadvocate tha= t the alternative methods specified

=0A=0A

   in this draft=0Ashould completely replace th= e IGP as the method of

=0A=0A

&n= bsp;  creating the TED.=E2=80=9D

=0A=0A

 

=0A=0A

Why not? I mean there i= s a variety of ways how the=0Aalternative methods could relate to the IGP-T= E method of managing TEDs. And I=E2=80=99d=0Alike to see a section describi= ng different use cases and examples of IGP-TE and=0Athe alternatives cooper= ating with each other. One such use case is, for=0Aexample, a network built= of simple optical NEs managed by a tiny control plane=0Athat consists of:<= /p>=0A=0A

1) PCC instance to send updates to remote P= CE(s) on local=0Aresources status and also request path computations;

= =0A=0A

2) Very limited RSVP-TE instance for signaling= fully=0Aexplicit EROs  provided by the PCE(s)= .

=0A=0A

 

=0A=0A

In this case IGP-TE is not involved at all.

=0A=0A

 

=0A=0A

There could be= different ways how the alternatives can=0Acooperate with IGP-TE. One such = cooperation, as you suggested, could be a split=0Aof what information is di= stributed by IGP-TE and what via alternatives. For=0Aexample, it makes sens= e to distribute =E2=80=9Cstatic=E2=80=9D (rarely modified) and sizable=0Ada= ta =E2=80=93 e.g. NE switching asymmetricity =E2=80=93 via methods other th= an IGP-TE, while=0Amore frequently changed data via IGP-TE. This could sign= ificantly decrease the=0AIGP-TE information and its footprint on all speake= rs.

=0A=0A

 

=0A=0A

Another type of cooperation between the IGP-TE method and=0Aits = alternatives is limiting number and type of elements participating in=0AIGP= -TE. Your architectural option #3 requires inter-PCE TED synchronization.= =0AHow about interconnecting PCEs into one or more rings&n= bsp; via IP-IP tunnels and use an  inst= ance of IGP-TE over the tunnels for the=0Asole purpose of TED synchronizati= on between the PCEs?

=0A=0A

 

= =0A=0A

2. You wrote:

=0A=0A

=  

=0A=0A

=E2=80=9CIn OSPF the info= rmation directly related to IP

=0A=0A

   connectivity (and=0Ahence the control communicati= ons plane for all

=0A=0A

 &= nbsp; three technologies)=0Ais kept in the link state database (LSDB= ), while

=0A=0A

   additional=0Ainformation related to traffic engineering used by MPLS =0A=0A

   and GMP= LS is kept=0Ain a (conceptually) separate traffic engineering

=0A=0A

   database (TED)=E2= =80=9D.

=0A=0A

 

=0A=0A

This is not accurate. All IP and non-IP advertisements are= =0Astored in LSDB. Additionally, TE info is kept in TED.

=0A=0A

 

=0A=0A

3. In sect= ion 2.0 you describe the advantages of using=0Aalternative to IGP-TE method= s. You also need here to clearly state the=0Adisadvantages, which are:

= =0A=0A

a)  necessity of= =0Amechanisms that we take for granted when use IGP-TE: removal of stale=0A= information, reliable delivery of updates to all participants; recovery aft= er=0Areboots/crashes/upgrades, etc.

=0A=0A

b) addi= tional security concerns;

=0A=0A

c) protocol to di= scover PCEs that are capable and willing to=0Aaccept direct updates;

=0A= =0A

d) protocol to send the updates;

=0A=0A

etc.

=0A=0A

 

= =0A=0A

4. Why not PCEP?

=0A=0A

 

=0A=0A

This is not a requirem= ent document. So I think it would be=0Abeneficial to suggest a solution for= the protocol to be used by NEs to send=0Aresource updates to PCE(s). Consi= dering that this protocol is supposed to:

=0A=0A

a= ) discover PCE(s) capable and willing to receive such=0Aupdates;

=0A=0A<= p class=3D"MsoNormal">b) maintain sessions between NEs and PCE(s);

=0A= =0A

c) address all the security concerns  for PCE(s) to accept such updates;

=0A=0A

d) guarantee reliable delivery of the updates;

=0A=0A

 

=0A=0A

why not t= o extend PCEP for this purpose since it is already=0Adoing all these things= ?

=0A=0A

 

=0A=0A<= p class=3D"MsoNormal">Cheers,

=0A=0A

Igor

=0A= =0A
=0A=0A

=0A=0A --0-578359687-1239909294=:9046-- From ylee@huawei.com Thu Apr 16 13:23:13 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3243A69CE for ; Thu, 16 Apr 2009 13:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZXbr8Q+el90 for ; Thu, 16 Apr 2009 13:23:03 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id DC9FC3A6902 for ; Thu, 16 Apr 2009 13:23:02 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI7000PNNCFNV@usaga04-in.huawei.com> for pce@ietf.org; Thu, 16 Apr 2009 15:24:15 -0500 (CDT) Received: from L73682 ([10.124.12.80]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI7001EMNCDVW@usaga04-in.huawei.com> for pce@ietf.org; Thu, 16 Apr 2009 15:24:14 -0500 (CDT) Date: Thu, 16 Apr 2009 15:24:13 -0500 From: Young Lee In-reply-to: <81761.9046.qm@web36807.mail.mud.yahoo.com> To: 'Igor Bryskin' , pce@ietf.org Message-id: <002f01c9bed1$4f5172f0$500c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_isg7HSQ8TCDM6QIJo5RKXQ)" Thread-index: Acm+x6OkjFqYqXJVSQeFQmJOIYVtRAAAm5EA References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> <81761.9046.qm@web36807.mail.mud.yahoo.com> Subject: Re: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 20:23:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_isg7HSQ8TCDM6QIJo5RKXQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Igor, Thanks for your comments on the draft. Please see in-line for my reply. Thanks. Regards, Young _____ From: Igor Bryskin [mailto:i_bryskin@yahoo.com] Sent: Thursday, April 16, 2009 2:15 PM To: Young Lee; pce@ietf.org Subject: Comments on draft-lee-pce-ted-alternatives-01.txt Hi, Here is my comments on the draft "Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements" http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt General comments. 1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to make it clear. I know that many people think that IGP-TE is an extension of IGP for TE purposes, but in fact, the two are completely different protocols with completely different purposes: one is to dynamically manage IP forwarding tables, and the other is to discover network resources of various network layers and use this information for constraint based path computations. The only thing that the two have in common is that they may share the same instance of the IGP flooding/synchronization machinery (even this becomes increasingly untrue: today many use separate instances, look for the OSPF transport instance and multi-instance activities in the OSPF WG). Other then that, the two protocols have nothing in common; and this is especially true in the context of this document. It is quite reasonable to imagine, for example, that within the PCE Architecture one can completely eliminate use of IGP-TE by using, say, PCEP instead, to send local resource updates directly to PCE(s). However, one will still need IGP for forwarding control plane traffic. So my point here is that we want alternative methods to IGP-TE and not to IGP. Young>> Yes, we meant IGP, IGP-TE. 2. I'd like to see in the draft a discussion on why the flooding of TE information and the PCE architecture is not a good match. And this is because flooding of any type of information works well on homogeneous topologies, where all participants originate, distribute and use the information. That's why IP OSPF, for example, works well: all OSPF speakers originate LSAs, flood local and remote LSAs and use them in route calculations. The PCE architecture is by definition asymmetrical with respect to the information used in path computations: many elements originate, but only few use it, and the flooding under these circumstances could be very inefficient for all these reasons that you mentioned: memory, CPU, bandwidth, etc. Young>> I agree. This sounds like a helpful discussion within the draft highlighting the motivation for this work. Specific comments: 1. You write: " This draft does not advocate that the alternative methods specified in this draft should completely replace the IGP as the method of creating the TED." Young>> What the statement above meant was for general case. For WSON case, we see great value considering alternative methods that can replace IGP-TE. On the other hands, there are applications (as you mentioned in 2) where current method (IGP-TE) works perfectly well. Why not? I mean there is a variety of ways how the alternative methods could relate to the IGP-TE method of managing TEDs. And I'd like to see a section describing different use cases and examples of IGP-TE and the alternatives cooperating with each other. One such use case is, for example, a network built of simple optical NEs managed by a tiny control plane that consists of: 1) PCC instance to send updates to remote PCE(s) on local resources status and also request path computations; 2) Very limited RSVP-TE instance for signaling fully explicit EROs provided by the PCE(s). Young>> Again, I tend to agree with you that these cases would justify PCE based alternative method. In this case IGP-TE is not involved at all. There could be different ways how the alternatives can cooperate with IGP-TE. One such cooperation, as you suggested, could be a split of what information is distributed by IGP-TE and what via alternatives. For example, it makes sense to distribute "static" (rarely modified) and sizable data - e.g. NE switching asymmetricity - via methods other than IGP-TE, while more frequently changed data via IGP-TE. This could significantly decrease the IGP-TE information and its footprint on all speakers. Young>> Yes, cooperation between IGP-TE and alternative methods can prove some cases. I was envisioning that IGP-TE would continue distribute existing TE while WSON related info would be distributed via a new alternative. Another type of cooperation between the IGP-TE method and its alternatives is limiting number and type of elements participating in IGP-TE. Your architectural option #3 requires inter-PCE TED synchronization. How about interconnecting PCEs into one or more rings via IP-IP tunnels and use an instance of IGP-TE over the tunnels for the sole purpose of TED synchronization between the PCEs? Young>> I was thinking a similar method that runs a separate OPSF-TE instance over the tunnels taking advantage of OSPF's database synchronization and updates capability with neighbors. 2. You wrote: "In OSPF the information directly related to IP connectivity (and hence the control communications plane for all three technologies) is kept in the link state database (LSDB), while additional information related to traffic engineering used by MPLS and GMPLS is kept in a (conceptually) separate traffic engineering database (TED)". This is not accurate. All IP and non-IP advertisements are stored in LSDB. Additionally, TE info is kept in TED. Young>> We can correct this. 3. In section 2.0 you describe the advantages of using alternative to IGP-TE methods. You also need here to clearly state the disadvantages, which are: a) necessity of mechanisms that we take for granted when use IGP-TE: removal of stale information, reliable delivery of updates to all participants; recovery after reboots/crashes/upgrades, etc. b) additional security concerns; c) protocol to discover PCEs that are capable and willing to accept direct updates; d) protocol to send the updates; etc. Young>> This is fair to put in the document. That's why if we can re-use many of the IGP-TE's mechanism (for instance for architectural option #3, we can re-use OSPF-TE between PCE-PCE for TED synch, etc.). 4. Why not PCEP? This is not a requirement document. So I think it would be beneficial to suggest a solution for the protocol to be used by NEs to send resource updates to PCE(s). Considering that this protocol is supposed to: a) discover PCE(s) capable and willing to receive such updates; b) maintain sessions between NEs and PCE(s); c) address all the security concerns for PCE(s) to accept such updates; d) guarantee reliable delivery of the updates; why not to extend PCEP for this purpose since it is already doing all these things? Young>> This was the original motivation for this work. We need to elaborate this point in the update. Thanks. Cheers, Igor --Boundary_(ID_isg7HSQ8TCDM6QIJo5RKXQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Igor,

 

Thanks for your comments on the = draft. Please see in-line for my reply. Thanks.

 

Regards,

Young

 

From: Igor = Bryskin [mailto:i_bryskin@yahoo.com]
Sent: Thursday, April 16, = 2009 2:15 PM
To: Young Lee; = pce@ietf.org
Subject: Comments on draft-lee-pce-ted-alternatives-01.txt

 

Hi,



Here is my comments on  the draft “Alternative Approaches to =
Traffic Engineering Database Creation and Maintenance for Path =
Computation Elements”

http://tools.ietf.org/id/draft-lee-pce-ted-alternatives= -01.txt

 

General comments.

 

1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is = worth to make it clear. I know that many people think that IGP-TE is an extension = of IGP for TE purposes, but in fact, the two are completely different protocols = with completely different purposes: one is to dynamically manage IP = forwarding tables, and the other is to discover network resources of various = network layers and use this information for constraint based path computations. = The only thing that the two have in common is that they may share the same = instance of the IGP flooding/synchronization machinery (even this becomes = increasingly untrue: today many use separate instances, look for the OSPF transport = instance and multi-instance activities in the OSPF WG). Other then that, the two protocols have nothing in common; and this is especially true in the = context of this document. It is quite reasonable to imagine, for example, that = within the PCE Architecture one can completely eliminate use  of IGP-TE by = using, say, PCEP instead, to send local resource updates directly to PCE(s).  However, one will still need IGP for forwarding control plane = traffic. So my point here is that we want alternative methods to IGP-TE and not to = IGP.

 

Young>> Yes, we meant IGP, = IGP-TE.

 

2. I’d like to see in the draft a discussion on why the = flooding of TE information and the PCE architecture is not a good match. And this = is because flooding of any type of information works well on homogeneous topologies, where all participants originate, distribute and use the information. That’s why IP OSPF, for example, works well: all OSPF speakers originate LSAs, flood local and remote LSAs and use them in = route calculations. The PCE architecture is by definition asymmetrical with = respect to the information used in path computations: many elements originate, = but only few use it, and the flooding under these circumstances could be very inefficient for all these reasons that you mentioned: memory, CPU, = bandwidth, etc.

 

Young>> I agree. This sounds = like a helpful discussion within the draft highlighting the motivation for this = work.

Specific comments:

 

1. You write:

“  This draft does not advocate that the alternative = methods specified

   in this draft should completely replace the IGP as = the method of

   creating the = TED.”

 

=

Young>> What the statement = above meant was for general case. For WSON case, we see great value = considering alternative methods that can replace IGP-TE. On the other hands, there are = applications (as you mentioned in 2) where current method (IGP-TE) works perfectly well. =

 

Why not? I mean there is a variety of ways how the alternative = methods could relate to the IGP-TE method of managing TEDs. And I’d like = to see a section describing different use cases and examples of IGP-TE and the alternatives cooperating with each other. One such use case is, for = example, a network built of simple optical NEs managed by a tiny control plane that consists of:

1) PCC instance to send updates to remote PCE(s) on local = resources status and also request path computations;

2) Very limited RSVP-TE instance for signaling fully explicit EROs  provided by the PCE(s).

 

Young>> Again, I tend to = agree with you that these cases would justify PCE based alternative method. =

 

In this case IGP-TE is not involved at all. =

 

There could be different ways how the alternatives can cooperate = with IGP-TE. One such cooperation, as you suggested, could be a split of what information is distributed by IGP-TE and what via alternatives. For = example, it makes sense to distribute “static” (rarely modified) and = sizable data – e.g. NE switching asymmetricity – via methods other = than IGP-TE, while more frequently changed data via IGP-TE. This could = significantly decrease the IGP-TE information and its footprint on all = speakers.

 

Young>>  Yes, = cooperation between IGP-TE and alternative methods can prove some cases. I was = envisioning that IGP-TE would continue distribute existing TE while WSON related = info would be distributed via a new alternative.

 

Another type of cooperation between the IGP-TE method and its alternatives is limiting number and type of elements participating in = IGP-TE. Your architectural option #3 requires inter-PCE TED synchronization. How = about interconnecting PCEs into one or more rings  via IP-IP tunnels and = use an  instance of IGP-TE over the tunnels for the sole purpose of TED synchronization between the PCEs?

 

Young>> I was thinking a = similar method that runs a separate OPSF-TE instance over the tunnels taking = advantage of OSPF’s database synchronization and updates capability with = neighbors.

2. You wrote:

 

“In OSPF the information directly related to IP =

   connectivity (and hence the control communications = plane for all

   three technologies) is kept in the link state = database (LSDB), while

   additional information related to traffic = engineering used by MPLS

   and GMPLS is kept in a (conceptually) separate = traffic engineering

   database (TED)”.

 

This is not accurate. All IP and non-IP advertisements are = stored in LSDB. Additionally, TE info is kept in TED.

 

Young>> We can correct this. =

 

3. In section 2.0 you describe the advantages of using = alternative to IGP-TE methods. You also need here to clearly state the disadvantages, = which are:

a)  necessity of mechanisms that we take for granted when = use IGP-TE: removal of stale information, reliable delivery of updates to = all participants; recovery after reboots/crashes/upgrades, = etc.

b) additional security concerns;

c) protocol to discover PCEs that are capable and willing to = accept direct updates;

d) protocol to send the updates;

etc.

 

Young>> This is fair to put = in the document. That’s why if we can re-use many of the IGP-TE’s mechanism (for instance for architectural option #3, we can re-use = OSPF-TE between PCE-PCE for TED synch, etc.).

 

4. Why not PCEP?

 

This is not a requirement document. So I think it would be = beneficial to suggest a solution for the protocol to be used by NEs to send = resource updates to PCE(s). Considering that this protocol is supposed = to:

a) discover PCE(s) capable and willing to receive such = updates;

b) maintain sessions between NEs and = PCE(s);

c) address all the security concerns  for PCE(s) to accept = such updates;

d) guarantee reliable delivery of the = updates;

 

why not to extend PCEP for this purpose since it is already = doing all these things?

 

Young>> This was the original motivation for this work. We need to elaborate this point in the update. = Thanks.

 

Cheers,

Igor

 

--Boundary_(ID_isg7HSQ8TCDM6QIJo5RKXQ)-- From jvasseur@cisco.com Fri Apr 17 01:18:40 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D6E3A6DA7 for ; Fri, 17 Apr 2009 01:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.263 X-Spam-Level: X-Spam-Status: No, score=-10.263 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu2jEIiU031U for ; Fri, 17 Apr 2009 01:18:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 45DB83A6B39 for ; Fri, 17 Apr 2009 01:18:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,203,1238976000"; d="scan'208,217";a="38515355" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Apr 2009 08:19:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3H8Jpst026932; Fri, 17 Apr 2009 10:19:51 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3H8JpCP000734; Fri, 17 Apr 2009 08:19:51 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:19:51 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 10:19:50 +0200 Message-Id: <330BF810-20FF-4126-866D-00D751FEC6E2@cisco.com> From: JP Vasseur To: Ross Callon , pce@ietf.org, Adrian Farrel , julien.meuric@orange-ftgroup.com In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C061FE4D4@emailwf1.jnpr.net> Content-Type: multipart/alternative; boundary=Apple-Mail-68--343815529 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 10:19:49 +0200 References: <3525C9833C09ED418C6FD6CD9514668C061FE4D4@emailwf1.jnpr.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 17 Apr 2009 08:19:50.0754 (UTC) FILETIME=[4752A420:01C9BF35] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3748; t=1239956391; x=1240820391; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20Change=20in=20Co-chairs |Sender:=20; bh=xbHqN09lYvkEOQWxNKaB2rT/kk58VqJEuzGzVrkf2eI=; b=DSZBWROKoGUMrAAS4OUIsa9WNTpFmXs/il2WcRpCcunauv/ASm5HwKg1k8 kGtv+6PoEtBw+vnsuwe7zqfubYvy6m7K/6DCV0em2gR/THaQwlBih2bwAqFl 6XffmBGPpn; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Pce] Change in Co-chairs X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:18:40 -0000 --Apple-Mail-68--343815529 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I would like to add my personal thank to Adrian. We started together about 5 years ago and the least that we can say is that this has been a very successful WG that produced excellent work. Needless to say that Adrian was instrumental and of course he will continue to be involved. Warm welcome to Julien. Thanks. JP. On Apr 15, 2009, at 11:27 PM, Ross Callon wrote: > Adrian Farrel has stepped down as co-chair of PCE (due to his being > appointed as Routing Area Director). Julien Meuric has agreed to > take Adrian's place as PCE co-chair. JP Vasseur will continue as the > other co-chair of PCE. > > I would like to thank Adrian Farrel for his great job as co-chair > over the years, and also thank Julien for agreeing to take on this > task. > > Thanks, Ross --Apple-Mail-68--343815529 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I would like to add my personal = thank to Adrian. We started together about 5 years ago and the least = that we can say is that this has been a very successful WG = that produced  excellent work. Needless to say that Adrian was = instrumental and of course he will continue to be = involved.

Warm welcome to = Julien.

Thanks.

JP.

On Apr 15, 2009, at 11:27 PM, Ross Callon = wrote:

Adrian Farrel has = stepped down as co-chair of PCE (due to his being appointed as Routing = Area Director). Julien Meuric has agreed to take Adrian's place as PCE = co-chair. JP Vasseur will continue as the other co-chair of = PCE.
I = would like to thank Adrian Farrel for his great job as co-chair over the = years, and also thank Julien for agreeing to take on this = task.
To: "'Young Lee'" References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> <81761.9046.qm@web36807.mail.mud.yahoo.com> <002f01c9bed1$4f5172f0$500c7c0a@china.huawei.com> In-Reply-To: <002f01c9bed1$4f5172f0$500c7c0a@china.huawei.com> Date: Mon, 20 Apr 2009 14:42:30 +0100 Message-ID: <004c01c9c1bd$da0ec2f0$8e2c48d0$@co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C9C1C6.3BD32AF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acm+x6OkjFqYqXJVSQeFQmJOIYVtRAAAm5EAALzpDsA= Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 13:41:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004D_01C9C1C6.3BD32AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Young, et al. I thought the draft was well written and an interesting area for discussion. I had the following general comments. a) A key goal of the work is to gather necessary network management information for offline complex path computation. Its logical to assume that the complex offline path computation might be centralized. It might be worth stating this as an assumption. b) We should not get to caught up in the details of proposed mechanisms or solutions. This is after all an architecture document. c) A hybrid approach to performing path computation in the network might be considered as there is motivation for performing path computation (simple versus complex) in different parts of the network. All planning and complex path computation could be performed by the offline and centralized PCE. Rapid restoration and local repair could then distributed to the local PCEs. Each distributed PCE can always signal the centralized PCE for reoptimization after the initial local path computation, in order to request a path computation that considers more complex constraints. d) Fundamentally we should use the right mechanism to distribute the data according to where it is needed. If some form of path computation is needed on LSRs, then in my opinion the necessary information should be distributed using the IGPs. We should be careful about recommending a solution that does not use the IGP at all. In a model where there are many nodes with path computation capabilities, we effectively need to flood information to each PCE. The IGPs have been designed for this. If we use PCEP to distribute information to go in the TED we may end up trying to turn PCEP into a flooding protocol that replaces the IGPs. e) As mentioned in point (b), we should avoid getting into solution details. As an architecture/requirements document, this draft should maybe not mention any protocols at all except in the context of what they already do and are used for. So, discussing using PCEP for data distribution, or discussing LDAP may be out of scope (even for an Appendix). But it is very valid to describe the data model, and I think that bit that is not generally flooded is a distributed database just like in the LDAP model. f) I made some minor comments and suggestions along the points above as change modifications in a word document. I will unicast the document to you shortly. Br, Dan. ------=_NextPart_000_004D_01C9C1C6.3BD32AF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Young, et al.

 

I thought the draft was well written and an interesting = area for discussion. I had the following general comments.

 

a) A key goal of the work is to gather necessary network management information for offline complex path computation. Its logical = to assume that the complex offline path computation might be centralized. = It might be worth stating this as an assumption.

 

b) We should not get to caught up in the details of = proposed mechanisms or solutions. This is after all an architecture document. =

 

c) A hybrid approach to performing path computation in = the network might be considered as there is motivation for performing path computation (simple versus complex) in different parts of the network. = All planning and complex path computation could be performed by the offline = and centralized PCE. Rapid restoration and local repair could then = distributed to the local PCEs. Each distributed PCE can always signal the centralized = PCE for reoptimization after the initial local path computation, in order to = request a path computation that considers more complex constraints. =

 

d) Fundamentally we should  use the right mechanism = to distribute the data according to where it is needed. If some form of = path computation is needed on LSRs, then in my opinion the necessary = information should  be distributed using the IGPs. We should be careful about recommending a solution that does not use the IGP at all. In a model = where there are many nodes with path computation capabilities, we effectively = need to flood information to each PCE. The IGPs have been designed for this. If = we use PCEP to distribute information to go in the TED we may end up trying to = turn PCEP into a flooding protocol that replaces the IGPs. =

 

e) As mentioned in point (b), we should avoid getting = into solution details. As an architecture/requirements document, this draft = should maybe not mention any protocols at all except in the context of what = they already do and are used for. So, discussing using PCEP for data = distribution, or discussing LDAP may be out of scope (even for an Appendix). But it is = very valid to describe the data model, and I think that bit that is not = generally flooded is a distributed database just like in the LDAP = model.

 

f) I made some minor comments and suggestions along the = points above as change modifications in a word document. I will unicast the = document to you shortly.

 

Br, Dan.

 

------=_NextPart_000_004D_01C9C1C6.3BD32AF0-- From i_bryskin@yahoo.com Tue Apr 21 10:57:51 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D7B28C0DC for ; Tue, 21 Apr 2009 10:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rj57XBSZatz for ; Tue, 21 Apr 2009 10:57:49 -0700 (PDT) Received: from web36802.mail.mud.yahoo.com (web36802.mail.mud.yahoo.com [209.191.85.53]) by core3.amsl.com (Postfix) with SMTP id D700A3A6AD0 for ; Tue, 21 Apr 2009 10:57:48 -0700 (PDT) Received: (qmail 33708 invoked by uid 60001); 21 Apr 2009 17:59:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240336745; bh=jN96kvF9y7DSrGDQZH4n/Rc8fmSQjiuy2vZTapGfyOg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jQl56HMMDWdf7AUCXqg4NQfdO5Db1CYwKqLZ5wUlC7nkulN009YbviUJD+q1Jk054iY3use3znCvhh/XJBgdV5oVQAvDsGLL5oJTUhEQuV0aRqIwQrlW0pGIF3Ry8G107csoTku2jBIDeoPSfpdLdfQclFFb6baGUJiJTUwQbQE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zpj3OqSLnzhw4x+eTJe7Yy64Gk26M7dQiFfZe5U3oGrWXpBpv+8TZ33t0tq4mOEG7jFYRCravMltfd9P8m7oWK3ZviPdV/cf9eE16rjEfS8U1g3vMJrUVPHKjOQkkT8fU2NkFws4dRIn57N+wmwSF/6JbZgE0gk+gUVyaNnW220=; Message-ID: <332299.33564.qm@web36802.mail.mud.yahoo.com> X-YMail-OSG: LisvV2QVM1lVQmT4Lj_ZQbvM2zlCFm_f629vNXcq8uxJ40e1dBSAVnjxjDhuQvzAXLH70RmVcr5H5g.T6NhaEWLPaSegMhEsGclhn.bvnpWeVyAWv4L.7w1dtcpWu4c59vv7DivP4fcyQTG_qcO0CCA63DO_7gglk1V49fx5ghB1rYFqmxN9_FaiheuZljCCViixteNulHYvU62UezZvGDN45eMEaAH81.PIX_CRN6OZD7lyBI8fT59P4B_RJK0c.kgWGDFxqkzX7jJAccnlqmdq5SNbyPFUYAOpZb8IqYSIjTG2qb1dLOKqciN93iAvNrCiyZU- Received: from [67.102.145.11] by web36802.mail.mud.yahoo.com via HTTP; Tue, 21 Apr 2009 10:59:05 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> <81761.9046.qm@web36807.mail.mud.yahoo.com> <003401c9bed1$aad507e0$500c7c0a@china.huawei.com> <49E7A504.2000808@grotto-networking.com> Date: Tue, 21 Apr 2009 10:59:05 -0700 (PDT) From: Igor Bryskin To: Greg Bernstein , Young Lee In-Reply-To: <49E7A504.2000808@grotto-networking.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-298974806-1240336745=:33564" Cc: pce@ietf.org Subject: Re: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 17:57:51 -0000 --0-298974806-1240336745=:33564 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AIn my comments I forgot to mention IMO a very good argument in fav= or and a strong drive for using an alternative to IGP-TE method for managin= g TED.=0A=0AConsider a "network planner" type of applications which try var= ious "what if?" scenarios on network topologies that do not (fully or parti= ally) exist yet but could be provisioned under certain circumstances. These= applications , of course, require numerous complex path computations and a= re great candidates to play the PCC role. But, as Eve Varma said on the la= st IETF, our path computations are only as good as our advertisements. So, = for a Network Planner it would be quite easy to use PCEP and send the neces= sary resource state information to a PCE for not yet existing links on beha= lf of not yet existing NEs, request the path computation(s) and then clean = up the PCE's TED. It is much more difficult (if not impossible) to do the s= ame things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and the= n flush them out when they are not needed anymore).=0A=0ASo there are two i= mportant byproducts that a PCEP based method of managing TED gives compared= to the IGP-TE method:=0Aa) ability to send TE info updates on behalf of un= existing links and NEs;=0Ab) determine the moment when all the necessary TE= info is installed in the PCE's TED, and it is possible to request the path= computations.=0A=0ANote that b) in its own right is quite non-trivial prob= lem to solve when one uses the IGP-TE method for the TED management.=0A=0AC= heers,=0AIgor=0A=0A=0A=0A=0A________________________________=0AFrom: Greg B= ernstein =0ATo: Young Lee =0A= Cc: Igor Bryskin =0ASent: Thursday, April 16, 2009 5:3= 7:08 PM=0ASubject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt=0A= =0AGreat to have help with the editing and concept development!=0A=0ACheers= =0A=0AGreg=0A=0AYoung Lee wrote: =0A =0AHi Igor,=0A =0AThanks a lot=0Afor y= our comments. They are=0Aall valuable ones and we can put most of them in t= he update. I will=0Asend you=0Athe WORD template of the existing version so= that you may be able to=0Aparticipate editing exercise with other co-autho= rs. Thanks. =0A =0ARegards,=0AYoung=0A =0A=0A______________________________= __=0A=0AFrom:Igor Bryskin=0A[mailto:i_bryskin@yahoo.com] =0ASent: Thursday,= April=0A16, 2009=0A2:15 PM=0ATo: Young Lee; pce@ietf.org=0ASubject: Commen= ts on=0Adraft-lee-pce-ted-alternatives-01.txt=0A =0AHi,=0A=0A=0A=0AHere is = my comments on the draft =E2=80=9CAlternative Approaches to Traffic Engine= ering Database Creation and Maintenance for Path Computation Elements=E2=80= =9D =0Ahttp://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt =0A = =0AGeneral=0Acomments.=0A =0A1. Everywhere you say IGP you mean, I am=0Asur= e, IGP-TE. It is worth to=0Amake it clear. I know that many people think th= at IGP-TE is an=0Aextension of IGP=0Afor TE purposes, but in fact, the two = are completely different=0Aprotocols with=0Acompletely different purposes: = one is to dynamically manage IP=0Aforwarding=0Atables, and the other is to = discover network resources of various=0Anetwork=0Alayers and use this infor= mation for constraint based path computations.=0AThe=0Aonly thing that the = two have in common is that they may share the same=0Ainstance=0Aof the IGP = flooding/synchronization machinery (even this becomes=0Aincreasingly=0Auntr= ue: today many use separate instances, look for the OSPF transport=0Ainstan= ce=0Aand multi-instance activities in the OSPF WG). Other then that, the tw= o=0Aprotocols have nothing in common; and this is especially true in the=0A= context of=0Athis document. It is quite reasonable to imagine, for example,= that=0Awithin the=0APCE Architecture one can completely eliminate use of = IGP-TE by using,=0Asay, PCEP instead, to send local resource updates direct= ly to PCE(s).=0A However, one will still need IGP for forwarding control pl= ane traffic.=0ASo=0Amy point here is that we want alternative methods to IG= P-TE and not to=0AIGP.=0A =0A2. I=E2=80=99d like to see in the draft a disc= ussion=0Aon why the flooding of TE=0Ainformation and the PCE architecture i= s not a good match. And this is=0Abecause=0Aflooding of any type of informa= tion works well on homogeneous=0Atopologies, where=0Aall participants origi= nate, distribute and use the information. That=E2=80=99s=0Awhy IP=0AOSPF, f= or example, works well: all OSPF speakers originate LSAs, flood=0Alocal=0Aa= nd remote LSAs and use them in route calculations. The PCE=0Aarchitecture i= s by=0Adefinition asymmetrical with respect to the information used in path= =0Acomputations: many elements originate, but only few use it, and the=0Afl= ooding=0Aunder these circumstances could be very inefficient for all these= =0Areasons that=0Ayou mentioned: memory, CPU, bandwidth, etc.=0A =0ASpecifi= c comments:=0A =0A1. You write:=0A=E2=80=9C This draft does not advocate t= hat the=0Aalternative methods=0Aspecified =0A in this draft should comple= tely replace=0Athe IGP as the=0Amethod of =0A creating the TED.=E2=80=9D= =0A =0AWhy not? I mean there is a variety of ways=0Ahow the alternative met= hods=0Acould relate to the IGP-TE method of managing TEDs. And I=E2=80=99d = like to see=0Aa=0Asection describing different use cases and examples of IG= P-TE and the=0Aalternatives=0Acooperating with each other. One such use cas= e is, for example, a=0Anetwork built=0Aof simple optical NEs managed by a t= iny control plane that consists of:=0A1) PCC instance to send updates to re= mote=0APCE(s) on local resources=0Astatus and also request path computation= s;=0A2) Very limited RSVP-TE instance for=0Asignaling fully explicit=0AEROs= provided by the PCE(s).=0A =0AIn this case IGP-TE is not involved at all.= =0A =0AThere could be different ways how the=0Aalternatives can cooperate = with=0AIGP-TE. One such cooperation, as you suggested, could be a split of= =0Awhat=0Ainformation is distributed by IGP-TE and what via alternatives. F= or=0Aexample, it=0Amakes sense to distribute =E2=80=9Cstatic=E2=80=9D (rare= ly modified) and sizable data =E2=80=93=0Ae.g. NE=0Aswitching asymmetricity= =E2=80=93 via methods other than IGP-TE, while more=0Afrequently=0Achanged= data via IGP-TE. This could significantly decrease the IGP-TE=0Ainformatio= n and its footprint on all speakers.=0A =0AAnother type of cooperation betw= een the=0AIGP-TE method and its=0Aalternatives is limiting number and type = of elements participating in=0AIGP-TE.=0AYour architectural option #3 requi= res inter-PCE TED synchronization.=0AHow about=0Ainterconnecting PCEs into = one or more rings via IP-IP tunnels and use=0Aan instance of IGP-TE over = the tunnels for the sole purpose of TED=0Asynchronization=0Abetween the PCE= s?=0A =0A2. You wrote:=0A =0A=E2=80=9CIn OSPF the information directly rela= ted to=0AIP =0A connectivity (and hence the control=0Acommunications plan= e=0Afor all =0A three technologies) is kept in the link=0Astate database= =0A(LSDB), while =0A additional information related to traffic=0Aengineer= ing used=0Aby MPLS =0A and GMPLS is kept in a (conceptually)=0Aseparate t= raffic=0Aengineering =0A database (TED)=E2=80=9D.=0A =0AThis is not accur= ate. All IP and non-IP=0Aadvertisements are stored in=0ALSDB. Additionally,= TE info is kept in TED.=0A =0A3. In section 2.0 you describe the advantage= s=0Aof using alternative to=0AIGP-TE methods. You also need here to clearly= state the disadvantages,=0Awhich=0Aare:=0Aa) necessity of mechanisms that= we take for=0Agranted when use=0AIGP-TE: removal of stale information, rel= iable delivery of updates to=0Aall=0Aparticipants; recovery after reboots/c= rashes/upgrades, etc.=0Ab) additional security concerns;=0Ac) protocol to d= iscover PCEs that are capable=0Aand willing to accept=0Adirect updates;=0Ad= ) protocol to send the updates;=0Aetc.=0A =0A4. Why not PCEP?=0A =0AThis is= not a requirement document. So I=0Athink it would be beneficial=0Ato sugge= st a solution for the protocol to be used by NEs to send=0Aresource=0Aupdat= es to PCE(s). Considering that this protocol is supposed to:=0Aa) discover = PCE(s) capable and willing to=0Areceive such updates;=0Ab) maintain session= s between NEs and PCE(s);=0Ac) address all the security concerns for=0APCE= (s) to accept such=0Aupdates;=0Ad) guarantee reliable delivery of the updat= es;=0A =0Awhy not to extend PCEP for this purpose since=0Ait is already doi= ng all=0Athese things?=0A =0ACheers,=0AIgor=0A =0A=0A-- =0A=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0ADr Greg B= ernstein, Grotto Networking (510) 573-2237=0A=0A=0A --0-298974806-1240336745=:33564 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

In my comments I forgot to mention IMO a very = good argument in favor and a strong drive for using an alternative to IGP-T= E method for managing TED.

Consider a "network planner" type of appl= ications which try various "what if?" scenarios on network topologies that = do not (fully or partially) exist yet but could be provisioned under certai= n circumstances. These applications , of course, require numerous complex p= ath computations and are great candidates  to play the PCC role. But, = as Eve Varma said on the last IETF, our path computations are only as good = as our advertisements. So, for a Network Planner it would be quite easy to = use PCEP and send the necessary resource state information to a PCE for not= yet existing links on behalf of not yet existing NEs, request the path computation(s) and then clean up the PCE's TED. It is much more difficult = (if not impossible) to do the same things using IGP-TE (e.g. have unexistin= g NEs originate TE LSAs and then flush them out when they are not needed an= ymore).

So there are two important byproducts that a PCEP based meth= od of managing TED gives compared to the IGP-TE method:
a) ability to se= nd TE info updates on behalf of unexisting links and NEs;
b) determine t= he moment when all the necessary TE info is installed in the PCE's TED, and= it is possible to request the path computations.

Note that b) in it= s own right is quite non-trivial problem to solve when one uses the IGP-TE = method for the TED management.

Cheers,
Igor
From: Greg Bernstein <gregb@gro= tto-networking.com>
To:<= /b> Young Lee <ylee@huawei.com>
Cc: Igor Bryskin <i_bryskin@yahoo.com>
Sent: Thursday, April 16, 2009 5:37:08= PM
Subject: Re: Commen= ts on draft-lee-pce-ted-alternatives-01.txt

=0A=0A=0A=0A =0A= =0AGreat to have help with the editing and concept development!
=0A
= =0ACheers
=0A
=0AGreg
=0A
=0AYoung Lee wrote:=0A
=0A =0A =0A=0A =0A
=0A

H= i Igor,

=0A

 

=0A

Thanks a lot=0Afor your comments. They ar= e=0Aall valuable ones and we can put most of them in the update. I will=0As= end you=0Athe WORD template of the existing version so that you may be able= to=0Aparticipate editing exercise with other co-authors. Thanks.

=0A

Regards,

=0A

<= font color=3D"navy" size=3D"2" face=3D"Arial">Young

=0A

 

=0A
=0A
=0A

From: Igor Bryskin=0A[mailto:i_bryskin@y= ahoo.com]
=0A Sent: Thursday, April=0A16, 2009=0A2:15 PM
=0A To: Young Lee;=0Apce@ietf.org
=0A Subject: Comments on=0Adraft-lee-pce-ted-alternativ= es-01.txt

=0A

 

=0A 
Hi,



Here is my comme=
nts on  the draft =E2=80=9CAlternative Approaches to Traffic Engineeri=
ng Database Creation and Maintenance for Path Computation Elements=E2=80=9D=
=0A

http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt= =0A

=0A

 

=0A

General=0Acomment= s.

=0A

 

= =0A

1. Everywhere you say IGP you mean, I am=0Asure= , IGP-TE. It is worth to=0Amake it clear. I know that many people think tha= t IGP-TE is an=0Aextension of IGP=0Afor TE purposes, but in fact, the two a= re completely different=0Aprotocols with=0Acompletely different purposes: o= ne is to dynamically manage IP=0Aforwarding=0Atables, and the other is to d= iscover network resources of various=0Anetwork=0Alayers and use this inform= ation for constraint based path computations.=0AThe=0Aonly thing that the t= wo have in common is that they may share the same=0Ainstance=0Aof the IGP f= looding/synchronization machinery (even this becomes=0Aincreasingly=0Auntru= e: today many use separate instances, look for the OSPF transport=0Ainstanc= e=0Aand multi-instance activities in the OSPF WG). Other then that, the two= =0Aprotocols have nothing in common; and this is especially true in the=0Ac= ontext of=0Athis document. It is quite reasonable to imagine, for example, = that=0Awithin the=0APCE Architecture one can completely eliminate use = of IGP-TE by using,=0Asay, PCEP instead, to send local resource updates di= rectly to PCE(s).=0A However, one will still need IGP for forwarding c= ontrol plane traffic.=0ASo=0Amy point here is that we want alternative meth= ods to IGP-TE and not to=0AIGP.

=0A

 

=0A

2. I=E2=80=99d like= to see in the draft a discussion=0Aon why the flooding of TE=0Ainformation= and the PCE architecture is not a good match. And this is=0Abecause=0Afloo= ding of any type of information works well on homogeneous=0Atopologies, whe= re=0Aall participants originate, distribute and use the information. That= =E2=80=99s=0Awhy IP=0AOSPF, for example, works well: all OSPF speakers orig= inate LSAs, flood=0Alocal=0Aand remote LSAs and use them in route calculati= ons. The PCE=0Aarchitecture is by=0Adefinition asymmetrical with respect to= the information used in path=0Acomputations: many elements originate, but = only few use it, and the=0Aflooding=0Aunder these circumstances could be ve= ry inefficient for all these=0Areasons that=0Ayou mentioned: memory, CPU, b= andwidth, etc.

=0A

 <= /font>

=0A

Specific comments:

= =0A

 

=0A

1. You write:

=0A

=E2=80= =9C  This draft does not advocate that the=0Aalternative methods=0Aspe= cified

=0A

   in this = draft should completely replace=0Athe IGP as the=0Amethod of =

=0A

=    creating the TED.=E2=80=9D

=0A

 

=0A <= p class=3D"MsoNormal">Why not? I mean there is a variety of ways=0Ahow the = alternative methods=0Acould relate to the IGP-TE method of managing TEDs. A= nd I=E2=80=99d like to see=0Aa=0Asection describing different use cases and= examples of IGP-TE and the=0Aalternatives=0Acooperating with each other. O= ne such use case is, for example, a=0Anetwork built=0Aof simple optical NEs= managed by a tiny control plane that consists of:

=0A <= p class=3D"MsoNormal">1) PCC instance to send updates to remote=0APCE(s) on= local resources=0Astatus and also request path computations;=

=0A

= 2) Very limited RSVP-TE instance for=0Asig= naling fully explicit=0AEROs  provided by the PCE(s). =0A

 

=0A

In this case IGP-TE is not involved at all.

=0A =

 

=0A

 

=0A

Another type of co= operation between the=0AIGP-TE method and its=0Aalternatives is limiting nu= mber and type of elements participating in=0AIGP-TE.=0AYour architectural o= ption #3 requires inter-PCE TED synchronization.=0AHow about=0Ainterconnect= ing PCEs into one or more rings  via IP-IP tunnels and use=0Aan  = instance of IGP-TE over the tunnels for the sole purpose of TED=0Asynchroni= zation=0Abetween the PCEs?

=0A

&n= bsp;

=0A

2. You wrote:

=0A

 

=0A

=E2=80=9CIn OSPF the information directly related to=0AIP

=0A

   connectivity (and= hence the control=0Acommunications plane=0Afor all

=0A =

   three technologies) is kept in the lin= k=0Astate database=0A(LSDB), while

=0A

   additional information related to traffic=0Aengineering= used=0Aby MPLS

=0A

 &nbs= p; and GMPLS is kept in a (conceptually)=0Aseparate traffic=0Aengineering <= /span>

=0A

   database (TED)= =E2=80=9D.

=0A

 

=0A

This is not accurate. All IP and non-IP= =0Aadvertisements are stored in=0ALSDB. Additionally, TE info is kept in TE= D.

=0A

 

= =0A

3. In section 2.0 you describe the advantages= =0Aof using alternative to=0AIGP-TE methods. You also need here to clearly = state the disadvantages,=0Awhich=0Aare:

=0A

a)  necessity of mechanisms that we take for=0Agranted when= use=0AIGP-TE: removal of stale information, reliable delivery of updates t= o=0Aall=0Aparticipants; recovery after reboots/crashes/upgrades, etc.

=0A

b) additional security concerns;

=0A

c) protocol to discover PCEs t= hat are capable=0Aand willing to accept=0Adirect updates;

= =0A

d) protocol to send the updates;=

=0A

= etc.

=0A

 

=0A

4. Why not PC= EP?

=0A

 

= =0A

This is not a requirement document. So I=0Athin= k it would be beneficial=0Ato suggest a solution for the protocol to be use= d by NEs to send=0Aresource=0Aupdates to PCE(s). Considering that this prot= ocol is supposed to:

=0A

a) disco= ver PCE(s) capable and willing to=0Areceive such updates;

= =0A

b) maintain sessions between NEs and PCE(s);

=0A

c) address all the security co= ncerns  for=0APCE(s) to accept such=0Aupdates;

=0A =

d) guarantee reliable delivery of the updates;

=0A

 

=0A

why not to extend PCEP for this purpose since=0Ait is al= ready doing all=0Athese things?

=0A

 

=0A

Cheers,

=0A

Igor

=0A

 

=0A
=0A
=0A
=0A<= pre class=3D"moz-signature">--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networ= king (510) 573-2237

=0A

=0A=0A --0-298974806-1240336745=:33564-- From peng.he.2000@gmail.com Wed Apr 22 07:03:11 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C973A68BA for ; Wed, 22 Apr 2009 07:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfeZU91bJ3sx for ; Wed, 22 Apr 2009 07:03:09 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id 6105528C529 for ; Wed, 22 Apr 2009 07:00:50 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so1422673fkq.5 for ; Wed, 22 Apr 2009 07:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tGXZ1ef920wYg1+SosLExabyjRChvuHyi5GxxeEoUpE=; b=dtCw22MgVa/GcxsLE056a07rqiLoJlm4SOb0VhhRDexO4rV47iq30NXSKzlgPd9T3V b+wIl9x4Bb5RVRSb6HChnysJIKwQIrHPNvg1M40JNhjJsd0Jv1yJd8Lrg7S9rc2Rif/C 339BAgt+68KXhtAyGAH5Vg9iAqDoEEaI72heo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aknqiraWDmUx8jCii77lTr4JUJ1VKffM4YgAMsEsKr8gRuiNeGgrlm8kLkx5S1a3q+ gVpceClodRf/sAqvAS0Ns1Crc5sbruD85jJ1fdj34sWFbKfTQ24CnheDWnptG+XlqOGf hZONH2fNaX2lSDfd7UCWkEnx2Rr5NxCTmNqMU= MIME-Version: 1.0 Received: by 10.103.226.20 with SMTP id d20mr4593776mur.8.1240408926654; Wed, 22 Apr 2009 07:02:06 -0700 (PDT) In-Reply-To: <332299.33564.qm@web36802.mail.mud.yahoo.com> References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> <81761.9046.qm@web36807.mail.mud.yahoo.com> <003401c9bed1$aad507e0$500c7c0a@china.huawei.com> <49E7A504.2000808@grotto-networking.com> <332299.33564.qm@web36802.mail.mud.yahoo.com> Date: Wed, 22 Apr 2009 10:02:06 -0400 Message-ID: <406e32c00904220702y95486f6p65270f504b6702e9@mail.gmail.com> From: Peng He To: Young Lee Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "pce@ietf.org" Subject: Re: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 14:03:11 -0000 Hello Young, This is definitely a very interesting draft. Have a question here: you mentioned at page 13 that "One key function is to ensure that the network information obtained from nodes or elsewhere is relatively timely, or not stale "; I'd like to know if you have considered how to make sure the obtained information is NOT stale? what is the metric to justify it? what is the bottom line?say, 1 second, or i minute? maybe the question is too detail :) Thanks a lot. Regards, Peng On Tue, Apr 21, 2009 at 1:59 PM, Igor Bryskin wrote: > Hi, > > In my comments I forgot to mention IMO a very good argument in favor and = a > strong drive for using an alternative to IGP-TE method for managing TED. > > Consider a "network planner" type of applications which try various "what > if?" scenarios on network topologies that do not (fully or partially) exi= st > yet but could be provisioned under certain circumstances. These applicati= ons > , of course, require numerous complex path computations and are great > candidates=A0 to play the PCC role. But, as Eve Varma said on the last IE= TF, > our path computations are only as good as our advertisements. So, for a > Network Planner it would be quite easy to use PCEP and send the necessary > resource state information to a PCE for not yet existing links on behalf = of > not yet existing NEs, request the path computation(s) and then clean up t= he > PCE's TED. It is much more difficult (if not impossible) to do the same > things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then > flush them out when they are not needed anymore). > > So there are two important byproducts that a PCEP based method of managin= g > TED gives compared to the IGP-TE method: > a) ability to send TE info updates on behalf of unexisting links and NEs; > b) determine the moment when all the necessary TE info is installed in th= e > PCE's TED, and it is possible to request the path computations. > > Note that b) in its own right is quite non-trivial problem to solve when = one > uses the IGP-TE method for the TED management. > > Cheers, > Igor > > ________________________________ > From: Greg Bernstein > To: Young Lee > Cc: Igor Bryskin > Sent: Thursday, April 16, 2009 5:37:08 PM > Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt > > Great to have help with the editing and concept development! > > Cheers > > Greg > > Young Lee wrote: > > Hi Igor, > > > > Thanks a lot for your comments. They are all valuable ones and we can put > most of them in the update. I will send you the WORD template of the > existing version so that you may be able to participate editing exercise > with other co-authors. Thanks. > > > > Regards, > > Young > > > > ________________________________ > > From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > Sent: Thursday, April 16, 2009 2:15 PM > To: Young Lee; pce@ietf.org > Subject: Comments on draft-lee-pce-ted-alternatives-01.txt > > > > Hi, > > > > Here is my comments on=A0 the draft =93Alternative Approaches to Traffic > Engineering Database Creation and Maintenance for Path Computation Elemen= ts=94 > > http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt > > > > General comments. > > > > 1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to mak= e > it clear. I know that many people think that IGP-TE is an extension of IG= P > for TE purposes, but in fact, the two are completely different protocols > with completely different purposes: one is to dynamically manage IP > forwarding tables, and the other is to discover network resources of vari= ous > network layers and use this information for constraint based path > computations. The only thing that the two have in common is that they may > share the same instance of the IGP flooding/synchronization machinery (ev= en > this becomes increasingly untrue: today many use separate instances, look > for the OSPF transport instance and multi-instance activities in the OSPF > WG). Other then that, the two protocols have nothing in common; and this = is > especially true in the context of this document. It is quite reasonable t= o > imagine, for example, that within the PCE Architecture one can completely > eliminate use=A0 of IGP-TE by using, say, PCEP instead, to send local res= ource > updates directly to PCE(s). =A0However, one will still need IGP for forwa= rding > control plane traffic. So my point here is that we want alternative metho= ds > to IGP-TE and not to IGP. > > > > 2. I=92d like to see in the draft a discussion on why the flooding of TE > information and the PCE architecture is not a good match. And this is > because flooding of any type of information works well on homogeneous > topologies, where all participants originate, distribute and use the > information. That=92s why IP OSPF, for example, works well: all OSPF spea= kers > originate LSAs, flood local and remote LSAs and use them in route > calculations. The PCE architecture is by definition asymmetrical with > respect to the information used in path computations: many elements > originate, but only few use it, and the flooding under these circumstance= s > could be very inefficient for all these reasons that you mentioned: memor= y, > CPU, bandwidth, etc. > > > > Specific comments: > > > > 1. You write: > > =93=A0 This draft does not advocate that the alternative methods specifie= d > > =A0=A0 in this draft should completely replace the IGP as the method of > > =A0=A0 creating the TED.=94 > > > > Why not? I mean there is a variety of ways how the alternative methods co= uld > relate to the IGP-TE method of managing TEDs. And I=92d like to see a sec= tion > describing different use cases and examples of IGP-TE and the alternative= s > cooperating with each other. One such use case is, for example, a network > built of simple optical NEs managed by a tiny control plane that consists > of: > > 1) PCC instance to send updates to remote PCE(s) on local resources statu= s > and also request path computations; > > 2) Very limited RSVP-TE instance for signaling fully explicit EROs=A0 pro= vided > by the PCE(s). > > > > In this case IGP-TE is not involved at all. > > > > There could be different ways how the alternatives can cooperate with > IGP-TE. One such cooperation, as you suggested, could be a split of what > information is distributed by IGP-TE and what via alternatives. For examp= le, > it makes sense to distribute =93static=94 (rarely modified) and sizable d= ata =96 > e.g. NE switching asymmetricity =96 via methods other than IGP-TE, while = more > frequently changed data via IGP-TE. This could significantly decrease the > IGP-TE information and its footprint on all speakers. > > > > Another type of cooperation between the IGP-TE method and its alternative= s > is limiting number and type of elements participating in IGP-TE. Your > architectural option #3 requires inter-PCE TED synchronization. How about > interconnecting PCEs into one or more rings=A0 via IP-IP tunnels and use = an > instance of IGP-TE over the tunnels for the sole purpose of TED > synchronization between the PCEs? > > > > 2. You wrote: > > > > =93In OSPF the information directly related to IP > > =A0=A0 connectivity (and hence the control communications plane for all > > =A0=A0 three technologies) is kept in the link state database (LSDB), whi= le > > =A0=A0 additional information related to traffic engineering used by MPLS > > =A0=A0 and GMPLS is kept in a (conceptually) separate traffic engineering > > =A0=A0 database (TED)=94. > > > > This is not accurate. All IP and non-IP advertisements are stored in LSDB= . > Additionally, TE info is kept in TED. > > > > 3. In section 2.0 you describe the advantages of using alternative to IGP= -TE > methods. You also need here to clearly state the disadvantages, which are= : > > a) =A0necessity of mechanisms that we take for granted when use IGP-TE: > removal of stale information, reliable delivery of updates to all > participants; recovery after reboots/crashes/upgrades, etc. > > b) additional security concerns; > > c) protocol to discover PCEs that are capable and willing to accept direc= t > updates; > > d) protocol to send the updates; > > etc. > > > > 4. Why not PCEP? > > > > This is not a requirement document. So I think it would be beneficial to > suggest a solution for the protocol to be used by NEs to send resource > updates to PCE(s). Considering that this protocol is supposed to: > > a) discover PCE(s) capable and willing to receive such updates; > > b) maintain sessions between NEs and PCE(s); > > c) address all the security concerns=A0 for PCE(s) to accept such updates= ; > > d) guarantee reliable delivery of the updates; > > > > why not to extend PCEP for this purpose since it is already doing all the= se > things? > > > > Cheers, > > Igor > > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From gregb@grotto-networking.com Thu Apr 23 08:22:43 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A92E3A72C4 for ; Thu, 23 Apr 2009 08:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT80iLyhgWyO for ; Thu, 23 Apr 2009 08:22:41 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id EA2453A72C7 for ; Thu, 23 Apr 2009 08:22:23 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n3NFNN2D042404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 08:23:26 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <49F087EB.3020007@grotto-networking.com> Date: Thu, 23 Apr 2009 08:23:23 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Peng He References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> <81761.9046.qm@web36807.mail.mud.yahoo.com> <003401c9bed1$aad507e0$500c7c0a@china.huawei.com> <49E7A504.2000808@grotto-networking.com> <332299.33564.qm@web36802.mail.mud.yahoo.com> <406e32c00904220702y95486f6p65270f504b6702e9@mail.gmail.com> In-Reply-To: <406e32c00904220702y95486f6p65270f504b6702e9@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------050500040701060307000400" Cc: "pce@ietf.org" , Young Lee Subject: Re: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:22:43 -0000 This is a multi-part message in MIME format. --------------050500040701060307000400 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Peng, I think Young is out of the office this week. On the statement "One key function is to ensure that the network information obtained from nodes or elsewhere is relatively timely, or not stale " . This is similar to the requirements we see on link state IGPs and seemed appropriate here as an important maintenance procedure. By the way link state IPGs use two mechanisms: (a) link state update messages (there is some rate control on how often these can be sent, but the latency can be significantly under 1 second), (b) aging of link state advertisements (LSAs) -- OSPF terminology --. In the "aging" mechanism information gets removed from the TED if not refreshed (typically many minutes). However we didn't want to get into implementation details. Best Regards Greg (trying to fill in for Young) Peng He wrote: > Hello Young, > > This is definitely a very interesting draft. Have a question here: > you mentioned at page 13 that "One key function is to ensure that the > network information obtained from nodes or elsewhere is relatively > timely, or not stale "; > > I'd like to know if you have considered how to make sure the obtained > information is NOT stale? what is the metric to justify it? what is > the bottom line?say, 1 second, or i minute? maybe the question is too > detail :) Thanks a lot. > > > Regards, > Peng > > On Tue, Apr 21, 2009 at 1:59 PM, Igor Bryskin wrote: > >> Hi, >> >> In my comments I forgot to mention IMO a very good argument in favor and a >> strong drive for using an alternative to IGP-TE method for managing TED. >> >> Consider a "network planner" type of applications which try various "what >> if?" scenarios on network topologies that do not (fully or partially) exist >> yet but could be provisioned under certain circumstances. These applications >> , of course, require numerous complex path computations and are great >> candidates to play the PCC role. But, as Eve Varma said on the last IETF, >> our path computations are only as good as our advertisements. So, for a >> Network Planner it would be quite easy to use PCEP and send the necessary >> resource state information to a PCE for not yet existing links on behalf of >> not yet existing NEs, request the path computation(s) and then clean up the >> PCE's TED. It is much more difficult (if not impossible) to do the same >> things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then >> flush them out when they are not needed anymore). >> >> So there are two important byproducts that a PCEP based method of managing >> TED gives compared to the IGP-TE method: >> a) ability to send TE info updates on behalf of unexisting links and NEs; >> b) determine the moment when all the necessary TE info is installed in the >> PCE's TED, and it is possible to request the path computations. >> >> Note that b) in its own right is quite non-trivial problem to solve when one >> uses the IGP-TE method for the TED management. >> >> Cheers, >> Igor >> >> ________________________________ >> From: Greg Bernstein >> To: Young Lee >> Cc: Igor Bryskin >> Sent: Thursday, April 16, 2009 5:37:08 PM >> Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt >> >> Great to have help with the editing and concept development! >> >> Cheers >> >> Greg >> >> Young Lee wrote: >> >> Hi Igor, >> >> >> >> Thanks a lot for your comments. They are all valuable ones and we can put >> most of them in the update. I will send you the WORD template of the >> existing version so that you may be able to participate editing exercise >> with other co-authors. Thanks. >> >> >> >> Regards, >> >> Young >> >> >> >> ________________________________ >> >> From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >> Sent: Thursday, April 16, 2009 2:15 PM >> To: Young Lee; pce@ietf.org >> Subject: Comments on draft-lee-pce-ted-alternatives-01.txt >> >> >> >> Hi, >> >> >> >> Here is my comments on the draft “Alternative Approaches to Traffic >> Engineering Database Creation and Maintenance for Path Computation Elements” >> >> http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt >> >> >> >> General comments. >> >> >> >> 1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to make >> it clear. I know that many people think that IGP-TE is an extension of IGP >> for TE purposes, but in fact, the two are completely different protocols >> with completely different purposes: one is to dynamically manage IP >> forwarding tables, and the other is to discover network resources of various >> network layers and use this information for constraint based path >> computations. The only thing that the two have in common is that they may >> share the same instance of the IGP flooding/synchronization machinery (even >> this becomes increasingly untrue: today many use separate instances, look >> for the OSPF transport instance and multi-instance activities in the OSPF >> WG). Other then that, the two protocols have nothing in common; and this is >> especially true in the context of this document. It is quite reasonable to >> imagine, for example, that within the PCE Architecture one can completely >> eliminate use of IGP-TE by using, say, PCEP instead, to send local resource >> updates directly to PCE(s). However, one will still need IGP for forwarding >> control plane traffic. So my point here is that we want alternative methods >> to IGP-TE and not to IGP. >> >> >> >> 2. I’d like to see in the draft a discussion on why the flooding of TE >> information and the PCE architecture is not a good match. And this is >> because flooding of any type of information works well on homogeneous >> topologies, where all participants originate, distribute and use the >> information. That’s why IP OSPF, for example, works well: all OSPF speakers >> originate LSAs, flood local and remote LSAs and use them in route >> calculations. The PCE architecture is by definition asymmetrical with >> respect to the information used in path computations: many elements >> originate, but only few use it, and the flooding under these circumstances >> could be very inefficient for all these reasons that you mentioned: memory, >> CPU, bandwidth, etc. >> >> >> >> Specific comments: >> >> >> >> 1. You write: >> >> “ This draft does not advocate that the alternative methods specified >> >> in this draft should completely replace the IGP as the method of >> >> creating the TED.” >> >> >> >> Why not? I mean there is a variety of ways how the alternative methods could >> relate to the IGP-TE method of managing TEDs. And I’d like to see a section >> describing different use cases and examples of IGP-TE and the alternatives >> cooperating with each other. One such use case is, for example, a network >> built of simple optical NEs managed by a tiny control plane that consists >> of: >> >> 1) PCC instance to send updates to remote PCE(s) on local resources status >> and also request path computations; >> >> 2) Very limited RSVP-TE instance for signaling fully explicit EROs provided >> by the PCE(s). >> >> >> >> In this case IGP-TE is not involved at all. >> >> >> >> There could be different ways how the alternatives can cooperate with >> IGP-TE. One such cooperation, as you suggested, could be a split of what >> information is distributed by IGP-TE and what via alternatives. For example, >> it makes sense to distribute “static” (rarely modified) and sizable data – >> e.g. NE switching asymmetricity – via methods other than IGP-TE, while more >> frequently changed data via IGP-TE. This could significantly decrease the >> IGP-TE information and its footprint on all speakers. >> >> >> >> Another type of cooperation between the IGP-TE method and its alternatives >> is limiting number and type of elements participating in IGP-TE. Your >> architectural option #3 requires inter-PCE TED synchronization. How about >> interconnecting PCEs into one or more rings via IP-IP tunnels and use an >> instance of IGP-TE over the tunnels for the sole purpose of TED >> synchronization between the PCEs? >> >> >> >> 2. You wrote: >> >> >> >> “In OSPF the information directly related to IP >> >> connectivity (and hence the control communications plane for all >> >> three technologies) is kept in the link state database (LSDB), while >> >> additional information related to traffic engineering used by MPLS >> >> and GMPLS is kept in a (conceptually) separate traffic engineering >> >> database (TED)”. >> >> >> >> This is not accurate. All IP and non-IP advertisements are stored in LSDB. >> Additionally, TE info is kept in TED. >> >> >> >> 3. In section 2.0 you describe the advantages of using alternative to IGP-TE >> methods. You also need here to clearly state the disadvantages, which are: >> >> a) necessity of mechanisms that we take for granted when use IGP-TE: >> removal of stale information, reliable delivery of updates to all >> participants; recovery after reboots/crashes/upgrades, etc. >> >> b) additional security concerns; >> >> c) protocol to discover PCEs that are capable and willing to accept direct >> updates; >> >> d) protocol to send the updates; >> >> etc. >> >> >> >> 4. Why not PCEP? >> >> >> >> This is not a requirement document. So I think it would be beneficial to >> suggest a solution for the protocol to be used by NEs to send resource >> updates to PCE(s). Considering that this protocol is supposed to: >> >> a) discover PCE(s) capable and willing to receive such updates; >> >> b) maintain sessions between NEs and PCE(s); >> >> c) address all the security concerns for PCE(s) to accept such updates; >> >> d) guarantee reliable delivery of the updates; >> >> >> >> why not to extend PCEP for this purpose since it is already doing all these >> things? >> >> >> >> Cheers, >> >> Igor >> >> >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >> >> > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------050500040701060307000400 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Peng, I think Young is out of the office this week.
On the statement "One key function is to ensure that the network information obtained from nodes or elsewhere is relatively timely, or not stale " .
This is similar to the requirements we see on link state IGPs and seemed appropriate here as an important maintenance procedure.

By the way link state IPGs use two mechanisms: (a) link state update messages (there is some rate control on how often these can be sent, but the latency can be significantly under 1 second), (b) aging of link state advertisements (LSAs) -- OSPF terminology --. In the "aging" mechanism information gets removed from the TED if not refreshed (typically many minutes). However we didn't want to get into implementation details.

Best Regards

Greg (trying to fill in for Young)

Peng He wrote: 
Hello Young,

This is definitely a very interesting draft. Have a question here:
you mentioned at page 13 that "One key function is to ensure that the
network information obtained from nodes or elsewhere is relatively
timely, or not stale ";

I'd like to know if you have considered how to make sure the obtained
information is NOT stale? what is the metric to justify it? what is
the bottom line?say, 1 second, or i minute? maybe the question is too
detail :) Thanks a lot.


Regards,
Peng

On Tue, Apr 21, 2009 at 1:59 PM, Igor Bryskin <i_bryskin@yahoo.com> wrote:
  
Hi,

In my comments I forgot to mention IMO a very good argument in favor and a
strong drive for using an alternative to IGP-TE method for managing TED.

Consider a "network planner" type of applications which try various "what
if?" scenarios on network topologies that do not (fully or partially) exist
yet but could be provisioned under certain circumstances. These applications
, of course, require numerous complex path computations and are great
candidates  to play the PCC role. But, as Eve Varma said on the last IETF,
our path computations are only as good as our advertisements. So, for a
Network Planner it would be quite easy to use PCEP and send the necessary
resource state information to a PCE for not yet existing links on behalf of
not yet existing NEs, request the path computation(s) and then clean up the
PCE's TED. It is much more difficult (if not impossible) to do the same
things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then
flush them out when they are not needed anymore).

So there are two important byproducts that a PCEP based method of managing
TED gives compared to the IGP-TE method:
a) ability to send TE info updates on behalf of unexisting links and NEs;
b) determine the moment when all the necessary TE info is installed in the
PCE's TED, and it is possible to request the path computations.

Note that b) in its own right is quite non-trivial problem to solve when one
uses the IGP-TE method for the TED management.

Cheers,
Igor

________________________________
From: Greg Bernstein <gregb@grotto-networking.com>
To: Young Lee <ylee@huawei.com>
Cc: Igor Bryskin <i_bryskin@yahoo.com>
Sent: Thursday, April 16, 2009 5:37:08 PM
Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt

Great to have help with the editing and concept development!

Cheers

Greg

Young Lee wrote:

Hi Igor,



Thanks a lot for your comments. They are all valuable ones and we can put
most of them in the update. I will send you the WORD template of the
existing version so that you may be able to participate editing exercise
with other co-authors. Thanks.



Regards,

Young



________________________________

From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
Sent: Thursday, April 16, 2009 2:15 PM
To: Young Lee; pce@ietf.org
Subject: Comments on draft-lee-pce-ted-alternatives-01.txt



Hi,



Here is my comments on  the draft “Alternative Approaches to Traffic
Engineering Database Creation and Maintenance for Path Computation Elements”

http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt



General comments.



1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to make
it clear. I know that many people think that IGP-TE is an extension of IGP
for TE purposes, but in fact, the two are completely different protocols
with completely different purposes: one is to dynamically manage IP
forwarding tables, and the other is to discover network resources of various
network layers and use this information for constraint based path
computations. The only thing that the two have in common is that they may
share the same instance of the IGP flooding/synchronization machinery (even
this becomes increasingly untrue: today many use separate instances, look
for the OSPF transport instance and multi-instance activities in the OSPF
WG). Other then that, the two protocols have nothing in common; and this is
especially true in the context of this document. It is quite reasonable to
imagine, for example, that within the PCE Architecture one can completely
eliminate use  of IGP-TE by using, say, PCEP instead, to send local resource
updates directly to PCE(s).  However, one will still need IGP for forwarding
control plane traffic. So my point here is that we want alternative methods
to IGP-TE and not to IGP.



2. I’d like to see in the draft a discussion on why the flooding of TE
information and the PCE architecture is not a good match. And this is
because flooding of any type of information works well on homogeneous
topologies, where all participants originate, distribute and use the
information. That’s why IP OSPF, for example, works well: all OSPF speakers
originate LSAs, flood local and remote LSAs and use them in route
calculations. The PCE architecture is by definition asymmetrical with
respect to the information used in path computations: many elements
originate, but only few use it, and the flooding under these circumstances
could be very inefficient for all these reasons that you mentioned: memory,
CPU, bandwidth, etc.



Specific comments:



1. You write:

“  This draft does not advocate that the alternative methods specified

   in this draft should completely replace the IGP as the method of

   creating the TED.”



Why not? I mean there is a variety of ways how the alternative methods could
relate to the IGP-TE method of managing TEDs. And I’d like to see a section
describing different use cases and examples of IGP-TE and the alternatives
cooperating with each other. One such use case is, for example, a network
built of simple optical NEs managed by a tiny control plane that consists
of:

1) PCC instance to send updates to remote PCE(s) on local resources status
and also request path computations;

2) Very limited RSVP-TE instance for signaling fully explicit EROs  provided
by the PCE(s).



In this case IGP-TE is not involved at all.



There could be different ways how the alternatives can cooperate with
IGP-TE. One such cooperation, as you suggested, could be a split of what
information is distributed by IGP-TE and what via alternatives. For example,
it makes sense to distribute “static” (rarely modified) and sizable data –
e.g. NE switching asymmetricity – via methods other than IGP-TE, while more
frequently changed data via IGP-TE. This could significantly decrease the
IGP-TE information and its footprint on all speakers.



Another type of cooperation between the IGP-TE method and its alternatives
is limiting number and type of elements participating in IGP-TE. Your
architectural option #3 requires inter-PCE TED synchronization. How about
interconnecting PCEs into one or more rings  via IP-IP tunnels and use an
instance of IGP-TE over the tunnels for the sole purpose of TED
synchronization between the PCEs?



2. You wrote:



“In OSPF the information directly related to IP

   connectivity (and hence the control communications plane for all

   three technologies) is kept in the link state database (LSDB), while

   additional information related to traffic engineering used by MPLS

   and GMPLS is kept in a (conceptually) separate traffic engineering

   database (TED)”.



This is not accurate. All IP and non-IP advertisements are stored in LSDB.
Additionally, TE info is kept in TED.



3. In section 2.0 you describe the advantages of using alternative to IGP-TE
methods. You also need here to clearly state the disadvantages, which are:

a)  necessity of mechanisms that we take for granted when use IGP-TE:
removal of stale information, reliable delivery of updates to all
participants; recovery after reboots/crashes/upgrades, etc.

b) additional security concerns;

c) protocol to discover PCEs that are capable and willing to accept direct
updates;

d) protocol to send the updates;

etc.



4. Why not PCEP?



This is not a requirement document. So I think it would be beneficial to
suggest a solution for the protocol to be used by NEs to send resource
updates to PCE(s). Considering that this protocol is supposed to:

a) discover PCE(s) capable and willing to receive such updates;

b) maintain sessions between NEs and PCE(s);

c) address all the security concerns  for PCE(s) to accept such updates;

d) guarantee reliable delivery of the updates;



why not to extend PCEP for this purpose since it is already doing all these
things?



Cheers,

Igor



--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237



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


    

  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------050500040701060307000400-- From gregimirsky@gmail.com Thu Apr 23 10:45:09 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04BC3A6C31 for ; Thu, 23 Apr 2009 10:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfZxZAiG1W3m for ; Thu, 23 Apr 2009 10:45:08 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 4F5AB3A6AA5 for ; Thu, 23 Apr 2009 10:45:07 -0700 (PDT) Received: by fxm2 with SMTP id 2so683163fxm.37 for ; Thu, 23 Apr 2009 10:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=65M6RMMZoCYu7fbBXHd6YfTiZoCR+8rC+Jlls5Suxnw=; b=taKoIe7aEm1Syll+OwRX2jVgpjmTIMo6aRaIXH9ZOKIFGgle5yLDegYu0eQrW6VMs8 xdOjTXrtFeG0acWaipV6uGP0qJdqjQ6dW0HiihAIxxKPFKrBIyjXVLDXgi+9KsA4N0l9 Zy21sdwtC8feYgeRz8SvjEYw8bZt3NyD43B/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nuvGQpxcbb7CVANYcagA4kWetDRoUXk5+u4M7Z2ZHN4mrW5nVEQmXgg4V5R8MaOuNC kavbVdYvhPXuRPGozjCQmyNdz4dxuM8eTwDazr8fNQgIiflM+R7VC9v2JIxUdgAER+Ct adZbSDhKTitVEoXItDHP/eiKxCMgBmqJiUj1w= MIME-Version: 1.0 Received: by 10.103.221.5 with SMTP id y5mr757990muq.66.1240508784549; Thu, 23 Apr 2009 10:46:24 -0700 (PDT) In-Reply-To: <49F087EB.3020007@grotto-networking.com> References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> <81761.9046.qm@web36807.mail.mud.yahoo.com> <003401c9bed1$aad507e0$500c7c0a@china.huawei.com> <49E7A504.2000808@grotto-networking.com> <332299.33564.qm@web36802.mail.mud.yahoo.com> <406e32c00904220702y95486f6p65270f504b6702e9@mail.gmail.com> <49F087EB.3020007@grotto-networking.com> Date: Thu, 23 Apr 2009 10:46:24 -0700 Message-ID: <787be2780904231046p57124134v90609ffc5858ad3e@mail.gmail.com> From: Greg Mirsky To: Greg Bernstein Content-Type: multipart/alternative; boundary=0016367659eb71a19e04683c7569 Cc: "pce@ietf.org" , Young Lee Subject: Re: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 17:45:10 -0000 --0016367659eb71a19e04683c7569 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Greg, without getting into implementation details I'd add third important mechanism used by IGPs to maintain reasonably up-to-date LSDB - exchange of Hello/Keepalive messages between immediate neighbors. Regards, Greg On Thu, Apr 23, 2009 at 8:23 AM, Greg Bernstein wrote: > Hi Peng, I think Young is out of the office this week. > On the statement "One key function is to ensure that the network > information obtained from nodes or elsewhere is relatively timely, or not > stale " . > This is similar to the requirements we see on link state IGPs and seemed > appropriate here as an important maintenance procedure. > > By the way link state IPGs use two mechanisms: (a) link state update > messages (there is some rate control on how often these can be sent, but = the > latency can be significantly under 1 second), (b) aging of link state > advertisements (LSAs) -- OSPF terminology --. In the "aging" mechanism > information gets removed from the TED if not refreshed (typically many > minutes). However we didn't want to get into implementation details. > > Best Regards > > Greg (trying to fill in for Young) > > > Peng He wrote: > > Hello Young, > > This is definitely a very interesting draft. Have a question here: > you mentioned at page 13 that "One key function is to ensure that the > network information obtained from nodes or elsewhere is relatively > timely, or not stale "; > > I'd like to know if you have considered how to make sure the obtained > information is NOT stale? what is the metric to justify it? what is > the bottom line?say, 1 second, or i minute? maybe the question is too > detail :) Thanks a lot. > > > Regards, > Peng > > On Tue, Apr 21, 2009 at 1:59 PM, Igor Bryskin wrote: > > > Hi, > > In my comments I forgot to mention IMO a very good argument in favor and = a > strong drive for using an alternative to IGP-TE method for managing TED. > > Consider a "network planner" type of applications which try various "what > if?" scenarios on network topologies that do not (fully or partially) exi= st > yet but could be provisioned under certain circumstances. These applicati= ons > , of course, require numerous complex path computations and are great > candidates to play the PCC role. But, as Eve Varma said on the last IETF= , > our path computations are only as good as our advertisements. So, for a > Network Planner it would be quite easy to use PCEP and send the necessary > resource state information to a PCE for not yet existing links on behalf = of > not yet existing NEs, request the path computation(s) and then clean up t= he > PCE's TED. It is much more difficult (if not impossible) to do the same > things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then > flush them out when they are not needed anymore). > > So there are two important byproducts that a PCEP based method of managin= g > TED gives compared to the IGP-TE method: > a) ability to send TE info updates on behalf of unexisting links and NEs; > b) determine the moment when all the necessary TE info is installed in th= e > PCE's TED, and it is possible to request the path computations. > > Note that b) in its own right is quite non-trivial problem to solve when = one > uses the IGP-TE method for the TED management. > > Cheers, > Igor > > ________________________________ > From: Greg Bernstein > To: Young Lee > Cc: Igor Bryskin > Sent: Thursday, April 16, 2009 5:37:08 PM > Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt > > Great to have help with the editing and concept development! > > Cheers > > Greg > > Young Lee wrote: > > Hi Igor, > > > > Thanks a lot for your comments. They are all valuable ones and we can put > most of them in the update. I will send you the WORD template of the > existing version so that you may be able to participate editing exercise > with other co-authors. Thanks. > > > > Regards, > > Young > > > > ________________________________ > > From: Igor Bryskin [mailto:i_bryskin@yahoo.com ] > Sent: Thursday, April 16, 2009 2:15 PM > To: Young Lee; pce@ietf.org > Subject: Comments on draft-lee-pce-ted-alternatives-01.txt > > > > Hi, > > > > Here is my comments on the draft =93Alternative Approaches to Traffic > Engineering Database Creation and Maintenance for Path Computation Elemen= ts=94 > http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt > > > > General comments. > > > > 1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to mak= e > it clear. I know that many people think that IGP-TE is an extension of IG= P > for TE purposes, but in fact, the two are completely different protocols > with completely different purposes: one is to dynamically manage IP > forwarding tables, and the other is to discover network resources of vari= ous > network layers and use this information for constraint based path > computations. The only thing that the two have in common is that they may > share the same instance of the IGP flooding/synchronization machinery (ev= en > this becomes increasingly untrue: today many use separate instances, look > for the OSPF transport instance and multi-instance activities in the OSPF > WG). Other then that, the two protocols have nothing in common; and this = is > especially true in the context of this document. It is quite reasonable t= o > imagine, for example, that within the PCE Architecture one can completely > eliminate use of IGP-TE by using, say, PCEP instead, to send local resou= rce > updates directly to PCE(s). However, one will still need IGP for forward= ing > control plane traffic. So my point here is that we want alternative metho= ds > to IGP-TE and not to IGP. > > > > 2. I=92d like to see in the draft a discussion on why the flooding of TE > information and the PCE architecture is not a good match. And this is > because flooding of any type of information works well on homogeneous > topologies, where all participants originate, distribute and use the > information. That=92s why IP OSPF, for example, works well: all OSPF spea= kers > originate LSAs, flood local and remote LSAs and use them in route > calculations. The PCE architecture is by definition asymmetrical with > respect to the information used in path computations: many elements > originate, but only few use it, and the flooding under these circumstance= s > could be very inefficient for all these reasons that you mentioned: memor= y, > CPU, bandwidth, etc. > > > > Specific comments: > > > > 1. You write: > > =93 This draft does not advocate that the alternative methods specified > > in this draft should completely replace the IGP as the method of > > creating the TED.=94 > > > > Why not? I mean there is a variety of ways how the alternative methods co= uld > relate to the IGP-TE method of managing TEDs. And I=92d like to see a sec= tion > describing different use cases and examples of IGP-TE and the alternative= s > cooperating with each other. One such use case is, for example, a network > built of simple optical NEs managed by a tiny control plane that consists > of: > > 1) PCC instance to send updates to remote PCE(s) on local resources statu= s > and also request path computations; > > 2) Very limited RSVP-TE instance for signaling fully explicit EROs provi= ded > by the PCE(s). > > > > In this case IGP-TE is not involved at all. > > > > There could be different ways how the alternatives can cooperate with > IGP-TE. One such cooperation, as you suggested, could be a split of what > information is distributed by IGP-TE and what via alternatives. For examp= le, > it makes sense to distribute =93static=94 (rarely modified) and sizable d= ata =96 > e.g. NE switching asymmetricity =96 via methods other than IGP-TE, while = more > frequently changed data via IGP-TE. This could significantly decrease the > IGP-TE information and its footprint on all speakers. > > > > Another type of cooperation between the IGP-TE method and its alternative= s > is limiting number and type of elements participating in IGP-TE. Your > architectural option #3 requires inter-PCE TED synchronization. How about > interconnecting PCEs into one or more rings via IP-IP tunnels and use an > instance of IGP-TE over the tunnels for the sole purpose of TED > synchronization between the PCEs? > > > > 2. You wrote: > > > > =93In OSPF the information directly related to IP > > connectivity (and hence the control communications plane for all > > three technologies) is kept in the link state database (LSDB), while > > additional information related to traffic engineering used by MPLS > > and GMPLS is kept in a (conceptually) separate traffic engineering > > database (TED)=94. > > > > This is not accurate. All IP and non-IP advertisements are stored in LSDB= . > Additionally, TE info is kept in TED. > > > > 3. In section 2.0 you describe the advantages of using alternative to IGP= -TE > methods. You also need here to clearly state the disadvantages, which are= : > > a) necessity of mechanisms that we take for granted when use IGP-TE: > removal of stale information, reliable delivery of updates to all > participants; recovery after reboots/crashes/upgrades, etc. > > b) additional security concerns; > > c) protocol to discover PCEs that are capable and willing to accept direc= t > updates; > > d) protocol to send the updates; > > etc. > > > > 4. Why not PCEP? > > > > This is not a requirement document. So I think it would be beneficial to > suggest a solution for the protocol to be used by NEs to send resource > updates to PCE(s). Considering that this protocol is supposed to: > > a) discover PCE(s) capable and willing to receive such updates; > > b) maintain sessions between NEs and PCE(s); > > c) address all the security concerns for PCE(s) to accept such updates; > > d) guarantee reliable delivery of the updates; > > > > why not to extend PCEP for this purpose since it is already doing all the= se > things? > > > > Cheers, > > Igor > > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > > _______________________________________________ > Pce mailing listPce@ietf.orghttps://www.ietf.org/mailman/listinfo/pce > > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --0016367659eb71a19e04683c7569 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Greg,
without getting into implementation details I'd add third= important mechanism used by IGPs to maintain reasonably up-to-date LSDB - = exchange of Hello/Keepalive messages between immediate neighbors.

Regards,
Greg

On Thu, Apr 23, 2009 at = 8:23 AM, Greg Bernstein <gregb@grotto-networking.com> wrote:
=20 =20
Hi Peng, I think Young is out of the office this week.
On the statement "One key function is to ensure that the network information obtained from nodes or elsewhere is relatively timely, or not stale " .
This is similar to the requirements we see on link state IGPs and seemed appropriate here as an important maintenance procedure.

By the way link state IPGs use two mechanisms: (a) link state update messages (there is some rate control on how often these can be sent, but the latency can be significantly under 1 second), (b) aging of link state advertisements (LSAs) -- OSPF terminology --. In the "aging"= ; mechanism information gets removed from the TED if not refreshed (typically many minutes). However we didn't want to get into implementation details.

Best Regards

Greg (trying to fill in for Young)


Peng He wrote: 
Hello Young,

This is definitely a very interesting draft. Have a question here:
you mentioned at page 13 that "One key function is to ensure that the
network information obtained from nodes or elsewhere is relatively
timely, or not stale ";

I'd like to know if you have considered how to make sure the obtained
information is NOT stale? what is the metric to justify it? what is
the bottom line?say, 1 second, or i minute? maybe the question is too
detail :) Thanks a lot.


Regards,
Peng

On Tue, Apr 21, 2009 at 1:59 PM, Igor Bryskin <i_bryskin@yahoo.com> wrote:
  
Hi,

In my comments I forgot to mention IMO a very good argument in favor and a
strong drive for using an alternative to IGP-TE method for managing TED.

Consider a "network planner" type of applications which try vario=
us "what
if?" scenarios on network topologies that do not (fully or partially) =
exist
yet but could be provisioned under certain circumstances. These application=
s
, of course, require numerous complex path computations and are great
candidates=A0 to play the PCC role. But, as Eve Varma said on the last IETF=
,
our path computations are only as good as our advertisements. So, for a
Network Planner it would be quite easy to use PCEP and send the necessary
resource state information to a PCE for not yet existing links on behalf of
not yet existing NEs, request the path computation(s) and then clean up the
PCE's TED. It is much more difficult (if not impossible) to do the same
things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then
flush them out when they are not needed anymore).

So there are two important byproducts that a PCEP based method of managing
TED gives compared to the IGP-TE method:
a) ability to send TE info updates on behalf of unexisting links and NEs;
b) determine the moment when all the necessary TE info is installed in the
PCE's TED, and it is possible to request the path computations.

Note that b) in its own right is quite non-trivial problem to solve when on=
e
uses the IGP-TE method for the TED management.

Cheers,
Igor

________________________________
From: Greg Bernstein <gregb@grotto-networking.com>
To: Young Lee <ylee=
@huawei.com>
Cc: Igor Bryskin &=
lt;i_bryskin@yahoo.com>
Sent: Thursday, April 16, 2009 5:37:08 PM
Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt

Great to have help with the editing and concept development!

Cheers

Greg

Young Lee wrote:

Hi Igor,



Thanks a lot for your comments. They are all valuable ones and we can put
most of them in the update. I will send you the WORD template of the
existing version so that you may be able to participate editing exercise
with other co-authors. Thanks.



Regards,

Young



________________________________

From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
Sent: Thursday, April 16, 2009 2:15 PM
To: Young Lee; pce@ietf.o=
rg
Subject: Comments on draft-lee-pce-ted-alternatives-01.txt



Hi,



Here is my comments on=A0 the draft =93Alternative Approaches to Traffic
Engineering Database Creation and Maintenance for Path Computation Elements=
=94

http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-0=
1.txt



General comments.



1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to make
it clear. I know that many people think that IGP-TE is an extension of IGP
for TE purposes, but in fact, the two are completely different protocols
with completely different purposes: one is to dynamically manage IP
forwarding tables, and the other is to discover network resources of variou=
s
network layers and use this information for constraint based path
computations. The only thing that the two have in common is that they may
share the same instance of the IGP flooding/synchronization machinery (even
this becomes increasingly untrue: today many use separate instances, look
for the OSPF transport instance and multi-instance activities in the OSPF
WG). Other then that, the two protocols have nothing in common; and this is
especially true in the context of this document. It is quite reasonable to
imagine, for example, that within the PCE Architecture one can completely
eliminate use=A0 of IGP-TE by using, say, PCEP instead, to send local resou=
rce
updates directly to PCE(s). =A0However, one will still need IGP for forward=
ing
control plane traffic. So my point here is that we want alternative methods
to IGP-TE and not to IGP.



2. I=92d like to see in the draft a discussion on why the flooding of TE
information and the PCE architecture is not a good match. And this is
because flooding of any type of information works well on homogeneous
topologies, where all participants originate, distribute and use the
information. That=92s why IP OSPF, for example, works well: all OSPF speake=
rs
originate LSAs, flood local and remote LSAs and use them in route
calculations. The PCE architecture is by definition asymmetrical with
respect to the information used in path computations: many elements
originate, but only few use it, and the flooding under these circumstances
could be very inefficient for all these reasons that you mentioned: memory,
CPU, bandwidth, etc.



Specific comments:



1. You write:

=93=A0 This draft does not advocate that the alternative methods specified

=A0=A0 in this draft should completely replace the IGP as the method of

=A0=A0 creating the TED.=94



Why not? I mean there is a variety of ways how the alternative methods coul=
d
relate to the IGP-TE method of managing TEDs. And I=92d like to see a secti=
on
describing different use cases and examples of IGP-TE and the alternatives
cooperating with each other. One such use case is, for example, a network
built of simple optical NEs managed by a tiny control plane that consists
of:

1) PCC instance to send updates to remote PCE(s) on local resources status
and also request path computations;

2) Very limited RSVP-TE instance for signaling fully explicit EROs=A0 provi=
ded
by the PCE(s).



In this case IGP-TE is not involved at all.



There could be different ways how the alternatives can cooperate with
IGP-TE. One such cooperation, as you suggested, could be a split of what
information is distributed by IGP-TE and what via alternatives. For example=
,
it makes sense to distribute =93static=94 (rarely modified) and sizable dat=
a =96
e.g. NE switching asymmetricity =96 via methods other than IGP-TE, while mo=
re
frequently changed data via IGP-TE. This could significantly decrease the
IGP-TE information and its footprint on all speakers.



Another type of cooperation between the IGP-TE method and its alternatives
is limiting number and type of elements participating in IGP-TE. Your
architectural option #3 requires inter-PCE TED synchronization. How about
interconnecting PCEs into one or more rings=A0 via IP-IP tunnels and use an
instance of IGP-TE over the tunnels for the sole purpose of TED
synchronization between the PCEs?



2. You wrote:



=93In OSPF the information directly related to IP

=A0=A0 connectivity (and hence the control communications plane for all

=A0=A0 three technologies) is kept in the link state database (LSDB), while

=A0=A0 additional information related to traffic engineering used by MPLS

=A0=A0 and GMPLS is kept in a (conceptually) separate traffic engineering

=A0=A0 database (TED)=94.



This is not accurate. All IP and non-IP advertisements are stored in LSDB.
Additionally, TE info is kept in TED.



3. In section 2.0 you describe the advantages of using alternative to IGP-T=
E
methods. You also need here to clearly state the disadvantages, which are:

a) =A0necessity of mechanisms that we take for granted when use IGP-TE:
removal of stale information, reliable delivery of updates to all
participants; recovery after reboots/crashes/upgrades, etc.

b) additional security concerns;

c) protocol to discover PCEs that are capable and willing to accept direct
updates;

d) protocol to send the updates;

etc.



4. Why not PCEP?



This is not a requirement document. So I think it would be beneficial to
suggest a solution for the protocol to be used by NEs to send resource
updates to PCE(s). Considering that this protocol is supposed to:

a) discover PCE(s) capable and willing to receive such updates;

b) maintain sessions between NEs and PCE(s);

c) address all the security concerns=A0 for PCE(s) to accept such updates;

d) guarantee reliable delivery of the updates;



why not to extend PCEP for this purpose since it is already doing all these
things?



Cheers,

Igor



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237



_______________________________________________
Pce mailing list
Pce@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/pce


    
  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


--0016367659eb71a19e04683c7569-- From peng.he.2000@gmail.com Fri Apr 24 06:22:35 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D610928C1A0 for ; Fri, 24 Apr 2009 06:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5ash49sgilW for ; Fri, 24 Apr 2009 06:22:34 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 006FE3A6BD6 for ; Fri, 24 Apr 2009 06:22:33 -0700 (PDT) Received: by fxm2 with SMTP id 2so1097570fxm.37 for ; Fri, 24 Apr 2009 06:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yZUTcrNRHb3eKtV/3VVTMOZ/rF9AJLjJNLl7VjoR2FQ=; b=X5GJstfpzzOr1sGS+ZXxZiZ1twnn/pGhLtegleEfyWwUsaNcCGWWLxs/Bk1VSnvrqg WyWyiRkFJ1lFua5txZqrCf8actQT6H/Y48ctaP9TcMErjbksrl+RsKa8vORhcQ8e3Imw YkRXO/xsWoB4ApSl6aspDRjkWKqgtFXYE/xj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hGDPBmyvEL1EYZIpKbLva6iNUkVEtHhX1yGr4IWos6nbQjDB149lFaWcRCVkfNpMM0 +F1/tnn9wT5F5krMv7lIS01YqOVPxbUTBNsZ06+lf3acKL7reSsryVFM9bnJ2np5nISZ OSCCmVQo/isKdMuFAwPR+KprbdkJeRYY4FcBU= MIME-Version: 1.0 Received: by 10.103.227.13 with SMTP id e13mr1287207mur.20.1240579431938; Fri, 24 Apr 2009 06:23:51 -0700 (PDT) In-Reply-To: <49F087EB.3020007@grotto-networking.com> References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> <81761.9046.qm@web36807.mail.mud.yahoo.com> <003401c9bed1$aad507e0$500c7c0a@china.huawei.com> <49E7A504.2000808@grotto-networking.com> <332299.33564.qm@web36802.mail.mud.yahoo.com> <406e32c00904220702y95486f6p65270f504b6702e9@mail.gmail.com> <49F087EB.3020007@grotto-networking.com> Date: Fri, 24 Apr 2009 09:23:51 -0400 Message-ID: <406e32c00904240623q71335403of47528f1e19c3ca@mail.gmail.com> From: Peng He To: Greg Bernstein Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "pce@ietf.org" , Young Lee Subject: Re: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 13:22:35 -0000 Dear Greg, Got it. Many thanks.. My intent is just to emphasize the not-stale TE info is so important to the quality of path computation; although above some special 'threshold' value, increasing refreshing rate may have very limited contribution to improve the path computation quality. Regards, Peng On Thu, Apr 23, 2009 at 11:23 AM, Greg Bernstein wrote: > Hi Peng, I think Young is out of the office this week. > On the statement "One key function is to ensure that the network informat= ion > obtained from nodes or elsewhere is relatively timely, or not stale " . > This is similar to the requirements we see on link state IGPs and seemed > appropriate here as an important maintenance procedure. > > By the way link state IPGs use two mechanisms: (a) link state update > messages (there is some rate control on how often these can be sent, but = the > latency can be significantly under 1 second), (b) aging of link state > advertisements (LSAs) -- OSPF terminology --. In the "aging" mechanism > information gets removed from the TED if not refreshed (typically many > minutes). However we didn't want to get into implementation details. > > Best Regards > > Greg (trying to fill in for Young) > > Peng He wrote: > > Hello Young, > > This is definitely a very interesting draft. Have a question here: > you mentioned at page 13 that "One key function is to ensure that the > network information obtained from nodes or elsewhere is relatively > timely, or not stale "; > > I'd like to know if you have considered how to make sure the obtained > information is NOT stale? what is the metric to justify it? what is > the bottom line?say, 1 second, or i minute? maybe the question is too > detail :) Thanks a lot. > > > Regards, > Peng > > On Tue, Apr 21, 2009 at 1:59 PM, Igor Bryskin wrote= : > > > Hi, > > In my comments I forgot to mention IMO a very good argument in favor and = a > strong drive for using an alternative to IGP-TE method for managing TED. > > Consider a "network planner" type of applications which try various "what > if?" scenarios on network topologies that do not (fully or partially) exi= st > yet but could be provisioned under certain circumstances. These applicati= ons > , of course, require numerous complex path computations and are great > candidates=A0 to play the PCC role. But, as Eve Varma said on the last IE= TF, > our path computations are only as good as our advertisements. So, for a > Network Planner it would be quite easy to use PCEP and send the necessary > resource state information to a PCE for not yet existing links on behalf = of > not yet existing NEs, request the path computation(s) and then clean up t= he > PCE's TED. It is much more difficult (if not impossible) to do the same > things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then > flush them out when they are not needed anymore). > > So there are two important byproducts that a PCEP based method of managin= g > TED gives compared to the IGP-TE method: > a) ability to send TE info updates on behalf of unexisting links and NEs; > b) determine the moment when all the necessary TE info is installed in th= e > PCE's TED, and it is possible to request the path computations. > > Note that b) in its own right is quite non-trivial problem to solve when = one > uses the IGP-TE method for the TED management. > > Cheers, > Igor > > ________________________________ > From: Greg Bernstein > To: Young Lee > Cc: Igor Bryskin > Sent: Thursday, April 16, 2009 5:37:08 PM > Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt > > Great to have help with the editing and concept development! > > Cheers > > Greg > > Young Lee wrote: > > Hi Igor, > > > > Thanks a lot for your comments. They are all valuable ones and we can put > most of them in the update. I will send you the WORD template of the > existing version so that you may be able to participate editing exercise > with other co-authors. Thanks. > > > > Regards, > > Young > > > > ________________________________ > > From: Igor Bryskin [mailto:i_bryskin@yahoo.com] > Sent: Thursday, April 16, 2009 2:15 PM > To: Young Lee; pce@ietf.org > Subject: Comments on draft-lee-pce-ted-alternatives-01.txt > > > > Hi, > > > > Here is my comments on=A0 the draft =93Alternative Approaches to Traffic > Engineering Database Creation and Maintenance for Path Computation Elemen= ts=94 > > http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt > > > > General comments. > > > > 1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to mak= e > it clear. I know that many people think that IGP-TE is an extension of IG= P > for TE purposes, but in fact, the two are completely different protocols > with completely different purposes: one is to dynamically manage IP > forwarding tables, and the other is to discover network resources of vari= ous > network layers and use this information for constraint based path > computations. The only thing that the two have in common is that they may > share the same instance of the IGP flooding/synchronization machinery (ev= en > this becomes increasingly untrue: today many use separate instances, look > for the OSPF transport instance and multi-instance activities in the OSPF > WG). Other then that, the two protocols have nothing in common; and this = is > especially true in the context of this document. It is quite reasonable t= o > imagine, for example, that within the PCE Architecture one can completely > eliminate use=A0 of IGP-TE by using, say, PCEP instead, to send local res= ource > updates directly to PCE(s). =A0However, one will still need IGP for forwa= rding > control plane traffic. So my point here is that we want alternative metho= ds > to IGP-TE and not to IGP. > > > > 2. I=92d like to see in the draft a discussion on why the flooding of TE > information and the PCE architecture is not a good match. And this is > because flooding of any type of information works well on homogeneous > topologies, where all participants originate, distribute and use the > information. That=92s why IP OSPF, for example, works well: all OSPF spea= kers > originate LSAs, flood local and remote LSAs and use them in route > calculations. The PCE architecture is by definition asymmetrical with > respect to the information used in path computations: many elements > originate, but only few use it, and the flooding under these circumstance= s > could be very inefficient for all these reasons that you mentioned: memor= y, > CPU, bandwidth, etc. > > > > Specific comments: > > > > 1. You write: > > =93=A0 This draft does not advocate that the alternative methods specifie= d > > =A0=A0 in this draft should completely replace the IGP as the method of > > =A0=A0 creating the TED.=94 > > > > Why not? I mean there is a variety of ways how the alternative methods co= uld > relate to the IGP-TE method of managing TEDs. And I=92d like to see a sec= tion > describing different use cases and examples of IGP-TE and the alternative= s > cooperating with each other. One such use case is, for example, a network > built of simple optical NEs managed by a tiny control plane that consists > of: > > 1) PCC instance to send updates to remote PCE(s) on local resources statu= s > and also request path computations; > > 2) Very limited RSVP-TE instance for signaling fully explicit EROs=A0 pro= vided > by the PCE(s). > > > > In this case IGP-TE is not involved at all. > > > > There could be different ways how the alternatives can cooperate with > IGP-TE. One such cooperation, as you suggested, could be a split of what > information is distributed by IGP-TE and what via alternatives. For examp= le, > it makes sense to distribute =93static=94 (rarely modified) and sizable d= ata =96 > e.g. NE switching asymmetricity =96 via methods other than IGP-TE, while = more > frequently changed data via IGP-TE. This could significantly decrease the > IGP-TE information and its footprint on all speakers. > > > > Another type of cooperation between the IGP-TE method and its alternative= s > is limiting number and type of elements participating in IGP-TE. Your > architectural option #3 requires inter-PCE TED synchronization. How about > interconnecting PCEs into one or more rings=A0 via IP-IP tunnels and use = an > instance of IGP-TE over the tunnels for the sole purpose of TED > synchronization between the PCEs? > > > > 2. You wrote: > > > > =93In OSPF the information directly related to IP > > =A0=A0 connectivity (and hence the control communications plane for all > > =A0=A0 three technologies) is kept in the link state database (LSDB), whi= le > > =A0=A0 additional information related to traffic engineering used by MPLS > > =A0=A0 and GMPLS is kept in a (conceptually) separate traffic engineering > > =A0=A0 database (TED)=94. > > > > This is not accurate. All IP and non-IP advertisements are stored in LSDB= . > Additionally, TE info is kept in TED. > > > > 3. In section 2.0 you describe the advantages of using alternative to IGP= -TE > methods. You also need here to clearly state the disadvantages, which are= : > > a) =A0necessity of mechanisms that we take for granted when use IGP-TE: > removal of stale information, reliable delivery of updates to all > participants; recovery after reboots/crashes/upgrades, etc. > > b) additional security concerns; > > c) protocol to discover PCEs that are capable and willing to accept direc= t > updates; > > d) protocol to send the updates; > > etc. > > > > 4. Why not PCEP? > > > > This is not a requirement document. So I think it would be beneficial to > suggest a solution for the protocol to be used by NEs to send resource > updates to PCE(s). Considering that this protocol is supposed to: > > a) discover PCE(s) capable and willing to receive such updates; > > b) maintain sessions between NEs and PCE(s); > > c) address all the security concerns=A0 for PCE(s) to accept such updates= ; > > d) guarantee reliable delivery of the updates; > > > > why not to extend PCEP for this purpose since it is already doing all the= se > things? > > > > Cheers, > > Igor > > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > > > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > From ylee@huawei.com Tue Apr 28 10:03:16 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2A63A710F for ; Tue, 28 Apr 2009 10:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHltwyxxhieF for ; Tue, 28 Apr 2009 10:03:08 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 4A48B28C10D for ; Tue, 28 Apr 2009 10:03:08 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00M33M3CME@usaga02-in.huawei.com> for pce@ietf.org; Tue, 28 Apr 2009 10:04:26 -0700 (PDT) Received: from L73682 ([10.124.12.80]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT00HSFKCS2T@usaga02-in.huawei.com> for pce@ietf.org; Tue, 28 Apr 2009 09:26:52 -0700 (PDT) Date: Tue, 28 Apr 2009 11:26:51 -0500 From: Young Lee In-reply-to: <004c01c9c1bd$da0ec2f0$8e2c48d0$@co.uk> To: 'Daniel King' Message-id: <00fa01c9c81e$233093d0$500c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_HmnwBbWy6Pqid0R2YQh1iQ)" Thread-index: Acm+x6OkjFqYqXJVSQeFQmJOIYVtRAAAm5EAALzpDsABlu1sMA== References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> <81761.9046.qm@web36807.mail.mud.yahoo.com> <002f01c9bed1$4f5172f0$500c7c0a@china.huawei.com> <004c01c9c1bd$da0ec2f0$8e2c48d0$@co.uk> Cc: pce@ietf.org Subject: Re: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:03:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_HmnwBbWy6Pqid0R2YQh1iQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Dan, Sorry for my late response. I just got back to office. Please see in-line for my response to your comments. Thanks. Regards, Young _____ From: Daniel King [mailto:daniel@olddog.co.uk] Sent: Monday, April 20, 2009 8:43 AM To: 'Young Lee' Cc: pce@ietf.org Subject: RE: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt Hi Young, et al. I thought the draft was well written and an interesting area for discussion. I had the following general comments. a) A key goal of the work is to gather necessary network management information for offline complex path computation. Its logical to assume that the complex offline path computation might be centralized. It might be worth stating this as an assumption. Young>> We are not necessarily assuming centralised offline PCE regime in this draft. As we explore many architecture options that include multiple PCE options and possibly using some on-line protocols in disseminating TED related information, I am a little hesitant to state your suggested assumption. b) We should not get to caught up in the details of proposed mechanisms or solutions. This is after all an architecture document. Young>> Yes, this document is basically an architecture/framework document. We are not proposing any particular mechanisms or solutions here. We simply stated a set of candidate mechanisms/solutions to give a more realistic perspective. We will clean up the texts in the revision to make sure your point is addressed. c) A hybrid approach to performing path computation in the network might be considered as there is motivation for performing path computation (simple versus complex) in different parts of the network. All planning and complex path computation could be performed by the offline and centralized PCE. Rapid restoration and local repair could then distributed to the local PCEs. Each distributed PCE can always signal the centralized PCE for reoptimization after the initial local path computation, in order to request a path computation that considers more complex constraints. Young>> Good point! As you point out, there may be cases where both node-based PCE and server-based PCE may need to interact. I can also envision that complex path computation like IA-RWA solely depend on server-based PCE while quick calculation has to be done at the node level such as restoration, etc. We can add a section that discusses usage scenarios. d) Fundamentally we should use the right mechanism to distribute the data according to where it is needed. If some form of path computation is needed on LSRs, then in my opinion the necessary information should be distributed using the IGPs. We should be careful about recommending a solution that does not use the IGP at all. In a model where there are many nodes with path computation capabilities, we effectively need to flood information to each PCE. The IGPs have been designed for this. If we use PCEP to distribute information to go in the TED we may end up trying to turn PCEP into a flooding protocol that replaces the IGPs. Young>> Yes, we are NOT proposing replacement of IGP-TE in favour of alternative mechanisms. I envision that IGP-TE and the alternative mechanism would be complementary to each other. It all depends on where path computation would be done. Route calculation can be done easily at the node level while WA (Wavelength Assignment) and IV (Impairment Validation) can be done at the server PCE although all of them can be done at the server level or at the node level. I envision that whatever is defined in the current IGP-TE, we should continue to use them using IGP-TE's flooding while new information may be transported using new mechanism. e) As mentioned in point (b), we should avoid getting into solution details. As an architecture/requirements document, this draft should maybe not mention any protocols at all except in the context of what they already do and are used for. So, discussing using PCEP for data distribution, or discussing LDAP may be out of scope (even for an Appendix). But it is very valid to describe the data model, and I think that bit that is not generally flooded is a distributed database just like in the LDAP model. Young>> I think we discussed this issue previously. f) I made some minor comments and suggestions along the points above as change modifications in a word document. I will unicast the document to you shortly. Young>> Thanks for your help! We have a quite a few comments/suggestions so far for this work. I will put them together in the revision and let the WG know the changes from the previous version. Look forward to seeing your modifications. Br, Dan. --Boundary_(ID_HmnwBbWy6Pqid0R2YQh1iQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Dan, =

Sorry for my late response. I just = got back to office. Please see in-line for my response to your comments. = Thanks.

 

Regards,
Young

 

From: = Daniel King [mailto:daniel@olddog.co.uk]
Sent: Monday, April 20, = 2009 8:43 AM
To: 'Young Lee'
Cc: pce@ietf.org
Subject: RE: [Pce] = Comments on draft-lee-pce-ted-alternatives-01.txt

 

Hi Young, et al.

 <= /o:p>

I thought = the draft was well written and an interesting area for discussion. I had the = following general comments.

 <= /o:p>

a) A key = goal of the work is to gather necessary network management information for offline = complex path computation. Its logical to assume that the complex offline path computation might be centralized. It might be worth stating this as an assumption.

 

Young>> We = are not necessarily assuming centralised offline PCE regime in this draft. As we explore many architecture options that include multiple PCE options and possibly using some on-line protocols in disseminating TED related = information, I am a little hesitant to state your suggested assumption. =

 =

b) We = should not get to caught up in the details of proposed mechanisms or solutions. This is = after all an architecture document.

 

Young>> = Yes, this document is basically an architecture/framework document. We are not = proposing any particular mechanisms or solutions here. We simply stated a set of candidate mechanisms/solutions to give a more realistic perspective. We = will clean up the texts in the revision to make sure your point is addressed. =

 =

c) A hybrid = approach to performing path computation in the network might be considered as = there is motivation for performing path computation (simple versus complex) in = different parts of the network. All planning and complex path computation could be performed by the offline and centralized PCE. Rapid restoration and = local repair could then distributed to the local PCEs. Each distributed PCE = can always signal the centralized PCE for reoptimization after the initial = local path computation, in order to request a path computation that considers = more complex constraints.

 

Young>> = Good point! As you point out, there may be cases where both node-based PCE and = server-based PCE may need to interact. I can also envision that complex path = computation like IA-RWA solely depend on server-based PCE while quick calculation = has to be done at the node level such as restoration, etc. We can add a section = that discusses usage scenarios.

 =

d) = Fundamentally we should  use the right mechanism to distribute the data according to = where it is needed. If some form of path computation is needed on LSRs, then = in my opinion the necessary information should  be distributed using the = IGPs. We should be careful about recommending a solution that does not use the = IGP at all. In a model where there are many nodes with path computation = capabilities, we effectively need to flood information to each PCE. The IGPs have been designed for this. If we use PCEP to distribute information to go in the = TED we may end up trying to turn PCEP into a flooding protocol that replaces = the IGPs.

 

Young>> = Yes, we are NOT proposing replacement of IGP-TE in favour of alternative mechanisms. = I envision that IGP-TE and the alternative mechanism would be = complementary to each other. It all depends on where path computation would be done. = Route calculation can be done easily at the node level while WA (Wavelength Assignment) and IV (Impairment Validation) can be done at the server PCE although all of them can be done at the server level or at the node = level. I envision that whatever is defined in the current IGP-TE, we should = continue to use them using IGP-TE’s flooding while new information may be = transported using new mechanism.

 =

e) As = mentioned in point (b), we should avoid getting into solution details. As an architecture/requirements document, this draft should maybe not mention = any protocols at all except in the context of what they already do and are = used for. So, discussing using PCEP for data distribution, or discussing LDAP = may be out of scope (even for an Appendix). But it is very valid to describe = the data model, and I think that bit that is not generally flooded is a = distributed database just like in the LDAP model.

 

Young>> I = think we discussed this issue previously.

 =

f) I made = some minor comments and suggestions along the points above as change modifications = in a word document. I will unicast the document to you shortly. =

 

Young>> = Thanks for your help! We have a quite a few comments/suggestions so far for this = work. I will put them together in the revision and let the WG know the changes = from the previous version. Look forward to seeing your modifications. =

Br, = Dan.

 <= /o:p>

--Boundary_(ID_HmnwBbWy6Pqid0R2YQh1iQ)-- From ylee@huawei.com Tue Apr 28 13:51:50 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391393A6969 for ; Tue, 28 Apr 2009 13:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y674saTu+4SM for ; Tue, 28 Apr 2009 13:51:38 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 8CA1B28C1D5 for ; Tue, 28 Apr 2009 13:51:01 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT001B6WN87D@usaga02-in.huawei.com> for pce@ietf.org; Tue, 28 Apr 2009 13:52:22 -0700 (PDT) Received: from L73682 ([10.124.12.80]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT001WUV89TV@usaga02-in.huawei.com> for pce@ietf.org; Tue, 28 Apr 2009 13:21:46 -0700 (PDT) Date: Tue, 28 Apr 2009 15:21:45 -0500 From: Young Lee In-reply-to: <332299.33564.qm@web36802.mail.mud.yahoo.com> To: 'Igor Bryskin' , 'Greg Bernstein' Message-id: <000d01c9c83e$f3cfcfe0$500c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_pFPfLSGG4cSI7FvCa92ZRg)" Thread-index: AcnCqvqEpKEJoyfwS12l34d6jj2T+QFkY8Ug References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> <81761.9046.qm@web36807.mail.mud.yahoo.com> <003401c9bed1$aad507e0$500c7c0a@china.huawei.com> <49E7A504.2000808@grotto-networking.com> <332299.33564.qm@web36802.mail.mud.yahoo.com> Cc: pce@ietf.org Subject: Re: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 20:51:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_pFPfLSGG4cSI7FvCa92ZRg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Igor, I have a couple of comments on your "network planner" application using PCEP. - First of all, this is specific to PCEP implementation which we need to address in the solutions draft once the PCE-TED draft idea has been accepted in the WG. We need to separate detail discussion on a particular implementation from the current draft. But I think your suggested application is worth to revisit once we have a solution draft. - The intention of PCE-TED draft is not necessarily to replace the whole IGP-TE as information disseminating mechanism but to suggest that certain applications may warrant alternative methods that can co-exist with IGP-TE. We don't want to reinvent the new wheel necessarily with the current scope of the draft. We would want to stay as "complementary" to IGP-TE. Thanks. Regards, Young _____ From: Igor Bryskin [mailto:i_bryskin@yahoo.com] Sent: Tuesday, April 21, 2009 12:59 PM To: Greg Bernstein; Young Lee Cc: pce@ietf.org Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt Hi, In my comments I forgot to mention IMO a very good argument in favor and a strong drive for using an alternative to IGP-TE method for managing TED. Consider a "network planner" type of applications which try various "what if?" scenarios on network topologies that do not (fully or partially) exist yet but could be provisioned under certain circumstances. These applications , of course, require numerous complex path computations and are great candidates to play the PCC role. But, as Eve Varma said on the last IETF, our path computations are only as good as our advertisements. So, for a Network Planner it would be quite easy to use PCEP and send the necessary resource state information to a PCE for not yet existing links on behalf of not yet existing NEs, request the path computation(s) and then clean up the PCE's TED. It is much more difficult (if not impossible) to do the same things using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then flush them out when they are not needed anymore). So there are two important byproducts that a PCEP based method of managing TED gives compared to the IGP-TE method: a) ability to send TE info updates on behalf of unexisting links and NEs; b) determine the moment when all the necessary TE info is installed in the PCE's TED, and it is possible to request the path computations. Note that b) in its own right is quite non-trivial problem to solve when one uses the IGP-TE method for the TED management. Cheers, Igor _____ From: Greg Bernstein To: Young Lee Cc: Igor Bryskin Sent: Thursday, April 16, 2009 5:37:08 PM Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt Great to have help with the editing and concept development! Cheers Greg Young Lee wrote: Hi Igor, Thanks a lot for your comments. They are all valuable ones and we can put most of them in the update. I will send you the WORD template of the existing version so that you may be able to participate editing exercise with other co-authors. Thanks. Regards, Young _____ From: Igor Bryskin [mailto:i_bryskin@yahoo.com] Sent: Thursday, April 16, 2009 2:15 PM To: Young Lee; pce@ietf.org Subject: Comments on draft-lee-pce-ted-alternatives-01.txt Hi, Here is my comments on the draft "Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements" http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt General comments. 1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth to make it clear. I know that many people think that IGP-TE is an extension of IGP for TE purposes, but in fact, the two are completely different protocols with completely different purposes: one is to dynamically manage IP forwarding tables, and the other is to discover network resources of various network layers and use this information for constraint based path computations. The only thing that the two have in common is that they may share the same instance of the IGP flooding/synchronization machinery (even this becomes increasingly untrue: today many use separate instances, look for the OSPF transport instance and multi-instance activities in the OSPF WG). Other then that, the two protocols have nothing in common; and this is especially true in the context of this document. It is quite reasonable to imagine, for example, that within the PCE Architecture one can completely eliminate use of IGP-TE by using, say, PCEP instead, to send local resource updates directly to PCE(s). However, one will still need IGP for forwarding control plane traffic. So my point here is that we want alternative methods to IGP-TE and not to IGP. 2. I'd like to see in the draft a discussion on why the flooding of TE information and the PCE architecture is not a good match. And this is because flooding of any type of information works well on homogeneous topologies, where all participants originate, distribute and use the information. That's why IP OSPF, for example, works well: all OSPF speakers originate LSAs, flood local and remote LSAs and use them in route calculations. The PCE architecture is by definition asymmetrical with respect to the information used in path computations: many elements originate, but only few use it, and the flooding under these circumstances could be very inefficient for all these reasons that you mentioned: memory, CPU, bandwidth, etc. Specific comments: 1. You write: " This draft does not advocate that the alternative methods specified in this draft should completely replace the IGP as the method of creating the TED." Why not? I mean there is a variety of ways how the alternative methods could relate to the IGP-TE method of managing TEDs. And I'd like to see a section describing different use cases and examples of IGP-TE and the alternatives cooperating with each other. One such use case is, for example, a network built of simple optical NEs managed by a tiny control plane that consists of: 1) PCC instance to send updates to remote PCE(s) on local resources status and also request path computations; 2) Very limited RSVP-TE instance for signaling fully explicit EROs provided by the PCE(s). In this case IGP-TE is not involved at all. There could be different ways how the alternatives can cooperate with IGP-TE. One such cooperation, as you suggested, could be a split of what information is distributed by IGP-TE and what via alternatives. For example, it makes sense to distribute "static" (rarely modified) and sizable data - e.g. NE switching asymmetricity - via methods other than IGP-TE, while more frequently changed data via IGP-TE. This could significantly decrease the IGP-TE information and its footprint on all speakers. Another type of cooperation between the IGP-TE method and its alternatives is limiting number and type of elements participating in IGP-TE. Your architectural option #3 requires inter-PCE TED synchronization. How about interconnecting PCEs into one or more rings via IP-IP tunnels and use an instance of IGP-TE over the tunnels for the sole purpose of TED synchronization between the PCEs? 2. You wrote: "In OSPF the information directly related to IP connectivity (and hence the control communications plane for all three technologies) is kept in the link state database (LSDB), while additional information related to traffic engineering used by MPLS and GMPLS is kept in a (conceptually) separate traffic engineering database (TED)". This is not accurate. All IP and non-IP advertisements are stored in LSDB. Additionally, TE info is kept in TED. 3. In section 2.0 you describe the advantages of using alternative to IGP-TE methods. You also need here to clearly state the disadvantages, which are: a) necessity of mechanisms that we take for granted when use IGP-TE: removal of stale information, reliable delivery of updates to all participants; recovery after reboots/crashes/upgrades, etc. b) additional security concerns; c) protocol to discover PCEs that are capable and willing to accept direct updates; d) protocol to send the updates; etc. 4. Why not PCEP? This is not a requirement document. So I think it would be beneficial to suggest a solution for the protocol to be used by NEs to send resource updates to PCE(s). Considering that this protocol is supposed to: a) discover PCE(s) capable and willing to receive such updates; b) maintain sessions between NEs and PCE(s); c) address all the security concerns for PCE(s) to accept such updates; d) guarantee reliable delivery of the updates; why not to extend PCEP for this purpose since it is already doing all these things? Cheers, Igor -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --Boundary_(ID_pFPfLSGG4cSI7FvCa92ZRg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Igor,

 

I have a couple of comments on your = “network planner” application using PCEP.

 

-          First of all, this is specific to PCEP implementation which we need to address in = the solutions draft once the PCE-TED draft idea has been accepted in the WG. = We need to separate detail discussion on a particular implementation from = the current draft. But I think your suggested application is worth to = revisit once we have a solution draft.

 =

-          The intention of PCE-TED draft is not necessarily to replace the whole = IGP-TE as information disseminating mechanism but to suggest that certain = applications may warrant alternative methods that can co-exist with IGP-TE.  We = don’t want to reinvent the new wheel necessarily with the current scope of the = draft. We would want to stay as “complementary” to IGP-TE. =

 

Thanks.

=

 

Regards,

Young

From: Igor = Bryskin [mailto:i_bryskin@yahoo.com]
Sent: Tuesday, April 21, = 2009 12:59 PM
To: Greg Bernstein; Young = Lee
Cc: pce@ietf.org
Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt

 

Hi,

In my comments I forgot to mention IMO a very good argument in favor and = a strong drive for using an alternative to IGP-TE method for managing = TED.

Consider a "network planner" type of applications which try = various "what if?" scenarios on network topologies that do not (fully = or partially) exist yet but could be provisioned under certain = circumstances. These applications , of course, require numerous complex path = computations and are great candidates  to play the PCC role. But, as Eve Varma said = on the last IETF, our path computations are only as good as our advertisements. = So, for a Network Planner it would be quite easy to use PCEP and send the = necessary resource state information to a PCE for not yet existing links on behalf = of not yet existing NEs, request the path computation(s) and then clean up the = PCE's TED. It is much more difficult (if not impossible) to do the same things = using IGP-TE (e.g. have unexisting NEs originate TE LSAs and then flush them = out when they are not needed anymore).

So there are two important byproducts that a PCEP based method of = managing TED gives compared to the IGP-TE method:
a) ability to send TE info updates on behalf of unexisting links and = NEs;
b) determine the moment when all the necessary TE info is installed in = the PCE's TED, and it is possible to request the path computations.

Note that b) in its own right is quite non-trivial problem to solve when = one uses the IGP-TE method for the TED management.

Cheers,
Igor

 

From: Greg = Bernstein <gregb@grotto-networking.com>
To: Young Lee <ylee@huawei.com>
Cc: Igor Bryskin <i_bryskin@yahoo.com>
Sent: Thursday, April 16, = 2009 5:37:08 PM
Subject: Re: Comments on draft-lee-pce-ted-alternatives-01.txt

Great to have help with the editing and concept development!

Cheers

Greg

Young Lee wrote:

Hi = Igor,

 

Thanks a lot for your comments. = They are all valuable ones and we can put most of them in the update. I will send = you the WORD template of the existing version so that you may be able to participate editing exercise with other co-authors. Thanks. =

 

Regards,

Young

 

From: Igor = Bryskin [mailto:i_bryskin@yahoo.com] =
Sent: Thursday, April 16, = 2009 2:15 PM
To: Young Lee; pce@ietf.org
Subject: Comments on draft-lee-pce-ted-alternatives-01.txt

 

Hi,







Here is my comments on  the draft “Alternative Approaches to =
Traffic Engineering Database Creation and Maintenance for Path =
Computation Elements”

http://tools.ietf.org/id/draft-lee-pce-ted-alternatives= -01.txt

 

General comments.

 

1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is = worth to make it clear. I know that many people think that IGP-TE is an extension = of IGP for TE purposes, but in fact, the two are completely different protocols = with completely different purposes: one is to dynamically manage IP forwarding tables, = and the other is to discover network resources of various network layers and use = this information for constraint based path computations. The only thing that = the two have in common is that they may share the same instance of the IGP flooding/synchronization machinery (even this becomes increasingly = untrue: today many use separate instances, look for the OSPF transport instance = and multi-instance activities in the OSPF WG). Other then that, the two = protocols have nothing in common; and this is especially true in the context of = this document. It is quite reasonable to imagine, for example, that within = the PCE Architecture one can completely eliminate use  of IGP-TE by using, = say, PCEP instead, to send local resource updates directly to PCE(s). =  However, one will still need IGP for forwarding control plane traffic. So my = point here is that we want alternative methods to IGP-TE and not to = IGP.

 

2. I’d like to see in the draft a discussion on why the = flooding of TE information and the PCE architecture is not a good match. And this = is because flooding of any type of information works well on homogeneous topologies, where all participants originate, distribute and use the information. That’s why IP OSPF, for example, works well: all OSPF speakers originate LSAs, flood local and remote LSAs and use them in = route calculations. The PCE architecture is by definition asymmetrical with = respect to the information used in path computations: many elements originate, = but only few use it, and the flooding under these circumstances could be very inefficient for all these reasons that you mentioned: memory, CPU, = bandwidth, etc.

 

Specific comments:

 

1. You write:

“  This draft does not advocate that the alternative = methods specified

   in this draft should completely replace the IGP as = the method of

   creating the = TED.”

 

Why not? I mean there is a variety of ways how the alternative = methods could relate to the IGP-TE method of managing TEDs. And I’d like = to see a section describing different use cases and examples of IGP-TE and the alternatives cooperating with each other. One such use case is, for = example, a network built of simple optical NEs managed by a tiny control plane that consists of:

1) PCC instance to send updates to remote PCE(s) on local = resources status and also request path computations;

2) Very limited RSVP-TE instance for signaling fully explicit EROs  provided by the PCE(s).

 

In this case IGP-TE is not involved at all. =

 

There could be different ways how the alternatives can cooperate = with IGP-TE. One such cooperation, as you suggested, could be a split of what information is distributed by IGP-TE and what via alternatives. For = example, it makes sense to distribute “static” (rarely modified) and = sizable data – e.g. NE switching asymmetricity – via methods other = than IGP-TE, while more frequently changed data via IGP-TE. This could = significantly decrease the IGP-TE information and its footprint on all = speakers.

 

Another type of cooperation between the IGP-TE method and its alternatives is limiting number and type of elements participating in = IGP-TE. Your architectural option #3 requires inter-PCE TED synchronization. How = about interconnecting PCEs into one or more rings  via IP-IP tunnels and = use an  instance of IGP-TE over the tunnels for the sole purpose of TED synchronization between the PCEs?

 

2. You wrote:

 

“In OSPF the information directly related to IP =

   connectivity (and hence the control communications = plane for all

   three technologies) is kept in the link state = database (LSDB), while

   additional information related to traffic = engineering used by MPLS

   and GMPLS is kept in a (conceptually) separate = traffic engineering

   database (TED)”.

 

This is not accurate. All IP and non-IP advertisements are = stored in LSDB. Additionally, TE info is kept in TED.

 

3. In section 2.0 you describe the advantages of using = alternative to IGP-TE methods. You also need here to clearly state the disadvantages, = which are:

a)  necessity of mechanisms that we take for granted when = use IGP-TE: removal of stale information, reliable delivery of updates to = all participants; recovery after reboots/crashes/upgrades, = etc.

b) additional security concerns;

c) protocol to discover PCEs that are capable and willing to = accept direct updates;

d) protocol to send the updates;

etc.

 

4. Why not PCEP?

 

This is not a requirement document. So I think it would be = beneficial to suggest a solution for the protocol to be used by NEs to send = resource updates to PCE(s). Considering that this protocol is supposed = to:

a) discover PCE(s) capable and willing to receive such = updates;

b) maintain sessions between NEs and = PCE(s);

c) address all the security concerns  for PCE(s) to accept = such updates;

d) guarantee reliable delivery of the = updates;

 

why not to extend PCEP for this purpose since it is already = doing all these things?

 

Cheers,

Igor

 

 

-- 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Dr Greg Bernstein, Grotto Networking (510) =
573-2237

 

--Boundary_(ID_pFPfLSGG4cSI7FvCa92ZRg)-- From rfc-editor@rfc-editor.org Tue Apr 28 16:56:19 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D01B3A6D2F; Tue, 28 Apr 2009 16:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.924 X-Spam-Level: X-Spam-Status: No, score=-16.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fh0D9LMST5Ya; Tue, 28 Apr 2009 16:56:18 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id F0C093A6D2D; Tue, 28 Apr 2009 16:56:17 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 001F1293E52; Tue, 28 Apr 2009 16:54:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090428235456.001F1293E52@bosco.isi.edu> Date: Tue, 28 Apr 2009 16:54:56 -0700 (PDT) Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] RFC 5520 on Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 23:56:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5520 Title: Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism Author: R. Bradford, Ed., JP. Vasseur, A. Farrel Status: Standards Track Date: April 2009 Mailbox: rbradfor@cisco.com, jpv@cisco.com, adrian@olddog.co.uk Pages: 19 Characters: 43125 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-path-key-05.txt URL: http://www.rfc-editor.org/rfc/rfc5520.txt Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 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 (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes 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 AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message 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 TE (RSVP-TE) explicit route object. [STANDARDS TRACK] This document is a product of the Path Computation Element Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Apr 28 16:56:27 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7A93A6D5A; Tue, 28 Apr 2009 16:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.924 X-Spam-Level: X-Spam-Status: No, score=-16.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht0GaqAulSBI; Tue, 28 Apr 2009 16:56:27 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id B74D13A6D4F; Tue, 28 Apr 2009 16:56:26 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id B94A3293E56; Tue, 28 Apr 2009 16:55:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090428235505.B94A3293E56@bosco.isi.edu> Date: Tue, 28 Apr 2009 16:55:05 -0700 (PDT) Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] RFC 5521 on Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 23:56:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5521 Title: Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions Author: E. Oki, T. Takeda, A. Farrel Status: Standards Track Date: April 2009 Mailbox: oki@ice.uec.ac.jp, takeda.tomonori@lab.ntt.co.jp, adrian@olddog.co.uk Pages: 16 Characters: 36294 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-pcep-xro-06.txt URL: http://www.rfc-editor.org/rfc/rfc5521.txt The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions". The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS TRACK] This document is a product of the Path Computation Element Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From jvasseur@cisco.com Tue Apr 28 23:18:14 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D183A67C0 for ; Tue, 28 Apr 2009 23:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.758 X-Spam-Level: X-Spam-Status: No, score=-9.758 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP-SwjUMATyo for ; Tue, 28 Apr 2009 23:18:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 436A73A6859 for ; Tue, 28 Apr 2009 23:18:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,264,1238976000"; d="scan'208";a="39369589" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2009 06:19:27 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3T6JRJM006889 for ; Wed, 29 Apr 2009 08:19:27 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3T6JR9U025853 for ; Wed, 29 Apr 2009 06:19:27 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 08:19:27 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 08:19:27 +0200 Message-Id: <9D5640B9-2949-4DC4-AD43-5C8A0D6564D7@cisco.com> From: JP Vasseur To: pce@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 17:39:54 +0200 References: <20090422162325.GB16226@isi.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 29 Apr 2009 06:19:27.0408 (UTC) FILETIME=[72D48300:01C9C892] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1594; t=1240985967; x=1241849967; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20Cluster=20Pages=20Now=20Available |Sender:=20; bh=fp960Tz1KYhc10KB4bMi99U0Xmy20FP5Y3V7k71w+V4=; b=TV8uhmf22jDB1gDSspc1zKx5oouVSG8DF8uCoDVn0noKnakptCyEDmeGwO XqWfMgvfjp8MhlyxBMzl0xzRen369lA+kEdDS0EkSH7ySy3pkwyZgaKH63+x Oy5h1lWZ00; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Pce] Fwd: Cluster Pages Now Available X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 06:18:14 -0000 Quite useful. Begin forwarded message: > > Date: Tue, 21 Apr 2009 17:28:38 -0700 > From: RFC Editor > To: rfc-interest@rfc-editor.org > Cc: RFC Editor > Subject: [rfc-i] Cluster Pages Now Available > > Greetings All, > > The RFC Editor has made pages available to show the clusters of > documents that are linked by Normative References. Please see these > pages for more information: > http://www.rfc-editor.org/all_clusters.php > http://www.rfc-editor.org/cluster_def.html > > The purpose of the new cluster pages is to make clear why specific > drafts are being held (to authors, WG chairs, ADs, and other > interested parties) and to aid in the RFC Editor's processing of > documents. As noted on http://www.rfc-editor.org/cluster_def.html: > > A cluster is a set of 2 or more drafts that are moving through the > RFC publication process together for one of the following reasons: > > * They are linked by normative references directly. > > * They are linked by normative references indirectly > (i.e., 2nd or 3rd generation). > > * There was a specific request from the IESG or authors for > simultaneous publication. > > At this time, the cluster information is available from the queue > page (http://www.rfc-editor.org/queue2.html), but not the XML version > of the queue. > > RFC Editor > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest > > ----- End forwarded message ----- From i_bryskin@yahoo.com Wed Apr 29 09:49:00 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A7F28C140 for ; Wed, 29 Apr 2009 09:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq3k6E5Xrslg for ; Wed, 29 Apr 2009 09:48:57 -0700 (PDT) Received: from web36801.mail.mud.yahoo.com (web36801.mail.mud.yahoo.com [209.191.85.52]) by core3.amsl.com (Postfix) with SMTP id 88B623A7176 for ; Wed, 29 Apr 2009 09:48:57 -0700 (PDT) Received: (qmail 59797 invoked by uid 60001); 29 Apr 2009 16:50:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241023815; bh=9TxIJfxfyNGrGkfDiPz5MWZQnoY2lkowVGR71aDh4ug=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lttoqGBoh7bIE93Z5wCyGtwXkzuEn/K/C/B/4iqqQh5rcILOuVhWtU4Aqe5YkcwEzZwuAaCzZ5j7bwM3O+46qesOlsMKH+e84ZnE3NK71Y/SkHod1l/hPlfVTZc4ovrlj98Rl+TrBUj4By1tabJXbLuJFyKXMBNGCysfcz0BOa0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FvFVzQKGKqL+d4GRwSpeE5RZjBZvA1SVMqzcyWM3llNf2Kb2dMKEvUWU3Tp0+N6rR8b/InOZFwMFOmxTn13LRFJfHHM5drmU63BbSLx8zRwu28yfU5tod1yTUwIlTSYIFHgEoVwL9DUS/4a7BRgbI7+dcqRge7/PzOqyzK/R1LU=; Message-ID: <729136.50063.qm@web36801.mail.mud.yahoo.com> X-YMail-OSG: fgmcLEEVM1k3dbHr58BOt_nKjGPdDTDHKR5aCZSOCnbjk6VauuHnSF1tdLYtKPbFq.VT3RbS7.E5_ddNiggTH0hxDJvDvf1kHjapk9BoHGk6jTqVFXyEWAQaPSmU9wcEB1t0eq_bHDQRdu896niKp4GJiOwsHgiUszzNDf_mAzdmylQrBPqvHjhiMlILxD238DNviDVj_Riel83M_oG.dtsCZdk1xlfwss_9mfwkvfidxxAzL07cNz_ihabcOhWvThdXK6kd214yEXm0PCH7hXrUF20K7V6pqn55AyIPVaWwxzUMDgzdZUx6HUMuQSzNENtoLeE- Received: from [67.102.145.11] by web36801.mail.mud.yahoo.com via HTTP; Wed, 29 Apr 2009 09:50:15 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <004d01c9bc70$d3c3e6c0$500c7c0a@china.huawei.com> <81761.9046.qm@web36807.mail.mud.yahoo.com> <003401c9bed1$aad507e0$500c7c0a@china.huawei.com> <49E7A504.2000808@grotto-networking.com> <332299.33564.qm@web36802.mail.mud.yahoo.com> <000d01c9c83e$f3cfcfe0$500c7c0a@china.huawei.com> Date: Wed, 29 Apr 2009 09:50:15 -0700 (PDT) From: Igor Bryskin To: Young Lee , Greg Bernstein In-Reply-To: <000d01c9c83e$f3cfcfe0$500c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-835747330-1241023815=:50063" Cc: pce@ietf.org Subject: Re: [Pce] Comments on draft-lee-pce-ted-alternatives-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 16:49:00 -0000 --0-835747330-1241023815=:50063 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Young.=0A=0APlease see my comments in line.=0A=0AIgor=0A=0A=0A=0A=0A_______= _________________________=0AFrom: Young Lee =0ATo: Igor Br= yskin ; Greg Bernstein = =0ACc: pce@ietf.org=0ASent: Tuesday, April 28, 2009 4:21:45 PM=0ASubject: R= E: Comments on draft-lee-pce-ted-alternatives-01.txt=0A=0A =0AHi Igor,=0A = =0AI have a couple of=0Acomments on your =E2=80=9Cnetwork planner=E2=80=9D = application using PCEP. =0A =0A- First=0Aof all, this is specific = to PCEP implementation which we need to address in the=0Asolutions draft on= ce the PCE-TED draft idea has been accepted in the WG. We=0Aneed to separat= e detail discussion on a particular implementation from the=0Acurrent draft= . But I think your suggested application is worth to revisit once=0Awe have= a solution draft. =0A=0A=0AIB>>=0AI know you want to avoid to talk about s= pecific solutions to IGP-TE alternative=0Aat this stage. But this is not a = requirements document. So IMO it is OK to give=0Aan example of one obvious = (at least to me) such solution - extended PCEP -=0Abecause:=0Aa)=0Ano matte= r how TED is managed on the PCE, each NE will have to support the PCC=0Asid= e of PCEP to take advantage of the remote path computation service, so why = use/invent=0Aother protocols?=0Ab)=0APCEP already addresses (or at least is= supposed to address) such important=0Aaspects as security, reliable and in= -order message delivery, client-server=0Asession support, etc.=0Ac)=0AI als= o remember discussions in PCE WG about having PCEP provide an opaque=0Aopti= on to deliver arbitrary information between PCC and PCE, everybody agreed= =0A(as I remember) that this is a reasonable and quite easy thing to do; an= d this=0Ais exactly what we need for the PCE-TED application=0A=0A - = The=0Aintention of PCE-TED draft is not necessarily to replace the whole= IGP-TE as=0Ainformation disseminating mechanism but to suggest that certai= n applications=0Amay warrant alternative methods that can co-exist with IGP= -TE. We don=E2=80=99t=0Awant to reinvent the new wheel necessarily with th= e current scope of the draft.=0AWe would want to stay as =E2=80=9Ccomplemen= tary=E2=80=9D to IGP-TE. =0A=0A=0AIB>>=0AI think we need to consider two ca= ses:=0A1)=0AAll path computations are performed on PCEs (no local path comp= utations)=0A2)=0ASome path computations are performed on PCEs, while some l= ocally.=0AIn=0Acase 1) I don't really see why PCE-TED should co-exist with = IGP-TE. If two=0Amechanisms perform exactly the same function, and one is b= etter than the other,=0Awhat sense does it make to advertise certain things= via one and other things using=0Athe other? It makes perfect sense to me j= ust to pick the better one;=0AIn=0Acase 2) it does make some sense to have = IGP-TE and PCE-TED co-exist. One=0Aexample of such co-operation is that you= can break your optical layer network=0Ainto multiple areas in such a way t= hat intra-area paths would not require=0Aoptical impairments aware path com= putations, while inter-area paths should be computed=0Awith optical impairm= ents constraints in mind. So now you can split:=0Aa)=0Aadvertising: IGP-TE = for all non-impairement related information;=0A =0APC= E-TED for all impairement related information;=0Ab)=0Acomputation: local fo= r intra-area paths; PCE for inter-area paths.=0A=0AOne=0Alast note. My unde= rstanding, Young, that you have in mind to use PCE-TED for=0Aall WSON-relat= ed information, and IGP-TE for everything else. This path, I=0Athink, is no= t correct for the following reasons:=0Aa)=0Aas I mentioned above such coope= ration only makes sense when you assume that at=0Aleast some path computati= ons are performed locally (not via remote PCE);=0Ab)=0Ain the optical layer= network link level path computations (what you call=0Arouting without lamb= da assignment in a hope that somebody else (signaling or=0APCE) assign prop= er lambdas over computed link-level paths) are very impractical=0A(to say t= he least) . Because local TEDs won't contain in this case lambda and switch= ing=0Aassymetricity information, local path computations will produce no va= lue, hence=0Aall computations eventually would have to be performed on PCEs= which (as I=0Amentioned above) will make the PCE-TED and IGP-TE cooperatio= n unnecessary.=0A=0ACheers,=0AIgor=0A =0A =0AThanks.=0A =0ARegards,=0AYoung= =0A=0A________________________________=0A =0AFrom:Igor Bryskin=0A[mailto:i_= bryskin@yahoo.com] =0ASent: Tuesday, April 21, 2009=0A12:59 PM=0ATo: Greg B= ernstein; Young Lee=0ACc: pce@ietf.org=0ASubject: Re: Comments on=0Adraft-l= ee-pce-ted-alternatives-01.txt=0A =0AHi,=0A=0AIn my comments I forgot to me= ntion IMO a very good argument in favor and a=0Astrong drive for using an a= lternative to IGP-TE method for managing TED.=0A=0AConsider a "network plan= ner" type of applications which try various=0A"what if?" scenarios on netwo= rk topologies that do not (fully or=0Apartially) exist yet but could be pro= visioned under certain circumstances.=0AThese applications , of course, req= uire numerous complex path computations and=0Aare great candidates to play= the PCC role. But, as Eve Varma said on the=0Alast IETF, our path computat= ions are only as good as our advertisements. So,=0Afor a Network Planner it= would be quite easy to use PCEP and send the necessary=0Aresource state in= formation to a PCE for not yet existing links on behalf of not=0Ayet existi= ng NEs, request the path computation(s) and then clean up the PCE's=0ATED. = It is much more difficult (if not impossible) to do the same things using= =0AIGP-TE (e.g. have unexisting NEs originate TE LSAs and then flush them o= ut when=0Athey are not needed anymore).=0A=0ASo there are two important byp= roducts that a PCEP based method of managing TED=0Agives compared to the IG= P-TE method:=0Aa) ability to send TE info updates on behalf of unexisting l= inks and NEs;=0Ab) determine the moment when all the necessary TE info is i= nstalled in the=0APCE's TED, and it is possible to request the path computa= tions.=0A=0ANote that b) in its own right is quite non-trivial problem to s= olve when one=0Auses the IGP-TE method for the TED management.=0A=0ACheers,= =0AIgor=0A =0A=0A________________________________=0A =0AFrom:Greg Bernstein= =0A=0ATo: Young Lee=0A=0ACc: = Igor Bryskin=0A=0ASent: Thursday, April 16, 2009=0A5:3= 7:08 PM=0ASubject: Re: Comments on=0Adraft-lee-pce-ted-alternatives-01.txt= =0A=0AGreat to have help with the editing and concept development!=0A=0AChe= ers=0A=0AGreg=0A=0AYoung Lee wrote: =0AHi Igor,=0A =0AThanks a lot for your= comments. They are=0Aall valuable ones and we can put most of them in the = update. I will send you=0Athe WORD template of the existing version so that= you may be able to=0Aparticipate editing exercise with other co-authors. T= hanks. =0A =0ARegards,=0AYoung=0A =0A=0A________________________________=0A= =0AFrom:Igor Bryskin [mailto:i_bryskin@yahoo.com] =0ASent: Thursday, April= 16, 2009=0A2:15 PM=0ATo: Young Lee; pce@ietf.org=0ASubject: Comments on=0A= draft-lee-pce-ted-alternatives-01.txt=0A =0AHi,=0A=0A=0A=0A=0AHere is my co= mments on the draft =E2=80=9CAlternative Approaches to Traffic Engineering= Database Creation and Maintenance for Path Computation Elements=E2=80=9D = =0Ahttp://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt =0A =0AGe= neral comments.=0A =0A1. Everywhere you say IGP you mean, I am sure, IGP-TE= . It is worth to=0Amake it clear. I know that many people think that IGP-TE= is an extension of IGP=0Afor TE purposes, but in fact, the two are complet= ely different protocols with completely=0Adifferent purposes: one is to dyn= amically manage IP forwarding tables, and the=0Aother is to discover networ= k resources of various network layers and use this=0Ainformation for constr= aint based path computations. The only thing that the two=0Ahave in common = is that they may share the same instance of the IGP=0Aflooding/synchronizat= ion machinery (even this becomes increasingly untrue:=0Atoday many use sepa= rate instances, look for the OSPF transport instance and=0Amulti-instance a= ctivities in the OSPF WG). Other then that, the two protocols=0Ahave nothin= g in common; and this is especially true in the context of this=0Adocument.= It is quite reasonable to imagine, for example, that within the PCE=0AArch= itecture one can completely eliminate use of IGP-TE by using, say,=0APCEP = instead, to send local resource updates directly to PCE(s). However,=0Aone= will still need IGP for forwarding control plane traffic. So my point here= =0Ais that we want alternative methods to IGP-TE and not to IGP.=0A =0A2. I= =E2=80=99d like to see in the draft a discussion on why the flooding=0Aof T= E information and the PCE architecture is not a good match. And this is=0Ab= ecause flooding of any type of information works well on homogeneous=0Atopo= logies, where all participants originate, distribute and use the=0Ainformat= ion. That=E2=80=99s why IP OSPF, for example, works well: all OSPF=0Aspeake= rs originate LSAs, flood local and remote LSAs and use them in route=0Acalc= ulations. The PCE architecture is by definition asymmetrical with respect= =0Ato the information used in path computations: many elements originate, b= ut only=0Afew use it, and the flooding under these circumstances could be v= ery=0Ainefficient for all these reasons that you mentioned: memory, CPU, ba= ndwidth,=0Aetc.=0A =0ASpecific comments:=0A =0A1. You write:=0A=E2=80=9C T= his draft does not advocate that the alternative methods=0Aspecified =0A = in this draft should completely replace the IGP as the=0Amethod of =0A cr= eating the TED.=E2=80=9D=0A =0AWhy not? I mean there is a variety of ways h= ow the alternative methods=0Acould relate to the IGP-TE method of managing = TEDs. And I=E2=80=99d like to see a=0Asection describing different use case= s and examples of IGP-TE and the=0Aalternatives cooperating with each other= . One such use case is, for example, a=0Anetwork built of simple optical NE= s managed by a tiny control plane that=0Aconsists of:=0A1) PCC instance to = send updates to remote PCE(s) on local resources=0Astatus and also request = path computations;=0A2) Very limited RSVP-TE instance for signaling fully e= xplicit=0AEROs provided by the PCE(s).=0A =0AIn this case IGP-TE is not in= volved at all. =0A =0AThere could be different ways how the alternatives ca= n cooperate with=0AIGP-TE. One such cooperation, as you suggested, could be= a split of what=0Ainformation is distributed by IGP-TE and what via altern= atives. For example, it=0Amakes sense to distribute =E2=80=9Cstatic=E2=80= =9D (rarely modified) and sizable=0Adata =E2=80=93 e.g. NE switching asymme= tricity =E2=80=93 via methods other than=0AIGP-TE, while more frequently ch= anged data via IGP-TE. This could significantly=0Adecrease the IGP-TE infor= mation and its footprint on all speakers.=0A =0AAnother type of cooperation= between the IGP-TE method and its=0Aalternatives is limiting number and ty= pe of elements participating in IGP-TE.=0AYour architectural option #3 requ= ires inter-PCE TED synchronization. How about=0Ainterconnecting PCEs into o= ne or more rings via IP-IP tunnels and use=0Aan instance of IGP-TE over t= he tunnels for the sole purpose of TED=0Asynchronization between the PCEs?= =0A =0A2. You wrote:=0A =0A=E2=80=9CIn OSPF the information directly relate= d to IP =0A connectivity (and hence the control communications plane=0Afo= r all =0A three technologies) is kept in the link state database=0A(LSDB)= , while =0A additional information related to traffic engineering used=0A= by MPLS =0A and GMPLS is kept in a (conceptually) separate traffic=0Aengi= neering =0A database (TED)=E2=80=9D.=0A =0AThis is not accurate. All IP a= nd non-IP advertisements are stored in=0ALSDB. Additionally, TE info is kep= t in TED.=0A =0A3. In section 2.0 you describe the advantages of using alte= rnative to=0AIGP-TE methods. You also need here to clearly state the disadv= antages, which=0Aare:=0Aa) necessity of mechanisms that we take for grante= d when use=0AIGP-TE: removal of stale information, reliable delivery of upd= ates to all=0Aparticipants; recovery after reboots/crashes/upgrades, etc.= =0Ab) additional security concerns;=0Ac) protocol to discover PCEs that are= capable and willing to accept=0Adirect updates;=0Ad) protocol to send the = updates;=0Aetc.=0A =0A4. Why not PCEP?=0A =0AThis is not a requirement docu= ment. So I think it would be beneficial=0Ato suggest a solution for the pro= tocol to be used by NEs to send resource=0Aupdates to PCE(s). Considering t= hat this protocol is supposed to:=0Aa) discover PCE(s) capable and willing = to receive such updates;=0Ab) maintain sessions between NEs and PCE(s);=0Ac= ) address all the security concerns for PCE(s) to accept such updates;=0Ad= ) guarantee reliable delivery of the updates;=0A =0Awhy not to extend PCEP = for this purpose since it is already doing all=0Athese things?=0A =0ACheers= ,=0AIgor=0A =0A =0A-- =0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0ADr Greg Bernstein, Grotto Networking= (510) 573-2237=0A=0A=0A --0-835747330-1241023815=:50063 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Young.

Please see my comments in line.

Igor=

From: Young Lee <yle= e@huawei.com>
To: Ig= or Bryskin <i_bryskin@yahoo.com>; Greg Bernstein <gregb@grotto-net= working.com>
Cc: pce= @ietf.org
Sent: Tuesday= , April 28, 2009 4:21:45 PM
Subjec= t: RE: Comments on draft-lee-pce-ted-alternatives-01.txt

=0A=0A=0A=0A =0A =0A=0A=0A=0A=0A=0A
<= meta name=3D"ProgId" content=3D"Word.Document">=0A=0A

Hi Igor,=0A=0A

 

=0A=0A

I have a couple of=0Acomments on your =E2=80=9Cnetwork pla= nner=E2=80=9D application using PCEP.

=0A=0A

 

=0A=0A

-  &nb= sp;      =0AFirst=0Aof all, this is spec= ific to PCEP implementation which we need to address in the=0Asolutions dra= ft once the PCE-TED draft idea has been accepted in the WG. We=0Aneed to se= parate detail discussion on a particular implementation from the=0Acurrent = draft. But I think your suggested application is worth to revisit once=0Awe= have a solution draft.


=0A=0A

IB>>=0AI know you want to avoid to talk about specific solut= ions to IGP-TE alternative=0Aat this stage. But this is not a requirements = document. So IMO it is OK to give=0Aan example of one obvious (at least to = me) such solution - extended PCEP -=0Abecause:

=0A=0A<= p class=3D"MsoNormal" style=3D"margin-left: 0.5in;">a)=0Ano matter how TED is manage= d on the PCE, each NE will have to support the PCC=0Aside of PCEP to take a= dvantage of the remote path computation service, so why use/invent=0Aother = protocols?

=0A=0A

b)=0APCEP already addresses (or at least is supposed to address) suc= h important=0Aaspects as security, reliable and in-order message delivery, = client-server=0Asession support, etc.

=0A=0A

c)=0AI also remember discussions in PCE= WG about having PCEP provide an opaque=0Aoption to deliver arbitrary infor= mation between PCC and PCE, everybody agreed=0A(as I remember) that this is= a reasonable and quite easy thing to do; and this=0Ais exactly what we nee= d for the PCE-TED application


=0A=0A

 -   =       =0AThe=0Aintention of PCE-TED draf= t is not necessarily to replace the whole IGP-TE as=0Ainformation dissemina= ting mechanism but to suggest that certain applications=0Amay warrant alter= native methods that can co-exist with IGP-TE.  We don=E2=80=99t=0Awant= to reinvent the new wheel necessarily with the current scope of the draft.= =0AWe would want to stay as =E2=80=9Ccomplementary=E2=80=9D to IGP-TE.
=


=0A=0A

IB>>=0AI thi= nk we need to consider two cases:

=0A=0A

1)=0AAll path computations are performed on P= CEs (no local path computations)

=0A=0A

2)=0ASome path computations are performed on P= CEs, while some locally.

=0A=0A

In=0Acase 1) I don't really see why PCE-TED should co-= exist with IGP-TE. If two=0Amechanisms perform exactly the same function, a= nd one is better than the other,=0Awhat sense does it make to advertise cer= tain things via one and other things using=0Athe other? It makes perfect se= nse to me just to pick the better one;

=0A=0A

In=0Acase 2) it does make some sense to= have IGP-TE and PCE-TED co-exist. One=0Aexample of such co-operation is th= at you can break your optical layer network=0Ainto multiple areas in such a= way that intra-area paths would not require=0Aoptical impairments aware pa= th computations, while inter-area paths should be computed=0Awith optical i= mpairments constraints in mind. So now you can split:

= =0A=0A

a)=0Aadvertising: IGP-TE = for all non-impairement related information;

=0A=0A

     &nbs= p;            &= nbsp;    =0APCE-TED for all impairement related informa= tion;

=0A=0A


=

=0A=0A

One=0Alast note. My = understanding, Young, that you have in mind to use PCE-TED for=0Aall WSON-r= elated information, and IGP-TE for everything else. This path, I=0Athink, i= s not correct for the following reasons:

=0A=0A

a)=0Aas I mentioned above such coopera= tion only makes sense when you assume that at=0Aleast some path computation= s are performed locally (not via remote PCE);

=0A=0Ab)=0Ain the optical layer network= link level path computations (what you call=0Arouting without lambda assig= nment in a hope that somebody else (signaling or=0APCE) assign proper lambd= as over computed link-level paths) are very impractical=0A(to say the = least) . Because local TEDs won't contain in this case lambda and switching= =0Aassymetricity information, local path computations will produce no value= , hence=0Aall computations eventually would have to be performed on PCEs wh= ich (as I=0Amentioned above) will make the PCE-TED and IGP-TE cooperation u= nnecessary.

=

=0A=0A

Cheers,<= /span>

=0A=0A

Igor=

=0A=0A

 

=0A= =0A

 

=0A=0A

Thanks.

=0A=0A

 

=0A=0A

Regards,

=0A=0A=

Young

=0A=0A
=0A=0A
=0A=0A
=0A=0A

From: Igor Bryskin=0A[ma= ilto:i_bryskin@yahoo.com]
=0ASent= : Tuesday, April 21, 2009=0A12:59 PM
=0ATo: Greg Bernstein; Young Lee
=0ACc: pce@ietf.org
=0ASubject: Re: Comments on=0Adraft-lee-pce= -ted-alternatives-01.txt

=0A=0A

&n= bsp;

=0A=0A

Hi,
=0A
= =0AIn my comments I forgot to mention IMO a very good argument in favor and= a=0Astrong drive for using an alternative to IGP-TE method for managing TE= D.
=0A
=0AConsider a "network planner" type of applications which try= various=0A"what if?" scenarios on network topologies that do not (fully or= =0Apartially) exist yet but could be provisioned under certain circumstance= s.=0AThese applications , of course, require numerous complex path computat= ions and=0Aare great candidates  to play the PCC role. But, as Eve Var= ma said on the=0Alast IETF, our path computations are only as good as our a= dvertisements. So,=0Afor a Network Planner it would be quite easy to use PC= EP and send the necessary=0Aresource state information to a PCE for not yet= existing links on behalf of not=0Ayet existing NEs, request the path compu= tation(s) and then clean up the PCE's=0ATED. It is much more difficult (if = not impossible) to do the same things using=0AIGP-TE (e.g. have unexisting = NEs originate TE LSAs and then flush them out when=0Athey are not needed an= ymore).
=0A
=0ASo there are two important byproducts that a PCEP base= d method of managing TED=0Agives compared to the IGP-TE method:
=0Aa) ab= ility to send TE info updates on behalf of unexisting links and NEs;
=0A= b) determine the moment when all the necessary TE info is installed in the= =0APCE's TED, and it is possible to request the path computations.
=0A=0ANote that b) in its own right is quite non-trivial problem to solve wh= en one=0Auses the IGP-TE method for the TED management.
=0A
=0ACheers= ,
=0AIgor

=0A=0A
=0A=0A

 

=0A=0A
=0A=0A
=0A=0A
=0A=0A
=0A=0A

From: Gre= g Bernstein=0A<gregb@grotto-networking.com>
=0ATo: Young Lee=0A<ylee@huawei.com>
= =0ACc: Igor Bryskin=0A<= i_bryskin@yahoo.com>
=0ASent: Thursday, April 16, 2009=0A5:37:08 PM
=0ASubject: Re: Comments on=0Adraft-lee-pce-ted-al= ternatives-01.txt
=0A
=0AGreat to have help with the ed= iting and concept development!
=0A
=0ACheers
=0A
=0AGreg
=0A=
=0AYoung Lee wrote:

=0A=0A
=0A=0A

Hi Igor,

=0A=0A

 =

=0A=0A

Tha= nks a lot for your comments. They are=0Aall valuable ones and we can put mo= st of them in the update. I will send you=0Athe WORD template of the existi= ng version so that you may be able to=0Aparticipate editing exercise with o= ther co-authors. Thanks.

=0A=0A

 

=0A=0A

Regards,

=0A=0A

Y= oung

=0A=0A

 

=0A=0A
=0A=0A
=0A=0A
=0A=0A

From:= Igor Bryskin [mailto:i_b= ryskin@yahoo.com]
=0ASent: Thursday, April 16, 2009=0A2:15 PM
=0ATo: Young Lee; pce@ietf.org=
=0ASubject: Commen= ts on=0Adraft-lee-pce-ted-alternatives-01.txt

=0A=0A

 

=0A=0A
Hi,
=0A
=0A
=0A
=0AHere is my comments on&n=
bsp; the draft =E2=80=9CAlternative Approaches to Traffic Engineering Datab=
ase Creation and Maintenance for Path Computation Elements=E2=80=9D =
=0A=0A

= http://tools.ietf.org/id/draft-lee-pce-ted-alternatives-01.txt= =0A

=0A=0A

 <= /font>

=0A=0A

General comments.

= =0A=0A

 

=0A=0A

1. Everywhere you say IGP you mean, I am sure, IGP-TE. It is worth= to=0Amake it clear. I know that many people think that IGP-TE is an extens= ion of IGP=0Afor TE purposes, but in fact, the two are completely different= protocols with completely=0Adifferent purposes: one is to dynamically mana= ge IP forwarding tables, and the=0Aother is to discover network resources o= f various network layers and use this=0Ainformation for constraint based pa= th computations. The only thing that the two=0Ahave in common is that they = may share the same instance of the IGP=0Aflooding/synchronization machinery= (even this becomes increasingly untrue:=0Atoday many use separate instance= s, look for the OSPF transport instance and=0Amulti-instance activities in = the OSPF WG). Other then that, the two protocols=0Ahave nothing in common; = and this is especially true in the context of this=0Adocument. It is quite = reasonable to imagine, for example, that within the PCE=0AArchitecture one = can completely eliminate use  of IGP-TE by using, say,=0APCEP instead,= to send local resource updates directly to PCE(s).  However,=0Aone wi= ll still need IGP for forwarding control plane traffic. So my point here=0A= is that we want alternative methods to IGP-TE and not to IGP.=

=0A=0A

 

=0A=0A

2. I=E2=80=99d like to see in the draft a discussion on why = the flooding=0Aof TE information and the PCE architecture is not a good mat= ch. And this is=0Abecause flooding of any type of information works well on= homogeneous=0Atopologies, where all participants originate, distribute and= use the=0Ainformation. That=E2=80=99s why IP OSPF, for example, works well= : all OSPF=0Aspeakers originate LSAs, flood local and remote LSAs and use t= hem in route=0Acalculations. The PCE architecture is by definition asymmetr= ical with respect=0Ato the information used in path computations: many elem= ents originate, but only=0Afew use it, and the flooding under these circums= tances could be very=0Ainefficient for all these reasons that you mentioned= : memory, CPU, bandwidth,=0Aetc.

=0A=0A

 

=0A=0A

Specific comment= s:

=0A=0A

 

= =0A=0A

1. You write:

=0A=0A

=E2=80=9C  This draft does not advocate that the altern= ative methods=0Aspecified

=0A=0A

<= font size=3D"3" face=3D"Times New Roman">&= nbsp;  in this draft should completely replace the IGP as the=0Amethod= of

=0A=0A

   creating= the TED.=E2=80=9D

=0A=0A

 

=0A=0A

Why not? I mean there is a var= iety of ways how the alternative methods=0Acould relate to the IGP-TE metho= d of managing TEDs. And I=E2=80=99d like to see a=0Asection describing diff= erent use cases and examples of IGP-TE and the=0Aalternatives cooperating w= ith each other. One such use case is, for example, a=0Anetwork built of sim= ple optical NEs managed by a tiny control plane that=0Aconsists of:<= /font>

=0A=0A

1) PCC instance to send updates to = remote PCE(s) on local resources=0Astatus and also request path computation= s;

=0A=0A

2) Very limited RSVP-TE i= nstance for signaling fully explicit=0AEROs  provided by the PCE(s).

=0A=0A

 

=0A= =0A

In this case IGP-TE is not involved at all.

=0A=0A

 

=0A=0A<= p class=3D"MsoNormal">There could be different ways how the alternatives ca= n cooperate with=0AIGP-TE. One such cooperation, as you suggested, could be= a split of what=0Ainformation is distributed by IGP-TE and what via altern= atives. For example, it=0Amakes sense to distribute =E2=80=9Cstatic=E2=80= =9D (rarely modified) and sizable=0Adata =E2=80=93 e.g. NE switching asymme= tricity =E2=80=93 via methods other than=0AIGP-TE, while more frequently ch= anged data via IGP-TE. This could significantly=0Adecrease the IGP-TE infor= mation and its footprint on all speakers.

=0A=0A

 

=0A=0A

Anothe= r type of cooperation between the IGP-TE method and its=0Aalternatives is l= imiting number and type of elements participating in IGP-TE.=0AYour archite= ctural option #3 requires inter-PCE TED synchronization. How about=0Ainterc= onnecting PCEs into one or more rings  via IP-IP tunnels and use=0Aan&= nbsp; instance of IGP-TE over the tunnels for the sole purpose of TED=0Asyn= chronization between the PCEs?

=0A=0A

 

=0A=0A

2. You wrote:

=0A=0A

 

=0A=0A<= p class=3D"MsoNormal">=E2=80=9CIn OSPF the information directly related to = IP

=0A=0A

   connectivit= y (and hence the control communications plane=0Afor all

= =0A=0A

   three technologies) is kept in th= e link state database=0A(LSDB), while

=0A=0A

   additional information related to traffic engineeri= ng used=0Aby MPLS

=0A=0A

 &nb= sp; and GMPLS is kept in a (conceptually) separate traffic=0Aengineering

=0A=0A

   database (TED)= =E2=80=9D.

=0A=0A

 

=0A=0A

This is not accurate. All IP and non-I= P advertisements are stored in=0ALSDB. Additionally, TE info is kept in TED= .

=0A=0A

 

= =0A=0A

3. In section 2.0 you describe the advantages = of using alternative to=0AIGP-TE methods. You also need here to clearly sta= te the disadvantages, which=0Aare:

=0A=0A

a)  necessity of mechanisms that we take for granted when use= =0AIGP-TE: removal of stale information, reliable delivery of updates to al= l=0Aparticipants; recovery after reboots/crashes/upgrades, etc.

=0A=0A

b) additional security concerns;=

=0A=0A

c) protocol to discover PCEs that = are capable and willing to accept=0Adirect updates;

=0A= =0A

d) protocol to send the updates; =0A=0A

etc.

=0A=0A

 

=0A=0A

4. Why not PC= EP?

=0A=0A

 

= =0A=0A

This is not a requirement document. So I thin= k it would be beneficial=0Ato suggest a solution for the protocol to be use= d by NEs to send resource=0Aupdates to PCE(s). Considering that this protoc= ol is supposed to:

=0A=0A

a) discov= er PCE(s) capable and willing to receive such updates;

= =0A=0A

b) maintain sessions between NEs and PCE(s);

=0A=0A

c) address all the security c= oncerns  for PCE(s) to accept such updates;

=0A=0Ad) guarantee reliable delivery of the updates;=

=0A=0A

 

=0A=0A

why not to extend PCEP for this purpose since it is a= lready doing all=0Athese things?

=0A=0A

 

=0A=0A

Cheers,

=0A=0A

Igor

=0A=0A

 

=0A=0A
=0A=0A

 

=0A=0A
=
-- <=
br>=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
=0ADr Greg Bernstein, Grotto Networking (510) 573-2237<=
/font>
=0A=0A
=0A=0A

 <= /font>

=0A=0A
=0A=0A

=0A=0A --0-835747330-1241023815=:50063--