From julien.meuric@orange.com Mon Jul 1 09:14:40 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B711E80E2 for ; Mon, 1 Jul 2013 09:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glYRpL+wfpzw for ; Mon, 1 Jul 2013 09:14:35 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8AB21F9635 for ; Mon, 1 Jul 2013 09:14:35 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1ED64DE4005; Mon, 1 Jul 2013 18:16:17 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 12B58DE4003; Mon, 1 Jul 2013 18:16:17 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Jul 2013 18:14:32 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Jul 2013 18:14:32 +0200 Message-ID: <51D1AAE7.4060208@orange.com> Date: Mon, 01 Jul 2013 18:14:31 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2013 16:14:32.0328 (UTC) FILETIME=[1229F080:01CE7676] Cc: 'JP Vasseur' Subject: [Pce] Slot Request for Berlin X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 16:14:40 -0000 Hi all. The preliminary agenda for IETF 87 is out. The PCE WG meeting is currently scheduled in the afternoon of Wednesday 31. If you intend to discuss an issue with the WG, now is time to ask for a slot. Please send your request to your chairs and secretary not later than Monday July 15, including a title or corresponding I-D(s), the intended duration and the expected speaker. Thanks, Dan, JP & Julien From internet-drafts@ietf.org Mon Jul 1 14:44:33 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B071311E82B0; Mon, 1 Jul 2013 14:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5373Mu67LcK; Mon, 1 Jul 2013 14:44:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF2B21F9BBA; Mon, 1 Jul 2013 14:44:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701214406.10273.42308.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 14:44:06 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 21:44:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : PCEP Extensions for Stateful PCE Author(s) : Edward Crabbe Jan Medved Ina Minei Robert Varga Filename : draft-ietf-pce-stateful-pce-05.txt Pages : 60 Date : 2013-07-01 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-stateful-pce-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ina@juniper.net Mon Jul 1 14:54:30 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390DD21F918F for ; Mon, 1 Jul 2013 14:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJjRoSLxcXUO for ; Mon, 1 Jul 2013 14:54:24 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id D43A921F91B4 for ; Mon, 1 Jul 2013 14:54:23 -0700 (PDT) Received: from mail157-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE009.bigfish.com (10.174.4.72) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Jul 2013 21:54:22 +0000 Received: from mail157-db8 (localhost [127.0.0.1]) by mail157-db8-R.bigfish.com (Postfix) with ESMTP id 4EAE1401BE for ; Mon, 1 Jul 2013 21:54:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz9371I936eI542Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail157-db8: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=ina@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail157-db8 (localhost.localdomain [127.0.0.1]) by mail157-db8 (MessageSwitch) id 1372715660467586_20170; Mon, 1 Jul 2013 21:54:20 +0000 (UTC) Received: from DB8EHSMHS024.bigfish.com (unknown [10.174.8.249]) by mail157-db8.bigfish.com (Postfix) with ESMTP id 6E1EC360049 for ; Mon, 1 Jul 2013 21:54:20 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by DB8EHSMHS024.bigfish.com (10.174.4.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 1 Jul 2013 21:54:20 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 1 Jul 2013 14:54:18 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 1 Jul 2013 14:54:17 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 1 Jul 2013 15:06:06 -0700 Received: from mail127-va3-R.bigfish.com (10.7.14.225) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Jul 2013 21:54:16 +0000 Received: from mail127-va3 (localhost [127.0.0.1]) by mail127-va3-R.bigfish.com (Postfix) with ESMTP id BE9E63201DA for ; Mon, 1 Jul 2013 21:54:16 +0000 (UTC) Received: from mail127-va3 (localhost.localdomain [127.0.0.1]) by mail127-va3 (MessageSwitch) id 1372715654805435_13975; Mon, 1 Jul 2013 21:54:14 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.242]) by mail127-va3.bigfish.com (Postfix) with ESMTP id BD80F42004B for ; Mon, 1 Jul 2013 21:54:14 +0000 (UTC) Received: from BLUPRD0511HT004.namprd05.prod.outlook.com (157.56.232.213) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 1 Jul 2013 21:54:09 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.186]) by BLUPRD0511HT004.namprd05.prod.outlook.com ([10.255.135.167]) with mapi id 14.16.0324.000; Mon, 1 Jul 2013 21:54:09 +0000 From: Ina Minei To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt Thread-Index: AQHOdqQ1coNUf2Eve0elhZ6tG3mFmplQXA9A Date: Mon, 1 Jul 2013 21:54:08 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3037FAA51@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <20130701214406.10273.42308.idtracker@ietfa.amsl.com> In-Reply-To: <20130701214406.10273.42308.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 21:54:30 -0000 Version 05 of the draft addresses many of the issues raised on the list, in= particular: support for more robust error reporting and correlation, clari= fications on the make-before-break behavior and behavior under failure cond= itions.=20 Review and comments are welcome.=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of inter= net-drafts@ietf.org Sent: Monday, July 01, 2013 2:44 PM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : PCEP Extensions for Stateful PCE Author(s) : Edward Crabbe Jan Medved Ina Minei Robert Varga Filename : draft-ietf-pce-stateful-pce-05.txt Pages : 60 Date : 2013-07-01 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-stateful-pce-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pe-jiang@kddi.com Mon Jul 1 18:54:05 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5700621F8267 for ; Mon, 1 Jul 2013 18:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyL5ZeUlL8as for ; Mon, 1 Jul 2013 18:54:01 -0700 (PDT) Received: from UTMC1104.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id DD4EF11E8373 for ; Mon, 1 Jul 2013 18:54:00 -0700 (PDT) Received: from UTMC1131 (unknown [10.5.16.192]) by UTMC1104.kddi.com (Postfix) with SMTP id 302D22A2B; Tue, 2 Jul 2013 10:53:58 +0900 (JST) Received: from UTMC1122.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id F1FC75D65; Tue, 2 Jul 2013 10:53:46 +0900 (JST) Received: from UTMC1113.kddi.com (unknown [10.5.16.13]) by UTMC1122.kddi.com (Postfix) with ESMTP id E06DF5D4F; Tue, 2 Jul 2013 10:53:46 +0900 (JST) Received: from KDDI-0806PC0671 ([10.200.129.117] [10.200.129.117]) by post-ims.kddi.com with ESMTPA; Tue, 2 Jul 2013 10:53:46 +0900 To: jvasseur@cisco.com, pce@ietf.org, julien.meuric@orange.com From: Peng JIANG References: <201210151120.AHI81244.QFtBOHJK@kddi.com> <03B78081B371D44390ED6E7BADBB4A7721FE06A3@xmb-rcd-x02.cisco.com> <201210151638.AGF34889.JOKQtBHF@kddi.com> <201305101017.BED02471.OBtKHFQJ@kddi.com> In-Reply-To: <201305101017.BED02471.OBtKHFQJ@kddi.com> Message-Id: <201307021053.FFH12467.OBJtHQFK@kddi.com> X-Mailer: Winbiff [Version 2.51 PL3] X-Accept-Language: ja,en,zh Date: Tue, 2 Jul 2013 10:53:46 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 1307021053470000107365 Cc: jpv@cisco.com Subject: Re: [Pce] About draft-kumaki-murai-pce-pcep-extension-l3vpn X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 01:54:05 -0000 Dear JP, Julien and PCEers, The following email was sent a few days ago. > Please let me remind you that we have a new version for the PCEP > extension draft. > http://tools.ietf.org/html/draft-kumaki-murai-pce-pcep-extension > -l3vpn-11 > > We received a few comments during the presentation at the > Atlanta meeting. One of the comments is that the Intended Status > should be the same as that of the signaling protocol. > > In this new version, the Intended Status has been changed to > Experimental together with various expression change that comply > with the new Intended Status. > > FYI, The RSVP signaling protocol that we proposed is now RFC6882. > http://tools.ietf.org/html/rfc6882 > > We also add a reference to this new RFC. > > Please let us konw if you have new comments. > And we would like to ask for WG adoption if you all feel OK > about this draft. Please let us know your opinion about this new version. Your comment is highly appreciated. Thanks! Best Regards, Peng JIANG KDDI > Dear JP and PCEers, > > Please let me remind you that we have a new version for the PCEP > extension draft. > http://tools.ietf.org/html/draft-kumaki-murai-pce-pcep-extension > -l3vpn-11 > > We received a few comments during the presentation at the > Atlanta meeting. One of the comments is that the Intended Status > should be the same as that of the signaling protocol. > > In this new version, the Intended Status has been changed to > Experimental together with various expression change that comply > with the new Intended Status. > > FYI, The RSVP signaling protocol that we proposed is now RFC6882. > http://tools.ietf.org/html/rfc6882 > > We also add a reference to this new RFC. > > Please let us konw if you have new comments. > And we would like to ask for WG adoption if you all feel OK > about this draft. > > Best Regards, > Peng JIANG > KDDI > > > Dear JP, > > Cc: KDDI Miyasaka-san > > > > Thank you very much for your quick reply. > > > > > JP> Yes I believe that it is now time to get back to the PCE WG for a last > > > presentation. > > > > Thank you very much for your suggestion. > > We would like to request a presentation slot for 5 or 10 minutes. > > Could you please assign one to us? > > My colleague Miyasaka-san will attend IETF85 and he is willing > > to make this presentation. > > > > Best Regards, > > Peng JIANG > > KDDI > > > > > > > Dear Jiang-san, > > > > > > On Oct 15, 2012, at 4:20 AM, Peng JIANG wrote: > > > > > > > Dear JP, > > > > > > > > I am one of the co-authors of draft-kumaki-murai-pce-pcep- > > > > extension-l3vpn. This draft defines the PCEP extensions for the > > > > dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites. > > > > > > > > We have been waiting for the signaling protocol(draft-kumaki- > > > > murai-l3vpn-rsvp-te) to be standarized. Now, the IESG Last Call > > > > has finished and we are now waiting for the Go-Ahead sign of the > > > > sponsor AD. > > > > > > > > Since the signaling protocol standardization is almost finished > > > > now, we are considering progressing the PCEP extension draft to > > > > a WG item. > > > > > > > > It has been a while since we last present the WG. Do you think > > > > it is proper that we remind the WG on the list about the > > > > contents of the PCEP extension together with the progress of the > > > > signaling protocol and then ask for WG last call? I think we > > > > have agreed to progress the PCEP extension once the signaling > > > > protocol standardization is finished. > > > > > > > > > > JP> Yes I believe that it is now time to get back to the PCE WG for a last > > > presentation. > > > > > > Thanks! > > > > > > JP. > > > > > > > Best Regards, > > > > Peng JIANG > > > > KDDI > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@ietf.org > > > https://www.ietf.org/mailman/listinfo/pce > > > > > > From jvasseur@cisco.com Tue Jul 2 01:01:42 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163B711E841F for ; Tue, 2 Jul 2013 01:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6h+swLBWPeS for ; Tue, 2 Jul 2013 01:01:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 13E3D11E841C for ; Tue, 2 Jul 2013 01:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13366; q=dns/txt; s=iport; t=1372752093; x=1373961693; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z+TNikASIdwg8GMpeEIY5o3Q4DMk5d5zVUCqIE4HLjo=; b=U3UAhQGM922+0nMnpfwSsbv2uYqzbzPNg5EPZtAZcvibQUAnDUPEHlq9 /F9uDjXOsXquYSa6pDy8KyQZrzuaHPMMRQlRgcpc7xbQ+ft8AxOrueKmE /xx8J9hG87uZyNIJh8LSIOE0llEN7gZWchzZab+lRrF4IrVghDJJwS40K U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFALaG0lGtJXG8/2dsb2JhbABagkVEe79OfBZ0giMBAQEEZRQQAgEIEQQBAQsdBzIUCQgCBA4FCBOHdLtYjy0xBgGDBGMDqQ2DEYIo X-IronPort-AV: E=Sophos;i="4.87,979,1363132800"; d="scan'208,217";a="229878337" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jul 2013 08:01:32 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6281W5t026617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 08:01:32 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 03:01:32 -0500 From: "JP Vasseur (jvasseur)" To: Leeyoung Thread-Topic: Stateful PCE applicability Thread-Index: AQHOdvpcaZ/dSlZcRk6ZMyD+9IoShw== Date: Tue, 2 Jul 2013 08:01:31 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77235F669A@xmb-rcd-x02.cisco.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A77235C3D6B@xmb-rcd-x02.cisco.com> <7AEB3D6833318045B4AE71C2C87E8E1729157DA6@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729157DA6@dfweml511-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.226] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77235F669Axmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] Stateful PCE applicability X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 08:01:42 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77235F669Axmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We just need to be careful not to make well balanced showing the pros and c= ons since this cannot be seen as the magic solution to all problems. On Jun 26, 2013, at 7:17 PM, Leeyoung wrote: Hi, I support the idea of the need for Stateful PCE applicability. As stated in= the latest draft, this document is pivotal in providing an overarching sta= teful PCE applicability to various scenarios. This draft should have preced= ed any other stateful PCE related drafts, but it is not too late to include= this work in PCE WG. Regards, Young From: pce-bounces@ietf.org [mailto:pce-bounces= @ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: Saturday, June 22, 2013 3:20 AM To: Ina Minei; pce@ietf.org Subject: Re: [Pce] Stateful PCE applicability Thanks Ina - good question : WG, please voice your opinion Thanks JP. On Jun 21, 2013, at 9:16 AM, Ina Minei wrote: Dear chairs and working group, In light of the recent working group re-charter which now includes stateful= PCE, we wanted to hear the opinions of the group on 1. the need for an applicability document for stateful PCE and 2. whether draft-zhang-pce-stateful-pce-app satisfies this need, or a= ny gaps it might have Thank you, Ina and Xian --_000_03B78081B371D44390ED6E7BADBB4A77235F669Axmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <4BB89592A58031429679C0CC61CD23A4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable We just need to be careful not to make well balanced showing the pros and c= ons since this cannot be seen as the magic solution to all problems.

On Jun 26, 2013, at 7:17 PM, Leeyoung wrote:

Hi,
 
I support the idea of the need for Stateful PCE applicabi= lity. As stated in the latest draft, this document is pivotal in providing = an overarching stateful PCE applicability to various scenarios. This draft should have preceded any other stateful P= CE related drafts, but it is not too late to include this work in PCE WG.
 
Regards,
Young
 
 
 
From:=  pce-= bounces@ietf.org [mai= lto:pce-bounces@ietf.org] On Behalf Of JP Vasseur= (jvasseur)
Sent: Saturday, Ju= ne 22, 2013 3:20 AM
To: Ina Minei; pce@ietf.org Subject: Re: [Pce]= Stateful PCE applicability
 
Thanks Ina - good question : WG, please voice your opinion =
 
Thanks JP.
 
On Jun 21, 2013, at 9:16 AM, Ina Minei wrote:


Dear ch= airs and working group,
 <= o:p>
In ligh= t of the recent working group re-charter which now includes stateful PCE, w= e wanted to hear the opinions of the group on
 <= o:p>
1= .=       &= nbsp;the need for an applicability document for stateful PCE and<= /div>
 <= o:p>
2= .=       &= nbsp;whether draft-zhang-pce-stateful-pce-app satisfies this need, or any gaps it might= have
 <= o:p>
Thank y= ou,
 <= o:p>
Ina and= Xian
 <= o:p>
 

--_000_03B78081B371D44390ED6E7BADBB4A77235F669Axmbrcdx02ciscoc_-- From julien.meuric@orange.com Tue Jul 2 01:22:45 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8111E842B for ; Tue, 2 Jul 2013 01:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0aqqcHYLuqC for ; Tue, 2 Jul 2013 01:22:37 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 27C0511E841F for ; Tue, 2 Jul 2013 01:22:21 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CCA8F5D8C3F for ; Tue, 2 Jul 2013 10:22:09 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.orange.com (Postfix) with ESMTP id C33305D83E3 for ; Tue, 2 Jul 2013 10:22:09 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Jul 2013 10:22:09 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Jul 2013 10:22:09 +0200 Message-ID: <51D28DB0.2080305@orange.com> Date: Tue, 02 Jul 2013 10:22:08 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "pce@ietf.org" References: <20130701234030.24738.41427.idtracker@ietfa.amsl.com> In-Reply-To: <20130701234030.24738.41427.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130701234030.24738.41427.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2013 08:22:09.0554 (UTC) FILETIME=[3EF79720:01CE76FD] Subject: [Pce] Fwd: NOMCOM 2013-14 Volunteering - 3rd and Final Call for Volunteers X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 08:22:46 -0000 Hi all. Have you considered volunteering? Julien -------- Original message -------- From: NomCom Chair 2013 Hi, everyone, We are short of our goal of 200 volunteers for the upcoming nomcom. Please do volunteer. Our publicly verifiable random algorithm has fully adequate entropy for a flood of volunteers - more names, more names, more names, more brains --- er, oops, not yet a zombie. The more volunteers we get, the better chance we have of choosing a random yet representative cross section of the IETF. Respond to this challenge and strengthen our statistical significance just by hitting Reply (but not Reply-All, please). Oh, first, please do check the official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The details of the selection and operation of the nomcom can be found in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, reply to this email and volunteer. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. Being a nomcom member will require some time commitment - there will be interviews with candidates at meetings, regularly scheduled conference calls to ensure progress, collection and review of requirements from the commitment, review of candidate questionnaires and of community feedback. A more detailed timetable for the nomcom tasks will appear soon. Please respond to this email before 23:59 EDT (UTC -4 hours) July 04, 2013. In the body include: 1. your Given Name as you enter it when you register for the IETF 2. your Family Name as you enter it when you register for the IETF 3. your current primary affilation (the information you enter into the Company field) 4. any/all email addresses you've used to register for IETF meetings 5. which email address you prefer 6. your phone number (for our use in confirming you if selected). On July 05, 2013 there will be an announcement of validated volunteers. If you haven't received an acknowledgement message from me to your email (indicating that you are or are not eligible) and you do not see your name in the July 05 list, contact me AS SOON AS POSSIBLE, on or before July 06. Looking forward to adding your name to the "hat" very soon, Allison Allison Mankin Nomcom Chair 2013-2014 From ramon.casellas@cttc.es Tue Jul 2 01:23:05 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9573B11E842E for ; Tue, 2 Jul 2013 01:23:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHO0uajJPo9C for ; Tue, 2 Jul 2013 01:23:04 -0700 (PDT) Received: from rudy.puc.rediris.es (rudy.puc.rediris.es [IPv6:2001:720:418:ca01::132]) by ietfa.amsl.com (Postfix) with ESMTP id ACB9B11E841F for ; Tue, 2 Jul 2013 01:23:03 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by rudy.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Utvra-0000hJ-42 for pce@ietf.org; Tue, 02 Jul 2013 10:23:02 +0200 Received: from [192.168.1.123] (62.83.140.15.dyn.user.ono.com [62.83.140.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id F39F51FC62 for ; Tue, 2 Jul 2013 10:22:58 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <51D28DE4.3020407@cttc.es> Date: Tue, 02 Jul 2013 10:23:00 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: pce@ietf.org References: <02b901ce7323$d534f3f0$7f9edbd0$@olddog.co.uk> <51CD2FC6.4030501@cttc.es> <51CDB504.5050105@orange.com> In-Reply-To: <51CDB504.5050105@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spamina-Bogosity: Ham Subject: Re: [Pce] Some thoughts on using RBNF and "completeness" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 08:23:05 -0000 El 28/06/2013 18:08, Julien Meuric escribió: > Hi Ramon. > > Your point is legitimate and is certainly shared by several > implementers. I personally like the way you try to disambiguate syntax > below. I tend to interpret this like volunteering for putting that > into an I-D: it would be helpful to efficiently share with the WG and > decide about the interest of the approach (it would not have to tackle > all PCEP extensions in an early revision)... Julien, all Heh :) ok, I will try to get some contributors and prepare a first draft... Thanks R. From jvasseur@cisco.com Tue Jul 2 04:14:57 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF2711E848E for ; Tue, 2 Jul 2013 04:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S14+B+V01nxy for ; Tue, 2 Jul 2013 04:14:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ADF0C11E847C for ; Tue, 2 Jul 2013 04:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4363; q=dns/txt; s=iport; t=1372763692; x=1373973292; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PySHn0USFLEOGZUTmDLr4Nvmx583U9WC8ADajzDnT+M=; b=IQ5ZmQN2niZYCY8kFqD1npXlbdEZCckoiwUy34jxD0Eqr3JW/Stsg+uO c8jnLN1IAXJwweN5IFJj1ouyhC02l5EhrzTbiqPleNdgmClnhFNXLmRw+ UV97zCLK7I4V428WUu7sM4o/9m59VfiURu9il6PlUCoQ/6KMgE139//rE M=; X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208";a="229847948" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 02 Jul 2013 11:14:52 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r62BEqlH005296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 11:14:52 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 06:14:51 -0500 From: "JP Vasseur (jvasseur)" To: "pce@ietf.org" , Peng JIANG Thread-Topic: [Pce] About draft-kumaki-murai-pce-pcep-extension-l3vpn Thread-Index: AQHNqpwrLLJVcRZD/0mGX2pPgTECZw== Date: Tue, 2 Jul 2013 11:14:50 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77235F83C8@xmb-rcd-x02.cisco.com> References: <201210151120.AHI81244.QFtBOHJK@kddi.com> <03B78081B371D44390ED6E7BADBB4A7721FE06A3@xmb-rcd-x02.cisco.com> <201210151638.AGF34889.JOKQtBHF@kddi.com> <201305101017.BED02471.OBtKHFQJ@kddi.com> <201307021053.FFH12467.OBJtHQFK@kddi.com> In-Reply-To: <201307021053.FFH12467.OBJtHQFK@kddi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.226] Content-Type: text/plain; charset="us-ascii" Content-ID: <58AB90DAAC311141B73522F291D52496@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: JP Jp office Subject: Re: [Pce] About draft-kumaki-murai-pce-pcep-extension-l3vpn X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 11:14:57 -0000 Thanks, I would really suggest the WG to voice an opinion on this ID so as = to decide about the next steps. On Jul 2, 2013, at 3:53 AM, Peng JIANG wrote: > Dear JP, Julien and PCEers, >=20 > The following email was sent a few days ago.=20 >=20 >> Please let me remind you that we have a new version for the PCEP >> extension draft. >> http://tools.ietf.org/html/draft-kumaki-murai-pce-pcep-extension >> -l3vpn-11 >>=20 >> We received a few comments during the presentation at the=20 >> Atlanta meeting. One of the comments is that the Intended Status >> should be the same as that of the signaling protocol. >>=20 >> In this new version, the Intended Status has been changed to=20 >> Experimental together with various expression change that comply >> with the new Intended Status. >>=20 >> FYI, The RSVP signaling protocol that we proposed is now RFC6882. >> http://tools.ietf.org/html/rfc6882 >>=20 >> We also add a reference to this new RFC. >>=20 >> Please let us konw if you have new comments. >> And we would like to ask for WG adoption if you all feel OK=20 >> about this draft. >=20 > Please let us know your opinion about this new version. > Your comment is highly appreciated. Thanks! >=20 > Best Regards, > Peng JIANG > KDDI >=20 >> Dear JP and PCEers, >>=20 >> Please let me remind you that we have a new version for the PCEP >> extension draft. >> http://tools.ietf.org/html/draft-kumaki-murai-pce-pcep-extension >> -l3vpn-11 >>=20 >> We received a few comments during the presentation at the=20 >> Atlanta meeting. One of the comments is that the Intended Status >> should be the same as that of the signaling protocol. >>=20 >> In this new version, the Intended Status has been changed to=20 >> Experimental together with various expression change that comply >> with the new Intended Status. >>=20 >> FYI, The RSVP signaling protocol that we proposed is now RFC6882. >> http://tools.ietf.org/html/rfc6882 >>=20 >> We also add a reference to this new RFC. >>=20 >> Please let us konw if you have new comments. >> And we would like to ask for WG adoption if you all feel OK=20 >> about this draft. >>=20 >> Best Regards, >> Peng JIANG >> KDDI >>=20 >>> Dear JP, >>> Cc: KDDI Miyasaka-san >>>=20 >>> Thank you very much for your quick reply. >>>=20 >>>> JP> Yes I believe that it is now time to get back to the PCE WG for a= =20 > last >>=20 >>> presentation. >>>=20 >>> Thank you very much for your suggestion. >>> We would like to request a presentation slot for 5 or 10 minutes. >>> Could you please assign one to us? >>> My colleague Miyasaka-san will attend IETF85 and he is willing=20 >>> to make this presentation. >>>=20 >>> Best Regards, >>> Peng JIANG >>> KDDI >>>=20 >>>=20 >>>> Dear Jiang-san, >>>>=20 >>>> On Oct 15, 2012, at 4:20 AM, Peng JIANG wrote: >>>>=20 >>>>> Dear JP, >>>>>=20 >>>>> I am one of the co-authors of draft-kumaki-murai-pce-pcep- >>>>> extension-l3vpn. This draft defines the PCEP extensions for the=20 >>>>> dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites. >>>>>=20 >>>>> We have been waiting for the signaling protocol(draft-kumaki- >>>>> murai-l3vpn-rsvp-te) to be standarized. Now, the IESG Last Call=20 >>>>> has finished and we are now waiting for the Go-Ahead sign of the >>>>> sponsor AD. >>>>>=20 >>>>> Since the signaling protocol standardization is almost finished=20 >>>>> now, we are considering progressing the PCEP extension draft to=20 >>>>> a WG item. >>>>>=20 >>>>> It has been a while since we last present the WG. Do you think=20 >>>>> it is proper that we remind the WG on the list about the=20 >>>>> contents of the PCEP extension together with the progress of the >>>>> signaling protocol and then ask for WG last call? I think we=20 >>>>> have agreed to progress the PCEP extension once the signaling=20 >>>>> protocol standardization is finished. >>>>>=20 >>>>=20 >>>> JP> Yes I believe that it is now time to get back to the PCE WG for a= =20 > last >>=20 >>> presentation. >>>>=20 >>>> Thanks! >>>>=20 >>>> JP. >>>>=20 >>>>> Best Regards, >>>>> Peng JIANG >>>>> KDDI >>>>=20 >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pce >>>>=20 >>>=20 >>=20 From dhruv.ietf@gmail.com Tue Jul 2 09:40:17 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C1E21F9F12 for ; Tue, 2 Jul 2013 09:40:17 -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.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTNMIMmF3MW0 for ; Tue, 2 Jul 2013 09:40:16 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3ED21F9F0D for ; Tue, 2 Jul 2013 09:40:16 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so13080258ied.28 for ; Tue, 02 Jul 2013 09:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=znNhOARrjW4L7RF0d7ZbXGHmOg0WUveQFkfzQsCUeZc=; b=coS7QmoVvLy61M3Mx5CyIV9H5/fWC9nfT5Cd2XGxeNqOP72kz3y4FwZ5mJ6EzMTqpq xojxUO+oJCYenmxJR7Fi+JEPSWZbZRgO5gJ+7lQpyAdWolArYRQY6PF+jhW6+WscvktX p2PqAWozZy0/zceAT+TsBxM8gkrL4k4iHu4n1i77r4awHBES7UL9qOZ7rz8h+7o0rrEi mOie7WGYhWDtdpTpje9dxeqQHyPUq/oV6BZ4xKPUyf+r5dAXGGXWOxoZJ/ZznfznkdS4 TEDi2sVG9joJRAfl2Vy9VOoWorlcp8o+P9yGu/mMvdk5h2bHDSEzF0Qc3+FeApcovDOq r2Vg== MIME-Version: 1.0 X-Received: by 10.50.118.74 with SMTP id kk10mr22036860igb.2.1372783215737; Tue, 02 Jul 2013 09:40:15 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.152.176 with HTTP; Tue, 2 Jul 2013 09:40:15 -0700 (PDT) Date: Tue, 2 Jul 2013 22:10:15 +0530 X-Google-Sender-Auth: 6dY1KB91YUdZPsxX0zwNH5E2gAU Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=089e011821eaed84b504e089ff02 Cc: draft-george-mpls-ipv6-only-gap@tools.ietf.org Subject: [Pce] Fwd: IPv6-only MPLS gap analysis X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:40:17 -0000 --089e011821eaed84b504e089ff02 Content-Type: text/plain; charset=ISO-8859-1 Adding PCE WG, this may interest some of you... Apologies, if you received multiple copies :) Regards, Dhruv ---------- Forwarded message ---------- From: George, Wes Date: Mon, Jul 1, 2013 at 7:12 PM Subject: IPv6-only MPLS gap analysis To: "mpls@ietf.org" Cc: "l2vpn@ietf.org" , "draft-ietf-l2vpn-evpn@tools.ietf.org" , "l3vpn@ietf.org" , " draft-mpls-ipv6-only-gap@tools.ietf.org" < draft-mpls-ipv6-only-gap@tools.ietf.org> As discussed in Orlando in the MPLS WG, we have begun work on a Gap Analysis for MPLS operation on an IPv6-only network. I am copying the L2VPN and L3VPN WGs, as the authors would certainly value their review and input, and we also wanted to make those WGs aware of the need to begin considering IPv6-only operation in any new standards work that they might undertake, e.g. EVPN. This may take the form of referring to existing gaps from this document that must be addressed before the dependency is resolved, or it may take the form of changes to the draft to explicitly allow IPv6-only operation, but we limited our scope to existing RFCs in order to keep what is already a fairly large undertaking manageable. This is still very much a work in progress. We're especially interested in feedback on the structure of the document (do the categories make sense) and whether we are missing major items to include in the gap analysis, across control plane, applications, or OAM. Thanks, Wes George, on behalf of the other authors -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, July 01, 2013 9:23 AM To: Ron Bonica; Rajiv Papneja; Dhruv Dhody; George, Wes; Carlos Pignataro; Kamran Raza; Ronald Bonica; Vishwas Manral; Rajiv Asati Subject: New Version Notification for draft-mpls-ipv6-only-gap-00.txt A new version of I-D, draft-mpls-ipv6-only-gap-00.txt has been successfully submitted by Wesley George and posted to the IETF repository. Filename: draft-mpls-ipv6-only-gap Revision: 00 Title: Gap Analysis for Operating IPv6-only MPLS Networks Creation date: 2013-07-01 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-mpls-ipv6-only-gap-00.txt Status: http://datatracker.ietf.org/doc/draft-mpls-ipv6-only-gap Htmlized: http://tools.ietf.org/html/draft-mpls-ipv6-only-gap-00 Abstract: This document reviews the MPLS protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS- related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. The IETF Secretariat This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. --089e011821eaed84b504e089ff02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adding PCE WG, this may interest some of you...

Apologies, if you received multiple copies :)=A0

Regards,
Dhruv=A0

---------- = Forwarded message ----------
From: George, Wes <<= a href=3D"mailto:wesley.george@twcable.com">wesley.george@twcable.com&g= t;
Date: Mon, Jul 1, 2013 at 7:12 PM
Subject: IPv6-only MPLS g= ap analysis
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, "draft-ietf-l2vpn-evpn@tools.ietf.org" <draft-ietf-l2vpn-evpn= @tools.ietf.org>, "l3vpn@ietf= .org" <l3vpn@ietf.org>= , "draft-mp= ls-ipv6-only-gap@tools.ietf.org" <draft-mpls-ipv6-only-gap@tools.ietf.org&g= t;


As discussed in Orlando in the MPLS WG, we have begun work on a Gap= Analysis for MPLS operation on an IPv6-only network. I am copying the L2VP= N and L3VPN WGs, as the authors would certainly value their review and inpu= t, and we also wanted to make those WGs aware of the need to begin consider= ing IPv6-only operation in any new standards work that they might undertake= , e.g. EVPN. This may take the form of referring to existing gaps from this= document that must be addressed before the dependency is resolved, or it m= ay take the form of changes to the draft to explicitly allow IPv6-only oper= ation, but we limited our scope to existing RFCs in order to keep what is a= lready a fairly large undertaking manageable.

This is still very much a work in progress. We're especially interested= in feedback on the structure of the document (do the categories make sense= ) and whether we are missing major items to include in the gap analysis, ac= ross control plane, applications, or OAM.

Thanks,

Wes George, on behalf of the other authors

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Monday, July 01, 2013 9:23 AM
To: Ron Bonica; Rajiv Papneja; Dhruv Dhody; George, Wes; Carlos Pignataro; = Kamran Raza; Ronald Bonica; Vishwas Manral; Rajiv Asati
Subject: New Version Notification for draft-mpls-ipv6-only-gap-00.txt


A new version of I-D, draft-mpls-ipv6-only-gap-00.txt
has been successfully submitted by Wesley George and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mpls-ipv6-only-gap
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Gap Analysis for Operating IPv6-only MPLS Networ= ks
Creation date: =A0 2013-07-01
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 20
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/int= ernet-drafts/draft-mpls-ipv6-only-gap-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draf= t-mpls-ipv6-only-gap
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-mpls-ip= v6-only-gap-00


Abstract:
=A0 =A0This document reviews the MPLS protocol suite in the context of IPv6=
=A0 =A0and identifies gaps that must be addressed in order to allow MPLS- =A0 =A0related protocols and applications to be used with IPv6-only
=A0 =A0networks. =A0This document is not intended to highlight a particular=
=A0 =A0vendor's implementation (or lack thereof) in the context of IPv6= -only
=A0 =A0MPLS functionality, but rather to focus on gaps in the standards
=A0 =A0defining the MPLS suite.




The IETF Secretariat


This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.

--089e011821eaed84b504e089ff02-- From dhruv.ietf@gmail.com Tue Jul 2 09:42:38 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324A721F9F0D for ; Tue, 2 Jul 2013 09:42:38 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSwISV9MYyRc for ; Tue, 2 Jul 2013 09:42:37 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1056021F9EDB for ; Tue, 2 Jul 2013 09:42:36 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so13095407iea.3 for ; Tue, 02 Jul 2013 09:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=pcUOWgK8XcocumZtlXEIqswLVCBDVoG9+VQICcQ6pGw=; b=YVYnAl4VNV/8+5VThjTBCH4wwqK+OCL2cI+QkkkiEMziVsyUbOJnd/UyiK9gIzw7HQ 5XkwnJp3rNbU0wzWhrSQYujX6kxKhwAaAJ7pcKDxwXs5N3oFjaQMZdPpmd0B391EXg6p n3kpv2gxR38LCKKOYQBdon10C4N2Odvlg3IhqTyuz/gb2HLpaD362tQt5FxULZKXQ/Wb 1+8m/xRK2hbHkj/PTbZNxM/WA7JqyVWT5B6Ez0yv0lQq4dBsj7/PfY2rGSJIQV2iJ+u8 X/0RkKVwhinAuG7t5jkspCtSukVep2yJn4vjurmoARdUdxUXk8firm9HEr0W9PZqtZgk Dj8Q== MIME-Version: 1.0 X-Received: by 10.50.41.34 with SMTP id c2mr21217036igl.57.1372783355592; Tue, 02 Jul 2013 09:42:35 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.152.176 with HTTP; Tue, 2 Jul 2013 09:42:35 -0700 (PDT) Date: Tue, 2 Jul 2013 22:12:35 +0530 X-Google-Sender-Auth: R0w6YNIJ7pWXRhP3YTIq5b_OKmY Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=089e01183b60438a2f04e08a08f4 Subject: [Pce] Fwd: IPv6-only MPLS gap analysis X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:42:38 -0000 --089e01183b60438a2f04e08a08f4 Content-Type: text/plain; charset=ISO-8859-1 The updated Link: http://datatracker.ietf.org/doc/draft-george-mpls-ipv6-only-gap/?include_text=1 Dhruv ---------- Forwarded message ---------- From: Dhruv Dhody Date: Tue, Jul 2, 2013 at 10:10 PM Subject: Fwd: IPv6-only MPLS gap analysis To: "pce@ietf.org" Cc: draft-george-mpls-ipv6-only-gap@tools.ietf.org Adding PCE WG, this may interest some of you... Apologies, if you received multiple copies :) Regards, Dhruv ---------- Forwarded message ---------- From: George, Wes Date: Mon, Jul 1, 2013 at 7:12 PM Subject: IPv6-only MPLS gap analysis To: "mpls@ietf.org" Cc: "l2vpn@ietf.org" , "draft-ietf-l2vpn-evpn@tools.ietf.org" , "l3vpn@ietf.org" , " draft-mpls-ipv6-only-gap@tools.ietf.org" < draft-mpls-ipv6-only-gap@tools.ietf.org> As discussed in Orlando in the MPLS WG, we have begun work on a Gap Analysis for MPLS operation on an IPv6-only network. I am copying the L2VPN and L3VPN WGs, as the authors would certainly value their review and input, and we also wanted to make those WGs aware of the need to begin considering IPv6-only operation in any new standards work that they might undertake, e.g. EVPN. This may take the form of referring to existing gaps from this document that must be addressed before the dependency is resolved, or it may take the form of changes to the draft to explicitly allow IPv6-only operation, but we limited our scope to existing RFCs in order to keep what is already a fairly large undertaking manageable. This is still very much a work in progress. We're especially interested in feedback on the structure of the document (do the categories make sense) and whether we are missing major items to include in the gap analysis, across control plane, applications, or OAM. Thanks, Wes George, on behalf of the other authors -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, July 01, 2013 9:23 AM To: Ron Bonica; Rajiv Papneja; Dhruv Dhody; George, Wes; Carlos Pignataro; Kamran Raza; Ronald Bonica; Vishwas Manral; Rajiv Asati Subject: New Version Notification for draft-mpls-ipv6-only-gap-00.txt A new version of I-D, draft-mpls-ipv6-only-gap-00.txt has been successfully submitted by Wesley George and posted to the IETF repository. Filename: draft-mpls-ipv6-only-gap Revision: 00 Title: Gap Analysis for Operating IPv6-only MPLS Networks Creation date: 2013-07-01 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-mpls-ipv6-only-gap-00.txt Status: http://datatracker.ietf.org/doc/draft-mpls-ipv6-only-gap Htmlized: http://tools.ietf.org/html/draft-mpls-ipv6-only-gap-00 Abstract: This document reviews the MPLS protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS- related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. The IETF Secretariat This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. --089e01183b60438a2f04e08a08f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The updated Link:=A0http://datatracker.= ietf.org/doc/draft-george-mpls-ipv6-only-gap/?include_text=3D1

=
Dhruv

---------- Forwarded message ------= ----
From: Dhruv Dhody <dhruv.ietf@gmail.com>=
Date: Tue, Jul 2, 2013 at 10:10 PM
Subject: Fwd: IPv6-only MPLS gap anal= ysis
To: "pce@ietf.org" &l= t;pce@ietf.org>
Cc: draft-george-mpls-ipv6= -only-gap@tools.ietf.org


Adding PCE WG, this may interest some of you...
Apologies, if you received multiple copies :)=A0

<= /div>
Regards,
Dhruv=A0


---------- Forwarded message ----------
From: George, Wes <<= a href=3D"mailto:wesley.george@twcable.com" target=3D"_blank">wesley.george= @twcable.com>
Date: Mon, Jul 1, 2013 at 7:12 PM
Subject= : IPv6-only MPLS gap analysis
To: "mpls@ietf.org<= /a>" <mpls@ietf.= org>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, "draft-ietf-l2vpn-evpn@tools.ietf.org" <draft-ietf-l2vpn-evpn@tools.ietf.org>, "l3vpn@ietf.org" <l3vpn@ietf.org>, &quo= t;draft-mpls-ipv6-only-gap@tools.ietf.org" <draft-mpls-ipv6= -only-gap@tools.ietf.org>


As discussed in Orlando in the MPLS WG, we have begun work on a Gap= Analysis for MPLS operation on an IPv6-only network. I am copying the L2VP= N and L3VPN WGs, as the authors would certainly value their review and inpu= t, and we also wanted to make those WGs aware of the need to begin consider= ing IPv6-only operation in any new standards work that they might undertake= , e.g. EVPN. This may take the form of referring to existing gaps from this= document that must be addressed before the dependency is resolved, or it m= ay take the form of changes to the draft to explicitly allow IPv6-only oper= ation, but we limited our scope to existing RFCs in order to keep what is a= lready a fairly large undertaking manageable.

This is still very much a work in progress. We're especially interested= in feedback on the structure of the document (do the categories make sense= ) and whether we are missing major items to include in the gap analysis, ac= ross control plane, applications, or OAM.

Thanks,

Wes George, on behalf of the other authors

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 01, 2013 9:23 AM
To: Ron Bonica; Rajiv Papneja; Dhruv Dhody; George, Wes; Carlos Pignataro; = Kamran Raza; Ronald Bonica; Vishwas Manral; Rajiv Asati
Subject: New Version Notification for draft-mpls-ipv6-only-gap-00.txt


A new version of I-D, draft-mpls-ipv6-only-gap-00.txt
has been successfully submitted by Wesley George and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mpls-ipv6-only-gap
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Gap Analysis for Operating IPv6-only MPLS Networ= ks
Creation date: =A0 2013-07-01
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 20
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/int= ernet-drafts/draft-mpls-ipv6-only-gap-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draf= t-mpls-ipv6-only-gap
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-mpls-ip= v6-only-gap-00


Abstract:
=A0 =A0This document reviews the MPLS protocol suite in the context of IPv6=
=A0 =A0and identifies gaps that must be addressed in order to allow MPLS- =A0 =A0related protocols and applications to be used with IPv6-only
=A0 =A0networks. =A0This document is not intended to highlight a particular=
=A0 =A0vendor's implementation (or lack thereof) in the context of IPv6= -only
=A0 =A0MPLS functionality, but rather to focus on gaps in the standards
=A0 =A0defining the MPLS suite.




The IETF Secretariat


This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.


--089e01183b60438a2f04e08a08f4-- From ina@juniper.net Tue Jul 2 11:05:45 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072F321F9BBC for ; Tue, 2 Jul 2013 11:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO+51cO-b2c0 for ; Tue, 2 Jul 2013 11:05:38 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9C93F21F9BFC for ; Tue, 2 Jul 2013 11:05:37 -0700 (PDT) Received: from mail44-db8-R.bigfish.com (10.174.8.226) by DB8EHSOBE022.bigfish.com (10.174.4.85) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 18:05:36 +0000 Received: from mail44-db8 (localhost [127.0.0.1]) by mail44-db8-R.bigfish.com (Postfix) with ESMTP id 987BA28012B for ; Tue, 2 Jul 2013 18:05:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371Ic85fhzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail44-db8: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=ina@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail44-db8 (localhost.localdomain [127.0.0.1]) by mail44-db8 (MessageSwitch) id 1372788334612399_15511; Tue, 2 Jul 2013 18:05:34 +0000 (UTC) Received: from DB8EHSMHS003.bigfish.com (unknown [10.174.8.225]) by mail44-db8.bigfish.com (Postfix) with ESMTP id 8CE7A9A004B for ; Tue, 2 Jul 2013 18:05:34 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.52) by DB8EHSMHS003.bigfish.com (10.174.4.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 2 Jul 2013 18:05:32 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Jul 2013 11:05:29 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 2 Jul 2013 11:05:29 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 2 Jul 2013 11:09:30 -0700 Received: from mail130-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 18:05:28 +0000 Received: from mail130-tx2 (localhost [127.0.0.1]) by mail130-tx2-R.bigfish.com (Postfix) with ESMTP id 6A3D64E0B16 for ; Tue, 2 Jul 2013 18:05:28 +0000 (UTC) Received: from mail130-tx2 (localhost.localdomain [127.0.0.1]) by mail130-tx2 (MessageSwitch) id 1372788325957202_19367; Tue, 2 Jul 2013 18:05:25 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.254]) by mail130-tx2.bigfish.com (Postfix) with ESMTP id DAF55140059; Tue, 2 Jul 2013 18:05:25 +0000 (UTC) Received: from BLUPRD0511HT004.namprd05.prod.outlook.com (157.56.232.213) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Jul 2013 18:05:25 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.186]) by BLUPRD0511HT004.namprd05.prod.outlook.com ([10.255.135.167]) with mapi id 14.16.0324.000; Tue, 2 Jul 2013 18:05:24 +0000 From: Ina Minei To: "JP Vasseur (jvasseur)" , Leeyoung Thread-Topic: Stateful PCE applicability Thread-Index: Ac5umsBOKlGLSPblRyS/lSkmK90b9QAhoLCAANvujIABGlffgAAU4K4g Date: Tue, 2 Jul 2013 18:05:24 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3037FADD7@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A77235C3D6B@xmb-rcd-x02.cisco.com> <7AEB3D6833318045B4AE71C2C87E8E1729157DA6@dfweml511-mbs.china.huawei.com> <03B78081B371D44390ED6E7BADBB4A77235F669A@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77235F669A@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] Content-Type: multipart/alternative; boundary="_000_70BDAD02381BA54CA31315A2A26A7AD3037FADD7BLUPRD0511MB436_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "pce@ietf.org" Subject: Re: [Pce] Stateful PCE applicability X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:05:45 -0000 --_000_70BDAD02381BA54CA31315A2A26A7AD3037FADD7BLUPRD0511MB436_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JP, Absolutely agree to this point, neither stateful PCE nor any other technolo= gy is a silver bullet :) There are scenarios where it fits better and othe= rs where existing solutions are just as good. Following your guidance at th= e previous IETF, the authors revised the draft while paying attention to th= is point, and we tried to show a balanced view of different use cases, incl= uding pros and cons. We welcome review and specific suggestions on how to further improve the do= cument, Ina From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com] Sent: Tuesday, July 02, 2013 1:02 AM To: Leeyoung Cc: Ina Minei; pce@ietf.org Subject: Re: Stateful PCE applicability We just need to be careful not to make well balanced showing the pros and c= ons since this cannot be seen as the magic solution to all problems. On Jun 26, 2013, at 7:17 PM, Leeyoung wrote: Hi, I support the idea of the need for Stateful PCE applicability. As stated in= the latest draft, this document is pivotal in providing an overarching sta= teful PCE applicability to various scenarios. This draft should have preced= ed any other stateful PCE related drafts, but it is not too late to include= this work in PCE WG. Regards, Young From: pce-bounces@ietf.org [mailto:pce-bounces= @ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: Saturday, June 22, 2013 3:20 AM To: Ina Minei; pce@ietf.org Subject: Re: [Pce] Stateful PCE applicability Thanks Ina - good question : WG, please voice your opinion Thanks JP. On Jun 21, 2013, at 9:16 AM, Ina Minei wrote: Dear chairs and working group, In light of the recent working group re-charter which now includes stateful= PCE, we wanted to hear the opinions of the group on 1. the need for an applicability document for stateful PCE and 2. whether draft-zhang-pce-stateful-pce-app satisfies this need, or a= ny gaps it might have Thank you, Ina and Xian --_000_70BDAD02381BA54CA31315A2A26A7AD3037FADD7BLUPRD0511MB436_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JP,

 <= /p>

Absolutely agree to this = point, neither stateful PCE nor any other technology is  a silver bull= et J There are scenarios where it fits bett= er and others where existing solutions are just as good. Following your guidance at the previous IETF, the authors revised the draf= t while paying attention to this point, and we tried to show a balanced vie= w of different use cases, including pros and cons.

 <= /p>

We welcome review and spe= cific suggestions on how to further improve the document,

 <= /p>

Ina

 <= /p>

From: JP Vasse= ur (jvasseur) [mailto:jvasseur@cisco.com]
Sent: Tuesday, July 02, 2013 1:02 AM
To: Leeyoung
Cc: Ina Minei; pce@ietf.org
Subject: Re: Stateful PCE applicability

 

We just need to be careful not to make well balanced= showing the pros and cons since this cannot be seen as the magic solution = to all problems.

 

On Jun 26, 2013, at 7:17 PM, Leeyoung wrote:



Hi,

 <= /p>

I support the idea of the= need for Stateful PCE applicability. As stated in the latest draft, this d= ocument is pivotal in providing an overarching stateful PCE applicability to various scenarios. This draft should have preceded an= y other stateful PCE related drafts, but it is not too late to include this= work in PCE WG.

 <= /p>

Regards,

Young

 <= /p>

 <= /p>

 <= /p>

From: pce-bounces@ietf.org [mailto:p= ce-bounces@ietf.org] = On Behalf Of JP Vasseur= (jvasseur)
Sent: Saturday, Ju= ne 22, 2013 3:20 AM
To: Ina Minei; pce@ietf.org
Subject: Re: [Pce]= Stateful PCE applicability

 

Thanks Ina - good question : WG, please voice your o= pinion 

 

Thanks JP.

 

On Jun 21, 2013, at 9:16 AM, Ina Minei wrote:




Dear chairs and working group,

 

In light of the recent working group re= -charter which now includes stateful PCE, we wanted to hear the opinions of= the group on

 

1.<= span style=3D"font-size:7.0pt">       the need for an applicability document for stateful PCE and<= /p>

 

2.<= span style=3D"font-size:7.0pt">       whether draft-zhang-pce-stateful-pce-app satisfies this need, or any gaps it might= have

 

Thank you,

 

Ina and Xian

 

 

 

--_000_70BDAD02381BA54CA31315A2A26A7AD3037FADD7BLUPRD0511MB436_-- From pe-jiang@kddi.com Tue Jul 2 17:54:01 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348C211E810B for ; Tue, 2 Jul 2013 17:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84MtU-RYcMuS for ; Tue, 2 Jul 2013 17:53:57 -0700 (PDT) Received: from UTMC1103.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id CED6321F9A7D for ; Tue, 2 Jul 2013 17:53:56 -0700 (PDT) Received: from UTMC1134 (unknown [10.5.16.201]) by UTMC1103.kddi.com (Postfix) with SMTP id 6D5F02948; Wed, 3 Jul 2013 09:53:54 +0900 (JST) Received: from UTMC1124.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id B5D461BFF; Wed, 3 Jul 2013 09:53:51 +0900 (JST) Received: from UTMC1112.kddi.com (unknown [10.5.16.9]) by UTMC1124.kddi.com (Postfix) with ESMTP id 9883819DC; Wed, 3 Jul 2013 09:53:51 +0900 (JST) Received: from KDDI-0806PC0671 ([10.200.129.117] [10.200.129.117]) by post-ims.kddi.com with ESMTPA; Wed, 3 Jul 2013 09:53:50 +0900 To: jvasseur@cisco.com, pce@ietf.org From: Peng JIANG References: <03B78081B371D44390ED6E7BADBB4A7721FE06A3@xmb-rcd-x02.cisco.com> <201210151638.AGF34889.JOKQtBHF@kddi.com> <201305101017.BED02471.OBtKHFQJ@kddi.com> <201307021053.FFH12467.OBJtHQFK@kddi.com> <03B78081B371D44390ED6E7BADBB4A77235F83C8@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77235F83C8@xmb-rcd-x02.cisco.com> Message-Id: <201307030953.GEC35926.OtJFBQHK@kddi.com> X-Mailer: Winbiff [Version 2.51 PL3] X-Accept-Language: ja,en,zh Date: Wed, 3 Jul 2013 09:53:50 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 1307030953510000401408 Cc: jpv@cisco.com Subject: Re: [Pce] About draft-kumaki-murai-pce-pcep-extension-l3vpn X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 00:54:01 -0000 Hi JP and PCEers, > Thanks, I would really suggest the WG to voice an opinion on this ID so as to decide about the next steps. Thanks! WG Members: Your opinion will be highly appreciated. I think most of you have once read or heard the presentation of this ID. But FYI, this ID defines how to extend the PCEP to support the dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites. It is assumed that this ID will be used together with a modified RSVP signaling protocol(RFC6882). Thanks, Peng JIANG KDDI > > On Jul 2, 2013, at 3:53 AM, Peng JIANG wrote: > > > Dear JP, Julien and PCEers, > > > > The following email was sent a few days ago. > > > >> Please let me remind you that we have a new version for the PCEP > >> extension draft. > >> http://tools.ietf.org/html/draft-kumaki-murai-pce-pcep-extension > >> -l3vpn-11 > >> > >> We received a few comments during the presentation at the > >> Atlanta meeting. One of the comments is that the Intended Status > >> should be the same as that of the signaling protocol. > >> > >> In this new version, the Intended Status has been changed to > >> Experimental together with various expression change that comply > >> with the new Intended Status. > >> > >> FYI, The RSVP signaling protocol that we proposed is now RFC6882. > >> http://tools.ietf.org/html/rfc6882 > >> > >> We also add a reference to this new RFC. > >> > >> Please let us konw if you have new comments. > >> And we would like to ask for WG adoption if you all feel OK > >> about this draft. > > > > Please let us know your opinion about this new version. > > Your comment is highly appreciated. Thanks! > > > > Best Regards, > > Peng JIANG > > KDDI > > > >> Dear JP and PCEers, > >> > >> Please let me remind you that we have a new version for the PCEP > >> extension draft. > >> http://tools.ietf.org/html/draft-kumaki-murai-pce-pcep-extension > >> -l3vpn-11 > >> > >> We received a few comments during the presentation at the > >> Atlanta meeting. One of the comments is that the Intended Status > >> should be the same as that of the signaling protocol. > >> > >> In this new version, the Intended Status has been changed to > >> Experimental together with various expression change that comply > >> with the new Intended Status. > >> > >> FYI, The RSVP signaling protocol that we proposed is now RFC6882. > >> http://tools.ietf.org/html/rfc6882 > >> > >> We also add a reference to this new RFC. > >> > >> Please let us konw if you have new comments. > >> And we would like to ask for WG adoption if you all feel OK > >> about this draft. > >> > >> Best Regards, > >> Peng JIANG > >> KDDI > >> > >>> Dear JP, > >>> Cc: KDDI Miyasaka-san > >>> > >>> Thank you very much for your quick reply. > >>> > >>>> JP> Yes I believe that it is now time to get back to the PCE WG for a > > last > >> > >>> presentation. > >>> > >>> Thank you very much for your suggestion. > >>> We would like to request a presentation slot for 5 or 10 minutes. > >>> Could you please assign one to us? > >>> My colleague Miyasaka-san will attend IETF85 and he is willing > >>> to make this presentation. > >>> > >>> Best Regards, > >>> Peng JIANG > >>> KDDI > >>> > >>> > >>>> Dear Jiang-san, > >>>> > >>>> On Oct 15, 2012, at 4:20 AM, Peng JIANG wrote: > >>>> > >>>>> Dear JP, > >>>>> > >>>>> I am one of the co-authors of draft-kumaki-murai-pce-pcep- > >>>>> extension-l3vpn. This draft defines the PCEP extensions for the > >>>>> dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites. > >>>>> > >>>>> We have been waiting for the signaling protocol(draft-kumaki- > >>>>> murai-l3vpn-rsvp-te) to be standarized. Now, the IESG Last Call > >>>>> has finished and we are now waiting for the Go-Ahead sign of the > >>>>> sponsor AD. > >>>>> > >>>>> Since the signaling protocol standardization is almost finished > >>>>> now, we are considering progressing the PCEP extension draft to > >>>>> a WG item. > >>>>> > >>>>> It has been a while since we last present the WG. Do you think > >>>>> it is proper that we remind the WG on the list about the > >>>>> contents of the PCEP extension together with the progress of the > >>>>> signaling protocol and then ask for WG last call? I think we > >>>>> have agreed to progress the PCEP extension once the signaling > >>>>> protocol standardization is finished. > >>>>> > >>>> > >>>> JP> Yes I believe that it is now time to get back to the PCE WG for a > > last > >> > >>> presentation. > >>>> > >>>> Thanks! > >>>> > >>>> JP. > >>>> > >>>>> Best Regards, > >>>>> Peng JIANG > >>>>> KDDI > >>>> > >>>> _______________________________________________ > >>>> Pce mailing list > >>>> Pce@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/pce > >>>> > >>> > >> > From julien.meuric@orange.com Wed Jul 3 02:04:04 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC81D21F9D00 for ; Wed, 3 Jul 2013 02:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGtdKzbxVp4W for ; Wed, 3 Jul 2013 02:03:58 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id CD0D721F9D1E for ; Wed, 3 Jul 2013 02:03:57 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A98567D4003 for ; Wed, 3 Jul 2013 11:03:55 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.orange.com (Postfix) with ESMTP id A97BF7D4002 for ; Wed, 3 Jul 2013 11:03:54 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Jul 2013 11:03:54 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Jul 2013 11:03:54 +0200 Message-ID: <51D3E8F9.7040007@orange.com> Date: Wed, 03 Jul 2013 11:03:53 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "pce@ietf.org" References: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> In-Reply-To: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2013 09:03:54.0351 (UTC) FILETIME=[3E5B07F0:01CE77CC] Subject: [Pce] Fwd: Draft submission deadlines change X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 09:04:04 -0000 Hi all. Please note the experiment below. To rephrase the 2nd paragraph: late submissions may still get lower priorities to reach WG agendas... JP & Julien -------- Message original -------- Date : Tue, 2 Jul 2013 22:17:01 -0700 De : IETF Chair Please note that for IETF 87, there is only one deadline for draft submission: Monday 15th July. Previously, there had been two different deadlines, one for -00 and another one for other versions. The IESG has decided to experiment with just one deadline for now to simplify the set of deadlines and enable easier submission of new drafts. While we realise that the change comes near the deadline, we hope that you find the extra time useful. But please do note that working group chairs will continue to make smart decisions about what topics are worthwhile for discussing in a session in the upcoming meeting, and will also set their agendas in a timely manner and create deadlines for their working groups that must be adhered to. The earlier new drafts are submitted, the more time there is to talk about them on the mailing lists and consider them for the session agendas. This is particularly important for BoFs. Jari Arkko for the IESG From julien.meuric@orange.com Wed Jul 3 02:07:03 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726D221F9D24 for ; Wed, 3 Jul 2013 02:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkLYOwPXzIjw for ; Wed, 3 Jul 2013 02:06:59 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4413821F9AEC for ; Wed, 3 Jul 2013 02:06:59 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A4DDB4102DC for ; Wed, 3 Jul 2013 11:06:58 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.orange.com (Postfix) with ESMTP id B4EA84102DA for ; Wed, 3 Jul 2013 11:06:57 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Jul 2013 11:06:57 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Jul 2013 11:06:57 +0200 Message-ID: <51D3E9B0.4020601@orange.com> Date: Wed, 03 Jul 2013 11:06:56 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: pce@ietf.org References: <51C1B43E.50605@orange.com> In-Reply-To: <51C1B43E.50605@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Jul 2013 09:06:57.0432 (UTC) FILETIME=[AB7AF980:01CE77CC] Subject: Re: [Pce] Poll for Adoption of draft-farrkingel-pce-questions X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 09:07:03 -0000 Hi. It seems that the support is loud and clear. Authors, you may submit your I-D as "draft-ietf-pce-questions-00" and then address received comments. Thanks, JP & Julien Le 19/06/2013 15:38, Julien Meuric a écrit : > Dear WG, > > Following the discussion about the future of the aforementioned > document and the feedback sent to the list, this message starts a poll > for the adoption of draft-farrkingel-pce-questions-03 by the PCE WG. > Pay attention to the document scope: the goal is _not_ to leave the > I-D open to gather all questions about PCE, but to store some useful > text associated to PCE by moving forward as an informational document. > > Please send your support/opposition to the PCE mailing list (the > latter typically requiring some explanation). Detailed comments on the > I-D are also welcome. > > Thanks, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From julien.meuric@orange.com Wed Jul 3 09:04:57 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F77421F9CAD for ; Wed, 3 Jul 2013 09:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qelm+NXNxULs for ; Wed, 3 Jul 2013 09:04:52 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7596D21F9CB1 for ; Wed, 3 Jul 2013 09:04:52 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F723DE4005 for ; Wed, 3 Jul 2013 18:06:33 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 83882DE4002 for ; Wed, 3 Jul 2013 18:06:33 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Jul 2013 18:04:49 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Jul 2013 18:04:49 +0200 Message-ID: <51D44BA0.4090800@orange.com> Date: Wed, 03 Jul 2013 18:04:48 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: pce@ietf.org References: <51B82C91.3050304@orange.com> <51C8747F.50604@orange.com> <523C37072C291347B9730C9291CCA07D09269C@DB3PRD0411MB427.eurprd04.prod.outlook.com> <51CABA62.3080703@cttc.es> In-Reply-To: <51CABA62.3080703@cttc.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Jul 2013 16:04:49.0291 (UTC) FILETIME=[0B790DB0:01CE7807] Subject: Re: [Pce] WG Last Call of draft-ietf-pce-vendor-constraints-10 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 16:04:57 -0000 Hi. Besides the previous comments already raised, mostly on section 2, I would add the following: ---------- Title + Abstract + Introduction ----- s/Path Computation Element Protocol/Path Computation Element Communication Protocol/ [x3] ---------- Section 2 ----- s/flag is clear, then as defined in [RFC5440],/flag is clear then, as defined in [RFC5440],/ ---------- Section 5 ----- Another protocol name without "communication", but no need to add it there since it is the current name of the registry... ---------- Section 6 ----- s/SHUOLD/SHOULD/ [already mentioned by Robert] ---------- Best regards, Julien Le 26/06/2013 11:54, Ramon Casellas a écrit : > El 26/06/2013 9:40, Margaria, Cyril (Coriant - DE/Munich) escribió: >> Support. >> >> I have a few remarks : >> 1) The definition does include the definitions from >> RFC5541 and RFC5557, the RFC5557 did not include the [] >> element, should this fixed by RFC5557 errata to match the >> pce-vendor-constraints definition? >> >> 2) This document include the XRO in the svec-list, but not in the >> , where should it go in the ? >> >> 3) the Path key expansion requests, nor monitoring are considered, >> is it OK? Basically should a new document take into account all the >> existing RFCs grammar element or should it cherry pick (and based on >> which criteria) >> >> 4) RFC5440/RFC6006/pce-vendor-constraints compatibility: >> RFC5440 indicates that the object order MUST be followed, >> RFC6006 did change the object order defined in RFC5440: >> - RRO list and RRO bandwidth should follow the , >> not the , >> - 3 BANDWITH objects are allowed >> - [] is before the [] in RFC6006 but after the >> [] in RFC5541 >> pce-vendor-constraints does use the [] definition of >> RFC5541 (after []), add the [] (without >> []) before the []( in contrary to RFC6006, which put >> the RROs after the endpoints) >> >> The object order are not consistent, which is not very good for >> implementation (need to support the different variation) >> >> I understand the need for a different grammar in RFC6006, my >> preference would be to define one p2p grammar and one p2mp grammar >> (as this is in the RP this is not perfect, but OK from implementation >> point of view) (as in gmpls-pcep-extensions). >> For the other points think this could be covered by erratas in the >> original documents. > > Dear all, > > I share Cyril's comments. In my humble opinion, we are more and more > having a set of documents with grammars selecting only some objects > from existing documents and not covering them all and, once integrated > in a single implementation, it becomes harder to make sense of all > them (e.g. "bandwidths" made worse later with also > GENERALIZED-BANDWIDTHs). Ordering constraints are also a problem that > would need to be addressed. > > Below a minor review. The draft is quite clear and self-explanatory > (all my comments are minor) . > > > OLD > The object can be present in two places within the PCReq message to > enable it to apply to a single path computation request or to a set > of synchronized requests > > Sorry to be picky, but I count three :-) within a SVEC, within an > individual request both as a direct constraint and within the endpoint > rro pair-list. Maybe just > > NEW > The object can be present to enable it to apply to a single path > computation request or to a set of synchronized requests. > > > > * I would, if not too much effort, separate the case where a PCE does > not parse/understand the VENDOR-INFORMATION object from the case it > does not support a given Enterprise number. In other words, the draft > could specify the procedures when a PCE finds a VERDOR-INFORMATION > object with an Enterprise number it does not understand (as done for > TLV, Section 2.1 deals with the case of "unknown object".) Maybe > something in the lines of "If the Enterprise Number is unknown to the > PCE, the PCE (...)". I think it could be useful to have a dedicated > error code for that. Alternatively Just add the text "If the > Enterprise Number is unknown to the PCE, it MUST treat that object as > Unknown" but I like this less. The curent text "if the P flag is set, > the object will be treated as mandatory and the request will either be > processed using the contents of the object" somehow covers it > implicitly, thuogh but I would like to see it explicitly written. > > OLD > > - The PCE determines how to interpret the information in the Vendor > Information object by examining the Enterprise Number it contains. > > NEW > > - The PCE determines how to interpret the information in the Vendor > Information object by examining the Enterprise Number it contains. > If the Enterprise Number is unknown to the PCE, it MUST treat that > object as an Unknown object. > > > > Note that the TLV text currently states > > - The PCE determines how to interpret the Vendor Information TLV by > examining the Enterprise Number it contains. If the Enterprise > Number is unknown to the PCE, it MUST treat the Vendor Information > TLV as an unknown TLV > > > > > * ::= lacks a [] after [] since XRO is mentioned > > > > * ::= I would suggest moving the vendor-info-list after > endpoints (for both p2p and p2mp) My personal preference would be > after metric list and objective function. endpoint-rro-pair-list at > least includes one mandatory ENDPOINTS object, making the mandatory RP > and ENDPOINTS objects appear first. > > > * The draft states "Thus, the PCReq message based on [RFC6006] is > encoded as follows". Much like RFC6006, the draft is ignoring the BNC > object in the grammar. Also it is not clear where in the PCReq it > should appear. RFC6006 also says that "The object can only be carried > in a PCReq message. A Path Request may carry at most one Branch Node > Object". But I am not sure how to specify a branch node list and a > non-branch node list. > > > * The draft just says "The Vendor Information object can be included > in a PCRep message in exactly the same way as any other object as > defined in [RFC5440]" I would suggest to provide a suggested > grammar/ordering which includes not only the vendor-information-list > but also othe RFC6006 extensions notably regarding > end-point-path-pair-list and ERO/SERO. As a bare minimum the draft > should refer to RFC6006 regarding to PCRep message instead of RFC5440. > > > * As RFC6006, the draft is ignoring the UNREACH-DESTINATION object and > is not present in the PCRep grammar > > > > Other "philosophical" comments > ============================= > > Although I understand it is inherited from RFC6006, it is unfortunate > that that we keep the name of endpoint-rro-pair-list, since it is more > and and more losing its meaning of a (endpoint, rro) pair list. > Dreaming on, I also believe it could useful to split into a P2P > grammar and a P2MP grammar, roughly as follows (as Cyril mentioned > this was also suggested for GMPLS extensions and clarifies RFC6006. In > any case, an implementation needs to parse the RP object to know if it > is a p2p or p2mp) > > ::= | | > > ::= > > ::= [] > > ::= CLASSTYPE LSPA BANDWIDTH metric-list > objective-functions vendor-info-list rro-bw-pair IRO BNC XRO > LOADBALANDING ... (all optional and parsed in any order for interworking) > > ::= [] > > ::= [] > > ::= etc. > > Finally, as a a personal comment which I echoed when the draft was > polled, and althgouh I support this draft, I still hope that the > objects and TLVs defined in this document are not overused and that > objective functions, related metrics, and constraints in general are > defined following open processes. > > > Thanks > R. > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From internet-drafts@ietf.org Thu Jul 4 07:01:41 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060F811E811E; Thu, 4 Jul 2013 07:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1wTpgFF9hyg; Thu, 4 Jul 2013 07:01:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A058721F9FC1; Thu, 4 Jul 2013 07:01:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130704140140.15812.80613.idtracker@ietfa.amsl.com> Date: Thu, 04 Jul 2013 07:01:40 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-questions-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:01:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : Unanswered Questions in the Path Computation Element Arc= hitecture Author(s) : Adrian Farrel Daniel King Filename : draft-ietf-pce-questions-00.txt Pages : 25 Date : 2013-07-04 Abstract: The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager in RFC 5623, and generalized to Hierarchical PCE in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF work efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-questions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-questions-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zali@cisco.com Thu Jul 4 07:32:25 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE2521F9E97 for ; Thu, 4 Jul 2013 07:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxfpw9ApXWBm for ; Thu, 4 Jul 2013 07:32:19 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C41B821F9E98 for ; Thu, 4 Jul 2013 07:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2738; q=dns/txt; s=iport; t=1372948339; x=1374157939; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=zcw3rzxAka9CgkFUjkL6b61hDtJQJAYdYJjPXkxcs4Y=; b=gO+OX9O/xxR4CtcB6MVDi/LNRCosXz35Wa333iPhhBIKIUMZOOT88fM7 fS1fO0l9DEoJM9scaGlQoSgDrA1HaHHND2CxZgFMjo1y5IPZvlK4IvZ5R Bom/blvj4ngXY2wcO+CkPnIgcT0RkkvALKpzhCCuR1sS9IZg+N2vapo8Q s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEWG1VGtJXG8/2dsb2JhbABagwl7wD6BAxZ0giMBAQEEgQUGAQgRAwECC1YdCAEBBAESCIgHuV6OKYEROAaCfmkDqQ6DEYFxNw X-IronPort-AV: E=Sophos;i="4.87,995,1363132800"; d="scan'208";a="228006645" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 04 Jul 2013 14:32:14 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r64EWDdQ009946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jul 2013 14:32:14 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 09:32:13 -0500 From: "Zafar Ali (zali)" To: "Zafar Ali (zali)" , "Margaria, Cyril (NSN - DE/Munich)" , "draft-ali-pce-remote-initiated-gmpls-lsp@tools.ietf.org" , "pce@ietf.org" Thread-Topic: Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00 Thread-Index: Ac4QKL6jmYErbjKLSeWghMsqzYggPwObOLuADPVyDoAJmA7FAA== Date: Thu, 4 Jul 2013 14:32:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.220.134] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <2D72A6FEA8CA824FAED1671758FE68A6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:32:25 -0000 Hi Margaria, authors of draft-crabbe-pce-pce-initiated-lsp and stateful PCE drafts: I followed up on comments from Margaria that we received on draft-ali-pce-remote-initiated-gmpls-lsp-00. However, we did not receive any response from authors of draft-crabbe-pce-pce-initiated-lsp and stateful PCE drafts to close on Margaria's comments. Please advise. Thanks Regards ... Zafar -----Original Message----- From: zali Date: Thursday, May 16, 2013 2:27 PM To: "cyril.margaria@nsn.com" , "draft-ali-pce-remote-initiated-gmpls-lsp@tools.ietf.org" , "pce@ietf.org" Subject: Re: Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00 Resent-From: Resent-To: , , Oscar de Dios , VICTOR ALVAREZ , zali Resent-Date: Thursday, May 16, 2013 2:27 PM > >-----Original Message----- >From: zali >Date: Monday, March 11, 2013 3:18 PM >To: "cyril.margaria@nsn.com" , >"draft-ali-pce-remote-initiated-gmpls-lsp@tools.ietf.org" >, "pce@ietf.org" > >Subject: Re: Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00 > >>>I think the document has good material, but address several separated >>>points : >>>1. Active Stateful PCE Applicability >>>2. MPLS multi-layer aspects >>>3. GMPLS (GENERALIZED-BW and SWITCH-LAYER) >>> >>>I think the second point may have a document on its own, but the first >>>and third point could be managed by merges. >> >>Like mentioned above, we are open to document rearrangement(s), if it >>simplify the process. At the moment this work is outside the scope of WG >>charter. I am sure in due time we will have more of such discussion and >>opinion from the WG. There are example where WG liked to keep GMPLS >>extensions separate from (packet) MPLS work. > >Hi Margaria-=20 > >Now that this is a chartered item, let's close on your comments. > >We will update the document based on your comments received under this >thread. However, document restructuring also requires agreement from >authors/ drivers for the other drafts. > >- (3) in above require merger of related text to >draft-crabbe-pce-pce-initiated-lsp. >- (1) requires merger to stateful PCE draft. > >Let's use this email to solicit feedback for authors of these draft if >they agree to the merge. I am fine, either-way but have a feeling that >separate document may remain a reality. > >Thanks > >Regards =A9 Zafar > > From bill.wu@huawei.com Thu Jul 4 19:44:42 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1C921F9A16 for ; Thu, 4 Jul 2013 19:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Egcixd9uHM+A for ; Thu, 4 Jul 2013 19:44:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C9D3721F9A13 for ; Thu, 4 Jul 2013 19:44:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUR67886; Fri, 05 Jul 2013 02:44:29 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 5 Jul 2013 03:44:23 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 5 Jul 2013 10:44:27 +0800 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Fri, 5 Jul 2013 10:44:22 +0800 From: Qin Wu To: "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Thread-Index: AQHOeSiMeobaJqAMg0SQwWnFiymSpJlVXtiA Date: Fri, 5 Jul 2013 02:44:22 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Pce] FW: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 02:44:42 -0000 Hi, folks: This is an initial draft (-v00) about DNS based PCE discovery. Here is the overview of this draft: " Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. " I like to solicit some feedback to see if there is interest in working out more details about DNS based discovery. Thanks! Regards! -Qin -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Friday, July 05, 2013 10:37 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Path Computation Element (PCE) Discovery using DNS Author(s) : Qin Wu Filename : draft-wu-pce-dns-pce-discovery-00.txt Pages : 14 Date : 2013-07-04 Abstract: Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-pce-dns-pce-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-pce-dns-pce-discovery-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From julien.meuric@orange.com Fri Jul 5 08:05:16 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A9311E8104 for ; Fri, 5 Jul 2013 08:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.172 X-Spam-Level: X-Spam-Status: No, score=-5.172 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6HeFf4V-nKa for ; Fri, 5 Jul 2013 08:05:12 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1F83C11E80F4 for ; Fri, 5 Jul 2013 08:05:12 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 139D0410223 for ; Fri, 5 Jul 2013 17:05:11 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 1B0A1410222 for ; Fri, 5 Jul 2013 17:05:10 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Jul 2013 17:05:10 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Jul 2013 17:05:09 +0200 Message-ID: <51D6E0A5.8000304@orange.com> Date: Fri, 05 Jul 2013 17:05:09 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: pce@ietf.org References: <7CFF94B047D8864CB6268315034E35DE2F5E9F98@EX10-MB2-MAD.hi.inet> <013501ce6be7$61378910$23a69b30$@olddog.co.uk> In-Reply-To: <013501ce6be7$61378910$23a69b30$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Jul 2013 15:05:09.0693 (UTC) FILETIME=[0AB13ED0:01CE7991] Subject: Re: [Pce] Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:05:16 -0000 Hi authors. Besides Oscar's, please find my complementary comments (which were stuck on my paper). A comment which globally spans the I-D: there are a few RFC 2119 keywords, but it feels like there are not enough when defining the mechanism's behavior; e.g. the definition of the C bit includes a "should" while I would have rather expected a "MUST" (or at least a "SHOULD"). Note that the "Manageability" section appropriately uses these keywords more frequently (different writer?). ---------- Abstract + Introduction ----- s/GMPLS networks/GMPLS-controlled networks/ [twice] ---------- Section 2 ----- The definitions of "boundary nodes" and "core tree" begin with " is...", unlike the others one. I suggest to drop those " is" phrases in the sentences to make them consistent. s/PCE (Path Computation Element): an entity/PCE: Path Computation Element. An entity/ ---------- Section 3 ----- s/GMPLS networks/GMPLS-controlled networks/ [one of my favorites! ;-) ] ---------- Section 5 ----- s/Its also important/It is also important/ The way requirements 5 to 8 are written is not consistent with the previous ones; adding "should be supported" at the end of each one would address my concern. ---------- Section 6 ----- s/called an Objective Function (OF) may be indicated/called an Objective Function (OF), may be indicated/ s/(the Core Tree) should be optimal/(the Core Tree), should be optimal/ ---------- Section 7 ----- s/Core Tree Based procedure/Core Tree-based procedure/ s/as a tree, which satisfies/as a tree that satisfies/ s/Path-Key Mechanism/path-key mechanism/ s/the same nodes and links/these nodes and links/ s/Path-key Mechanism can/Path-key mechanism can/ s/BRPC based procedure/BRPC-based procedure/ s/BRPC Based Core Tree/BRPC-Based Core Tree/ s/form a set of paths, we call it a/form all possible sets of paths, we call them/ s/point to point, BRPC procedure/point to point BRPC procedure/ s/message is as per/message as per/ s/not necessary pruned/not necessarily pruned/ s/intermediate PCEs.
The reason for/intermediate PCEs. The reason for/ s/its parent PCE/its upstream PCE/ [I'm surprised Oscar missed that one ;-) ] s/eventually by looking through all the combinations, and taking one sub-path from each set to built one P2MP tree it finds/eventually, by looking through all the combinations and taking one sub-path from each set to build one P2MP tree, it finds/ [commas + "build"] s/PCE MAY consider/A PCE MAY consider/ s/Sub Tree Computation/Sub-Tree Computation/ s/these mechanism are/these mechanisms are/ In section 7.4.2, I wonder why the IGP and BGP are not mentioned as possible ways of building domain trees based on source/leaves addresses (when relevant). When defining the grafting of leaf nodes, a scalability risk is identified on the number of inter-domain PCEP adjacencies. Hierarchical PCE is mentioned, which is relevant, but I fail to see this as an "alternative": both are alike in their hub and spoke approach, and the latter does not address the former issue. I would rephrase that as a commonalty rather than an "alternative". Related noted: the previous explanation is given 3 three times within 2 pages (sections 7.3, 7.5 and 7.6). Given that section 7.5 focuses on it, I would put the text there and prune some from other sections. ---------- Section 9 ----- s/configuration MAYBE stored/configuration MAY be stored/ s/and that this information/and this information/ s/The are also/They are also/ ---------- References ----- The number of normative references looks minimized, but I believe that at least RFC 5441 is normative in the document. ---------- Enjoy the week-end, Julien On 06/18/2013 07:47, Daniel King wrote: > > Thanks Oscar! This will really help improve the readability of the > draft. We will update the draft, but also respond to each of the > points specifically and clarify any technical issues. > > Br, Dan. > > *From:*Oscar González de Dios [mailto:ogondio@tid.es] > > Dear authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04, > > Please find bellow some comments regarding the PCEP P2MP Procedures > draft (sorry for sending them after the 2 weeks deadline for the LC > comments): > > - There is a strange page jump in the Terminology section. After > "RFC5862]" and "ABR: " there is whole blank page… > > - Terminology section: Blank line missing between Transit/branch > domain and VSPT > > - During the document there are 3 different acronyms "P2MP LSP" > (section 3 ) "P2MP TE-LSP" (this one only in section 6) and "P2MP TE > LSP" (the most common in the document). I suggest aligning the > terminology and always use the same term to avoid confusion. . For > "historical" reasons, "P2MP TE LSP", used in RFC 4461 seems > appropriate. The definition of P2M2 TE LSP used in RFC 4661 may be > cited too in the terminology section for completeness. > > - In the terminology section the term "Boundary node (BN) is defined. > However, later on, the term "border node" is also used, presumably as > an synonym. I suggest either choose one term for the whole document or > include the term border node too in the terminology. > > - Section 3. The sentence "A sub-tree is a part of the P2MP tree > describing how the root or an intermediate P2MP LSPs minimizes packet > duplication when P2P TE sub-LSPs traverse common links" is hard to > understand (maybe there is a typo and it should say "the root of an > intermediate P2P LSP"). > > - The term P2P TE sub-LSP is used in section 3. TE sub-LSP is defined > in RFC 4661. Maybe it should be worth adding the sub-LSP terms it to > the terminology section. > > - In section 4 the term "sequence of domains" is also used to refer to > the path domain tree. This introduces confusion, as there is also a > "domain sequence" term which applies only to P2P. Please use always > "path domain tree" > > -Section 4, 2nd paragraph, "domain path tree", use the term "path > domain tree" defined in the terminology section. > > - Section 4, figure 1 legend is "Domain sequence tree". This term is > not defined in the terminology. I would prefer to stick to the term > "Path Domain tree". Sorry to be picky about the terminology, but > reading the document is hard when the terms are mixed as they are very > alike…. > > - Section 4, assumptions, first bullet. Where it says " each of the > P2MP destination" it should day "each of the P2MP destinations". > > Section 4, assumption 1, "or PCE sequence (i.e. PCE that serves each > domain in the path domain tree)". I don't get this point…. Initially > it was stated that the path domain tree is known. In this point, is it > suggested an alternative to knowing the path domain tree? That is, > instead of assuming that the path domain tree is known, what is known > is a set of PCEs? Please clarify > > Section 4, assumption 1, How is the set of PCEs and their > relationships exchanged? What are the relationships that need to be > exchanged? > > Section 4, assumptions, I guess, there is an (maybe obvious) > assumptions that the association domain - PCE is known in advance. > > Sesction 4, assumption 4. "The boundary nodes to use on the LSP are > pre-determined". Does this mean then that both the path domain tree > AND the boundary nodes are known in advance for each possible P2MP > combination? > > At this point there is something I miss… Later, in section 7, it is > mentioned that a core tree is computed. However, it seems from the > assumptions that the core tree is fixed in advance… Maybe I am > mis-interpreting the assumptions… Please clarify the assumptions of > what is really pre-determined and what is computed. > > Section 5. requirement 4. I suggest using better "PCReq and PCEReq > messages" using the terminology of RFC 5440. > > Section 5. The requirements from 5 to 8 are not written like > requirements. I suggest re-writing them with requirements language. > > Section 6. Objective function 3. The definition of the core tree in > the terminology section considers ONLY entry boundary nodes as leaves. > However, it seems here both entry and exit BNs are considered. Please > clarify… (maybe it should be mentioned only BNs without distinction > among entry or exit). > > Section 6. Objective function 3 is about limiting the number of entry > points to a domain. Why would there be more that one entry point to a > domain? I would expect multiple exit points (that is, several boundary > nodes to exit to other domains in the tree). Also, given that, by the > assumptions in section 4, the path domain tree AND the boundary nodes > are flxed, I do not know if this objective function has any impact at > all…. > > In any case, limiting the number of entry points may an additional > constraint to the previous objective functions… It seems more a metric > constraint rather than an objective function.. > > Also, is it considered that several of this objective functions can be > applied or combined? > > Section 6, objective function 4… I don't get that one… could you > clarify it? > > Section 7.1 The sentence "An optimal core-tree [based on the OF] will > be computed with analyzing the nodes and links within the domains" > sounds a bit strange… maybe the "with" is not needed in the sentence? > Also.. Previously it was mentioned that the core-tree was formed only > considering entry and exit nodes, but now, it seems that the core-tree > is obtained taking into account the whole set of nodes and links… > Please clarify here (or clarify objective function 2 where it says > "formed by considering only the entry and exit nodes"…) > > - Section 7.3 When mentioning the request with the C bit set I suggest > adding "(defined later in section 7.4.1 of this document)", as it is a > new flag… > > - Section 7.4.2. I guess "domain-sequence" is really the domain tree… > One question… the PCE sequence… is a PCE tree? > > And that's all :-) I hope the comments can be useful to improve the > readability of the draft. > > Best Regards, > > Oscar > > ------------------------------------------------------------------------ > > > Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar nuestra política de envío y recepción de correo electrónico > en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send > and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From daniel@olddog.co.uk Fri Jul 5 09:32:38 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D9511E8142 for ; Fri, 5 Jul 2013 09:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.445 X-Spam-Level: X-Spam-Status: No, score=-100.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRCB+VovuwSH for ; Fri, 5 Jul 2013 09:32:34 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 80A6211E8129 for ; Fri, 5 Jul 2013 09:32:32 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r65GWV6q016489; Fri, 5 Jul 2013 17:32:31 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r65GWTIh016473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Jul 2013 17:32:30 +0100 From: "Daniel King" To: "'Julien Meuric'" References: <7CFF94B047D8864CB6268315034E35DE2F5E9F98@EX10-MB2-MAD.hi.inet> <013501ce6be7$61378910$23a69b30$@olddog.co.uk> <51D6E0A5.8000304@orange.com> In-Reply-To: <51D6E0A5.8000304@orange.com> Date: Fri, 5 Jul 2013 17:32:29 +0100 Message-ID: <002501ce799d$3e3d1560$bab74020$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-index: AQHZuKuBsgLNsNOSdzgjZ4hsHKP0QwMD8OYNAPhMY5uZH+Zy8A== Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 16:32:38 -0000 Great! We have circulated a new version amongst the authors that addresses = some (but not all) of these, so thank you very much! We will fix anything = still outstanding and submit early next week.=20 Br, Dan.=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Julien Meuric Sent: 05 July 2013 16:05 To: pce@ietf.org Subject: Re: [Pce] Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04 Hi authors. Besides Oscar's, please find my complementary comments (which were stuck = on my paper). A comment which globally spans the I-D: there are a few RFC 2119 = keywords, but it feels like there are not enough when defining the mechanism's behavior; e.g. the definition of the C bit includes a "should" while I = would have rather expected a "MUST" (or at least a "SHOULD"). Note that the "Manageability" section appropriately uses these keywords more = frequently (different writer?). ---------- Abstract + Introduction ----- s/GMPLS networks/GMPLS-controlled networks/ [twice] ---------- Section 2 ----- The definitions of "boundary nodes" and "core tree" begin with " is...", unlike the others one. I suggest to drop those " is" phrases in the sentences to make them consistent. s/PCE (Path Computation Element): an entity/PCE: Path Computation = Element. An entity/ ---------- Section 3 ----- s/GMPLS networks/GMPLS-controlled networks/ [one of my favorites! ;-) ] ---------- Section 5 ----- s/Its also important/It is also important/ The way requirements 5 to 8 are written is not consistent with the = previous ones; adding "should be supported" at the end of each one would address = my concern. ---------- Section 6 ----- s/called an Objective Function (OF) may be indicated/called an Objective Function (OF), may be indicated/ s/(the Core Tree) should be = optimal/(the Core Tree), should be optimal/ ---------- Section 7 ----- s/Core Tree Based procedure/Core Tree-based procedure/ s/as a tree, = which satisfies/as a tree that satisfies/ s/Path-Key Mechanism/path-key = mechanism/ s/the same nodes and links/these nodes and links/ s/Path-key Mechanism can/Path-key mechanism can/ s/BRPC based procedure/BRPC-based procedure/ s/BRPC Based Core Tree/BRPC-Based Core Tree/ s/form a set of paths, we = call it a/form all possible sets of paths, we call them/ s/point to point, = BRPC procedure/point to point BRPC procedure/ s/message is as per/message as = per/ s/not necessary pruned/not necessarily pruned/ s/intermediate = PCEs.
The reason for/intermediate PCEs. The reason for/ s/its parent PCE/its = upstream PCE/ [I'm surprised Oscar missed that one ;-) ] s/eventually by looking through all the combinations, and taking one sub-path from each set to built one P2MP tree it finds/eventually, by looking through all the combinations and taking one sub-path from each = set to build one P2MP tree, it finds/ [commas + "build"] s/PCE MAY = consider/A PCE MAY consider/ s/Sub Tree Computation/Sub-Tree Computation/ s/these mechanism are/these mechanisms are/ In section 7.4.2, I wonder why the IGP and BGP are not mentioned as = possible ways of building domain trees based on source/leaves addresses (when relevant). When defining the grafting of leaf nodes, a scalability risk is = identified on the number of inter-domain PCEP adjacencies. Hierarchical PCE is mentioned, which is relevant, but I fail to see this as an "alternative": both are alike in their hub and spoke approach, and the latter does not address the former issue. I would rephrase that as a commonalty rather than an "alternative". Related noted: the previous explanation is given 3 three times within 2 pages (sections 7.3, 7.5 and 7.6). Given that section 7.5 focuses on it, = I would put the text there and prune some from other sections. ---------- Section 9 ----- s/configuration MAYBE stored/configuration MAY be stored/ s/and that = this information/and this information/ s/The are also/They are also/ ---------- References ----- The number of normative references looks minimized, but I believe that = at least RFC 5441 is normative in the document. ---------- Enjoy the week-end, Julien On 06/18/2013 07:47, Daniel King wrote: > > Thanks Oscar! This will really help improve the readability of the=20 > draft. We will update the draft, but also respond to each of the=20 > points specifically and clarify any technical issues. > > Br, Dan. > > *From:*Oscar Gonz=E1lez de Dios [mailto:ogondio@tid.es] > > Dear authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04, > > Please find bellow some comments regarding the PCEP P2MP Procedures=20 > draft (sorry for sending them after the 2 weeks deadline for the LC > comments): > > - There is a strange page jump in the Terminology section. After=20 > "RFC5862]" and "ABR: " there is whole blank page=85 > > - Terminology section: Blank line missing between Transit/branch=20 > domain and VSPT > > - During the document there are 3 different acronyms "P2MP LSP"=20 > (section 3 ) "P2MP TE-LSP" (this one only in section 6) and "P2MP TE=20 > LSP" (the most common in the document). I suggest aligning the=20 > terminology and always use the same term to avoid confusion. . For=20 > "historical" reasons, "P2MP TE LSP", used in RFC 4461 seems=20 > appropriate. The definition of P2M2 TE LSP used in RFC 4661 may be=20 > cited too in the terminology section for completeness. > > - In the terminology section the term "Boundary node (BN) is defined.=20 > However, later on, the term "border node" is also used, presumably as=20 > an synonym. I suggest either choose one term for the whole document or = > include the term border node too in the terminology. > > - Section 3. The sentence "A sub-tree is a part of the P2MP tree=20 > describing how the root or an intermediate P2MP LSPs minimizes packet=20 > duplication when P2P TE sub-LSPs traverse common links" is hard to=20 > understand (maybe there is a typo and it should say "the root of an=20 > intermediate P2P LSP"). > > - The term P2P TE sub-LSP is used in section 3. TE sub-LSP is defined=20 > in RFC 4661. Maybe it should be worth adding the sub-LSP terms it to=20 > the terminology section. > > - In section 4 the term "sequence of domains" is also used to refer to = > the path domain tree. This introduces confusion, as there is also a=20 > "domain sequence" term which applies only to P2P. Please use always=20 > "path domain tree" > > -Section 4, 2nd paragraph, "domain path tree", use the term "path=20 > domain tree" defined in the terminology section. > > - Section 4, figure 1 legend is "Domain sequence tree". This term is=20 > not defined in the terminology. I would prefer to stick to the term=20 > "Path Domain tree". Sorry to be picky about the terminology, but=20 > reading the document is hard when the terms are mixed as they are very = > alike=85. > > - Section 4, assumptions, first bullet. Where it says " each of the=20 > P2MP destination" it should day "each of the P2MP destinations". > > Section 4, assumption 1, "or PCE sequence (i.e. PCE that serves each=20 > domain in the path domain tree)". I don't get this point=85. Initially = > it was stated that the path domain tree is known. In this point, is it = > suggested an alternative to knowing the path domain tree? That is,=20 > instead of assuming that the path domain tree is known, what is known=20 > is a set of PCEs? Please clarify > > Section 4, assumption 1, How is the set of PCEs and their=20 > relationships exchanged? What are the relationships that need to be=20 > exchanged? > > Section 4, assumptions, I guess, there is an (maybe obvious)=20 > assumptions that the association domain - PCE is known in advance. > > Sesction 4, assumption 4. "The boundary nodes to use on the LSP are=20 > pre-determined". Does this mean then that both the path domain tree=20 > AND the boundary nodes are known in advance for each possible P2MP=20 > combination? > > At this point there is something I miss=85 Later, in section 7, it is=20 > mentioned that a core tree is computed. However, it seems from the=20 > assumptions that the core tree is fixed in advance=85 Maybe I am=20 > mis-interpreting the assumptions=85 Please clarify the assumptions of=20 > what is really pre-determined and what is computed. > > Section 5. requirement 4. I suggest using better "PCReq and PCEReq=20 > messages" using the terminology of RFC 5440. > > Section 5. The requirements from 5 to 8 are not written like=20 > requirements. I suggest re-writing them with requirements language. > > Section 6. Objective function 3. The definition of the core tree in=20 > the terminology section considers ONLY entry boundary nodes as leaves. > However, it seems here both entry and exit BNs are considered. Please=20 > clarify=85 (maybe it should be mentioned only BNs without distinction=20 > among entry or exit). > > Section 6. Objective function 3 is about limiting the number of entry=20 > points to a domain. Why would there be more that one entry point to a=20 > domain? I would expect multiple exit points (that is, several boundary = > nodes to exit to other domains in the tree). Also, given that, by the=20 > assumptions in section 4, the path domain tree AND the boundary nodes=20 > are flxed, I do not know if this objective function has any impact at=20 > all=85. > > In any case, limiting the number of entry points may an additional=20 > constraint to the previous objective functions=85 It seems more a = metric=20 > constraint rather than an objective function.. > > Also, is it considered that several of this objective functions can be = > applied or combined? > > Section 6, objective function 4=85 I don't get that one=85 could you=20 > clarify it? > > Section 7.1 The sentence "An optimal core-tree [based on the OF] will=20 > be computed with analyzing the nodes and links within the domains" > sounds a bit strange=85 maybe the "with" is not needed in the = sentence?=20 > Also.. Previously it was mentioned that the core-tree was formed only=20 > considering entry and exit nodes, but now, it seems that the core-tree = > is obtained taking into account the whole set of nodes and links=85=20 > Please clarify here (or clarify objective function 2 where it says=20 > "formed by considering only the entry and exit nodes"=85) > > - Section 7.3 When mentioning the request with the C bit set I suggest = > adding "(defined later in section 7.4.1 of this document)", as it is a = > new flag=85 > > - Section 7.4.2. I guess "domain-sequence" is really the domain = tree=85=20 > One question=85 the PCE sequence=85 is a PCE tree? > > And that's all :-) I hope the comments can be useful to improve the=20 > readability of the draft. > > Best Regards, > > Oscar > > ---------------------------------------------------------------------- > -- > > > Este mensaje se dirige exclusivamente a su destinatario. Puede=20 > consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico=20 > en el enlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send=20 > and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From ina@juniper.net Sat Jul 6 10:48:20 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF10D21F9C86 for ; Sat, 6 Jul 2013 10:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDePpuOEd3tJ for ; Sat, 6 Jul 2013 10:48:15 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id DF97721F9C85 for ; Sat, 6 Jul 2013 10:48:14 -0700 (PDT) Received: from mail152-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Sat, 6 Jul 2013 17:48:13 +0000 Received: from mail152-va3 (localhost [127.0.0.1]) by mail152-va3-R.bigfish.com (Postfix) with ESMTP id B45894A0173 for ; Sat, 6 Jul 2013 17:48:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz9371I542I13fcI1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail152-va3: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=ina@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail152-va3 (localhost.localdomain [127.0.0.1]) by mail152-va3 (MessageSwitch) id 1373132891533439_1258; Sat, 6 Jul 2013 17:48:11 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.252]) by mail152-va3.bigfish.com (Postfix) with ESMTP id 7D9AAC0047 for ; Sat, 6 Jul 2013 17:48:11 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 6 Jul 2013 17:48:07 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 6 Jul 2013 10:48:06 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Sat, 6 Jul 2013 10:48:05 -0700 Received: from CH1EHSOBE020.bigfish.com (216.32.181.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 6 Jul 2013 11:00:50 -0700 Received: from mail193-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.22; Sat, 6 Jul 2013 17:48:04 +0000 Received: from mail193-ch1 (localhost [127.0.0.1]) by mail193-ch1-R.bigfish.com (Postfix) with ESMTP id 764584039C for ; Sat, 6 Jul 2013 17:48:04 +0000 (UTC) Received: from mail193-ch1 (localhost.localdomain [127.0.0.1]) by mail193-ch1 (MessageSwitch) id 1373132883133904_5227; Sat, 6 Jul 2013 17:48:03 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail193-ch1.bigfish.com (Postfix) with ESMTP id 13196C01D2; Sat, 6 Jul 2013 17:48:03 +0000 (UTC) Received: from BLUPRD0511HT003.namprd05.prod.outlook.com (157.56.232.213) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 6 Jul 2013 17:48:03 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.186]) by BLUPRD0511HT003.namprd05.prod.outlook.com ([10.255.135.166]) with mapi id 14.16.0324.000; Sat, 6 Jul 2013 17:48:02 +0000 From: Ina Minei To: "Zafar Ali (zali)" , "Margaria, Cyril (NSN - DE/Munich)" , "draft-ali-pce-remote-initiated-gmpls-lsp@tools.ietf.org" , "pce@ietf.org" Thread-Topic: Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00 Thread-Index: Ac4QKL6jmYErbjKLSeWghMsqzYggPwObOLuADPVyDoAJmA7FAABpIb9g Date: Sat, 6 Jul 2013 17:48:01 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3037FB8D5@BLUPRD0511MB436.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NSN.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [Pce] Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 17:48:21 -0000 Dear Zafar,=20 Version 02 of draft-crabbe-pce-pce-initiated-lsp is in final review and wil= l be posted on Thursday next week and will address the comments received so= far on draft-crabbe. Please advise which comments on draft-ietf-pce-stateful-pce are not address= ed in version 05 which was posted last week, this will help improve version= 06.=20 Thank you,=20 Ina=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Zafar= Ali (zali) Sent: Thursday, July 04, 2013 7:32 AM To: Zafar Ali (zali); Margaria, Cyril (NSN - DE/Munich); draft-ali-pce-remo= te-initiated-gmpls-lsp@tools.ietf.org; pce@ietf.org Subject: Re: [Pce] Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00 Hi Margaria, authors of draft-crabbe-pce-pce-initiated-lsp and stateful PCE= drafts: I followed up on comments from Margaria that we received on draft-ali-pce-r= emote-initiated-gmpls-lsp-00. However, we did not receive any response from= authors of draft-crabbe-pce-pce-initiated-lsp and stateful PCE drafts to c= lose on Margaria's comments. Please advise. Thanks Regards ... Zafar -----Original Message----- From: zali Date: Thursday, May 16, 2013 2:27 PM To: "cyril.margaria@nsn.com" , "draft-ali-pce-remot= e-initiated-gmpls-lsp@tools.ietf.org" , "pce@ietf.org" Subject: Re: Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00 Resent-From: Resent-To: , , Oscar de Dios , VICTOR ALVAREZ , zali Resent-Date: Thursday, May 16, 2013 2:27 PM > >-----Original Message----- >From: zali >Date: Monday, March 11, 2013 3:18 PM >To: "cyril.margaria@nsn.com" ,=20 >"draft-ali-pce-remote-initiated-gmpls-lsp@tools.ietf.org" >, "pce@ietf.org" > >Subject: Re: Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00 > >>>I think the document has good material, but address several separated=20 >>>points : >>>1. Active Stateful PCE Applicability >>>2. MPLS multi-layer aspects >>>3. GMPLS (GENERALIZED-BW and SWITCH-LAYER) >>> >>>I think the second point may have a document on its own, but the=20 >>>first and third point could be managed by merges. >> >>Like mentioned above, we are open to document rearrangement(s), if it=20 >>simplify the process. At the moment this work is outside the scope of=20 >>WG charter. I am sure in due time we will have more of such discussion=20 >>and opinion from the WG. There are example where WG liked to keep=20 >>GMPLS extensions separate from (packet) MPLS work. > >Hi Margaria- > >Now that this is a chartered item, let's close on your comments. > >We will update the document based on your comments received under this=20 >thread. However, document restructuring also requires agreement from=20 >authors/ drivers for the other drafts. > >- (3) in above require merger of related text to=20 >draft-crabbe-pce-pce-initiated-lsp. >- (1) requires merger to stateful PCE draft. > >Let's use this email to solicit feedback for authors of these draft if=20 >they agree to the merge. I am fine, either-way but have a feeling that=20 >separate document may remain a reality. > >Thanks > >Regards =A9 Zafar > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From ramon.casellas@cttc.es Mon Jul 8 02:58:24 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713CB11E819F for ; Mon, 8 Jul 2013 02:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.599, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH+CfOOXsGv8 for ; Mon, 8 Jul 2013 02:58:23 -0700 (PDT) Received: from rudy.puc.rediris.es (rudy.puc.rediris.es [IPv6:2001:720:418:ca01::132]) by ietfa.amsl.com (Postfix) with ESMTP id 45DE111E819D for ; Mon, 8 Jul 2013 02:58:22 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by rudy.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Uw8D6-0001hD-Jf for pce@ietf.org; Mon, 08 Jul 2013 11:58:20 +0200 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 2ABEF1FD41 for ; Mon, 8 Jul 2013 11:58:17 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <51DA8D3D.307@cttc.es> Date: Mon, 08 Jul 2013 11:58:21 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: pce@ietf.org References: <20130708093637.6172.33780.idtracker@ietfa.amsl.com> In-Reply-To: <20130708093637.6172.33780.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130708093637.6172.33780.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090403080609060907060506" X-Spamina-Bogosity: Ham Subject: [Pce] Fwd: New Version Notification for draft-cmfg-pce-pcep-grammar-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 09:58:24 -0000 This is a multi-part message in MIME format. --------------090403080609060907060506 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, "Encouraged" by our beloved WG co-chair Julien ;-) we have submitted a new I-D that discusses the issues that we have recently mentioned in the list, concerning the implementation of a set of PCEP extensions and the problems we have identified (such as Errata, object ordering and naming issues, lack of consistency, ambiguous grammars, etc.). Although the final objective would be to facilitate interoperability and to clarify the integration of independent normative documents by publishing an informational document, right now our main goal is to document the identified issues in published RFCs (and other also relevant drafts), and to clearly state the motivations behind this work. We have requested a 5 min slot to present them to the working group and to get feedback about WG potential interest. Note that, although there are already some suggestions within the document, our intention is to include get feedback by other implementors and work towards an agreement about the suggested RBNF notation. Feedback and comments welcome, Thanks and best regards Ramon of behalf of authors and contributors. -------- Mensaje original -------- Asunto: New Version Notification for draft-cmfg-pce-pcep-grammar-00.txt Fecha: Mon, 08 Jul 2013 02:36:37 -0700 De: internet-drafts@ietf.org Para: Adrian Farrel , Oscar Gonzalez de Dios , Cyril Margaria , Ramon Casellas A new version of I-D, draft-cmfg-pce-pcep-grammar-00.txt has been successfully submitted by Ramon Casellas and posted to the IETF repository. Filename: draft-cmfg-pce-pcep-grammar Revision: 00 Title: Current issues with existing RBNF notation for PCEP messages and extensions Creation date: 2013-07-08 Group: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-cmfg-pce-pcep-grammar-00.txt Status: http://datatracker.ietf.org/doc/draft-cmfg-pce-pcep-grammar Htmlized: http://tools.ietf.org/html/draft-cmfg-pce-pcep-grammar-00 Abstract: The PCEP protocol has been defined in [RFC5440] and later extended in several RFCs. This document aims at documenting inconsistencies when implementing a set of extensions and at providing a reference, complete and formal RBNF grammar for PCEP messages, including object ordering and precedence rules. The IETF Secretariat --------------090403080609060907060506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

"Encouraged" by our beloved WG co-chair Julien ;-) we have submitted a new I-D that discusses the issues that we have recently mentioned in the list, concerning the implementation of a set of PCEP extensions and the problems we have identified (such as Errata, object ordering and naming issues, lack of consistency, ambiguous grammars, etc.).

Although the final objective would be to facilitate interoperability and to clarify the integration of independent normative documents by publishing an informational document, right now our main goal is to document the identified issues in published RFCs (and other also relevant drafts), and to clearly state the motivations behind this work. We have requested a 5 min slot to present them to the working group and to get feedback about WG potential interest.

Note that, although there are already some suggestions within the document, our intention is to include get feedback by other implementors and work towards an agreement about the suggested RBNF notation.

Feedback and comments welcome,

Thanks and best regards
Ramon of behalf of authors and contributors.




-------- Mensaje original --------
Asunto: New Version Notification for draft-cmfg-pce-pcep-grammar-00.txt
Fecha: Mon, 08 Jul 2013 02:36:37 -0700
De: internet-drafts@ietf.org
Para: Adrian Farrel <adrian@olddog.co.uk>, Oscar Gonzalez de Dios <ogondio@tid.es>, Cyril Margaria <cyril.margaria@coriant.com>, Ramon Casellas <ramon.casellas@cttc.es> 


A new version of I-D, draft-cmfg-pce-pcep-grammar-00.txt
has been successfully submitted by Ramon Casellas and posted to the
IETF repository.

Filename:	 draft-cmfg-pce-pcep-grammar
Revision:	 00
Title:		 Current issues with existing RBNF notation for PCEP messages and extensions
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-cmfg-pce-pcep-grammar-00.txt
Status:          http://datatracker.ietf.org/doc/draft-cmfg-pce-pcep-grammar
Htmlized:        http://tools.ietf.org/html/draft-cmfg-pce-pcep-grammar-00


Abstract:
   The PCEP protocol has been defined in [RFC5440] and later extended in
   several RFCs.  This document aims at documenting inconsistencies when
   implementing a set of extensions and at providing a reference,
   complete and formal RBNF grammar for PCEP messages, including object
   ordering and precedence rules.

                                                                                  


The IETF Secretariat


--------------090403080609060907060506-- From zhang.xian@huawei.com Mon Jul 8 02:59:10 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E334311E819D for ; Mon, 8 Jul 2013 02:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zWEUCgu91-T for ; Mon, 8 Jul 2013 02:59:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 24ADF21F9EAD for ; Mon, 8 Jul 2013 02:59:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUT95366; Mon, 08 Jul 2013 09:59:04 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Jul 2013 10:58:35 +0100 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Jul 2013 10:58:50 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.176]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.007; Mon, 8 Jul 2013 17:58:36 +0800 From: "Zhangxian (Xian)" To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt Thread-Index: AQHOewbjfOhnk9ImH0mWsaFL9Wr7sZlaip8+ Date: Mon, 8 Jul 2013 09:58:36 +0000 Message-ID: References: <20130707114106.19250.97443.idtracker@ietfa.amsl.com> In-Reply-To: <20130707114106.19250.97443.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.78.119] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 09:59:11 -0000 SGksIERlYXIgUENFcnMsIA0KDQogICAgICBXZSBoYXZlIGp1c3QgdXBsb2FkIGEgbmV3IGRyYWZ0 IHNwZWNpZnlpbmcgdGhlIG5lZWQgaW4gUENFUCB0byBhbGxvdyBpbmNyZW1lbnRhbCBMU1Agc3Rh dGUgc3luY2hyb25pemF0aW9uIGFzIHdlbGwgYXMgUENFIGNvbnRyb2wgb3ZlciB0aGlzIHByb2Nl c3MgZm9yIHN0YXRlZnVsIFBDRShzKS4gIEl0IGFsc28gcHJvcG9zZXMgUENFUCBleHRlbnNpb25z IHRvIHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50cy4gICANCg0KICAgICAgIEFueSBjb21tZW50cy9m ZWVkYmFjayBhcmUgYXBwcmVjaWF0ZWQuIA0KDQpSZWdhcmRzLA0KWGlhbiAoIG9uIGJlaGFsZiBv ZiBhbGwgYXV0aG9ycykNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2ludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10NCreiy83KsbzkOiAyMDEzxOo31MI3yNUgMTk6NDENCrW9OiBaaGFuZ3hpYW4gKFhpYW4p OyBYaWVnYW5nIChBKTsgRGhydXYgRGhvZHkNCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0wMC50eHQNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXpoeC1wY2Utc3RhdGVmdWwtbHNwLXN5bmMtMDAudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW4gWmhhbmcgYW5kIHBvc3RlZCB0byB0 aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC16aHgtcGNlLXN0 YXRlZnVsLWxzcC1zeW5jDQpSZXZpc2lvbjogICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgIExT UCBTeW5jaHJvbml6YXRpb24gZm9yIFN0YXRlZnVsIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAo UENFKQ0KQ3JlYXRpb24gZGF0ZTogICAyMDEzLTA3LTA1DQpHcm91cDogICAgICAgICAgIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3DQpVUkw6ICAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpoeC1wY2Utc3RhdGVmdWwt bHNwLXN5bmMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYw0KSHRtbGl6ZWQ6ICAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1z eW5jLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IENv bW11bmljYXRpb24gUHJvdG9jb2wgKFBDRVApIHByb3ZpZGVzDQogICBtZWNoYW5pc21zIGZvciBQ YXRoIENvbXB1dGF0aW9uIEVsZW1lbnRzIChQQ0VzKSB0byBwZXJmb3JtIHBhdGgNCiAgIGNvbXB1 dGF0aW9ucyBpbiByZXNwb25zZSB0byBQYXRoIENvbXB1dGF0aW9uIENsaWVudHMgKFBDQ3MpIHJl cXVlc3RzLg0KDQogICBbU3RhdGVmdWwtcGNlcF0gc3BlY2lmaWVzIGEgc2V0IG9mIGV4dGVuc2lv bnMgdG8gUENFUCB0byBlbmFibGUNCiAgIHN0YXRlZnVsIGNvbnRyb2wgb2YgTVBMUy1URSBhbmQg R01QTFMgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExTUHMpIHZpYQ0KICAgUENFUCBhbmQgbWFpbnRh aW5pbmcgb2YgdGhlc2UgTFNQcyBhdCB0aGUgc3RhdGVmdWwgUENFLiAgVGhpcw0KICAgZG9jdW1l bnQgZGVzY3JpYmVzIHRoZSBtZWNoYW5pc21zIGZvciBpbmNyZW1lbnRhbCBMU1AgRGF0YWJhc2Ug KExTUC0NCiAgIERCKSBzeW5jaHJvbml6YXRpb24gYXMgd2VsbCBhcyBQQ0UgY29udHJvbCBvZiB0 aGUgTFNQLURCDQogICBzeW5jaHJvbml6YXRpb24gcHJvY2Vzcy4NCg0KDQoNCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQ= From cyril.margaria@coriant.com Mon Jul 8 05:34:43 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887DD11E81D1 for ; Mon, 8 Jul 2013 05:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5XUUbMGPoFr for ; Mon, 8 Jul 2013 05:34:37 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id EB64811E81DC for ; Mon, 8 Jul 2013 05:34:36 -0700 (PDT) Received: from mail171-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE034.bigfish.com (10.243.66.99) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 12:34:30 +0000 Received: from mail171-co1 (localhost [127.0.0.1]) by mail171-co1-R.bigfish.com (Postfix) with ESMTP id 6F2A4B4013C; Mon, 8 Jul 2013 12:34:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT002.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic89bhc85dh31c5Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1d7338h1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail171-co1: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT002.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail171-co1 (localhost.localdomain [127.0.0.1]) by mail171-co1 (MessageSwitch) id 137328686899077_27513; Mon, 8 Jul 2013 12:34:28 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.229]) by mail171-co1.bigfish.com (Postfix) with ESMTP id 12D12D00075; Mon, 8 Jul 2013 12:34:28 +0000 (UTC) Received: from DB3PRD0411HT002.eurprd04.prod.outlook.com (157.56.253.53) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 12:34:26 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.9]) by DB3PRD0411HT002.eurprd04.prod.outlook.com ([10.255.73.37]) with mapi id 14.16.0329.000; Mon, 8 Jul 2013 12:34:12 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: Ina Minei , "JP Vasseur (jvasseur)" , Julien Meuric , "pce@ietf.org" Thread-Topic: Stateful PCE applicability Thread-Index: Ac5umsBOKlGLSPblRyS/lSkmK90b9QNOWaFA Date: Mon, 8 Jul 2013 12:34:11 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D09EB9C@DB3PRD0411MB427.eurprd04.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.159.77.167] Content-Type: multipart/alternative; boundary="_000_523C37072C291347B9730C9291CCA07D09EB9CDB3PRD0411MB427eu_" MIME-Version: 1.0 X-OriginatorOrg: coriant.com Subject: Re: [Pce] Stateful PCE applicability X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:34:43 -0000 --_000_523C37072C291347B9730C9291CCA07D09EB9CDB3PRD0411MB427eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Yes we need an applicability document. draft-zhang-pce-stateful-pce-app is addressing this, but there are some par= ts that could be improved: Section 4.3 : This is a drawback of the stateful PCE, this could be stated= as follows : A staful PCE requires an LSP-DB synchronization, which cause an addition de= lay or synchronization issues, thus impacting negatively the survivability = of a PCE. . In my opinion a statfull PCE could mitigate that by acting as stateless unt= il this synchronization has been done. Section 5: maybe describing some use case not solved by a stateful PCE woul= d be useful, or which additional constraints this add For instance having an active stateful add another controller in the networ= k, it may not always sit well with existing NMS or network architecture, ye= t they would benefit from the passive stateful. Section 5 : it would be usefull to indicate which scenario requires an acti= ve stateful, For instance section several use cases can be solved using both, an active = stateful can fix the problem afterwards, a passive stateful could solve it = beforehand (if the planned services are known), So cases (for instance 5.4.2 or 5.4.3) can be solved using passive stateful= PCE only, which would not present the same implication for deployement. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ina M= inei Sent: Friday, June 21, 2013 6:17 PM To: JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org Subject: [Pce] Stateful PCE applicability Dear chairs and working group, In light of the recent working group re-charter which now includes stateful= PCE, we wanted to hear the opinions of the group on 1. the need for an applicability document for stateful PCE and 2. whether draft-zhang-pce-stateful-pce-app satisfies this need, or a= ny gaps it might have Thank you, Ina and Xian --_000_523C37072C291347B9730C9291CCA07D09EB9CDB3PRD0411MB427eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Yes we need an applicabil= ity document.

draft-zhang-pce-stateful-= pce-app is addressing this, but there are some parts that could be improved= :

 <= /p>

Section 4.3 :  This = is a drawback of the stateful PCE, this could be stated as follows :

 <= /p>

A staful PCE requires an = LSP-DB synchronization, which cause an addition delay or synchronization is= sues, thus impacting negatively the survivability of a PCE. .

 <= /p>

In my opinion a statfull = PCE could mitigate that by acting as stateless until this synchronization h= as been done.

 <= /p>

Section 5: maybe describi= ng some use case not solved by a stateful PCE would be useful, or which add= itional constraints this add

For instance having an ac= tive stateful add another controller in the network, it may not always sit = well with existing NMS or network architecture, yet they would benefit from the passive stateful.

 <= /p>

Section 5 : it would be u= sefull to indicate which scenario requires an active stateful,

For instance section seve= ral use cases can be solved using both, an active stateful can fix the prob= lem afterwards, a passive stateful could solve it beforehand (if the planned services are known),

 <= /p>

So cases (for instance 5.= 4.2 or 5.4.3) can be solved using passive stateful PCE only, which would no= t present the same implication for deployement.

 <= /p>

 <= /p>

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: pce-boun= ces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ina Minei
Sent: Friday, June 21, 2013 6:17 PM
To: JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org
Subject: [Pce] Stateful PCE applicability

 

Dear chairs and working group,

 

In light of the recent working group re= -charter which now includes stateful PCE, we wanted to hear the opinions of= the group on

 

1.    &nb= sp;  the need for an applicability d= ocument for stateful PCE and

 

2.    &nb= sp;  whether draft-zhang-pce-statefu= l-pce-app satisfies this need, or any gaps it might have<= /p>

 

Thank you,

 

Ina and Xian

 

--_000_523C37072C291347B9730C9291CCA07D09EB9CDB3PRD0411MB427eu_-- From dhruv.ietf@gmail.com Mon Jul 8 07:26:17 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB73621F9A5B for ; Mon, 8 Jul 2013 07:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMgPCnhzI86X for ; Mon, 8 Jul 2013 07:26:17 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0425121F9B7F for ; Mon, 8 Jul 2013 07:25:30 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so10108595iec.33 for ; Mon, 08 Jul 2013 07:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=LaMr7Hp/7v/LM6YlTUo0oExM2YYjXWO3DvjND59DDzI=; b=XYRCf52Ld7H9KMKAFVN/n6RzTAafwMUg4qluaZCUZX8b7qcCuxFg/vc3gotEzE6S9/ 2CfNsKWobWsFtJBCzz719ncAg75BS2vMi2KxjfX5zLz2HKAAStqOvrTEpL9OMnEQACoV HjF53i4l+VeZf3WD3wqYL5aycMLFEnc4wMBZ/XgS85l9zcbvb9uGAOAFB2UWdvgLSyDT smswo58jE0qj1sZ8euqY9qDlLJhs9s/QVWtsmf0Mj2sXLhHsae76rgBLDfOaBPxUyBUu Cg7KMvuSy8F+Kwetwyv+aPiRhNZmp41EGrVeRTnXc0L1j1X/sUK4eibhix+C/AS9Bhb8 X0VQ== MIME-Version: 1.0 X-Received: by 10.50.66.210 with SMTP id h18mr13411551igt.19.1373293530512; Mon, 08 Jul 2013 07:25:30 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.152.176 with HTTP; Mon, 8 Jul 2013 07:25:30 -0700 (PDT) In-Reply-To: <51d6f38c.055a420a.19b9.ffffa101SMTPIN_ADDED_BROKEN@mx.google.com> References: <51d6f38c.055a420a.19b9.ffffa101SMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 8 Jul 2013 19:55:30 +0530 X-Google-Sender-Auth: 7wPcdjIWpWuhI47PRGwldFNjAy8 Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdca4680f025e04e100d108 Subject: [Pce] Fwd: FW: New Version Notification for draft-palle-pce-stateful-pce-lspdb-sync-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:26:18 -0000 --047d7bdca4680f025e04e100d108 Content-Type: text/plain; charset=ISO-8859-1 Hi, We have published a new draft that describes LSP-DB synchronization between stateful PCEs including - Primary and Backup stateful PCE - Load-Balanced stateful PCE Comments and questions are always welcome. Dhruv (on behalf of co-authors and contributors) > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, July 05, 2013 3:22 PM > To: Xian Zhang; Udayasree Palle; Dhruv Dhody > Subject: New Version Notification for draft-palle-pce-stateful-pce-lspdb- > sync-00.txt > > > A new version of I-D, draft-palle-pce-stateful-pce-lspdb-sync-00.txt > has been successfully submitted by Udayasree Palle and posted to the > IETF repository. > > Filename: draft-palle-pce-stateful-pce-lspdb-sync > Revision: 00 > Title: LSP-DB Synchronization between Stateful PCEs > Creation date: 2013-07-05 > Group: Individual Submission > Number of pages: 12 > URL: http://www.ietf.org/internet-drafts/draft-palle-pce-stateful-pce-lspdb-sync-00.txt > Status: http://datatracker.ietf.org/doc/draft-palle-pce-stateful-pce-lspdb-sync > Htmlized: http://tools.ietf.org/html/draft-palle-pce-stateful-pce-lspdb-sync-00 > > > Abstract: > The Path Computation Element Communication Protocol (PCEP) provides > mechanisms for Path Computation Elements (PCEs) to perform path > computations in response to Path Computation Clients (PCCs) requests. > > [STATEFUL-PCE] specifies a set of extensions to PCEP to enable > stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via > PCEP and maintaining of these LSPs at the stateful PCE. This > document describes the mechanisms of LSP Database (LSP-DB) > synchronization between stateful PCEs. > > > > > The IETF Secretariat --047d7bdca4680f025e04e100d108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0

We have published a new draft that=A0describes LSP-DB synch= ronization between stateful PCEs including
- Primary and Backup stateful PCE
- Load-Balanced statef= ul PCE

Comments and questions are always welcome.=A0

Dhruv (on behalf of co-authors and=A0contributors= )

> = -----Original Message-----
> From: in= ternet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Friday, July 05, 2013 3:22 PM
> To: Xian Zhang; Udayasree Palle; Dhruv Dhody
> Subject: New Version Notification for draft-palle-pce-stateful-pce-lsp= db-
> sync-00.txt
>
>
> A new version of I-D, draft-palle-pce-stateful-pce-lspdb-sync-00.txt > has been successfully submitted by Udayasree Palle and posted to the > IETF repository.
>
> Filename: =A0 =A0 =A0draft-palle-pce-stateful-pce-lspdb-sync
> Revision: =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LSP-DB Synchronization between = Stateful PCEs
> Creation date: =A0 =A0 =A0 =A0 2013-07-05
> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 12
> URL: =A0 =A0 =A0 =A0 =A0 =A0 htt= p://www.ietf.org/internet-drafts/draft-palle-pce-stateful-pce-lspdb-sync-00= .txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatrack= er.ietf.org/doc/draft-palle-pce-stateful-pce-lspdb-sync
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.or= g/html/draft-palle-pce-stateful-pce-lspdb-sync-00
>
>
> Abstract:
> =A0 =A0The Path Computation Element Communication Protocol (PCEP) prov= ides
> =A0 =A0mechanisms for Path Computation Elements (PCEs) to perform path=
> =A0 =A0computations in response to Path Computation Clients (PCCs) req= uests.
>
> =A0 =A0[STATEFUL-PCE] specifies a set of extensions to PCEP to enable<= br> > =A0 =A0stateful control of MPLS-TE and GMPLS Label Switched Paths (LSP= s) via
> =A0 =A0PCEP and maintaining of these LSPs at the stateful PCE. =A0This=
> =A0 =A0document describes the mechanisms of LSP Database (LSP-DB)
> =A0 =A0synchronization between stateful PCEs.
>
>
>
>
> The IETF Secretariat


--047d7bdca4680f025e04e100d108-- From dhruv.ietf@gmail.com Mon Jul 8 07:26:38 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C4221F991E for ; Mon, 8 Jul 2013 07:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taAXZUfurDeO for ; Mon, 8 Jul 2013 07:26:37 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9975D21F9A40 for ; Mon, 8 Jul 2013 07:26:13 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so10236253iej.1 for ; Mon, 08 Jul 2013 07:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=6c1L0TBh7V9zSXwZDdHDM6tPYk9teIGXkDwnWN+mMck=; b=JP4XehnQOuVXd1npfvP3wiFNX1FhCuwBhtULhKHx6SzYi6WAoZSRd2BKiRdCgT+g1q LeQFGydhHeJ6Fqkvuy3XKIXv4mChcsinGq586KtBG4XgdClxK1AKEkPxsZo/LukCFDr4 mh3qv8lsNP1uPz4fICKx6l73ADU9a6ldS1ldv4yNJwq3gsplJsm+Wi8x77nRV5SH27UB TgwMuH19SbZ7qwyPn7nx5aSBfDvLf7Um8QJFkJaFcKoyir/xzRm0/m5IUbeeARVI3clv P/Mgco7JfvdOzXbao2d9p3FujCFUPOU3ulfNYc7/Wl9VBjnw86XFvR5SBLqzd3s6YOno w7Sg== MIME-Version: 1.0 X-Received: by 10.50.32.70 with SMTP id g6mr33225855igi.2.1373293573189; Mon, 08 Jul 2013 07:26:13 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.152.176 with HTTP; Mon, 8 Jul 2013 07:26:13 -0700 (PDT) In-Reply-To: <20130705040734.6485.38423.idtracker@ietfa.amsl.com> References: <20130705040734.6485.38423.idtracker@ietfa.amsl.com> Date: Mon, 8 Jul 2013 19:56:13 +0530 X-Google-Sender-Auth: cILhiwsCQaDOsXxz5pC564OAKwE Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=047d7b10ca559a37f204e100d328 Subject: [Pce] Fwd: New Version Notification for draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:26:38 -0000 --047d7b10ca559a37f204e100d328 Content-Type: text/plain; charset=ISO-8859-1 Hi, Here is an update on the automatic bandwidth adjustment draft for stateful PCE which allows the bandwidth adjustment of delegated LSP based on traffic flow information collected via the PCEP protocol itself. Comments and questions are always welcome. Dhruv (on behalf of co-authors and contributors) ---------- Forwarded message ---------- From: Date: Fri, Jul 5, 2013 at 9:37 AM Subject: New Version Notification for draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt To: Dhruv Dhody , Dhruv Dhody , Udayasree Palle A new version of I-D, draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Filename: draft-dhody-pce-stateful-pce-auto-bandwidth Revision: 01 Title: PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with stateful PCE Creation date: 2013-07-04 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt Status: http://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidth Htmlized: http://tools.ietf.org/html/draft-dhody-pce-stateful-pce-auto-bandwidth-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-pce-stateful-pce-auto-bandwidth-01 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The extensions described in [STATEFUL-PCE] provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the automatic bandwidth adjustment of such LSPs under the stateful PCE model. The IETF Secretariat --047d7b10ca559a37f204e100d328 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0

Here is an update on the=A0automatic bandwidth adjustment=A0draft = for stateful PCE which allows the bandwidth adjustment of delegated LSP bas= ed on traffic flow information collected via the PCEP protocol itself.=A0

Comments and questions are always welcome.=A0

Dhruv (on behalf of co-authors and=A0contributors)<= /font>


---------- Forwarded message ------= ----
From: <internet-drafts@i= etf.org>
Date: Fri, Jul 5, 2013 at 9:37 AM
Subject: New Version Notification for = draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt
To: Dhruv Dhody <<= a href=3D"mailto:dhruv.dhody@huawei.com" target=3D"_blank">dhruv.dhody@huaw= ei.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, Udayasree Palle <udayasree.palle@huawe= i.com>



A new version of I-D, draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt has been successfully submitted by Dhruv Dhody and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dhody-pce-stateful-pce-auto-bandwidth
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 PCEP Extensions for MPLS-TE LSP Automatic Bandwi= dth Adjustment with stateful PCE
Creation date: =A0 2013-07-04
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 11
URL: =A0 =A0 =A0 =A0 =A0 =A0 http= ://www.ietf.org/internet-drafts/draft-dhody-pce-stateful-pce-auto-bandwidth= -01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidth
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-dhody-pce-stateful-pce-auto-bandwidth-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://ww= w.ietf.org/rfcdiff?url2=3Ddraft-dhody-pce-stateful-pce-auto-bandwidth-01

Abstract:
=A0 =A0The Path Computation Element Communication Protocol (PCEP) provides<= br> =A0 =A0mechanisms for Path Computation Elements (PCEs) to perform path
=A0 =A0computations in response to Path Computation Clients (PCCs) requests= .
=A0 =A0The extensions described in [STATEFUL-PCE] provide stateful control<= br> =A0 =A0of Multiprotocol Label Switching (MPLS) Traffic Engineering Label =A0 =A0Switched Paths (TE LSP) via PCEP, for a model where the PCC delegate= s
=A0 =A0control over one or more locally configured LSPs to the PCE.

=A0 =A0This document describes the automatic bandwidth adjustment of such =A0 =A0LSPs under the stateful PCE model.




The IETF Secretariat


--047d7b10ca559a37f204e100d328-- From dhruv.ietf@gmail.com Mon Jul 8 07:26:42 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8997821F8F09 for ; Mon, 8 Jul 2013 07:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJSkJOaiAgbl for ; Mon, 8 Jul 2013 07:26:41 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id A11B221F9A5B for ; Mon, 8 Jul 2013 07:26:31 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so10251330iec.13 for ; Mon, 08 Jul 2013 07:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=pM+6Dl30W2BkZEkH8fCxmF7zQjMFhnIUoQu2XK8SgpA=; b=RlOnMxiEog6tjOMEcwNzXnXxO6MNkomUiH4MWFCX7c3+rswspPYsoQ9/AVi+V7eifH 0yu63W1pRZLzADTSMk0NamdMBHAxDTsBjkhlWYGP2ejk2SpLpFC0AJE+BFNOHfBYhIJg hFGWhMOAd15AS0tzEBYHyK97pQHDsHBLPGNNbnJyRUDpk1xWDjswdz8F4y5AJkSCXbHe 7znxLy7jErhZskDcHBqxWWH6NUiy5SoUDwB10tM+QhYjx3igaIxRcQH81+Z1lGeAl/Ci ARfzadpvmdyEGr9KDq9az7ECcRYAL1OVg+5KQmutlruPIey2DcsaOH7JtN8viffJJnCl s7cg== MIME-Version: 1.0 X-Received: by 10.43.141.206 with SMTP id jf14mr7529130icc.8.1373293591198; Mon, 08 Jul 2013 07:26:31 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.152.176 with HTTP; Mon, 8 Jul 2013 07:26:31 -0700 (PDT) In-Reply-To: <20130704114327.7819.30408.idtracker@ietfa.amsl.com> References: <20130704114327.7819.30408.idtracker@ietfa.amsl.com> Date: Mon, 8 Jul 2013 19:56:31 +0530 X-Google-Sender-Auth: 6ULaB3P877C4myQpOhbiOYls-UM Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2d478ad005704e100d4ee Subject: [Pce] Fwd: New Version Notification for draft-dhody-pce-pcep-pathkey-mib-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:26:42 -0000 --001a11c2d478ad005704e100d4ee Content-Type: text/plain; charset=ISO-8859-1 Hi, Here is an update to the Path-Key MIB document which has now been aligned to the base PCE-MIB. Comments and questions are always welcome. Dhruv (on behalf of co-authors) ---------- Forwarded message ---------- From: Date: Thu, Jul 4, 2013 at 5:13 PM Subject: New Version Notification for draft-dhody-pce-pcep-pathkey-mib-05.txt To: Dhruv Dhody , Quintin Zhao < quintin.zhao@huawei.com>, Daniel King , Udayasree Palle , Dhruv Dhody A new version of I-D, draft-dhody-pce-pcep-pathkey-mib-05.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Filename: draft-dhody-pce-pcep-pathkey-mib Revision: 05 Title: Management Information Base (MIB) for the PCE Communications Protocol (PCEP) for Path-Key based Confidentiality in Inter-Domain Path Computation. Creation date: 2013-07-04 Group: Individual Submission Number of pages: 22 URL: http://www.ietf.org/internet-drafts/draft-dhody-pce-pcep-pathkey-mib-05.txt Status: http://datatracker.ietf.org/doc/draft-dhody-pce-pcep-pathkey-mib Htmlized: http://tools.ietf.org/html/draft-dhody-pce-pcep-pathkey-mib-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhody-pce-pcep-pathkey-mib-05 Abstract: This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element communication Protocol (PCEP)for communications between a Path Computation Client (PCC)and a Path Computation Element (PCE), or between two PCEs when path-key- based confidentiality in inter-domain path computation is requested. The IETF Secretariat --001a11c2d478ad005704e100d4ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0

Here is an update to the Path-Ke= y MIB document which has now been aligned to the base PCE-MIB.=A0

Comments and questio= ns are always welcome.=A0

Dhruv (on behalf of co-authors)
=
---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
Date: Thu, Jul 4, 2013 at 5:13 PM
Subject: New Version Notification for = draft-dhody-pce-pcep-pathkey-mib-05.txt
To: Dhruv Dhody <dhruv.ietf@gmail.com>,= Quintin Zhao <quintin.zhao@huawei.com>, Daniel King <daniel@olddog.co.uk>, Udayasree P= alle <ud= ayasree.palle@huawei.com>, Dhruv Dhody <dhruv.dhody@huawei.com>



A new version of I-D, draft-dhody-pce-pcep-pathkey-mib-05.txt
has been successfully submitted by Dhruv Dhody and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dhody-pce-pcep-pathkey-mib
Revision: =A0 =A0 =A0 =A005
Title: =A0 =A0 =A0 =A0 =A0 Management Information Base (MIB) for the PCE Co= mmunications Protocol (PCEP) for Path-Key based Confidentiality in Inter-Do= main Path Computation.
Creation date: =A0 2013-07-04
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 22
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf= .org/internet-drafts/draft-dhody-pce-pcep-pathkey-mib-05.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/= doc/draft-dhody-pce-pcep-pathkey-mib
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft= -dhody-pce-pcep-pathkey-mib-05
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/= rfcdiff?url2=3Ddraft-dhody-pce-pcep-pathkey-mib-05

Abstract:
=A0 =A0This memo defines an experimental portion of the Management
=A0 =A0Information Base (MIB) for use with network management protocols in<= br> =A0 =A0the Internet community. =A0In particular, it describes managed objec= ts
=A0 =A0for modeling of the Path Computation Element communication Protocol<= br> =A0 =A0(PCEP)for communications between a Path Computation Client (PCC)and = a
=A0 =A0Path Computation Element (PCE), or between two PCEs when path-key- =A0 =A0based confidentiality in inter-domain path computation is requested.=




The IETF Secretariat


--001a11c2d478ad005704e100d4ee-- From ina@juniper.net Mon Jul 8 12:48:56 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FBF21F9C90 for ; Mon, 8 Jul 2013 12:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.822 X-Spam-Level: X-Spam-Status: No, score=0.822 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkJ4z1Rn-S7R for ; Mon, 8 Jul 2013 12:48:50 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8D73321F9C70 for ; Mon, 8 Jul 2013 12:48:50 -0700 (PDT) Received: from mail15-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE007.bigfish.com (10.236.130.70) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:48:50 +0000 Received: from mail15-co9 (localhost [127.0.0.1]) by mail15-co9-R.bigfish.com (Postfix) with ESMTP id 379CC2A01CD for ; Mon, 8 Jul 2013 19:48:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VPS-33(zz9371Ic89bh936eI542Ia65Rzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h941hd25hf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail15-co9: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=ina@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail15-co9 (localhost.localdomain [127.0.0.1]) by mail15-co9 (MessageSwitch) id 1373312927713350_31656; Mon, 8 Jul 2013 19:48:47 +0000 (UTC) Received: from CO9EHSMHS029.bigfish.com (unknown [10.236.132.242]) by mail15-co9.bigfish.com (Postfix) with ESMTP id AAFAC201D1 for ; Mon, 8 Jul 2013 19:48:47 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.54) by CO9EHSMHS029.bigfish.com (10.236.130.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 19:48:46 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Jul 2013 12:48:45 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 8 Jul 2013 12:48:45 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Jul 2013 12:52:19 -0700 Received: from mail20-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE019.bigfish.com (10.243.66.82) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:48:32 +0000 Received: from mail20-co1 (localhost [127.0.0.1]) by mail20-co1-R.bigfish.com (Postfix) with ESMTP id 2E791C4012A for ; Mon, 8 Jul 2013 19:48:32 +0000 (UTC) Received: from mail20-co1 (localhost.localdomain [127.0.0.1]) by mail20-co1 (MessageSwitch) id 1373312910163788_10443; Mon, 8 Jul 2013 19:48:30 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.253]) by mail20-co1.bigfish.com (Postfix) with ESMTP id 2482E800071; Mon, 8 Jul 2013 19:48:30 +0000 (UTC) Received: from BLUPRD0511HT003.namprd05.prod.outlook.com (157.56.232.213) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 19:48:29 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.186]) by BLUPRD0511HT003.namprd05.prod.outlook.com ([10.255.135.166]) with mapi id 14.16.0324.000; Mon, 8 Jul 2013 19:48:25 +0000 From: Ina Minei To: "Zhangxian (Xian)" , "pce@ietf.org" Thread-Topic: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt Thread-Index: AQHOewbjfOhnk9ImH0mWsaFL9Wr7sZlaip8+gACnKAA= Date: Mon, 8 Jul 2013 19:48:25 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3037FCB05@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <20130707114106.19250.97443.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 19:48:56 -0000 T25lIG1pbm9yIGNvbW1lbnQgZm9yIHRob3NlIG9mIHlvdSB3aG8gbWlnaHQgYmUgcmV2aWV3aW5n IHRoaXMgZHJhZnQsIHBsZWFzZSBiZSBhd2FyZSB0aGF0IA0KUGNlLXRyaWdnZXJlZCBzeW5jIGlz IGFsc28gY292ZXJlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBj ZS1zdGF0ZWZ1bC1wY2UtMDUjc2VjdGlvbi01LjUuNCAodGhvdWdoIHRoZSBlbnRpcmUgZGF0YWJh c2UgaXMgZXhjaGFuZ2VkIGluIHRoYXQgY2FzZSkuDQoNCkluYSANCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IHBjZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGNlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBaaGFuZ3hpYW4gKFhpYW4pDQpTZW50OiBNb25kYXks IEp1bHkgMDgsIDIwMTMgMjo1OSBBTQ0KVG86IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogW1BjZV0g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1s c3Atc3luYy0wMC50eHQNCg0KSGksIERlYXIgUENFcnMsIA0KDQogICAgICBXZSBoYXZlIGp1c3Qg dXBsb2FkIGEgbmV3IGRyYWZ0IHNwZWNpZnlpbmcgdGhlIG5lZWQgaW4gUENFUCB0byBhbGxvdyBp bmNyZW1lbnRhbCBMU1Agc3RhdGUgc3luY2hyb25pemF0aW9uIGFzIHdlbGwgYXMgUENFIGNvbnRy b2wgb3ZlciB0aGlzIHByb2Nlc3MgZm9yIHN0YXRlZnVsIFBDRShzKS4gIEl0IGFsc28gcHJvcG9z ZXMgUENFUCBleHRlbnNpb25zIHRvIHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50cy4gICANCg0KICAg ICAgIEFueSBjb21tZW50cy9mZWVkYmFjayBhcmUgYXBwcmVjaWF0ZWQuIA0KDQpSZWdhcmRzLA0K WGlhbiAoIG9uIGJlaGFsZiBvZiBhbGwgYXV0aG9ycykNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2lu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCreiy83KsbzkOiAyMDEzxOo31MI3yNUgMTk6NDENCrW9 OiBaaGFuZ3hpYW4gKFhpYW4pOyBYaWVnYW5nIChBKTsgRGhydXYgRGhvZHkNCtb3zOI6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0w MC50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoeC1wY2Utc3RhdGVmdWwtbHNw LXN5bmMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW4gWmhh bmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAg IGRyYWZ0LXpoeC1wY2Utc3RhdGVmdWwtbHNwLXN5bmMNClJldmlzaW9uOiAgICAgICAgMDANClRp dGxlOiAgICAgICAgICAgTFNQIFN5bmNocm9uaXphdGlvbiBmb3IgU3RhdGVmdWwgUGF0aCBDb21w dXRhdGlvbiBFbGVtZW50IChQQ0UpDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTMtMDctMDUNCkdyb3Vw OiAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDcNClVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt emh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5j DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoeC1w Y2Utc3RhdGVmdWwtbHNwLXN5bmMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoZSBQYXRoIENvbXB1 dGF0aW9uIEVsZW1lbnQgQ29tbXVuaWNhdGlvbiBQcm90b2NvbCAoUENFUCkgcHJvdmlkZXMNCiAg IG1lY2hhbmlzbXMgZm9yIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudHMgKFBDRXMpIHRvIHBlcmZv cm0gcGF0aA0KICAgY29tcHV0YXRpb25zIGluIHJlc3BvbnNlIHRvIFBhdGggQ29tcHV0YXRpb24g Q2xpZW50cyAoUENDcykgcmVxdWVzdHMuDQoNCiAgIFtTdGF0ZWZ1bC1wY2VwXSBzcGVjaWZpZXMg YSBzZXQgb2YgZXh0ZW5zaW9ucyB0byBQQ0VQIHRvIGVuYWJsZQ0KICAgc3RhdGVmdWwgY29udHJv bCBvZiBNUExTLVRFIGFuZCBHTVBMUyBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcykgdmlhDQog ICBQQ0VQIGFuZCBtYWludGFpbmluZyBvZiB0aGVzZSBMU1BzIGF0IHRoZSBzdGF0ZWZ1bCBQQ0Uu ICBUaGlzDQogICBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG1lY2hhbmlzbXMgZm9yIGluY3JlbWVu dGFsIExTUCBEYXRhYmFzZSAoTFNQLQ0KICAgREIpIHN5bmNocm9uaXphdGlvbiBhcyB3ZWxsIGFz IFBDRSBjb250cm9sIG9mIHRoZSBMU1AtREINCiAgIHN5bmNocm9uaXphdGlvbiBwcm9jZXNzLg0K DQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClBjZSBtYWlsaW5nIGxpc3QNClBjZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg== From Jonathan.Hardwick@metaswitch.com Mon Jul 8 13:51:59 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE22821F9DDC for ; Mon, 8 Jul 2013 13:51:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zgsp64DWGkv for ; Mon, 8 Jul 2013 13:51:53 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id D329E21F9E17 for ; Mon, 8 Jul 2013 13:51:52 -0700 (PDT) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 8 Jul 2013 21:51:43 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%19]) with mapi id 14.02.0342.003; Mon, 8 Jul 2013 21:51:49 +0100 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: Stateful PCE applicability Thread-Index: AQHObyFDJgXNfL1E2Ua4cIjIQL9O4plbTuNA Date: Mon, 8 Jul 2013 20:51:48 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBEB3@ENFICSMBX1.datcon.co.uk> References: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A77235C3D6B@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77235C3D6B@xmb-rcd-x02.cisco.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.161] Content-Type: multipart/alternative; boundary="_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBEB3ENFICSMBX1datco_" MIME-Version: 1.0 Subject: Re: [Pce] Stateful PCE applicability X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:51:59 -0000 --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBEB3ENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that we do need an applicability draft for stateful PCE. Here are = some initial comments on draft-zhang-pce-stateful-pce-app-04. This draft is a good starting point for discussing the applicability of sta= teful PCE and covers a good set of use cases. Should this draft get adopted by the WG at some later stage, I think the de= finitions of "active stateful", "passive stateful" should be moved to here = rather than in draft-ietf-pce-stateful-pce, along with the use cases. The draft abstract should also mention that this draft discusses the limita= tions of stateful PCEs. Section 2: The definition of minimum cut-set is wrong, because it states th= at the smallest set of links is the cut set. Change "the minimum set of li= nks" to "the set of links with minimum capacity" and the definition is corr= ect. Section 4.1 on coexistence. I wonder if you think that more than one activ= e, stateful PCE can coexist in the same network? Would you need to partiti= on the controlled PCCs between them? How would you keep their LSP database= s synchronized with each other? Section 4.2. This section might be the best place for a discussion of the = limitations of the stateful PCE's TE and LSP databases. Each of them lags = behind the true state of the network, the amount of lag being determined by= the channels by which the network updates the TE and LSP databases. Thus = use of a stateful PCE reduces but does not eliminate the possibility of cra= nkbacks, for example, and does not allow you to reach 100% utilization in a= dynamic network (although it undoubtedly would improve network utilization= in most scenarios). I think it is important to explain these limitations = and the reasons for them, otherwise people might get the wrong impression t= hat the stateful PCE is a perfect tool. As well as section 4.3 on survivability, which deals with recovery of the s= tateful PCE, you could also have a section 4.4 on redundancy. That is, mul= tiple stateful PCEs in the network which all provide the same function to a= ll clients should any one of them fail. Section 5.5 - I did not follow why the stateful PCE's interaction with the = VNTM is any different that the stateless PCE. Are section 5.6 and 5.7 significantly different use cases? 5.7 read as a s= pecial case of 5.6. Suggest merging them. Typo spotted in section 5.7 "cam be used" -> "can be used". Regards Jon From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Va= sseur (jvasseur) Sent: 22 June 2013 09:20 To: Ina Minei; pce@ietf.org Subject: Re: [Pce] Stateful PCE applicability Thanks Ina - good question : WG, please voice your opinion Thanks JP. On Jun 21, 2013, at 9:16 AM, Ina Minei wrote: Dear chairs and working group, In light of the recent working group re-charter which now includes stateful= PCE, we wanted to hear the opinions of the group on 1. the need for an applicability document for stateful PCE and 2. whether draft-zhang-pce-stateful-pce-app satisfies this need, or a= ny gaps it might have Thank you, Ina and Xian --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBEB3ENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that we do need a= n applicability draft for stateful PCE.  Here are some initial comment= s on draft-zhang-pce-stateful-pce-app-04.

 <= /p>

This draft is a good star= ting point for discussing the applicability of stateful PCE and covers a go= od set of use cases.

 <= /p>

Should this draft get ado= pted by the WG at some later stage, I think the definitions of “activ= e stateful”, “passive stateful” should be moved to here r= ather than in draft-ietf-pce-stateful-pce, along with the use cases.<= /span>

 <= /p>

The draft abstract should= also mention that this draft discusses the limitations of stateful PCEs.

 <= /p>

Section 2: The definition= of minimum cut-set is wrong, because it states that the smallest set of li= nks is the cut set.  Change “the minimum set of links” to “the set of links with minimum capacity” and the definition is= correct.

 <= /p>

Section 4.1 on coexistenc= e.  I wonder if you think that more than one active, stateful PCE can = coexist in the same network?  Would you need to partition the controlled PCCs between them?  How would you keep their LSP databases= synchronized with each other?

 <= /p>

Section 4.2.  This s= ection might be the best place for a discussion of the limitations of the s= tateful PCE’s TE and LSP databases.  Each of them lags behind the true state of the network, the amount of lag being determined by the c= hannels by which the network updates the TE and LSP databases.  Thus u= se of a stateful PCE reduces but does not eliminate the possibility of cran= kbacks, for example, and does not allow you to reach 100% utilization in a dynamic network (although it undoubtedl= y would improve network utilization in most scenarios).  I think it is= important to explain these limitations and the reasons for them, otherwise= people might get the wrong impression that the stateful PCE is a perfect tool.

 <= /p>

As well as section 4.3 on= survivability, which deals with recovery of the stateful PCE, you could al= so have a section 4.4 on redundancy.  That is, multiple stateful PCEs in the network which all provide the same function to all cl= ients should any one of them fail.

 <= /p>

Section 5.5 – I did= not follow why the stateful PCE’s interaction with the VNTM is any d= ifferent that the stateless PCE.

 <= /p>

Are section 5.6 and 5.7 s= ignificantly different use cases?  5.7 read as a special case of 5.6.&= nbsp; Suggest merging them.

 <= /p>

Typo spotted in section 5= .7 “cam be used” -> “can be used”.

 <= /p>

Regards=

Jon

 <= /p>

 <= /p>

 <= /p>

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 22 June 2013 09:20
To: Ina Minei; pce@ietf.org
Subject: Re: [Pce] Stateful PCE applicability

 

Thanks Ina - good question : WG, please voice your o= pinion 

 

Thanks JP.

 

On Jun 21, 2013, at 9:16 AM, Ina Minei wrote:



Dear chairs and working group,

 

In light of the recent working group re= -charter which now includes stateful PCE, we wanted to hear the opinions of= the group on

 

1.    &nb= sp;  the need for an applicability d= ocument for stateful PCE and

 

2.    &nb= sp;  whether draft-zhang-pce-statefu= l-pce-app satisfies this need, or any gaps it might have<= /p>

 

Thank you,

 

Ina and Xian

 

 

--_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBEB3ENFICSMBX1datco_-- From ina@juniper.net Mon Jul 8 14:27:09 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F3021F9B86 for ; Mon, 8 Jul 2013 14:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkYNCDMZukG3 for ; Mon, 8 Jul 2013 14:27:02 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id E4ABD21F9DF1 for ; Mon, 8 Jul 2013 14:26:55 -0700 (PDT) Received: from mail221-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 21:26:55 +0000 Received: from mail221-va3 (localhost [127.0.0.1]) by mail221-va3-R.bigfish.com (Postfix) with ESMTP id 2127C640110 for ; Mon, 8 Jul 2013 21:26:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz98dI9371I15bfKc85fh1521Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail221-va3: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=ina@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail221-va3 (localhost.localdomain [127.0.0.1]) by mail221-va3 (MessageSwitch) id 137331881256248_31606; Mon, 8 Jul 2013 21:26:52 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.227]) by mail221-va3.bigfish.com (Postfix) with ESMTP id 0086330004C for ; Mon, 8 Jul 2013 21:26:52 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.50) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 21:26:51 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Jul 2013 14:26:50 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 8 Jul 2013 14:26:49 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.207) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Jul 2013 14:30:36 -0700 Received: from mail69-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 21:26:47 +0000 Received: from mail69-am1 (localhost [127.0.0.1]) by mail69-am1-R.bigfish.com (Postfix) with ESMTP id 9E3774E00B0 for ; Mon, 8 Jul 2013 21:26:47 +0000 (UTC) Received: from mail69-am1 (localhost.localdomain [127.0.0.1]) by mail69-am1 (MessageSwitch) id 1373318805296319_5189; Mon, 8 Jul 2013 21:26:45 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.237]) by mail69-am1.bigfish.com (Postfix) with ESMTP id 4375C480046; Mon, 8 Jul 2013 21:26:45 +0000 (UTC) Received: from BLUPRD0511HT005.namprd05.prod.outlook.com (157.56.232.213) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 8 Jul 2013 21:26:44 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.186]) by BLUPRD0511HT005.namprd05.prod.outlook.com ([10.255.135.168]) with mapi id 14.16.0324.000; Mon, 8 Jul 2013 21:26:40 +0000 From: Ina Minei To: Jonathan Hardwick , "pce@ietf.org" Thread-Topic: Stateful PCE applicability Thread-Index: Ac5umsBOKlGLSPblRyS/lSkmK90b9QAhoLCAAz7s6AAAAEZJQA== Date: Mon, 8 Jul 2013 21:26:39 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3037FCC3B@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> <03B78081B371D44390ED6E7BADBB4A77235C3D6B@xmb-rcd-x02.cisco.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBEB3@ENFICSMBX1.datcon.co.uk> In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBEB3@ENFICSMBX1.datcon.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: multipart/alternative; boundary="_000_70BDAD02381BA54CA31315A2A26A7AD3037FCC3BBLUPRD0511MB436_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%METASWITCH.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [Pce] Stateful PCE applicability X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:27:09 -0000 --_000_70BDAD02381BA54CA31315A2A26A7AD3037FCC3BBLUPRD0511MB436_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jon, Thank you for the thoughtful comments, please see inline ###. Ina From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Monday, July 08, 2013 1:52 PM To: pce@ietf.org Cc: Ina Minei; JP Vasseur (jvasseur) Subject: RE: Stateful PCE applicability I agree that we do need an applicability draft for stateful PCE. Here are = some initial comments on draft-zhang-pce-stateful-pce-app-04. This draft is a good starting point for discussing the applicability of sta= teful PCE and covers a good set of use cases. Should this draft get adopted by the WG at some later stage, I think the de= finitions of "active stateful", "passive stateful" should be moved to here = rather than in draft-ietf-pce-stateful-pce, along with the use cases. ### Agreed, the use cases are still in draft-ietf-pce-stateful-pce to avoid= loss of information. I think repeating the definitions of active stateful/= passive stateful is worthwhile. The draft abstract should also mention that this draft discusses the limita= tions of stateful PCEs. ### Agreed. Section 2: The definition of minimum cut-set is wrong, because it states th= at the smallest set of links is the cut set. Change "the minimum set of li= nks" to "the set of links with minimum capacity" and the definition is corr= ect. ### We already have a thread offline with you on this, will resolve and add= to the new version. Section 4.1 on coexistence. I wonder if you think that more than one activ= e, stateful PCE can coexist in the same network? Would you need to partiti= on the controlled PCCs between them? How would you keep their LSP database= s synchronized with each other? ### Yes, they can, however an LSP is only ever delegated to a single PCE. = One option is to have sessions to both PCEs, another option is to synchroni= ze the databases between the PCEs. Adrian's open question draft discusses s= ome of these options, I don't think we need to discuss them again here, but= definitely we can add text to at least refer to the other document. Secti= on 4.1 was mostly focusing on co-existence of different pce types. Section 4.2. This section might be the best place for a discussion of the = limitations of the stateful PCE's TE and LSP databases. Each of them lags = behind the true state of the network, the amount of lag being determined by= the channels by which the network updates the TE and LSP databases. Thus = use of a stateful PCE reduces but does not eliminate the possibility of cra= nkbacks, for example, and does not allow you to reach 100% utilization in a= dynamic network (although it undoubtedly would improve network utilization= in most scenarios). I think it is important to explain these limitations = and the reasons for them, otherwise people might get the wrong impression t= hat the stateful PCE is a perfect tool. ### Fair enough :), will add in the next version As well as section 4.3 on survivability, which deals with recovery of the s= tateful PCE, you could also have a section 4.4 on redundancy. That is, mul= tiple stateful PCEs in the network which all provide the same function to a= ll clients should any one of them fail. ### will add in the next version Section 5.5 - I did not follow why the stateful PCE's interaction with the = VNTM is any different that the stateless PCE. ### Agree with you that the text needs to be clarified, will work with the = co-authors. In the meantime, if you have any text suggestions, they are wel= come :) Are section 5.6 and 5.7 significantly different use cases? 5.7 read as a s= pecial case of 5.6. Suggest merging them. ### I would prefer to keep optical and packet use cases separate. While I a= gree with you that one may argue they are in the same problem space, I thin= k it is easier for the reader to see them as separate. Typo spotted in section 5.7 "cam be used" -> "can be used". ### will fix. Regards Jon From: pce-bounces@ietf.org [mailto:pce-bounces= @ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: 22 June 2013 09:20 To: Ina Minei; pce@ietf.org Subject: Re: [Pce] Stateful PCE applicability Thanks Ina - good question : WG, please voice your opinion Thanks JP. On Jun 21, 2013, at 9:16 AM, Ina Minei wrote: Dear chairs and working group, In light of the recent working group re-charter which now includes stateful= PCE, we wanted to hear the opinions of the group on 1. the need for an applicability document for stateful PCE and 2. whether draft-zhang-pce-stateful-pce-app satisfies this need, or an= y gaps it might have Thank you, Ina and Xian --_000_70BDAD02381BA54CA31315A2A26A7AD3037FCC3BBLUPRD0511MB436_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jon,

 <= /p>

Thank you for the thought= ful comments, please see inline ###.

 <= /p>

Ina

 <= /p>

From: Jonathan= Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Monday, July 08, 2013 1:52 PM
To: pce@ietf.org
Cc: Ina Minei; JP Vasseur (jvasseur)
Subject: RE: Stateful PCE applicability

 

I agree th= at we do need an applicability draft for stateful PCE.  Here are some = initial comments on draft-zhang-pce-stateful-pce-app-04.<= /p>

 = ;

This draft= is a good starting point for discussing the applicability of stateful PCE = and covers a good set of use cases.

 = ;

Should thi= s draft get adopted by the WG at some later stage, I think the definitions = of “active stateful”, “passive stateful” should be = moved to here rather than in draft-ietf-pce-stateful-pce, along with the use cases.=

### Agreed= , the use cases are still in draft-ietf-pce-stateful-pce to avoid loss of i= nformation. I think repeating the definitions of active stateful/passive stateful is worthwhile.

 = ;

The draft = abstract should also mention that this draft discusses the limitations of s= tateful PCEs.

### Agreed= .

 = ;

Section 2:= The definition of minimum cut-set is wrong, because it states that the sma= llest set of links is the cut set.  Change “the minimum set of links” to “the set of links with minimum capacity” an= d the definition is correct.

### We alr= eady have a thread offline with you on this, will resolve and add to the ne= w version.

 = ;

Section 4.= 1 on coexistence.  I wonder if you think that more than one active, st= ateful PCE can coexist in the same network?  Would you need to partition the controlled PCCs between them?  How would you keep their= LSP databases synchronized with each other?

### Yes, t= hey can, however an LSP is only ever delegated to a single PCE.  One o= ption is to have sessions to both PCEs, another option is to synchronize the databases between the PCEs. Adrian’s open question draft discuss= es some of these options, I don’t think we need to discuss them again= here, but definitely we can add text to at least refer to the other docume= nt.  Section 4.1 was mostly focusing on co-existence of different pce types.

 = ;

Section 4.= 2.  This section might be the best place for a discussion of the limit= ations of the stateful PCE’s TE and LSP databases.  Each of them lags behind the true state of the network, the amount of lag being determi= ned by the channels by which the network updates the TE and LSP databases.&= nbsp; Thus use of a stateful PCE reduces but does not eliminate the possibi= lity of crankbacks, for example, and does not allow you to reach 100% utilization in a dynamic network (althoug= h it undoubtedly would improve network utilization in most scenarios). = ; I think it is important to explain these limitations and the reasons for = them, otherwise people might get the wrong impression that the stateful PCE is a perfect tool.

### Fair e= nough J, will ad= d in the next version

 = ;

As well as= section 4.3 on survivability, which deals with recovery of the stateful PC= E, you could also have a section 4.4 on redundancy.  That is, multiple stateful PCEs in the network which all provide the same funct= ion to all clients should any one of them fail.

### will a= dd in the next version

 = ;

Section 5.= 5 – I did not follow why the stateful PCE’s interaction with th= e VNTM is any different that the stateless PCE.

### Agree = with you that the text needs to be clarified, will work with the co-authors= . In the meantime, if you have any text suggestions, they are welcome J

 = ;

 = ;

Are sectio= n 5.6 and 5.7 significantly different use cases?  5.7 read as a specia= l case of 5.6.  Suggest merging them.

### I woul= d prefer to keep optical and packet use cases separate. While I agree with = you that one may argue they are in the same problem space, I think it is easier for the reader to see them as separate.

 = ;

Typo spott= ed in section 5.7 “cam be used” -> “can be used”= .

### will f= ix.

 = ;

Regards

Jon

 = ;

 = ;

 = ;

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur)
Sent: 22 June 2013 09:20
To: Ina Minei; pce@ietf.org
Subject: Re: [Pce] Stateful PCE applicability

 

Thanks Ina - good question : WG= , please voice your opinion 

 

Thanks JP.

 

On Jun 21, 2013, at 9:16 AM, In= a Minei wrote:

=  

Dear chairs and working = group,

 =

In light of the recent w= orking group re-charter which now includes stateful PCE, we wanted to hear = the opinions of the group on

 =

1.  =     the need for an = applicability document for stateful PCE and

 =

2.  =     whether draft-zh= ang-pce-stateful-pce-app satisfies this need, or any gaps it might have

 =

Thank you,

 =

Ina and Xian<= /span>

 =

 

--_000_70BDAD02381BA54CA31315A2A26A7AD3037FCC3BBLUPRD0511MB436_-- From ina@juniper.net Mon Jul 8 14:44:50 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C5321F9E48 for ; Mon, 8 Jul 2013 14:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tpmt4Nd2aQvx for ; Mon, 8 Jul 2013 14:44:43 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7234D21F9E44 for ; Mon, 8 Jul 2013 14:44:43 -0700 (PDT) Received: from mail72-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 21:44:42 +0000 Received: from mail72-ch1 (localhost [127.0.0.1]) by mail72-ch1-R.bigfish.com (Postfix) with ESMTP id 65CA860131 for ; Mon, 8 Jul 2013 21:44:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371Ic89bhc85dh31c5I1521Idb82hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail72-ch1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=ina@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail72-ch1 (localhost.localdomain [127.0.0.1]) by mail72-ch1 (MessageSwitch) id 1373319880991556_7587; Mon, 8 Jul 2013 21:44:40 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail72-ch1.bigfish.com (Postfix) with ESMTP id E44572E005B for ; Mon, 8 Jul 2013 21:44:40 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 21:44:40 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Jul 2013 14:44:40 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 8 Jul 2013 14:44:39 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Jul 2013 14:48:24 -0700 Received: from mail87-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 21:44:36 +0000 Received: from mail87-ch1 (localhost [127.0.0.1]) by mail87-ch1-R.bigfish.com (Postfix) with ESMTP id B3DF64800DA for ; Mon, 8 Jul 2013 21:44:36 +0000 (UTC) Received: from mail87-ch1 (localhost.localdomain [127.0.0.1]) by mail87-ch1 (MessageSwitch) id 1373319875215391_29886; Mon, 8 Jul 2013 21:44:35 +0000 (UTC) Received: from CH1EHSMHS033.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail87-ch1.bigfish.com (Postfix) with ESMTP id 305D26004F; Mon, 8 Jul 2013 21:44:35 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 21:44:34 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.186]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0324.000; Mon, 8 Jul 2013 21:44:33 +0000 From: Ina Minei To: "Margaria, Cyril (Coriant - DE/Munich)" , "JP Vasseur (jvasseur)" , Julien Meuric , "pce@ietf.org" Thread-Topic: Stateful PCE applicability Thread-Index: Ac5umsBOKlGLSPblRyS/lSkmK90b9QNOWaFAABO0knA= Date: Mon, 8 Jul 2013 21:44:32 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3037FCC8F@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> <523C37072C291347B9730C9291CCA07D09EB9C@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: <523C37072C291347B9730C9291CCA07D09EB9C@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: multipart/alternative; boundary="_000_70BDAD02381BA54CA31315A2A26A7AD3037FCC8FBLUPRD0511MB436_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CORIANT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [Pce] Stateful PCE applicability X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:44:50 -0000 --_000_70BDAD02381BA54CA31315A2A26A7AD3037FCC8FBLUPRD0511MB436_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cyril, Thank you for the very thoughtful comments. Please see inline ###. Ina From: Margaria, Cyril (Coriant - DE/Munich) [mailto:cyril.margaria@coriant.= com] Sent: Monday, July 08, 2013 5:34 AM To: Ina Minei; JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org Subject: RE: Stateful PCE applicability Hi, Yes we need an applicability document. draft-zhang-pce-stateful-pce-app is addressing this, but there are some par= ts that could be improved: Section 4.3 : This is a drawback of the stateful PCE, this could be stated= as follows : A staful PCE requires an LSP-DB synchronization, which cause an addition de= lay or synchronization issues, thus impacting negatively the survivability = of a PCE. . In my opinion a statfull PCE could mitigate that by acting as stateless unt= il this synchronization has been done. ### I agree we should discuss on potential drawbacks. As you have seen, the= re are various proposals (new drafts) submitted to alleviate this. Section 5: maybe describing some use case not solved by a stateful PCE woul= d be useful, or which additional constraints this add ### Discussion on constraints added by a stateful pce deployment is probabl= y something we should consider adding, but I wonder if this shouldn't fit b= etter in section 4 (e.g. discussion on state sync) For instance having an active stateful add another controller in the networ= k, it may not always sit well with existing NMS or network architecture, ye= t they would benefit from the passive stateful. ### Not sure what you mean, maybe you have specific text? Section 5 : it would be usefull to indicate which scenario requires an acti= ve stateful, For instance section several use cases can be solved using both, an active = stateful can fix the problem afterwards, a passive stateful could solve it = beforehand (if the planned services are known), So cases (for instance 5.4.2 or 5.4.3) can be solved using passive stateful= PCE only, which would not present the same implication for deployement. ### The draft doesn't go in a lot of discussion on active and passive, this= was not a goal. I can see the point you are making, will evaluate with th= e co-authors how to address the comment on sections 5.4.2 and 5.4.3 in the = next version. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: pce-bounces@ietf.org [mailto:pce-bounces= @ietf.org] On Behalf Of Ina Minei Sent: Friday, June 21, 2013 6:17 PM To: JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org Subject: [Pce] Stateful PCE applicability Dear chairs and working group, In light of the recent working group re-charter which now includes stateful= PCE, we wanted to hear the opinions of the group on 1. the need for an applicability document for stateful PCE and 2. whether draft-zhang-pce-stateful-pce-app satisfies this need, or an= y gaps it might have Thank you, Ina and Xian --_000_70BDAD02381BA54CA31315A2A26A7AD3037FCC8FBLUPRD0511MB436_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Cyril,

 <= /p>

Thank you for the very th= oughtful comments. Please see inline ###.

 <= /p>

Ina

 <= /p>

From: Margaria= , Cyril (Coriant - DE/Munich) [mailto:cyril.margaria@coriant.com]
Sent: Monday, July 08, 2013 5:34 AM
To: Ina Minei; JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org Subject: RE: Stateful PCE applicability

 

Hi,

 <= /p>

Yes we need an applicabil= ity document.

draft-zhang-pce-stateful-= pce-app is addressing this, but there are some parts that could be improved= :

 <= /p>

Section 4.3 :  This = is a drawback of the stateful PCE, this could be stated as follows :

 <= /p>

A staful PCE requires an = LSP-DB synchronization, which cause an addition delay or synchronization is= sues, thus impacting negatively the survivability of a PCE. .

 <= /p>

In my opinion a statfull = PCE could mitigate that by acting as stateless until this synchronization h= as been done.

### I agree we should dis= cuss on potential drawbacks. As you have seen, there are various proposals = (new drafts) submitted to alleviate this.

 <= /p>

Section 5: maybe describi= ng some use case not solved by a stateful PCE would be useful,

or which additional const= raints this add

### Discussion on constra= ints added by a stateful pce deployment is probably something we should con= sider adding, but I wonder if this shouldn’t fit better in section 4 (e.g. discussion on state sync)

For instance having an ac= tive stateful add another controller in the network, it may not always sit = well with existing NMS or network architecture, yet they would benefit from the passive stateful.

### Not sure what you mea= n, maybe you have specific text?

 <= /p>

Section 5 : it would be u= sefull to indicate which scenario requires an active stateful,

For instance section seve= ral use cases can be solved using both, an active stateful can fix the prob= lem afterwards, a passive stateful could solve it beforehand (if the planned services are known),

 <= /p>

So cases (for instance 5.= 4.2 or 5.4.3) can be solved using passive stateful PCE only, which would no= t present the same implication for deployement.

### The draft doesn’= ;t go in a lot of discussion on active and passive, this was not a goal.&nb= sp; I can see the point you are making, will evaluate with the co-authors how to address the comment on sections 5.4.2 and 5.4.3 in the next version= .

 <= /p>

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ina Minei
Sent: Friday, June 21, 2013 6:17 PM
To: JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org
Subject: [Pce] Stateful PCE applicability

 

Dear chairs and working group,

 

In light of the recent working group re= -charter which now includes stateful PCE, we wanted to hear the opinions of= the group on

 

1.    &nb= sp; the need for an applicability d= ocument for stateful PCE and

 

2.    &nb= sp; whether draft-zhang-pce-statefu= l-pce-app satisfies this need, or any gaps it might have<= /p>

 

Thank you,

 

Ina and Xian

 

--_000_70BDAD02381BA54CA31315A2A26A7AD3037FCC8FBLUPRD0511MB436_-- From Jonathan.Hardwick@metaswitch.com Mon Jul 8 14:46:25 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214AB21F9E1A for ; Mon, 8 Jul 2013 14:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[AWL=-2.101, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow2jRXA0lizT for ; Mon, 8 Jul 2013 14:46:21 -0700 (PDT) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 9A63021F9C38 for ; Mon, 8 Jul 2013 14:46:20 -0700 (PDT) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 8 Jul 2013 22:46:09 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%19]) with mapi id 14.02.0342.003; Mon, 8 Jul 2013 22:46:18 +0100 From: Jonathan Hardwick To: "Zhangxian (Xian)" , "draft-zhx-pce-stateful-lsp-sync@tools.ietf.org" Thread-Topic: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt Thread-Index: AQHOewbjfOhnk9ImH0mWsaFL9Wr7sZlaip8+gADBx6A= Date: Mon, 8 Jul 2013 21:46:17 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBF60@ENFICSMBX1.datcon.co.uk> References: <20130707114106.19250.97443.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.161] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:46:25 -0000 SGkgdGhlcmUNCg0KVGhlIGluY3JlbWVudGFsIHN0YXRlIHN5bmNocm9uaXphdGlvbiBtZWNoYW5p c20gbG9va3MgbGlrZSBhIHBvdGVudGlhbGx5IHVzZWZ1bCBvcHRpbWl6YXRpb24uICBJIGhhdmUg YSBmZXcgcXVlc3Rpb25zIGZvciB0aGUgZHJhZnQgYXV0aG9ycy4NCg0KVGhlIG1vdGl2YXRpb24g b2YgdGhlIGluY3JlbWVudGFsIHN5bmNocm9uaXphdGlvbiBtZWNoYW5pc20gaXMgdG8gcmVkdWNl IHRoZSB0aW1lIGFuZCBiYW5kd2lkdGggb2YgdGhlIHN5bmNocm9uaXphdGlvbiBwcm9jZXNzLiAg VGhpcyBpcyBsaWtlbHkgdG8gYmUgdHJ1ZSBpbiBzY2VuYXJpb3Mgd2hlcmUgdGhlIExTUCBkYXRh YmFzZSBpcyBsYXJnZSBhbmQgdGhlIG51bWJlciBvZiBjaGFuZ2VzIHNpbmNlIHRoZSBsYXN0IHN1 Y2Nlc3NmdWwgc3luY2hyb25pemF0aW9uIGlzIHNtYWxsLiAgQ29udmVyc2VseSwgaWYgdGhlIExT UCBkYXRhYmFzZSBpcyBzbWFsbCBhbmQgdGhlIFBDRSBoYXMgdGFrZW4gYSBsb25nIHRpbWUgdG8g cmVjb3ZlciB0aGVuIGl0IG1pZ2h0IGFjdHVhbGx5IGJlIHF1aWNrZXIgdG8gcGVyZm9ybSBhIGZ1 bGwgbWFyay1hbmQtc3dlZXAgc3luY2hyb25pemF0aW9uLg0KDQpJcyB0aGUgaW50ZW50IG9mIHlv dXIgZHJhZnQgdGhhdCB0aGUgUENDIGFuZCBQQ0UgY2FuIGNob29zZSB3aGV0aGVyIHRvIHBlcmZv cm0gYW4gaW5jcmVtZW50YWwgb3IgZnVsbCBzeW5jaHJvbml6YXRpb24gYmFzZWQgb24gaG93IG91 dCBvZiBkYXRlIHRoZSBQQ0UncyBkYXRhYmFzZSBpcz8gIEluIHdoaWNoIGNhc2UsIHdobyBtYWtl cyB0aGUgY2hvaWNlLCB1c2luZyB3aGF0IGNyaXRlcmlhLCBhbmQgaG93IGlzIHRoYXQgY2hvaWNl IG1hZGUga25vd24gdG8gdGhlIG90aGVyIHBhcnR5PyAgT3IgaXMgdGhlIGludGVudCB0aGF0IGlu Y3JlbWVudGFsIHN5bmNocm9uaXphdGlvbiBpcyBhbHdheXMgcHJlZmVycmVkIGlmIGJvdGggcGFy dGllcyBzdXBwb3J0IGl0Pw0KDQpUaGUgaW5jcmVtZW50YWwgc3luY2hyb25pemF0aW9uIHJlbGll cyBvbiB0aGUgUENDIHJlcGxheWluZyB0aGUgbmVjZXNzYXJ5IFBDUnB0IG1lc3NhZ2VzIHRvIHRo ZSBQQ0UgdG8gYnJpbmcgaXQgdXAgdG8gZGF0ZSwgaW5jbHVkaW5nIGFueSB0aGF0IHJlbGF0ZSB0 byBkZWxldGVkIExTUHMuICBEbyB5b3UgaGF2ZSBhbnkgZ3VpZGVsaW5lcyBvbiBob3cgbWFueSBQ Q1JwdHMgdGhlIFBDQyBzaG91bGQgY2FjaGUgYW5kIGZvciBob3cgbG9uZz8gIEhhdmUgeW91IGNv bnNpZGVyZWQgYSBjaGVjay1wb2ludGluZyBtZWNoYW5pc20gd2hlcmUgdGhlIFBDRSBvY2Nhc2lv bmFsbHkgY29uZmlybXMgdGhhdCBpcyBoYXMgYSBwZXJzaXN0ZW50IGNvcHkgb2YgREIgdmVyc2lv biB4IHRvIGF2b2lkIHRoaXMgY2FjaGUgZnJvbSBncm93aW5nIHRvbyBsYXJnZT8NCg0KWW91IG5l ZWQgdG8gZGVhbCB3aXRoIHRoZSBjYXNlIHdoZXJlIGJvdGggUENFIGFuZCBQQ0Mgc2V0IHRoZSBE IGZsYWcgYW5kIHlldCB0aGUgUENDJ3MgY2FjaGUgb2YgUENScHRzIGRvZXMgbm90IGdvIGJhY2sg ZmFyIGVub3VnaCB0byBtYWtlIGFuIGluY3JlbWVudGFsIHN5bmNocm9uaXphdGlvbiBwb3NzaWJs ZS4gIEluIHRoaXMgY2FzZSwgYSBmdWxsIHN5bmNocm9uaXphdGlvbiBpcyBuZWNlc3NhcnkgcmVn YXJkbGVzcyBvZiB0aGUgRCBiaXRzLg0KDQpSZWdhcmRzDQpKb24NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFpoYW5neGlhbiAoWGlhbikNClNlbnQ6IDA4IEp1 bHkgMjAxMyAxMDo1OQ0KVG86IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogW1BjZV0gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0w MC50eHQNCg0KSGksIERlYXIgUENFcnMsIA0KDQogICAgICBXZSBoYXZlIGp1c3QgdXBsb2FkIGEg bmV3IGRyYWZ0IHNwZWNpZnlpbmcgdGhlIG5lZWQgaW4gUENFUCB0byBhbGxvdyBpbmNyZW1lbnRh bCBMU1Agc3RhdGUgc3luY2hyb25pemF0aW9uIGFzIHdlbGwgYXMgUENFIGNvbnRyb2wgb3ZlciB0 aGlzIHByb2Nlc3MgZm9yIHN0YXRlZnVsIFBDRShzKS4gIEl0IGFsc28gcHJvcG9zZXMgUENFUCBl eHRlbnNpb25zIHRvIHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50cy4gICANCg0KICAgICAgIEFueSBj b21tZW50cy9mZWVkYmFjayBhcmUgYXBwcmVjaWF0ZWQuIA0KDQpSZWdhcmRzLA0KWGlhbiAoIG9u IGJlaGFsZiBvZiBhbGwgYXV0aG9ycykNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2ludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10NCreiy83KsbzkOiAyMDEzxOo31MI3yNUgMTk6NDENCrW9OiBaaGFuZ3hp YW4gKFhpYW4pOyBYaWVnYW5nIChBKTsgRGhydXYgRGhvZHkNCtb3zOI6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0wMC50eHQNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoeC1wY2Utc3RhdGVmdWwtbHNwLXN5bmMtMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW4gWmhhbmcgYW5kIHBv c3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC16 aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jDQpSZXZpc2lvbjogICAgICAgIDAwDQpUaXRsZTogICAg ICAgICAgIExTUCBTeW5jaHJvbml6YXRpb24gZm9yIFN0YXRlZnVsIFBhdGggQ29tcHV0YXRpb24g RWxlbWVudCAoUENFKQ0KQ3JlYXRpb24gZGF0ZTogICAyMDEzLTA3LTA1DQpHcm91cDogICAgICAg ICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3DQpVUkw6ICAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpoeC1wY2Ut c3RhdGVmdWwtbHNwLXN5bmMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYw0KSHRtbGl6 ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aHgtcGNlLXN0YXRl ZnVsLWxzcC1zeW5jLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUgUGF0aCBDb21wdXRhdGlvbiBF bGVtZW50IENvbW11bmljYXRpb24gUHJvdG9jb2wgKFBDRVApIHByb3ZpZGVzDQogICBtZWNoYW5p c21zIGZvciBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnRzIChQQ0VzKSB0byBwZXJmb3JtIHBhdGgN CiAgIGNvbXB1dGF0aW9ucyBpbiByZXNwb25zZSB0byBQYXRoIENvbXB1dGF0aW9uIENsaWVudHMg KFBDQ3MpIHJlcXVlc3RzLg0KDQogICBbU3RhdGVmdWwtcGNlcF0gc3BlY2lmaWVzIGEgc2V0IG9m IGV4dGVuc2lvbnMgdG8gUENFUCB0byBlbmFibGUNCiAgIHN0YXRlZnVsIGNvbnRyb2wgb2YgTVBM Uy1URSBhbmQgR01QTFMgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExTUHMpIHZpYQ0KICAgUENFUCBh bmQgbWFpbnRhaW5pbmcgb2YgdGhlc2UgTFNQcyBhdCB0aGUgc3RhdGVmdWwgUENFLiAgVGhpcw0K ICAgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBtZWNoYW5pc21zIGZvciBpbmNyZW1lbnRhbCBMU1Ag RGF0YWJhc2UgKExTUC0NCiAgIERCKSBzeW5jaHJvbml6YXRpb24gYXMgd2VsbCBhcyBQQ0UgY29u dHJvbCBvZiB0aGUgTFNQLURCDQogICBzeW5jaHJvbml6YXRpb24gcHJvY2Vzcy4NCg0KDQoNCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQo= From zhang.xian@huawei.com Tue Jul 9 00:33:35 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E873321F9F59 for ; Tue, 9 Jul 2013 00:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnSRt93LmPaL for ; Tue, 9 Jul 2013 00:33:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6E221F9A1C for ; Tue, 9 Jul 2013 00:33:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUU74824; Tue, 09 Jul 2013 07:33:29 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 9 Jul 2013 08:32:55 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 9 Jul 2013 08:33:24 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.176]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Tue, 9 Jul 2013 15:33:21 +0800 From: "Zhangxian (Xian)" To: Ina Minei Thread-Topic: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt Thread-Index: AQHOewbjfOhnk9ImH0mWsaFL9Wr7sZlaip8+gACnKACAAMKnEw== Date: Tue, 9 Jul 2013 07:33:20 +0000 Message-ID: References: <20130707114106.19250.97443.idtracker@ietfa.amsl.com> , <70BDAD02381BA54CA31315A2A26A7AD3037FCB05@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD3037FCB05@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.93.84] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: Re: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 07:33:36 -0000 SGksIEluYSwgDQoNCiAgICAgWWVzOyB3ZSBhcmUgYXdhcmUgb2YgdGhpcyBhbmQgc28gZnJvbSBw cm90b2NvbCBleHRlbnNpb25zIHBvaW50IG9mIHZpZXcsIHRoaXMgZHJhZnQgZG9lcyBmb2xsb3cg dGhlIHVzZSBvZiByZWxhdGVkIGZsYWdzIGRlZmluZWQgdGhlcmUuIA0KDQogICAgSG93ZXZlciwg dGhlIGludGVudGlvbiBvZiB0aGVzZSB0d28gUENFLXRyaWdnZXJlZCBhY3Rpb24gYXJlIGRpZmZl cmVudC4gSW4gdGhpcyBuZXcgZHJhZnQsIGl0IGFpbXMgdG8gYWxsb3cgdGhlIFBDRSB0byBjb250 cm9sIHRoZSB0aW1pbmcgb2YgTFNQIHN0YXRlIHN5bmNocm9uaXphdGlvbiAoZXZlbiBiZWZvcmUg aXRzIExTUCBEQiBpcyB1cC10by1kYXRlKSBhY3Jvc3MgUENFUCBzZXNzaW9ucy4gV2hpbGUgaW4g ZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTA1IGludGVuZHMgdG8gYWxsb3cgc2FuaXR5IGNo ZWNrIGJ5IFBDRSBhZnRlciB0aGUgc3RhdGVmdWwgUENFIGlzIGZ1bGx5IGZ1bmN0aW9uYWwgKGFr YSB3aXRoIGZ1bGwgTFNQLURCKS4gDQoNCiAgICBXaGF0IGRvIHlvdSB0aGluayBvZiB0aGUgZHJh ZnQgaXRzZWxmPyBEbyB5b3UgdGhpbmsgdGhlIHJlcXVpcmVtZW50cyBhcmUgdmFsaWQ/IA0KDQpS ZWdhcmRzLA0KWGlhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQq3orz+yMs6IEluYSBNaW5laSBbaW5hQGp1bmlwZXIubmV0XQ0Kt6LLzcqxvOQ6IDIwMTPE6jfU wjnI1SAzOjQ4DQq1vTogWmhhbmd4aWFuIChYaWFuKTsgcGNlQGlldGYub3JnDQrW98ziOiBSRTog W1BjZV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemh4LXBjZS1zdGF0 ZWZ1bC1sc3Atc3luYy0wMC50eHQNCg0KT25lIG1pbm9yIGNvbW1lbnQgZm9yIHRob3NlIG9mIHlv dSB3aG8gbWlnaHQgYmUgcmV2aWV3aW5nIHRoaXMgZHJhZnQsIHBsZWFzZSBiZSBhd2FyZSB0aGF0 DQpQY2UtdHJpZ2dlcmVkIHN5bmMgaXMgYWxzbyBjb3ZlcmVkIGluIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS0wNSNzZWN0aW9uLTUuNS40ICh0 aG91Z2ggdGhlIGVudGlyZSBkYXRhYmFzZSBpcyBleGNoYW5nZWQgaW4gdGhhdCBjYXNlKS4NCg0K SW5hDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwY2UtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWmhhbmd4aWFu IChYaWFuKQ0KU2VudDogTW9uZGF5LCBKdWx5IDA4LCAyMDEzIDI6NTkgQU0NClRvOiBwY2VAaWV0 Zi5vcmcNClN1YmplY3Q6IFtQY2VdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXpoeC1wY2Utc3RhdGVmdWwtbHNwLXN5bmMtMDAudHh0DQoNCkhpLCBEZWFyIFBDRXJzLA0K DQogICAgICBXZSBoYXZlIGp1c3QgdXBsb2FkIGEgbmV3IGRyYWZ0IHNwZWNpZnlpbmcgdGhlIG5l ZWQgaW4gUENFUCB0byBhbGxvdyBpbmNyZW1lbnRhbCBMU1Agc3RhdGUgc3luY2hyb25pemF0aW9u IGFzIHdlbGwgYXMgUENFIGNvbnRyb2wgb3ZlciB0aGlzIHByb2Nlc3MgZm9yIHN0YXRlZnVsIFBD RShzKS4gIEl0IGFsc28gcHJvcG9zZXMgUENFUCBleHRlbnNpb25zIHRvIHN1cHBvcnQgdGhlIHJl cXVpcmVtZW50cy4NCg0KICAgICAgIEFueSBjb21tZW50cy9mZWVkYmFjayBhcmUgYXBwcmVjaWF0 ZWQuDQoNClJlZ2FyZHMsDQpYaWFuICggb24gYmVoYWxmIG9mIGFsbCBhdXRob3JzKQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0Kt6LLzcqxvOQ6IDIwMTPE 6jfUwjfI1SAxOTo0MQ0Ktb06IFpoYW5neGlhbiAoWGlhbik7IFhpZWdhbmcgKEEpOyBEaHJ1diBE aG9keQ0K1vfM4jogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aHgtcGNlLXN0 YXRlZnVsLWxzcC1zeW5jLTAwLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtemh4 LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgWGlhbiBaaGFuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN CkZpbGVuYW1lOiAgICAgICAgZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYw0KUmV2aXNp b246ICAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgICBMU1AgU3luY2hyb25pemF0aW9uIGZvciBT dGF0ZWZ1bCBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgKFBDRSkNCkNyZWF0aW9uIGRhdGU6ICAg MjAxMy0wNy0wNQ0KR3JvdXA6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJl ciBvZiBwYWdlczogNw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jLTAwLnR4dA0KU3RhdHVz OiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoeC1wY2Ut c3RhdGVmdWwtbHNwLXN5bmMNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0wMA0KDQoNCkFic3RyYWN0Og0K ICAgVGhlIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCBDb21tdW5pY2F0aW9uIFByb3RvY29sIChQ Q0VQKSBwcm92aWRlcw0KICAgbWVjaGFuaXNtcyBmb3IgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50 cyAoUENFcykgdG8gcGVyZm9ybSBwYXRoDQogICBjb21wdXRhdGlvbnMgaW4gcmVzcG9uc2UgdG8g UGF0aCBDb21wdXRhdGlvbiBDbGllbnRzIChQQ0NzKSByZXF1ZXN0cy4NCg0KICAgW1N0YXRlZnVs LXBjZXBdIHNwZWNpZmllcyBhIHNldCBvZiBleHRlbnNpb25zIHRvIFBDRVAgdG8gZW5hYmxlDQog ICBzdGF0ZWZ1bCBjb250cm9sIG9mIE1QTFMtVEUgYW5kIEdNUExTIExhYmVsIFN3aXRjaGVkIFBh dGhzIChMU1BzKSB2aWENCiAgIFBDRVAgYW5kIG1haW50YWluaW5nIG9mIHRoZXNlIExTUHMgYXQg dGhlIHN0YXRlZnVsIFBDRS4gIFRoaXMNCiAgIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgbWVjaGFu aXNtcyBmb3IgaW5jcmVtZW50YWwgTFNQIERhdGFiYXNlIChMU1AtDQogICBEQikgc3luY2hyb25p emF0aW9uIGFzIHdlbGwgYXMgUENFIGNvbnRyb2wgb2YgdGhlIExTUC1EQg0KICAgc3luY2hyb25p emF0aW9uIHByb2Nlc3MuDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUGNlIG1haWxpbmcgbGlzdA0K UGNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ== From internet-drafts@ietf.org Tue Jul 9 05:01:14 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C8411E8124; Tue, 9 Jul 2013 05:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSwwRAid5wlg; Tue, 9 Jul 2013 05:01:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD7F21F9FAA; Tue, 9 Jul 2013 05:01:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709120113.27692.40586.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 05:01:13 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-service-aware-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 12:01:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : Extensions to the Path Computation Element Communication= Protocol (PCEP) to compute service aware Label Switched Path (LSP). Author(s) : Dhruv Dhody Vishwas Manral Zafar Ali George Swallow Kenji Kumaki Filename : draft-ietf-pce-pcep-service-aware-01.txt Pages : 18 Date : 2013-07-09 Abstract: In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency-Variation (jitter) and Packet Loss is becoming a key requirement for path computation along with other constraints and metrics. Latency, Latency-Variation and Packet Loss is associated with the Service Level Agreement (SLA) between customers and service providers. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with which network performance information is distributed via OSPF and ISIS respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. This document describes the extension to PCEP to carry Latency, Latency-Variation and Loss as constraints for end to end path computation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-service-aware-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-service-aware-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhang.xian@huawei.com Tue Jul 9 06:17:53 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A317E21F9FD5 for ; Tue, 9 Jul 2013 06:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy3X0koDSpFK for ; Tue, 9 Jul 2013 06:17:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BE33011E80E1 for ; Tue, 9 Jul 2013 06:17:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATG74023; Tue, 09 Jul 2013 13:17:43 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 9 Jul 2013 14:17:14 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 9 Jul 2013 14:17:30 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.176]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Tue, 9 Jul 2013 21:17:25 +0800 From: "Zhangxian (Xian)" To: Jonathan Hardwick Thread-Topic: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt Thread-Index: AQHOewbjfOhnk9ImH0mWsaFL9Wr7sZlaip8+gADBx6CAAMDA9Q== Date: Tue, 9 Jul 2013 13:17:24 +0000 Message-ID: References: <20130707114106.19250.97443.idtracker@ietfa.amsl.com> , <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBF60@ENFICSMBX1.datcon.co.uk> In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBF60@ENFICSMBX1.datcon.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.76.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" , "draft-zhx-pce-stateful-lsp-sync@tools.ietf.org" Subject: Re: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:17:53 -0000 SGksIERlYXIgSm9uLCANCg0KICAgIFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSB1c2VmdWwg Y29tbWVudHMuIFBsZWFzZSBzZWUgb3VyIHJlcGx5IGlubGluZSAobG9va2luZyBmb3IgW0FVVEhP UlNdKToNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjL OiBKb25hdGhhbiBIYXJkd2ljayBbSm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb21dDQq3 osvNyrG85DogMjAxM8TqN9TCOcjVIDU6NDYNCrW9OiBaaGFuZ3hpYW4gKFhpYW4pOyBkcmFmdC16 aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jQHRvb2xzLmlldGYub3JnDQpDYzogcGNlQGlldGYub3Jn DQrW98ziOiBSRTogW1BjZV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt emh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0wMC50eHQNCg0KSGkgdGhlcmUNCg0KVGhlIGluY3Jl bWVudGFsIHN0YXRlIHN5bmNocm9uaXphdGlvbiBtZWNoYW5pc20gbG9va3MgbGlrZSBhIHBvdGVu dGlhbGx5IHVzZWZ1bCBvcHRpbWl6YXRpb24uICBJIGhhdmUgYSBmZXcgcXVlc3Rpb25zIGZvciB0 aGUgZHJhZnQgYXV0aG9ycy4NCg0KVGhlIG1vdGl2YXRpb24gb2YgdGhlIGluY3JlbWVudGFsIHN5 bmNocm9uaXphdGlvbiBtZWNoYW5pc20gaXMgdG8gcmVkdWNlIHRoZSB0aW1lIGFuZCBiYW5kd2lk dGggb2YgdGhlIHN5bmNocm9uaXphdGlvbiBwcm9jZXNzLiAgVGhpcyBpcyBsaWtlbHkgdG8gYmUg dHJ1ZSBpbiBzY2VuYXJpb3Mgd2hlcmUgdGhlIExTUCBkYXRhYmFzZSBpcyBsYXJnZSBhbmQgdGhl IG51bWJlciBvZiBjaGFuZ2VzIHNpbmNlIHRoZSBsYXN0IHN1Y2Nlc3NmdWwgc3luY2hyb25pemF0 aW9uIGlzIHNtYWxsLiAgQ29udmVyc2VseSwgaWYgdGhlIExTUCBkYXRhYmFzZSBpcyBzbWFsbCBh bmQgdGhlIFBDRSBoYXMgdGFrZW4gYSBsb25nIHRpbWUgdG8gcmVjb3ZlciB0aGVuIGl0IG1pZ2h0 IGFjdHVhbGx5IGJlIHF1aWNrZXIgdG8gcGVyZm9ybSBhIGZ1bGwgbWFyay1hbmQtc3dlZXAgc3lu Y2hyb25pemF0aW9uLg0KW0FVVEhPUlNdOiBBZ3JlZWQuIA0KDQpJcyB0aGUgaW50ZW50IG9mIHlv dXIgZHJhZnQgdGhhdCB0aGUgUENDIGFuZCBQQ0UgY2FuIGNob29zZSB3aGV0aGVyIHRvIHBlcmZv cm0gYW4gaW5jcmVtZW50YWwgb3IgZnVsbCBzeW5jaHJvbml6YXRpb24gYmFzZWQgb24gaG93IG91 dCBvZiBkYXRlIHRoZSBQQ0UncyBkYXRhYmFzZSBpcz8gIEluIHdoaWNoIGNhc2UsIHdobyBtYWtl cyB0aGUgY2hvaWNlLCB1c2luZyB3aGF0IGNyaXRlcmlhLCBhbmQgaG93IGlzIHRoYXQgY2hvaWNl IG1hZGUga25vd24gdG8gdGhlIG90aGVyIHBhcnR5PyAgT3IgaXMgdGhlIGludGVudCB0aGF0IGlu Y3JlbWVudGFsIHN5bmNocm9uaXphdGlvbiBpcyBhbHdheXMgcHJlZmVycmVkIGlmIGJvdGggcGFy dGllcyBzdXBwb3J0IGl0Pw0KW0FVVEhPUlNdOiAgSW4gdGhlIGN1cnJlbnQgdmVyc2lvbiAnaW5j cmVtZW50YWwgc3luY2hyb25pemF0aW9uJyBpcyBhbHdheXMgcHJlZmVycmVkIGlmIGJvdGggcGFy dGllcyBzdXBwb3J0IGl0LiBEbyB5b3UgZmVlbCBzdHJvbmdseSBpZiB0aGlzIG5lZWRzIGNoYW5n aW5nPw0KDQpUaGUgaW5jcmVtZW50YWwgc3luY2hyb25pemF0aW9uIHJlbGllcyBvbiB0aGUgUEND IHJlcGxheWluZyB0aGUgbmVjZXNzYXJ5IFBDUnB0IG1lc3NhZ2VzIHRvIHRoZSBQQ0UgdG8gYnJp bmcgaXQgdXAgdG8gZGF0ZSwgaW5jbHVkaW5nIGFueSB0aGF0IHJlbGF0ZSB0byBkZWxldGVkIExT UHMuICBEbyB5b3UgaGF2ZSBhbnkgZ3VpZGVsaW5lcyBvbiBob3cgbWFueSBQQ1JwdHMgdGhlIFBD QyBzaG91bGQgY2FjaGUgYW5kIGZvciBob3cgbG9uZz8gIEhhdmUgeW91IGNvbnNpZGVyZWQgYSBj aGVjay1wb2ludGluZyBtZWNoYW5pc20gd2hlcmUgdGhlIFBDRSBvY2Nhc2lvbmFsbHkgY29uZmly bXMgdGhhdCBpcyBoYXMgYSBwZXJzaXN0ZW50IGNvcHkgb2YgREIgdmVyc2lvbiB4IHRvIGF2b2lk IHRoaXMgY2FjaGUgZnJvbSBncm93aW5nIHRvbyBsYXJnZT8NCg0KW0FVVEhPUlNdOiBQQ0MgbmVl ZHMgdG8gY2FjaGUgUENScHRzIG9mIGRlbGV0ZWQgTFNQcyBvbmx5IGlmIHRoZXJlIGV4aXN0IHNv bWUgUENFUCBzZXNzaW9uIHRvIGEgc3RhdGVmdWwgUENFIGEpd2hpY2ggd2FzIHByZXZpb3VzbHkg dXAgYW5kIExTUC1EQiBzeW5jaHJvbml6ZWQsIGJ1dCB0ZW1wb3JhcmlseSBkb3duOyBiKXN1cHBv cnRlZCBMU1AtREItVmVyc2lvbiBUTFYgaW4gUENScHRzIChJREIgZmxhZyB3YXMgc2V0IGluIE9Q RU4pLg0KICANCltBVVRIT1JTXTogQWxzbywgc2F5IHRoZSBEQiB2ZXJzaW9uIHdoZW4gYSBMU1Ag Z2V0cyBkZWxldGVkIGlzIFgsICBUaGUgREIgdmVyc2lvbiBhdCB0aGUgdGltZSBvZiBsYXN0IHN5 bmNocm9uaXphdGlvbiBmb3IgYSAnZG93bicgc2Vzc2lvbiBiZSBEQlYoaSkgd2hlcmUgaT0xIHRv IE4gKE4gdGVtcG9yYXJpbHkgZG93biBzZXNzaW9ucyB3aXRoIGFib3ZlIGNvbmRpdGlvbnMgc2F0 aXNmaWVkKSwgVGhlbiB5b3Ugbm8gbG9uZ2VyIG5lZWQgdG8gY2FjaGUgUENScHRzIG9mIGEgZGVs ZXRlZCBMU1BzIGlmIFggPCBNSU57REJWKGkpLChpPTEuLi5OKX0NCg0KW0FVVEhPUlNdOiBXaGVu ZXZlciBhIGRvd24gc2Vzc2lvbiBjb21lcyB1cCBhbmQgc3RhdGUgaXMgc3luY2hyb25pemVkLCB0 aGUgYWJvdmUgY29uZGl0aW9uIGNhbiBiZSB1c2VkIHRvIGNsZWFyIHRoZSBjYWNoZS4gU2luY2Ug dGhpcyBpcyBhIGxvY2FsIG1lY2hhbmlzbSBvZiBQQ0MsIHNob3VsZCBpdCBiZSBhIHBhcnQgb2Yg dGhlIHNwZWNpZmljYXRpb24/IA0KDQpZb3UgbmVlZCB0byBkZWFsIHdpdGggdGhlIGNhc2Ugd2hl cmUgYm90aCBQQ0UgYW5kIFBDQyBzZXQgdGhlIEQgZmxhZyBhbmQgeWV0IHRoZSBQQ0MncyBjYWNo ZSBvZiBQQ1JwdHMgZG9lcyBub3QgZ28gYmFjayBmYXIgZW5vdWdoIHRvIG1ha2UgYW4gaW5jcmVt ZW50YWwgc3luY2hyb25pemF0aW9uIHBvc3NpYmxlLiAgSW4gdGhpcyBjYXNlLCBhIGZ1bGwgc3lu Y2hyb25pemF0aW9uIGlzIG5lY2Vzc2FyeSByZWdhcmRsZXNzIG9mIHRoZSBEIGJpdHMuDQoNCltB VVRIT1JTXTogT25lIHdheSB0byBkbyB0aGlzIHdvdWxkIGJlIHRvIGhhdmUgYW5vdGhlciBmbGFn IGluIExTUCBvYmplY3QgYWxvbmcgd2l0aCBTWU5DIHRvIGluZGljYXRlIGlmIFBDQyByZXBvcnQg aXMgZm9yIGluY3JlbWVudGFsIHN0YXRlIHN5bmNocm9uaXphdGlvbi4gDQoNCkJlc3QgUmVnYXJk cywNClhpYW4gKG9uIGJlaGFsZiBvZiBhbGwgYXV0aG9ycykNCg0KUmVnYXJkcw0KSm9uDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBjZS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBaaGFuZ3hpYW4gKFhpYW4p DQpTZW50OiAwOCBKdWx5IDIwMTMgMTA6NTkNClRvOiBwY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFtQ Y2VdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpoeC1wY2Utc3RhdGVm dWwtbHNwLXN5bmMtMDAudHh0DQoNCkhpLCBEZWFyIFBDRXJzLA0KDQogICAgICBXZSBoYXZlIGp1 c3QgdXBsb2FkIGEgbmV3IGRyYWZ0IHNwZWNpZnlpbmcgdGhlIG5lZWQgaW4gUENFUCB0byBhbGxv dyBpbmNyZW1lbnRhbCBMU1Agc3RhdGUgc3luY2hyb25pemF0aW9uIGFzIHdlbGwgYXMgUENFIGNv bnRyb2wgb3ZlciB0aGlzIHByb2Nlc3MgZm9yIHN0YXRlZnVsIFBDRShzKS4gIEl0IGFsc28gcHJv cG9zZXMgUENFUCBleHRlbnNpb25zIHRvIHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50cy4NCg0KICAg ICAgIEFueSBjb21tZW50cy9mZWVkYmFjayBhcmUgYXBwcmVjaWF0ZWQuDQoNClJlZ2FyZHMsDQpY aWFuICggb24gYmVoYWxmIG9mIGFsbCBhdXRob3JzKQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0Kt6LLzcqxvOQ6IDIwMTPE6jfUwjfI1SAxOTo0MQ0Ktb06 IFpoYW5neGlhbiAoWGlhbik7IFhpZWdhbmcgKEEpOyBEaHJ1diBEaG9keQ0K1vfM4jogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jLTAw LnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3At c3luYy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhbiBaaGFu ZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAg IGRyYWZ0LXpoeC1wY2Utc3RhdGVmdWwtbHNwLXN5bmMNClJldmlzaW9uOiAgICAgICAgMDANClRp dGxlOiAgICAgICAgICAgTFNQIFN5bmNocm9uaXphdGlvbiBmb3IgU3RhdGVmdWwgUGF0aCBDb21w dXRhdGlvbiBFbGVtZW50IChQQ0UpDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTMtMDctMDUNCkdyb3Vw OiAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDcNClVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt emh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5j DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoeC1w Y2Utc3RhdGVmdWwtbHNwLXN5bmMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoZSBQYXRoIENvbXB1 dGF0aW9uIEVsZW1lbnQgQ29tbXVuaWNhdGlvbiBQcm90b2NvbCAoUENFUCkgcHJvdmlkZXMNCiAg IG1lY2hhbmlzbXMgZm9yIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudHMgKFBDRXMpIHRvIHBlcmZv cm0gcGF0aA0KICAgY29tcHV0YXRpb25zIGluIHJlc3BvbnNlIHRvIFBhdGggQ29tcHV0YXRpb24g Q2xpZW50cyAoUENDcykgcmVxdWVzdHMuDQoNCiAgIFtTdGF0ZWZ1bC1wY2VwXSBzcGVjaWZpZXMg YSBzZXQgb2YgZXh0ZW5zaW9ucyB0byBQQ0VQIHRvIGVuYWJsZQ0KICAgc3RhdGVmdWwgY29udHJv bCBvZiBNUExTLVRFIGFuZCBHTVBMUyBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcykgdmlhDQog ICBQQ0VQIGFuZCBtYWludGFpbmluZyBvZiB0aGVzZSBMU1BzIGF0IHRoZSBzdGF0ZWZ1bCBQQ0Uu ICBUaGlzDQogICBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG1lY2hhbmlzbXMgZm9yIGluY3JlbWVu dGFsIExTUCBEYXRhYmFzZSAoTFNQLQ0KICAgREIpIHN5bmNocm9uaXphdGlvbiBhcyB3ZWxsIGFz IFBDRSBjb250cm9sIG9mIHRoZSBMU1AtREINCiAgIHN5bmNocm9uaXphdGlvbiBwcm9jZXNzLg0K DQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClBjZSBtYWlsaW5nIGxpc3QNClBjZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2U= From internet-drafts@ietf.org Tue Jul 9 08:33:05 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E14011E812A; Tue, 9 Jul 2013 08:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQnTeXy73s9o; Tue, 9 Jul 2013 08:33:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB04F21F9EFE; Tue, 9 Jul 2013 08:33:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709153304.27737.1347.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 08:33:04 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-domain-sequence-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:33:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : Standard Representation Of Domain-Sequence Author(s) : Dhruv Dhody Udayasree Palle Ramon Casellas Filename : draft-ietf-pce-pcep-domain-sequence-03.txt Pages : 33 Date : 2013-07-09 Abstract: 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 Interior Gateway Protocol (IGP) area or an Autonomous Systems (AS). This document specifies a standard representation and encoding of a Domain-Sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain shortest constrained paths across a predetermined sequence of domains . This document also defines new subobjects to be used to encode domain identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-domain-sequence There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-domain-sequence-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-domain-sequence-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ina@juniper.net Tue Jul 9 09:19:01 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3700221F88FB for ; Tue, 9 Jul 2013 09:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.092 X-Spam-Level: ** X-Spam-Status: No, score=2.092 tagged_above=-999 required=5 tests=[AWL=-1.685, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDF8NOtmrpgb for ; Tue, 9 Jul 2013 09:18:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4143521F8AF4 for ; Tue, 9 Jul 2013 09:18:55 -0700 (PDT) Received: from mail211-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 16:18:54 +0000 Received: from mail211-ch1 (localhost [127.0.0.1]) by mail211-ch1-R.bigfish.com (Postfix) with ESMTP id 44728E016C for ; Tue, 9 Jul 2013 16:18:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: PS-35(zz9371Ic89bh936eI542I1dbaI4015Ia65Rzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h941hd25hf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail211-ch1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=ina@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail211-ch1 (localhost.localdomain [127.0.0.1]) by mail211-ch1 (MessageSwitch) id 1373386732152854_23967; Tue, 9 Jul 2013 16:18:52 +0000 (UTC) Received: from CH1EHSMHS034.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail211-ch1.bigfish.com (Postfix) with ESMTP id 16BAC3A006B for ; Tue, 9 Jul 2013 16:18:52 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by CH1EHSMHS034.bigfish.com (10.43.70.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 16:18:51 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 9 Jul 2013 09:18:50 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 9 Jul 2013 09:18:49 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.249) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Jul 2013 09:31:32 -0700 Received: from mail104-db9-R.bigfish.com (10.174.16.243) by DB9EHSOBE020.bigfish.com (10.174.14.83) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 16:18:47 +0000 Received: from mail104-db9 (localhost [127.0.0.1]) by mail104-db9-R.bigfish.com (Postfix) with ESMTP id C4E13240095 for ; Tue, 9 Jul 2013 16:18:47 +0000 (UTC) Received: from mail104-db9 (localhost.localdomain [127.0.0.1]) by mail104-db9 (MessageSwitch) id 137338672533478_23142; Tue, 9 Jul 2013 16:18:45 +0000 (UTC) Received: from DB9EHSMHS025.bigfish.com (unknown [10.174.16.231]) by mail104-db9.bigfish.com (Postfix) with ESMTP id 03D9A360031; Tue, 9 Jul 2013 16:18:45 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by DB9EHSMHS025.bigfish.com (10.174.14.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 9 Jul 2013 16:18:44 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.186]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0324.000; Tue, 9 Jul 2013 16:18:44 +0000 From: Ina Minei To: "Zhangxian (Xian)" Thread-Topic: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt Thread-Index: AQHOewbjfOhnk9ImH0mWsaFL9Wr7sZlaip8+gACnKACAAMKnE4AAi30A Date: Tue, 9 Jul 2013 16:18:44 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3037FD09A@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <20130707114106.19250.97443.idtracker@ietfa.amsl.com> , <70BDAD02381BA54CA31315A2A26A7AD3037FCB05@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "pce@ietf.org" Subject: Re: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:19:01 -0000 WGlhbiwgDQoNClRoZSBpZGVhIG9mIG9ubHkgZG9pbmcgYW4gaW5jcmVtZW50YWwgc3luYyBpcyB2 ZXJ5IHVzZWZ1bCwgSSB0aGluayB0aGUgcmVxdWlyZW1lbnRzIGFyZSB2YWxpZCBmb3IgY2FzZXMg d2hlcmUgbGFyZ2UgZGJzIGFyZSBpbnZvbHZlZC4gQXMgSm9uIG1lbnRpb25lZCwgaXQgaXMgbm90 IGFwcGxpY2FibGUgdG8gYWxsIHNjZW5hcmlvcywgYW5kIG9uZSBtdXN0IGFsd2F5cyB3ZWlnaHQg dGhlIGNvc3QgaW4gZXh0cmEgY29tcGxleGl0eSB2cyB0aGUgYmVuZWZpdC4gDQoNCk15IG9yaWdp bmFsIGVtYWlsIHdhcyB0byBtYWtlIHN1cmUgdGhlIHdnIGlzIGF3YXJlIG9mIHRoZSBvdGhlciBz eW5jLXJlbGF0ZWQgY2hhbmdlcyBpbiB0aGUgc3RhdGVmdWwgcGNlIGRyYWZ0LCBzaW5jZSBJIGRv bqGvdCB0aGluayBtYW55IHBlb3BsZSBoYXZlIGhhZCBhIGNoYW5jZSB0byByZWFkIHRoZSBkcmFm dC4NCg0KVGhlIGRyYWZ0IG1pZ2h0IHdhbnQgdG8gZXhwYW5kIG9uIGhvdyB0byBkZXRlcm1pbmUg d2hhdCBpcyBtaXNzaW5nLCBjb3JyZWxhdGlvbiBiZXR3ZWVuIHZlcnNpb24gZGIgYW5kIHNycC1p ZC1udW1iZXJzIG9yIG90aGVyIG1lY2hhbmlzbXMgdG8gYXZvaWQgaGF2aW5nIHRvIGtlZXAgdW5i b3VuZGVkIHN0YXRlIGZvciB0aGUgcHVycG9zZSBvZiBjcm9zcy1jaGVja2luZywgZXJyb3JzIGlu IHRoaXMgcHJvY2VzcyBhbmQgcmVjb3ZlcnkgZnJvbSB0aGVtLg0KDQpUaGFua3MsIA0KDQpJbmEg DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBaaGFuZ3hpYW4gKFhpYW4pIFtt YWlsdG86emhhbmcueGlhbkBodWF3ZWkuY29tXSANClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDksIDIw MTMgMTI6MzMgQU0NClRvOiBJbmEgTWluZWkNCkNjOiBwY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbUGNlXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aHgtcGNlLXN0 YXRlZnVsLWxzcC1zeW5jLTAwLnR4dA0KDQpIaSwgSW5hLCANCg0KICAgICBZZXM7IHdlIGFyZSBh d2FyZSBvZiB0aGlzIGFuZCBzbyBmcm9tIHByb3RvY29sIGV4dGVuc2lvbnMgcG9pbnQgb2Ygdmll dywgdGhpcyBkcmFmdCBkb2VzIGZvbGxvdyB0aGUgdXNlIG9mIHJlbGF0ZWQgZmxhZ3MgZGVmaW5l ZCB0aGVyZS4gDQoNCiAgICBIb3dldmVyLCB0aGUgaW50ZW50aW9uIG9mIHRoZXNlIHR3byBQQ0Ut dHJpZ2dlcmVkIGFjdGlvbiBhcmUgZGlmZmVyZW50LiBJbiB0aGlzIG5ldyBkcmFmdCwgaXQgYWlt cyB0byBhbGxvdyB0aGUgUENFIHRvIGNvbnRyb2wgdGhlIHRpbWluZyBvZiBMU1Agc3RhdGUgc3lu Y2hyb25pemF0aW9uIChldmVuIGJlZm9yZSBpdHMgTFNQIERCIGlzIHVwLXRvLWRhdGUpIGFjcm9z cyBQQ0VQIHNlc3Npb25zLiBXaGlsZSBpbiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtMDUg aW50ZW5kcyB0byBhbGxvdyBzYW5pdHkgY2hlY2sgYnkgUENFIGFmdGVyIHRoZSBzdGF0ZWZ1bCBQ Q0UgaXMgZnVsbHkgZnVuY3Rpb25hbCAoYWthIHdpdGggZnVsbCBMU1AtREIpLiANCg0KICAgIFdo YXQgZG8geW91IHRoaW5rIG9mIHRoZSBkcmFmdCBpdHNlbGY/IERvIHlvdSB0aGluayB0aGUgcmVx dWlyZW1lbnRzIGFyZSB2YWxpZD8gDQoNClJlZ2FyZHMsDQpYaWFuDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogSW5hIE1pbmVpIFtpbmFAanVuaXBl ci5uZXRdDQq3osvNyrG85DogMjAxM8TqN9TCOcjVIDM6NDgNCrW9OiBaaGFuZ3hpYW4gKFhpYW4p OyBwY2VAaWV0Zi5vcmcNCtb3zOI6IFJFOiBbUGNlXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jLTAwLnR4dA0KDQpPbmUgbWlu b3IgY29tbWVudCBmb3IgdGhvc2Ugb2YgeW91IHdobyBtaWdodCBiZSByZXZpZXdpbmcgdGhpcyBk cmFmdCwgcGxlYXNlIGJlIGF3YXJlIHRoYXQgUGNlLXRyaWdnZXJlZCBzeW5jIGlzIGFsc28gY292 ZXJlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1 bC1wY2UtMDUjc2VjdGlvbi01LjUuNCAodGhvdWdoIHRoZSBlbnRpcmUgZGF0YWJhc2UgaXMgZXhj aGFuZ2VkIGluIHRoYXQgY2FzZSkuDQoNCkluYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFpoYW5neGlhbiAoWGlhbikNClNlbnQ6IE1vbmRheSwgSnVseSAwOCwg MjAxMyAyOjU5IEFNDQpUbzogcGNlQGlldGYub3JnDQpTdWJqZWN0OiBbUGNlXSBGVzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jLTAw LnR4dA0KDQpIaSwgRGVhciBQQ0VycywNCg0KICAgICAgV2UgaGF2ZSBqdXN0IHVwbG9hZCBhIG5l dyBkcmFmdCBzcGVjaWZ5aW5nIHRoZSBuZWVkIGluIFBDRVAgdG8gYWxsb3cgaW5jcmVtZW50YWwg TFNQIHN0YXRlIHN5bmNocm9uaXphdGlvbiBhcyB3ZWxsIGFzIFBDRSBjb250cm9sIG92ZXIgdGhp cyBwcm9jZXNzIGZvciBzdGF0ZWZ1bCBQQ0UocykuICBJdCBhbHNvIHByb3Bvc2VzIFBDRVAgZXh0 ZW5zaW9ucyB0byBzdXBwb3J0IHRoZSByZXF1aXJlbWVudHMuDQoNCiAgICAgICBBbnkgY29tbWVu dHMvZmVlZGJhY2sgYXJlIGFwcHJlY2lhdGVkLg0KDQpSZWdhcmRzLA0KWGlhbiAoIG9uIGJlaGFs ZiBvZiBhbGwgYXV0aG9ycykNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2ludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10NCreiy83KsbzkOiAyMDEzxOo31MI3yNUgMTk6NDENCrW9OiBaaGFuZ3hpYW4gKFhp YW4pOyBYaWVnYW5nIChBKTsgRGhydXYgRGhvZHkNCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0wMC50eHQNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoeC1wY2Utc3RhdGVmdWwtbHNwLXN5bmMtMDAudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW4gWmhhbmcgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgIGRyYWZ0LXpoeC1wY2Ut c3RhdGVmdWwtbHNwLXN5bmMNClJldmlzaW9uOiAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAg TFNQIFN5bmNocm9uaXphdGlvbiBmb3IgU3RhdGVmdWwgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50 IChQQ0UpDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTMtMDctMDUNCkdyb3VwOiAgICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDcNClVSTDogICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemh4LXBjZS1zdGF0ZWZ1 bC1sc3Atc3luYy0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jDQpIdG1saXplZDogICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoeC1wY2Utc3RhdGVmdWwtbHNw LXN5bmMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoZSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQg Q29tbXVuaWNhdGlvbiBQcm90b2NvbCAoUENFUCkgcHJvdmlkZXMNCiAgIG1lY2hhbmlzbXMgZm9y IFBhdGggQ29tcHV0YXRpb24gRWxlbWVudHMgKFBDRXMpIHRvIHBlcmZvcm0gcGF0aA0KICAgY29t cHV0YXRpb25zIGluIHJlc3BvbnNlIHRvIFBhdGggQ29tcHV0YXRpb24gQ2xpZW50cyAoUENDcykg cmVxdWVzdHMuDQoNCiAgIFtTdGF0ZWZ1bC1wY2VwXSBzcGVjaWZpZXMgYSBzZXQgb2YgZXh0ZW5z aW9ucyB0byBQQ0VQIHRvIGVuYWJsZQ0KICAgc3RhdGVmdWwgY29udHJvbCBvZiBNUExTLVRFIGFu ZCBHTVBMUyBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcykgdmlhDQogICBQQ0VQIGFuZCBtYWlu dGFpbmluZyBvZiB0aGVzZSBMU1BzIGF0IHRoZSBzdGF0ZWZ1bCBQQ0UuICBUaGlzDQogICBkb2N1 bWVudCBkZXNjcmliZXMgdGhlIG1lY2hhbmlzbXMgZm9yIGluY3JlbWVudGFsIExTUCBEYXRhYmFz ZSAoTFNQLQ0KICAgREIpIHN5bmNocm9uaXphdGlvbiBhcyB3ZWxsIGFzIFBDRSBjb250cm9sIG9m IHRoZSBMU1AtREINCiAgIHN5bmNocm9uaXphdGlvbiBwcm9jZXNzLg0KDQoNCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClBjZSBtYWlsaW5nIGxpc3QNClBjZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg== From Jonathan.Hardwick@metaswitch.com Tue Jul 9 13:25:23 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BCD21F8EDF for ; Tue, 9 Jul 2013 13:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.803 X-Spam-Level: X-Spam-Status: No, score=0.803 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVRRErZtg14H for ; Tue, 9 Jul 2013 13:25:16 -0700 (PDT) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 305F521F9E28 for ; Tue, 9 Jul 2013 13:24:59 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.209.38) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 9 Jul 2013 21:24:55 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.02.0342.003; Tue, 9 Jul 2013 21:24:57 +0100 From: Jonathan Hardwick To: "Zhangxian (Xian)" Thread-Topic: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt Thread-Index: AQHOewbjfOhnk9ImH0mWsaFL9Wr7sZlaip8+gADBx6CAAMDA9YAAvkYg Date: Tue, 9 Jul 2013 20:24:57 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10ED714@ENFICSMBX1.datcon.co.uk> References: <20130707114106.19250.97443.idtracker@ietfa.amsl.com> , <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10EBF60@ENFICSMBX1.datcon.co.uk> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.167] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pce@ietf.org" , "draft-zhx-pce-stateful-lsp-sync@tools.ietf.org" Subject: Re: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 20:25:23 -0000 SGkgWGlhbg0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbGllcy4gIEhlcmUgYXJlIG15IHN1Z2dlc3Rp b25zLg0KDQotICBUaGUgZHJhZnQgc2hvdWxkIGV4cGxhaW4gbW9yZSBjbGVhcmx5IHRoZSBjaXJj dW1zdGFuY2VzIGluIHdoaWNoIHRoaXMgaXMgYSB3b3J0aHdoaWxlIG9wdGltaXphdGlvbi4NCg0K LSAgSSBhZ3JlZSB0aGF0IHRoZXJlIGlzIG5vIG5lZWQgZm9yIHlvdSB0byBnbyBpbnRvIGRldGFp bCBhYm91dCBob3cgdGhlIFBDQydzIGNhY2hlIG9mIGRhdGFiYXNlIHVwZGF0ZXMgc2hvdWxkIG9w ZXJhdGUuICBIb3dldmVyLCBJIGRvIHRoaW5rIHRoYXQgeW91IHNob3VsZCBzdGF0ZSB0aGF0IGl0 IGlzIG5vdCBuZWNlc3NhcnkgZm9yIHRoZSBQQ0MgdG8gc3RvcmUgYSBjb21wbGV0ZSBoaXN0b3J5 IG9mIGFsbCBkYXRhYmFzZSB1cGRhdGVzLg0KDQotICBZb3Ugc2hvdWxkIGRlZmluZSBhIG1lY2hh bmlzbSB3aGVyZSB0aGUgUENDIGNhbiBjaG9vc2UgdG8gc2VuZCBhIGZ1bGwgcmVzeW5jaHJvbml6 YXRpb24gaW5zdGVhZCBvZiBhbiBpbmNyZW1lbnRhbCBzeW5jaHJvbml6YXRpb24uICBUaGlzIGNv dWxkIGJlIGVpdGhlciBiZWNhdXNlIG9mIGEgcG9saWN5IG9uIHRoZSBQQ0Mgb3IgYmVjYXVzZSB0 aGUgUENDIGRvZXMgbm90IGhhdmUgZW5vdWdoIGhpc3RvcnkgaW4gaXRzIGRhdGFiYXNlIHVwZGF0 ZSBjYWNoZSB0byBwZXJmb3JtIGFuIGluY3JlbWVudGFsIHN5bmNocm9uaXphdGlvbi4NCg0KUmVn YXJkcw0KSm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFpoYW5neGlh biAoWGlhbikgW21haWx0bzp6aGFuZy54aWFuQGh1YXdlaS5jb21dIA0KU2VudDogMDkgSnVseSAy MDEzIDE0OjE3DQpUbzogSm9uYXRoYW4gSGFyZHdpY2sNCkNjOiBwY2VAaWV0Zi5vcmc7IGRyYWZ0 LXpoeC1wY2Utc3RhdGVmdWwtbHNwLXN5bmNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb UGNlXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aHgtcGNlLXN0YXRl ZnVsLWxzcC1zeW5jLTAwLnR4dA0KDQpIaSwgRGVhciBKb24sIA0KDQogICAgVGhhbmsgeW91IHZl cnkgbXVjaCBmb3IgdGhlIHVzZWZ1bCBjb21tZW50cy4gUGxlYXNlIHNlZSBvdXIgcmVwbHkgaW5s aW5lIChsb29raW5nIGZvciBbQVVUSE9SU10pOg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQq3orz+yMs6IEpvbmF0aGFuIEhhcmR3aWNrIFtKb25hdGhhbi5IYXJk d2lja0BtZXRhc3dpdGNoLmNvbV0NCreiy83KsbzkOiAyMDEzxOo31MI5yNUgNTo0Ng0Ktb06IFpo YW5neGlhbiAoWGlhbik7IGRyYWZ0LXpoeC1wY2Utc3RhdGVmdWwtbHNwLXN5bmNAdG9vbHMuaWV0 Zi5vcmcNCkNjOiBwY2VAaWV0Zi5vcmcNCtb3zOI6IFJFOiBbUGNlXSBGVzogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jLTAwLnR4dA0K DQpIaSB0aGVyZQ0KDQpUaGUgaW5jcmVtZW50YWwgc3RhdGUgc3luY2hyb25pemF0aW9uIG1lY2hh bmlzbSBsb29rcyBsaWtlIGEgcG90ZW50aWFsbHkgdXNlZnVsIG9wdGltaXphdGlvbi4gIEkgaGF2 ZSBhIGZldyBxdWVzdGlvbnMgZm9yIHRoZSBkcmFmdCBhdXRob3JzLg0KDQpUaGUgbW90aXZhdGlv biBvZiB0aGUgaW5jcmVtZW50YWwgc3luY2hyb25pemF0aW9uIG1lY2hhbmlzbSBpcyB0byByZWR1 Y2UgdGhlIHRpbWUgYW5kIGJhbmR3aWR0aCBvZiB0aGUgc3luY2hyb25pemF0aW9uIHByb2Nlc3Mu ICBUaGlzIGlzIGxpa2VseSB0byBiZSB0cnVlIGluIHNjZW5hcmlvcyB3aGVyZSB0aGUgTFNQIGRh dGFiYXNlIGlzIGxhcmdlIGFuZCB0aGUgbnVtYmVyIG9mIGNoYW5nZXMgc2luY2UgdGhlIGxhc3Qg c3VjY2Vzc2Z1bCBzeW5jaHJvbml6YXRpb24gaXMgc21hbGwuICBDb252ZXJzZWx5LCBpZiB0aGUg TFNQIGRhdGFiYXNlIGlzIHNtYWxsIGFuZCB0aGUgUENFIGhhcyB0YWtlbiBhIGxvbmcgdGltZSB0 byByZWNvdmVyIHRoZW4gaXQgbWlnaHQgYWN0dWFsbHkgYmUgcXVpY2tlciB0byBwZXJmb3JtIGEg ZnVsbCBtYXJrLWFuZC1zd2VlcCBzeW5jaHJvbml6YXRpb24uDQpbQVVUSE9SU106IEFncmVlZC4g DQoNCklzIHRoZSBpbnRlbnQgb2YgeW91ciBkcmFmdCB0aGF0IHRoZSBQQ0MgYW5kIFBDRSBjYW4g Y2hvb3NlIHdoZXRoZXIgdG8gcGVyZm9ybSBhbiBpbmNyZW1lbnRhbCBvciBmdWxsIHN5bmNocm9u aXphdGlvbiBiYXNlZCBvbiBob3cgb3V0IG9mIGRhdGUgdGhlIFBDRSdzIGRhdGFiYXNlIGlzPyAg SW4gd2hpY2ggY2FzZSwgd2hvIG1ha2VzIHRoZSBjaG9pY2UsIHVzaW5nIHdoYXQgY3JpdGVyaWEs IGFuZCBob3cgaXMgdGhhdCBjaG9pY2UgbWFkZSBrbm93biB0byB0aGUgb3RoZXIgcGFydHk/ICBP ciBpcyB0aGUgaW50ZW50IHRoYXQgaW5jcmVtZW50YWwgc3luY2hyb25pemF0aW9uIGlzIGFsd2F5 cyBwcmVmZXJyZWQgaWYgYm90aCBwYXJ0aWVzIHN1cHBvcnQgaXQ/DQpbQVVUSE9SU106ICBJbiB0 aGUgY3VycmVudCB2ZXJzaW9uICdpbmNyZW1lbnRhbCBzeW5jaHJvbml6YXRpb24nIGlzIGFsd2F5 cyBwcmVmZXJyZWQgaWYgYm90aCBwYXJ0aWVzIHN1cHBvcnQgaXQuIERvIHlvdSBmZWVsIHN0cm9u Z2x5IGlmIHRoaXMgbmVlZHMgY2hhbmdpbmc/DQoNClRoZSBpbmNyZW1lbnRhbCBzeW5jaHJvbml6 YXRpb24gcmVsaWVzIG9uIHRoZSBQQ0MgcmVwbGF5aW5nIHRoZSBuZWNlc3NhcnkgUENScHQgbWVz c2FnZXMgdG8gdGhlIFBDRSB0byBicmluZyBpdCB1cCB0byBkYXRlLCBpbmNsdWRpbmcgYW55IHRo YXQgcmVsYXRlIHRvIGRlbGV0ZWQgTFNQcy4gIERvIHlvdSBoYXZlIGFueSBndWlkZWxpbmVzIG9u IGhvdyBtYW55IFBDUnB0cyB0aGUgUENDIHNob3VsZCBjYWNoZSBhbmQgZm9yIGhvdyBsb25nPyAg SGF2ZSB5b3UgY29uc2lkZXJlZCBhIGNoZWNrLXBvaW50aW5nIG1lY2hhbmlzbSB3aGVyZSB0aGUg UENFIG9jY2FzaW9uYWxseSBjb25maXJtcyB0aGF0IGlzIGhhcyBhIHBlcnNpc3RlbnQgY29weSBv ZiBEQiB2ZXJzaW9uIHggdG8gYXZvaWQgdGhpcyBjYWNoZSBmcm9tIGdyb3dpbmcgdG9vIGxhcmdl Pw0KDQpbQVVUSE9SU106IFBDQyBuZWVkcyB0byBjYWNoZSBQQ1JwdHMgb2YgZGVsZXRlZCBMU1Bz IG9ubHkgaWYgdGhlcmUgZXhpc3Qgc29tZSBQQ0VQIHNlc3Npb24gdG8gYSBzdGF0ZWZ1bCBQQ0Ug YSl3aGljaCB3YXMgcHJldmlvdXNseSB1cCBhbmQgTFNQLURCIHN5bmNocm9uaXplZCwgYnV0IHRl bXBvcmFyaWx5IGRvd247IGIpc3VwcG9ydGVkIExTUC1EQi1WZXJzaW9uIFRMViBpbiBQQ1JwdHMg KElEQiBmbGFnIHdhcyBzZXQgaW4gT1BFTikuDQogIA0KW0FVVEhPUlNdOiBBbHNvLCBzYXkgdGhl IERCIHZlcnNpb24gd2hlbiBhIExTUCBnZXRzIGRlbGV0ZWQgaXMgWCwgIFRoZSBEQiB2ZXJzaW9u IGF0IHRoZSB0aW1lIG9mIGxhc3Qgc3luY2hyb25pemF0aW9uIGZvciBhICdkb3duJyBzZXNzaW9u IGJlIERCVihpKSB3aGVyZSBpPTEgdG8gTiAoTiB0ZW1wb3JhcmlseSBkb3duIHNlc3Npb25zIHdp dGggYWJvdmUgY29uZGl0aW9ucyBzYXRpc2ZpZWQpLCBUaGVuIHlvdSBubyBsb25nZXIgbmVlZCB0 byBjYWNoZSBQQ1JwdHMgb2YgYSBkZWxldGVkIExTUHMgaWYgWCA8IE1JTntEQlYoaSksKGk9MS4u Lk4pfQ0KDQpbQVVUSE9SU106IFdoZW5ldmVyIGEgZG93biBzZXNzaW9uIGNvbWVzIHVwIGFuZCBz dGF0ZSBpcyBzeW5jaHJvbml6ZWQsIHRoZSBhYm92ZSBjb25kaXRpb24gY2FuIGJlIHVzZWQgdG8g Y2xlYXIgdGhlIGNhY2hlLiBTaW5jZSB0aGlzIGlzIGEgbG9jYWwgbWVjaGFuaXNtIG9mIFBDQywg c2hvdWxkIGl0IGJlIGEgcGFydCBvZiB0aGUgc3BlY2lmaWNhdGlvbj8gDQoNCllvdSBuZWVkIHRv IGRlYWwgd2l0aCB0aGUgY2FzZSB3aGVyZSBib3RoIFBDRSBhbmQgUENDIHNldCB0aGUgRCBmbGFn IGFuZCB5ZXQgdGhlIFBDQydzIGNhY2hlIG9mIFBDUnB0cyBkb2VzIG5vdCBnbyBiYWNrIGZhciBl bm91Z2ggdG8gbWFrZSBhbiBpbmNyZW1lbnRhbCBzeW5jaHJvbml6YXRpb24gcG9zc2libGUuICBJ biB0aGlzIGNhc2UsIGEgZnVsbCBzeW5jaHJvbml6YXRpb24gaXMgbmVjZXNzYXJ5IHJlZ2FyZGxl c3Mgb2YgdGhlIEQgYml0cy4NCg0KW0FVVEhPUlNdOiBPbmUgd2F5IHRvIGRvIHRoaXMgd291bGQg YmUgdG8gaGF2ZSBhbm90aGVyIGZsYWcgaW4gTFNQIG9iamVjdCBhbG9uZyB3aXRoIFNZTkMgdG8g aW5kaWNhdGUgaWYgUENDIHJlcG9ydCBpcyBmb3IgaW5jcmVtZW50YWwgc3RhdGUgc3luY2hyb25p emF0aW9uLiANCg0KQmVzdCBSZWdhcmRzLA0KWGlhbiAob24gYmVoYWxmIG9mIGFsbCBhdXRob3Jz KQ0KDQpSZWdhcmRzDQpKb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog cGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFpoYW5neGlhbiAoWGlhbikNClNlbnQ6IDA4IEp1bHkgMjAxMyAxMDo1OQ0KVG86IHBj ZUBpZXRmLm9yZw0KU3ViamVjdDogW1BjZV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0wMC50eHQNCg0KSGksIERlYXIgUENF cnMsDQoNCiAgICAgIFdlIGhhdmUganVzdCB1cGxvYWQgYSBuZXcgZHJhZnQgc3BlY2lmeWluZyB0 aGUgbmVlZCBpbiBQQ0VQIHRvIGFsbG93IGluY3JlbWVudGFsIExTUCBzdGF0ZSBzeW5jaHJvbml6 YXRpb24gYXMgd2VsbCBhcyBQQ0UgY29udHJvbCBvdmVyIHRoaXMgcHJvY2VzcyBmb3Igc3RhdGVm dWwgUENFKHMpLiAgSXQgYWxzbyBwcm9wb3NlcyBQQ0VQIGV4dGVuc2lvbnMgdG8gc3VwcG9ydCB0 aGUgcmVxdWlyZW1lbnRzLg0KDQogICAgICAgQW55IGNvbW1lbnRzL2ZlZWRiYWNrIGFyZSBhcHBy ZWNpYXRlZC4NCg0KUmVnYXJkcywNClhpYW4gKCBvbiBiZWhhbGYgb2YgYWxsIGF1dGhvcnMpDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQq3osvNyrG85Dog MjAxM8TqN9TCN8jVIDE5OjQxDQq1vTogWmhhbmd4aWFuIChYaWFuKTsgWGllZ2FuZyAoQSk7IERo cnV2IERob2R5DQrW98ziOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpoeC1w Y2Utc3RhdGVmdWwtbHNwLXN5bmMtMDAudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBYaWFuIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRv cnkuDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYw0K UmV2aXNpb246ICAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgICBMU1AgU3luY2hyb25pemF0aW9u IGZvciBTdGF0ZWZ1bCBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgKFBDRSkNCkNyZWF0aW9uIGRh dGU6ICAgMjAxMy0wNy0wNQ0KR3JvdXA6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Ck51bWJlciBvZiBwYWdlczogNw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jLTAwLnR4dA0K U3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpo eC1wY2Utc3RhdGVmdWwtbHNwLXN5bmMNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemh4LXBjZS1zdGF0ZWZ1bC1sc3Atc3luYy0wMA0KDQoNCkFic3Ry YWN0Og0KICAgVGhlIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCBDb21tdW5pY2F0aW9uIFByb3Rv Y29sIChQQ0VQKSBwcm92aWRlcw0KICAgbWVjaGFuaXNtcyBmb3IgUGF0aCBDb21wdXRhdGlvbiBF bGVtZW50cyAoUENFcykgdG8gcGVyZm9ybSBwYXRoDQogICBjb21wdXRhdGlvbnMgaW4gcmVzcG9u c2UgdG8gUGF0aCBDb21wdXRhdGlvbiBDbGllbnRzIChQQ0NzKSByZXF1ZXN0cy4NCg0KICAgW1N0 YXRlZnVsLXBjZXBdIHNwZWNpZmllcyBhIHNldCBvZiBleHRlbnNpb25zIHRvIFBDRVAgdG8gZW5h YmxlDQogICBzdGF0ZWZ1bCBjb250cm9sIG9mIE1QTFMtVEUgYW5kIEdNUExTIExhYmVsIFN3aXRj aGVkIFBhdGhzIChMU1BzKSB2aWENCiAgIFBDRVAgYW5kIG1haW50YWluaW5nIG9mIHRoZXNlIExT UHMgYXQgdGhlIHN0YXRlZnVsIFBDRS4gIFRoaXMNCiAgIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUg bWVjaGFuaXNtcyBmb3IgaW5jcmVtZW50YWwgTFNQIERhdGFiYXNlIChMU1AtDQogICBEQikgc3lu Y2hyb25pemF0aW9uIGFzIHdlbGwgYXMgUENFIGNvbnRyb2wgb2YgdGhlIExTUC1EQg0KICAgc3lu Y2hyb25pemF0aW9uIHByb2Nlc3MuDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUGNlIG1haWxpbmcg bGlzdA0KUGNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3BjZQ0K From cyril.margaria@coriant.com Wed Jul 10 00:47:32 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04CC21F9F3D for ; Wed, 10 Jul 2013 00:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=2.500, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+NYOMM4G8GS for ; Wed, 10 Jul 2013 00:47:26 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 34A4C21F9F28 for ; Wed, 10 Jul 2013 00:47:25 -0700 (PDT) Received: from mail111-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE020.bigfish.com (10.236.130.83) with Microsoft SMTP Server id 14.1.225.22; Wed, 10 Jul 2013 07:47:25 +0000 Received: from mail111-co9 (localhost [127.0.0.1]) by mail111-co9-R.bigfish.com (Postfix) with ESMTP id 37ABB680110; Wed, 10 Jul 2013 07:47:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT005.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371Ic89bhc85dh31c5I1521Idb82hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1d7338h1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail111-co9: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT005.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail111-co9 (localhost.localdomain [127.0.0.1]) by mail111-co9 (MessageSwitch) id 1373442442582538_8769; Wed, 10 Jul 2013 07:47:22 +0000 (UTC) Received: from CO9EHSMHS020.bigfish.com (unknown [10.236.132.239]) by mail111-co9.bigfish.com (Postfix) with ESMTP id 8A5739C007F; Wed, 10 Jul 2013 07:47:22 +0000 (UTC) Received: from DB3PRD0411HT005.eurprd04.prod.outlook.com (157.56.253.53) by CO9EHSMHS020.bigfish.com (10.236.130.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 10 Jul 2013 07:47:21 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.9]) by DB3PRD0411HT005.eurprd04.prod.outlook.com ([10.255.73.40]) with mapi id 14.16.0329.000; Wed, 10 Jul 2013 07:46:47 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: Ina Minei , "JP Vasseur (jvasseur)" , Julien Meuric , "pce@ietf.org" Thread-Topic: Stateful PCE applicability Thread-Index: Ac5umsBOKlGLSPblRyS/lSkmK90b9QNOWaFAABO0knAARuijYA== Date: Wed, 10 Jul 2013 07:46:47 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D09FF18@DB3PRD0411MB427.eurprd04.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> <523C37072C291347B9730C9291CCA07D09EB9C@DB3PRD0411MB427.eurprd04.prod.outlook.com> <70BDAD02381BA54CA31315A2A26A7AD3037FCC8F@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD3037FCC8F@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.159.77.167] Content-Type: multipart/alternative; boundary="_000_523C37072C291347B9730C9291CCA07D09FF18DB3PRD0411MB427eu_" MIME-Version: 1.0 X-OriginatorOrg: coriant.com Subject: Re: [Pce] Stateful PCE applicability X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 07:47:32 -0000 --_000_523C37072C291347B9730C9291CCA07D09FF18DB3PRD0411MB427eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Margaria, Cyril (Coriant - DE/Munich) [mailto:cyril.margaria@coriant.= com] Sent: Monday, July 08, 2013 5:34 AM To: Ina Minei; JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org Subject: RE: Stateful PCE applicability Hi, Yes we need an applicability document. draft-zhang-pce-stateful-pce-app is addressing this, but there are some par= ts that could be improved: Section 4.3 : This is a drawback of the stateful PCE, this could be stated= as follows : A staful PCE requires an LSP-DB synchronization, which cause an addition de= lay or synchronization issues, thus impacting negatively the survivability = of a PCE. . In my opinion a statfull PCE could mitigate that by acting as stateless unt= il this synchronization has been done. ### I agree we should discuss on potential drawbacks. As you have seen, the= re are various proposals (new drafts) submitted to alleviate this. [[Margaria.C]] I know of draft-zhx-pce-stateful-lsp-sync, are there other d= rafts?. This draft propose an improvement on the LSP-DB synch avoidance by = queing the updates in the PCC and replaying them. This is a performance imp= rovement it reduces the delay but does add new synchronization checks. Hav= ing the PCE stateless during synchronization is another mitigation, is this= an invitation to have a new draft ;-)? Section 5: maybe describing some use case not solved by a stateful PCE woul= d be useful, or which additional constraints this add ### Discussion on constraints added by a stateful pce deployment is probabl= y something we should consider adding, but I wonder if this shouldn't fit b= etter in section 4 (e.g. discussion on state sync) [[Margaria.C]] State sync is orthogonal to a PCE being stateful (Can be eff= iciently learnt by management protocols, there are enough to use , so it m= ay be in section 4, but its not related to state sync. For instance having an active stateful add another controller in the networ= k, it may not always sit well with existing NMS or network architecture, ye= t they would benefit from the passive stateful. ### Not sure what you mean, maybe you have specific text? Section 5 : it would be usefull to indicate which scenario requires an acti= ve stateful, For instance section several use cases can be solved using both, an active = stateful can fix the problem afterwards, a passive stateful could solve it = beforehand (if the planned services are known), So cases (for instance 5.4.2 or 5.4.3) can be solved using passive stateful= PCE only, which would not present the same implication for deployement. ### The draft doesn't go in a lot of discussion on active and passive, this= was not a goal. I can see the point you are making, will evaluate with th= e co-authors how to address the comment on sections 5.4.2 and 5.4.3 in the = next version. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: pce-bounces@ietf.org [mailto:pce-bounces= @ietf.org] On Behalf Of Ina Minei Sent: Friday, June 21, 2013 6:17 PM To: JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org Subject: [Pce] Stateful PCE applicability Dear chairs and working group, In light of the recent working group re-charter which now includes stateful= PCE, we wanted to hear the opinions of the group on 1. the need for an applicability document for stateful PCE and 2. whether draft-zhang-pce-stateful-pce-app satisfies this need, or a= ny gaps it might have Thank you, Ina and Xian --_000_523C37072C291347B9730C9291CCA07D09FF18DB3PRD0411MB427eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 <= /p>

From: Margaria= , Cyril (Coriant - DE/Munich) [mailto:cyril.margaria@coriant.com]
Sent: Monday, July 08, 2013 5:34 AM
To: Ina Minei; JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org
Subject: RE: Stateful PCE applicability

 

Hi,

 <= /p>

Yes we need an applicabil= ity document.

draft-zhang-pce-stateful-= pce-app is addressing this, but there are some parts that could be improved= :

 <= /p>

Section 4.3 :  This = is a drawback of the stateful PCE, this could be stated as follows :

 <= /p>

A staful PCE requires an = LSP-DB synchronization, which cause an addition delay or synchronization is= sues, thus impacting negatively the survivability of a PCE. .

 <= /p>

In my opinion a statfull = PCE could mitigate that by acting as stateless until this synchronization h= as been done.

### I agree we should dis= cuss on potential drawbacks. As you have seen, there are various proposals = (new drafts) submitted to alleviate this.

[[Margaria.C]] I kn= ow of draft-zhx-pce-stateful-lsp-sync, are there other drafts?. This draft = propose an improvement on the LSP-DB synch avoidance by queing the updates in the PCC and replaying them. This is a performance im= provement it reduces the delay but  does add new synchronization check= s. Having the PCE stateless during synchronization is another mitigation, i= s this an invitation to have a new draft ;-)?

 <= /p>

Section 5: maybe describi= ng some use case not solved by a stateful PCE would be useful,

or which additional const= raints this add

### Discussion on constra= ints added by a stateful pce deployment is probably something we should con= sider adding, but I wonder if this shouldn’t fit better in section 4 (e.g. discussion on state sync)

[[Margaria.C]] Stat= e sync is orthogonal to a PCE being stateful (Can be efficiently learnt by = management protocols, there are enough to use , so  it may be in section 4, but its not related to state sync.<= /b>

 <= /p>

For instance having an ac= tive stateful add another controller in the network, it may not always sit = well with existing NMS or network architecture, yet they would benefit from the passive stateful.

### Not sure what you mea= n, maybe you have specific text?

 <= /p>

Section 5 : it would be u= sefull to indicate which scenario requires an active stateful,

For instance section seve= ral use cases can be solved using both, an active stateful can fix the prob= lem afterwards, a passive stateful could solve it beforehand (if the planned services are known),

 <= /p>

So cases (for instance 5.= 4.2 or 5.4.3) can be solved using passive stateful PCE only, which would no= t present the same implication for deployement.

### The draft doesn’= ;t go in a lot of discussion on active and passive, this was not a goal.&nb= sp; I can see the point you are making, will evaluate with the co-authors how to address the comment on sections 5.4.2 and 5.4.3 in the next version= .

 <= /p>

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ina Minei
Sent: Friday, June 21, 2013 6:17 PM
To: JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org
Subject: [Pce] Stateful PCE applicability

 

Dear chairs and working group,

 

In light of the recent working group re= -charter which now includes stateful PCE, we wanted to hear the opinions of= the group on

 

1.    &nb= sp;  the need for an applicability d= ocument for stateful PCE and

 

2.    &nb= sp;  whether draft-zhang-pce-statefu= l-pce-app satisfies this need, or any gaps it might have<= /p>

 

Thank you,

 

Ina and Xian

 

--_000_523C37072C291347B9730C9291CCA07D09FF18DB3PRD0411MB427eu_-- From jvasseur@cisco.com Wed Jul 10 01:01:31 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF7621F9FCF for ; Wed, 10 Jul 2013 01:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.598 X-Spam-Level: X-Spam-Status: No, score=-11.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2hcu-WhEv9S for ; Wed, 10 Jul 2013 01:01:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0FE21F9F9D for ; Wed, 10 Jul 2013 01:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25651; q=dns/txt; s=iport; t=1373443285; x=1374652885; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QXri+idxSmjhWSmS7WTWlrCXTVXDWVaJFchej1NdO7U=; b=RFgY7ogkOZ2/b9voJIfKPC+b80tnooEsw13D2Ooa/0VQVw2OnC3Sjbmy V28HGBh9gAzETXh9vFQ/ISPM3QM10YJjlR5JX0WPKWsNt20DnEB0CIcYj Cpy/HecuwWtM++04Y6AgtkPVnnVVj40W67nEEuI05D5k7jovC5WFYPQ81 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAN8T3VGtJXHA/2dsb2JhbABagkVEf8ELgRAWdIIjAQEBBHkQAgEIEQEDAQELFgcHMhQDBggCBA4FCBOHdLkjjiiBEjEGAYMJawOpHYMRgig X-IronPort-AV: E=Sophos;i="4.87,1034,1363132800"; d="scan'208,217";a="232947868" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 10 Jul 2013 08:01:24 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6A81OXR023442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 08:01:24 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 10 Jul 2013 03:01:24 -0500 From: "JP Vasseur (jvasseur)" To: "Margaria, Cyril (Coriant - DE/Munich)" Thread-Topic: Stateful PCE applicability Thread-Index: AQHOfUOrAhNlaF+1vE+bjzxWybSx/A== Date: Wed, 10 Jul 2013 08:01:23 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7723652BEF@xmb-rcd-x02.cisco.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> <523C37072C291347B9730C9291CCA07D09EB9C@DB3PRD0411MB427.eurprd04.prod.outlook.com> <70BDAD02381BA54CA31315A2A26A7AD3037FCC8F@BLUPRD0511MB436.namprd05.prod.outlook.com> <523C37072C291347B9730C9291CCA07D09FF18@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: <523C37072C291347B9730C9291CCA07D09FF18@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.229] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7723652BEFxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] Stateful PCE applicability X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 08:01:31 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7723652BEFxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Note that LSP-DB synchronization is a topic of interest for a number of sit= uations ... in normal condition. under major failures (with one or more sta= te full PCEs, ...), which may not lead to ONE solution. On Jul 10, 2013, at 12:46 AM, Margaria, Cyril (Coriant - DE/Munich) wrote: From: Margaria, Cyril (Coriant - DE/Munich) [mailto:cyril.margaria@coriant.= com] Sent: Monday, July 08, 2013 5:34 AM To: Ina Minei; JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org Subject: RE: Stateful PCE applicability Hi, Yes we need an applicability document. draft-zhang-pce-stateful-pce-app is addressing this, but there are some par= ts that could be improved: Section 4.3 : This is a drawback of the stateful PCE, this could be stated= as follows : A staful PCE requires an LSP-DB synchronization, which cause an addition de= lay or synchronization issues, thus impacting negatively the survivability = of a PCE. . In my opinion a statfull PCE could mitigate that by acting as stateless unt= il this synchronization has been done. ### I agree we should discuss on potential drawbacks. As you have seen, the= re are various proposals (new drafts) submitted to alleviate this. [[Margaria.C]] I know of draft-zhx-pce-stateful-lsp-sync, are there other d= rafts?. This draft propose an improvement on the LSP-DB synch avoidance by = queing the updates in the PCC and replaying them. This is a performance imp= rovement it reduces the delay but does add new synchronization checks. Hav= ing the PCE stateless during synchronization is another mitigation, is this= an invitation to have a new draft ;-)? Section 5: maybe describing some use case not solved by a stateful PCE woul= d be useful, or which additional constraints this add ### Discussion on constraints added by a stateful pce deployment is probabl= y something we should consider adding, but I wonder if this shouldn=92t fit= better in section 4 (e.g. discussion on state sync) [[Margaria.C]] State sync is orthogonal to a PCE being stateful (Can be eff= iciently learnt by management protocols, there are enough to use , so it m= ay be in section 4, but its not related to state sync. For instance having an active stateful add another controller in the networ= k, it may not always sit well with existing NMS or network architecture, ye= t they would benefit from the passive stateful. ### Not sure what you mean, maybe you have specific text? Section 5 : it would be usefull to indicate which scenario requires an acti= ve stateful, For instance section several use cases can be solved using both, an active = stateful can fix the problem afterwards, a passive stateful could solve it = beforehand (if the planned services are known), So cases (for instance 5.4.2 or 5.4.3) can be solved using passive stateful= PCE only, which would not present the same implication for deployement. ### The draft doesn=92t go in a lot of discussion on active and passive, th= is was not a goal. I can see the point you are making, will evaluate with = the co-authors how to address the comment on sections 5.4.2 and 5.4.3 in th= e next version. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: pce-bounces@ietf.org [mailto:pce-bounces= @ietf.org] On Behalf Of Ina Minei Sent: Friday, June 21, 2013 6:17 PM To: JP Vasseur (jvasseur); Julien Meuric; pce@ietf.org Subject: [Pce] Stateful PCE applicability Dear chairs and working group, In light of the recent working group re-charter which now includes stateful= PCE, we wanted to hear the opinions of the group on 1. the need for an applicability document for stateful PCE and 2. whether draft-zhang-pce-stateful-pce-app satisfies this need, or a= ny gaps it might have Thank you, Ina and Xian --_000_03B78081B371D44390ED6E7BADBB4A7723652BEFxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <73FA8C818936A84DB32F6D42BD0A5297@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Note that LSP-DB synchron= ization is a topic of interest for a number of situations ... in normal cond= ition. under major failures (with one or more state full
PCEs, ...), which may not lead to ONE solution.

On Jul 10, 2013, at 12:46 AM, Margaria, Cyril (Coriant - DE/Munich) wr= ote:

 
 
Hi,
 
Yes we need an applicability document.<= /div>
draft-zhang-pce-stateful-pce-app is addressing this, but = there are some parts that could be improved:
 
Section 4.3 :  This is a drawback of the stateful PC= E, this could be stated as follows :
 
A staful PCE requires an LSP-DB synchronization, which ca= use an addition delay or synchronization issues, thus impacting negatively = the survivability of a PCE. .
 
In my opinion a statfull PCE could mitigate that by actin= g as stateless until this synchronization has been done.<= /div>
### I agree we should discuss on potential drawbacks. As = you have seen, there are various proposals (new drafts) submitted to allevi= ate this.
[[Margaria.C]] I know of draft-zhx-pce-stateful-ls= p-sync, are there other drafts?. This draft propose an improvement on the L= SP-DB synch avoidance by queing the updates in the PCC and replaying them. This is a performance improvement i= t reduces the delay but  does add new synchronization checks. Having t= he PCE stateless during synchronization is another mitigation, is this an i= nvitation to have a new draft ;-)?
 
Section 5: maybe describing some use case not solved by a= stateful PCE would be useful,
or which additional constraints this add
### Discussion on constraints added by a stateful pce dep= loyment is probably something we should consider adding, but I wonder if th= is shouldn=92t fit better in section 4 (e.g. discussion on state sync)
[[Margaria.C]] State sync is orthogonal to a PCE b= eing stateful (Can be efficiently learnt by management protocols, there are= enough to use , so  it may be in section 4, but its not related to state sync.
 
For instance having an active stateful add another contro= ller in the network, it may not always sit well with existing NMS or networ= k architecture, yet they would benefit from the passive stateful.
### Not sure what you mean, maybe you have specific text?=
 
Section 5 : it would be usefull to indicate which scenari= o requires an active stateful,
For instance section several use cases can be solved usin= g both, an active stateful can fix the problem afterwards, a passive statef= ul could solve it beforehand (if the planned services are known),
 
So cases (for instance 5.4.2 or 5.4.3) can be solved usin= g passive stateful PCE only, which would not present the same implication f= or deployement.
### The draft doesn=92t go in a lot of discussion on acti= ve and passive, this was not a goal.  I can see the point you are maki= ng, will evaluate with the co-authors how to address the comment on sections 5.4.2 and 5.4.3 in the next version.
 
Mit freundlichen Gr=FC=DFen / Best Regards 
Cyril Margaria<= o:p>
From:=  pce-= bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ina Minei<= br> Sent: Friday, June= 21, 2013 6:17 PM
To: JP Vasseur (jv= asseur); Julien Meuric; <= a href=3D"mailto:pce@ietf.org" style=3D"color: blue; text-decoration: under= line; ">pce@ietf.org
Subject: [Pce] Sta= teful PCE applicability
 
Dear ch= airs and working group,
 <= o:p>
In ligh= t of the recent working group re-charter which now includes stateful PCE, w= e wanted to hear the opinions of the group on
 <= o:p>
1= .=       &= nbsp;the need for an applicability document for stateful PCE and<= /div>
 <= o:p>
2= .=       &= nbsp;whether draft-zhang-pce-stateful-pce-app satisfies this need, or any gaps it might= have
 <= o:p>
Thank y= ou,
 <= o:p>
Ina and= Xian
 <= o:p>

--_000_03B78081B371D44390ED6E7BADBB4A7723652BEFxmbrcdx02ciscoc_-- From frank.xialiang@huawei.com Thu Jul 11 01:13:45 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB06F21F9E77 for ; Thu, 11 Jul 2013 01:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrfD-wK3+clL for ; Thu, 11 Jul 2013 01:13:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC1421F9B4D for ; Thu, 11 Jul 2013 01:13:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUX38578; Thu, 11 Jul 2013 08:13:39 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 09:12:55 +0100 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 09:13:29 +0100 Received: from SZXEML530-MBS.china.huawei.com ([169.254.7.236]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.007; Thu, 11 Jul 2013 16:13:22 +0800 From: "Xialiang (C)" To: "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Thread-Index: AQHOeSiMeobaJqAMg0SQwWnFiymSpJlVXtiAgAnLKICAAAAjcA== Date: Thu, 11 Jul 2013 08:13:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.42.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] I-D Action: draft-wu-pce-dns-pce-discovery-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:13:46 -0000 Hi, I have reviewed draft-wu-pce-dns-pce-discovery-00 and think it is a very in= teresting draft. Two comments I have: 1. Why DNS based PCE discovery should be coupled with DHCP? Can DHCP be use= d to discover all the information needed? 2. How to use DNS to know PCE scope and PCE neighboring domain? B.R. Frank -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Qin W= u Sent: Friday, July 05, 2013 10:44 AM To: pce@ietf.org Subject: [Pce] FW: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Hi, folks: This is an initial draft (-v00) about DNS based PCE discovery. Here is the overview of this draft: " Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. " I like to solicit some feedback to see if there is interest in working out = more details about DNS based discovery. Thanks! Regards! -Qin -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Friday, July 05, 2013 10:37 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Path Computation Element (PCE) Discovery using DNS Author(s) : Qin Wu Filename : draft-wu-pce-dns-pce-discovery-00.txt Pages : 14 Date : 2013-07-04 Abstract: Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-pce-dns-pce-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-pce-dns-pce-discovery-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From bill.wu@huawei.com Thu Jul 11 01:58:11 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4406C21F9F16 for ; Thu, 11 Jul 2013 01:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OpBwbAKlke5 for ; Thu, 11 Jul 2013 01:58:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3846221F9EFE for ; Thu, 11 Jul 2013 01:58:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUX43382; Thu, 11 Jul 2013 08:58:00 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 09:57:19 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 09:57:54 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Thu, 11 Jul 2013 16:57:46 +0800 From: Qin Wu To: "Xialiang (C)" , "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Thread-Index: AQHOeSiMeobaJqAMg0SQwWnFiymSpJlVXtiAgAnLKICAAAAjcIAABe/w Date: Thu, 11 Jul 2013 08:57:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] I-D Action: draft-wu-pce-dns-pce-discovery-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:58:11 -0000 Hi,Frank Thank for your review and quick question, please see my reply inline below. Regards! -Qin -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Xiali= ang (C) Sent: Thursday, July 11, 2013 4:13 PM To: pce@ietf.org Subject: Re: [Pce] I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Hi, I have reviewed draft-wu-pce-dns-pce-discovery-00 and think it is a very in= teresting draft. Two comments I have: 1. Why DNS based PCE discovery should be coupled with DHCP? Can DHCP be use= d to discover all the information needed? [Qin]: DHCP does not need to be mandatory support. However in some case, DH= CP provides dynamic mechanism for deciding search path. Otherwise, we may rely on pre-configuration on the PCC. Regarding your question on whether DHCP can be used to discover all the PCE= related information, it depends on whether your DHCP server Can be configured to provide PCE related information. One interesting draft= is related to this aspect, which discusses=20 Customizing DHCP Configuration on the Basis of Network Topology http://www.ietf.org/id/draft-lemon-dhc-topo-conf-01.txt Therefore, in my opinion, it is possible to use DHCP to get all the informa= tion and DHCP could be one complimentary to DNS based PCE=20 discovery, however not all DHCP servers can provide such capability and som= e network doesn't support DHCP. 2. How to use DNS to know PCE scope and PCE neighboring domain? [Qin]: Good question, PCE scope and PCE neighboring domain can be metadata = provided by the Dynamic Delegation Discovery System (DDDS), We can define new resource records to store these metadata. PCC can look up= these resource record after knowing PCE address by performing A and/or AAAA record lookup(s)of the domain name. In the current draft, we haven't worked in details about this. B.R. Frank -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Qin W= u Sent: Friday, July 05, 2013 10:44 AM To: pce@ietf.org Subject: [Pce] FW: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Hi, folks: This is an initial draft (-v00) about DNS based PCE discovery. Here is the overview of this draft: " Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. " I like to solicit some feedback to see if there is interest in working out = more details about DNS based discovery. Thanks! Regards! -Qin -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Friday, July 05, 2013 10:37 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Path Computation Element (PCE) Discovery using DNS Author(s) : Qin Wu Filename : draft-wu-pce-dns-pce-discovery-00.txt Pages : 14 Date : 2013-07-04 Abstract: Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-pce-dns-pce-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-pce-dns-pce-discovery-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From frank.xialiang@huawei.com Thu Jul 11 02:46:46 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB8C21F9F83 for ; Thu, 11 Jul 2013 02:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7op0nhXwQca for ; Thu, 11 Jul 2013 02:46:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F188F21F9F58 for ; Thu, 11 Jul 2013 02:46:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUX48411; Thu, 11 Jul 2013 09:46:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 10:45:54 +0100 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 10:46:29 +0100 Received: from SZXEML530-MBS.china.huawei.com ([169.254.7.236]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.007; Thu, 11 Jul 2013 17:46:19 +0800 From: "Xialiang (C)" To: Qin Wu , "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Thread-Index: AQHOeSiMeobaJqAMg0SQwWnFiymSpJlVXtiAgAnLKICAAAAjcIAABe/wgAAUO6A= Date: Thu, 11 Jul 2013 09:46:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.42.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] I-D Action: draft-wu-pce-dns-pce-discovery-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 09:46:47 -0000 2. How to use DNS to know PCE scope and PCE neighboring domain? [Qin]: Good question, PCE scope and PCE neighboring domain can be metadata = provided by the Dynamic Delegation Discovery System (DDDS), We can define n= ew resource records to store these metadata. PCC can look up these resource= record after knowing PCE address by performing A and/or AAAA record lookup= (s)of the domain name. In the current draft, we haven't worked in details about this. [Frank]: When discovering PCE neighboring domain, Do you use DNS to return = OSPF area ID or ISIS area ID or not? B.R. Frank -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Qin W= u Sent: Friday, July 05, 2013 10:44 AM To: pce@ietf.org Subject: [Pce] FW: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Hi, folks: This is an initial draft (-v00) about DNS based PCE discovery. Here is the overview of this draft: " Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. " I like to solicit some feedback to see if there is interest in working out = more details about DNS based discovery. Thanks! Regards! -Qin -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Friday, July 05, 2013 10:37 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Path Computation Element (PCE) Discovery using DNS Author(s) : Qin Wu Filename : draft-wu-pce-dns-pce-discovery-00.txt Pages : 14 Date : 2013-07-04 Abstract: Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-pce-dns-pce-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-pce-dns-pce-discovery-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From bill.wu@huawei.com Thu Jul 11 02:52:59 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C6121F9D23 for ; Thu, 11 Jul 2013 02:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4D33WP-hxok for ; Thu, 11 Jul 2013 02:52:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 363E621F9D21 for ; Thu, 11 Jul 2013 02:52:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATI51405; Thu, 11 Jul 2013 09:52:51 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 10:52:13 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 10:52:48 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Thu, 11 Jul 2013 17:52:40 +0800 From: Qin Wu To: "Xialiang (C)" , "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Thread-Index: AQHOeSiMeobaJqAMg0SQwWnFiymSpJlVXtiAgAnLKICAAAAjcIAABe/wgAAUO6CAAACJgA== Date: Thu, 11 Jul 2013 09:52:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] I-D Action: draft-wu-pce-dns-pce-discovery-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 09:52:59 -0000 >>2. How to use DNS to know PCE scope and PCE neighboring domain? >>[Qin]: Good question, PCE scope and PCE neighboring domain can be metadat= a provided by the Dynamic Delegation Discovery System (DDDS), We can define= =20 >>new resource records to store these metadata. PCC can look up these resou= rce record after knowing PCE address by performing A and/or AAAA record >>lookup(s)of the domain name. >> In the current draft, we haven't worked in details about this. >[Frank]: When discovering PCE neighboring domain, Do you use DNS to return= OSPF area ID or ISIS area ID or not? [Qin]: No, it doesn't need to be like this since you can use OSPF or ISIS t= o advertise area ID, comparing with OSPF and ISIS, DNS is query and response mechanism, we can use DNS to return AS number or = some other provide defined Identifier that can be Used to stand for a group of endpoints, e.g., subnet or a group of subnet o= r a set of autonomous systems. -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Qin W= u Sent: Friday, July 05, 2013 10:44 AM To: pce@ietf.org Subject: [Pce] FW: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Hi, folks: This is an initial draft (-v00) about DNS based PCE discovery. Here is the overview of this draft: " Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. " I like to solicit some feedback to see if there is interest in working out = more details about DNS based discovery. Thanks! Regards! -Qin -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Friday, July 05, 2013 10:37 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Path Computation Element (PCE) Discovery using DNS Author(s) : Qin Wu Filename : draft-wu-pce-dns-pce-discovery-00.txt Pages : 14 Date : 2013-07-04 Abstract: Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-pce-dns-pce-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-pce-dns-pce-discovery-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From frank.xialiang@huawei.com Thu Jul 11 02:56:43 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8630321F9D71 for ; Thu, 11 Jul 2013 02:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-84U1U1L5hO for ; Thu, 11 Jul 2013 02:56:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D7CE821F9E0C for ; Thu, 11 Jul 2013 02:56:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUX49321; Thu, 11 Jul 2013 09:56:23 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 10:55:40 +0100 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 10:56:15 +0100 Received: from SZXEML530-MBS.china.huawei.com ([169.254.7.236]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Thu, 11 Jul 2013 17:55:07 +0800 From: "Xialiang (C)" To: Qin Wu , "pce@ietf.org" Thread-Topic: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Thread-Index: AQHOeSiMeobaJqAMg0SQwWnFiymSpJlVXtiAgAnLKICAAAAjcIAABe/wgAAUO6CAAACJgIAAAePQ Date: Thu, 11 Jul 2013 09:55:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.42.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] I-D Action: draft-wu-pce-dns-pce-discovery-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 09:56:43 -0000 Thanks, you address my comments. -----Original Message----- From: Qin Wu=20 Sent: Thursday, July 11, 2013 5:53 PM To: Xialiang (C); pce@ietf.org Subject: RE: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt >>2. How to use DNS to know PCE scope and PCE neighboring domain? >>[Qin]: Good question, PCE scope and PCE neighboring domain can be=20 >>metadata provided by the Dynamic Delegation Discovery System (DDDS),=20 >>We can define new resource records to store these metadata. PCC can look = up these resource record after knowing PCE address by performing A and/or A= AAA record lookup(s)of the domain name. >> In the current draft, we haven't worked in details about this. >[Frank]: When discovering PCE neighboring domain, Do you use DNS to return= OSPF area ID or ISIS area ID or not? [Qin]: No, it doesn't need to be like this since you can use OSPF or ISIS t= o advertise area ID, comparing with OSPF and ISIS, DNS is query and respons= e mechanism, we can use DNS to return AS number or some other provide defin= ed Identifier that can be Used to stand for a group of endpoints, e.g., sub= net or a group of subnet or a set of autonomous systems. -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Qin W= u Sent: Friday, July 05, 2013 10:44 AM To: pce@ietf.org Subject: [Pce] FW: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt Hi, folks: This is an initial draft (-v00) about DNS based PCE discovery. Here is the overview of this draft: " Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. " I like to solicit some feedback to see if there is interest in working out = more details about DNS based discovery. Thanks! Regards! -Qin -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Friday, July 05, 2013 10:37 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-pce-dns-pce-discovery-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Path Computation Element (PCE) Discovery using DNS Author(s) : Qin Wu Filename : draft-wu-pce-dns-pce-discovery-00.txt Pages : 14 Date : 2013-07-04 Abstract: Discovery of the (Path Computation Element (PCE) within an IGP area or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process. Therefore it would be beneficial for the Path Computation Client (PCC) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089]. This document specifies the requirements, use cases, procedures and extensions to support DNS for PCE discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-pce-dns-pce-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-pce-dns-pce-discovery-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From zhang.xian@huawei.com Fri Jul 12 03:06:17 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7969F21F8925 for ; Fri, 12 Jul 2013 03:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_56=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3wXxcWZFUVt for ; Fri, 12 Jul 2013 03:06:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3217221F99AC for ; Fri, 12 Jul 2013 03:06:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUY40184; Fri, 12 Jul 2013 10:06:03 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 11:05:15 +0100 Received: from SZXEML462-HUB.china.huawei.com (10.82.67.205) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 11:05:53 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.176]) by szxeml462-hub.china.huawei.com ([10.82.67.205]) with mapi id 14.01.0323.007; Fri, 12 Jul 2013 18:05:42 +0800 From: "Zhangxian (Xian)" To: Ina Minei , "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt Thread-Index: AQHOdqQyAW8yfnY7Vk6vasnK9njxb5lP16EAgBEGIUY= Date: Fri, 12 Jul 2013 10:05:41 +0000 Message-ID: References: <20130701214406.10273.42308.idtracker@ietfa.amsl.com>, <70BDAD02381BA54CA31315A2A26A7AD3037FAA51@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD3037FAA51@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.91.163] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 10:06:17 -0000 RGVhciBJbmEsIA0KDQogICBUaGFuayB5b3UgZm9yIHRoZSB1cGRhdGUuIFBsZWFzZSBzZWUgbXkg Y29tbWVudHMgb2YgdGhpcyBsYXRlc3QgdmVyc2lvbiBiZWxvdy4gSWYgeW91IG5lZWQgYW55IGNs YXJpZmljYXRpb24sIHBsZWFzZSBsZXQga25vdy4gDQoNClJlZ2FyZHMsDQpYaWFuDQoNCkNvbW1l bnRzOg0KDQotSW50cm9kdWN0aW9uDQogKjJuZCBwYXJhZ3JhcGg6ICJiZXR3ZWVuIGFuZCBhY3Jv c3MgUENFUCBzZXNzaW9ucyIsIHdoYXQgZG8geW91IGludGVuZCB0byBzYXk/IEl0IGlzIHNhbWUg YXMgIndpdGhpbiBhbmQgYWNyb3NzIFBDRVAgc2Vzc2lvbnMiIG1lbnRpb25lZCBsYXRlcj8NCg0K LVRlcm1pbm9sb2d5DQogKmxhc3Qgc2VudGVuY2Ugb2YgZGVsZWdhdGlvbiBkZWZpbml0aW9uOiB3 aGF0IGRvZXMgaXQgd2FudCB0byBzYXk/IEl0IHNlZW1zIHRvIGltcGx5IHRoYXQgdGhlIGNvbnRy b2wgb2YgTFNQIGNhbiBiZSBzaGlmdGVkIGZyb20gb25lIFBDQyB0byBhbm90aGVyIFBDQywgd2hp Y2ggSSBiZWxpZXZlIGlzIG5vdCB0cnVlLiBQbGVhc2UgY2xhcmlmeS4NCiAqIkxTUCBQcmlvcml0 eTogYSBzcGVjaWZpYyBwYWlyIG9mIE1QTFMgc2V0dXAgYW5kIGhvbGQgcHJpb3JpdHkgdmFsdWVz IGFzIGRlZmluZWQgaW4gW1JGQzMyMDldLiIsIG9ubHkgYXBwbGllcyB0byBNUExTPyBPciBzaG91 bGQgYmUgYXBwbGljYWJsZSBhbHNvIHRvIEdNUExTPw0KICogYWRkICJQQ0VQIFNwZWFrZXIiIGlu IHRoaXMgc2VjdGlvbj8gVGhpcyBwaHJhc2UgaXMgdXNlZCBxdWl0ZSBvZnRlbiANCg0KLVNlY3Rp b24gNS40LjENCiAqICJXaGVuIFN0YXRlIFN5bmNocm9uaXphdGlvbiBhdm9pZGFuY2UgaXMgZW5h YmxlZCBvbiBhIFBDRVAgc2Vzc2lvbiwgYSBQQ0MgaW5jbHVkZXMgdGhlIExTUC1EQi1WRVJTSU9O IFRMViBhcyBhbiBvcHRpb25hbCBUTFYgaW4gdGhlIExTUCBPYmplY3Qgb24gZWFjaCBMU1AgU3Rh dGUiLCBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBzZW50ZW5jZSB0cmllcyB0byBzYXku IFdoZXRoZXIgdG8gc2tpcCBhIHN0YXRlIHN5bmMuIGlzIG5vdCBhbiBvcHRpb24sIGJ1dCByYXRo ZXIgZGVjaWRlZCBieSB0aGUgTFNQIHN0YXRlIERCdiwgcmlnaHQ/IA0KICogRmlndXJlIDcgZG9l cyBub3QgbWF0Y2ggdGhlIHRleHQgaW4gdGhpcyBzZWN0aW9uLiAiUHVyZ2UgTFNQIHN0YXRlIiBp cyBkb25lIGF0IHRoZSBlbmQgb2YgdGhlIHN0YXRlIHN5bmNocm9uaXphdGlvbiwgZnJvbSB0aGUg dGV4dCBkZXNjcmlwdGlvbi4gDQoNCi1TZWN0aW9uIDUuNS40DQogKiAidGhlIGJhY2t1cCBQQ0Ug bWF5IGhhdmUgb25seSBhIHN1YnNldCBvZiBMU1BzIGRlbGVnYXRlZCB0byBpdC4gIFRoZSBiYWNr dXAgUENFIGRvZXMgbm90IHVwZGF0ZSBhbnkgTFNQcyB0aGF0IGFyZSBub3QgZGVsZWdhdGVkIHRv IGl0LCIgV2hhdCBkb2VzIHRoZSBmaXJzdCBzZW50ZW5jZSBpbnRlbmQgdG8gc2F5PyBXaHkgYSBi YWNrdXAgUENFIHdpbGwgaGF2ZSBMU1BzIGRlbGVnYXRlZCB0byBpdD8gRm9yIHRoZSAybmQgc2Vu dGVuY2UsIGlzIGl0IHRyeWluZyB0byBkZXNjcmliZSB0aGUgYmVoYXZpb3Igb2YgYmFja3VwIFBD RSBkdXJpbmcgcHJpbWFyeSBQQ0UgZmFpbHVyZSBjb25kaXRpb24/IElmIG5vdCwgaSBkbyBub3Qg dW5kZXJzdGFuZCB1bmRlciB3aGF0IGNvbmRpdGlvbiBjYW4gYSBiYWNrdXAvc3RhbmRieSBQQ0Ug dXBkYXRlIExTUCBzdGF0dXMvcGFyYW1ldGVycy4gUGxlYXNlIGNsYXJpZnkuDQoNCi1TZWN0aW9u IDUuNS41OiANCiAqIGhvdC1zdGFuZGJ5IFBDRSBpcyBtZW50aW9uZWQsIHdvdWxkIGJlIGdvb2Qg dG8gZXhwbGFpbiBob3cgaXQgaXMgZGlmZmVyZW50IGZyb20gdGhlIGJhY2t1cCBQQ0UuDQoNCi1T ZWN0aW9uIDYuMSAtIDYuMzoNCiAqIHRoZSBleHBsYW5hdGlvbiBvZiA8cGF0aD4gaW4gU2VjdGlv biA2LjIgc2hvdWxkIGFsc28gYmUgaW5jbHVkZWQgaW4gU2VjdGlvbiA2LjE/IFRoZSBsZXZlbCBv ZiBkZXRhaWxzIG9mIHRoZSBSQk5GIGlzIG5vdCB0aGUgc2FtZSBpbiB0aGVzZSB0d28gc2VjdGlv bnMuICBEbyB5b3UgbWVhbiB0aGUgdHdvIDxwYXRoPiBjb25zdHJ1Y3RzIGhhdmUgZGlmZmVyZW50 IG1lYW5pbmc/IFRoYXQgd291bGQgYmUgY29uZnVzaW5nLg0KICogobBJbiB0aGF0IGNhc2UsIFNS UC1JRC1udW1iZXIgTVVTVCBiZSBpbmNsdWRlZCB3aGlsZSB0aGUgc3RhdGUgb2YgdGhlIExTUCBp cyAicGVuZGluZyIsIGFmdGVyd2FyZHMgcmVzZXJ2ZWQgdmFsdWUgMHgwMDAwMDAwMCBTSE9VTEQg YmUgdXNlZC4uIiBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBzZW50ZW5jZSBpcyB0cnlp bmcgdG8gc2F5LCBjb3VsZCB5b3UgZXhwbGFpbiBhIGJpdD8gVGhlIHdvcmQgImFmdGVyd2FyZHMi IGlzIGNvbmZ1c2luZy4NCiAqIExhc3Qgc2VudGVuY2UgaW4gU2VjdGlvbiA2LjIgaXMgaW5jb21w bGV0ZT8gSWYgbXVsdGlwbGUgRXJyb3IgQ29kZSBwb3NzaWJsZSwgYSByZWZlcmVuY2UgdG8gdGhl IHNlY3Rpb24gc3BlY2lmeWluZyB0aGUgZXJyb3IgY29kZSB3b3VsZCBiZSB1c2VmdWwuDQogKiBJ ZiBQQ0UgaGFzIHRoZSBhYmlsaXR5IHRvIHB1dCBhIExTUCBpbiBub24tb3BlcmF0aW9uYWwgc3Rh dGUoYXNzdW1lIGl0IHNob3VsZCBiZSBhY2NlcHRlZCBieSBhIFBDQyksIHdoeSBpdCB3b3VsZCBj YXVzZSBQQ0MgdG8gc2VuZCBhIFBDUnB0IGluY2x1ZGluZyBMU1AtRVJST1ItVExWIGFzIHNwZWNp ZmllZCBpbiBsYXN0IHNlbnRlbmNlIGluIFNlY3Rpb24gNi4xPw0KDQotU2VjdGlvbiA2LjQgLSA2 LjU6DQogKiJbSS1ELmlldGYtcGNlLWdtcGxzLXBjZXAtZXh0ZW5zaW9uc10gaXMgZXh0ZW5kZWQg dG8gb3B0aW9uYWxseSBpbmNsdWRlIHRoZSBMU1Agb2JqZWN0IGFmdGVyIHRoZSBFTkQtUE9JTlRT IG9iamVjdC4gIEZvciBpbGx1c3RyYXRpb24gcHVycG9zZXMsIHRoZSBlbmNvZGluZyBmcm9tIFtS RkM1NDQwXSB3aWxsIGJlY29tZToiLCB3aGljaCBkcmFmdHMgeW91IGFyZSBiYXNlZD8gWW91IG1l bnRpb25lZCBleHRlbmRpbmcgR01QTFMtUENFUC1FeHRlbnNpb25zLCBidXQgdGhlIGVuY29kaW5n IGlzIHN0aWxsIGJhc2VkIG9uIFJGQzU0NDAuIFNhbWUgYXBwbGllcyBmb3IgU2VjdGlvbiA2LjUu IFRvIGF2b2lkIGNvbmZ1c2luZywgYmV0dGVyIGdldCB0aGVtIGNvbnNpc3RlbnQuDQogKiBJIHRo aW5rIGZvciBlYWNoIGV4dGVuc2lvbiBwcm92aWRlZCwgdGhlcmUgc2hvdWxkIGJlIGEgbmVlZC9q dXN0aWZpY2F0aW9uLiBJIGFtIG11Y2ggaW4gZmF2b3Igb2YgdGhlc2UgZXh0ZW5zaW9ucyBzaW5j ZSB5b3UgY2FuIHNlZSB0aGUgbW90aXZhdGlvbnMvdXNlIGNhc2VzIGRlc2NyaWJlZCBpbiBbZHJh ZnQtemhhbmctcGNlLXBjZXAtc3RhdGVmdWwtcGNlLWdtcGxzXS4gSG93ZXZlciwgdGhlc2UgdHdv IHNlY3Rpb25zIHN0aWxsIGxhY2sgb2YgdGhlIG1vdGl2YXRpb24uIE1heWJlIHlvdSBjYW4gcG9p bnQgbWUgdG8gcmVsZXZhbnQgcG9pbnRzIGxpc3RlZCBlYXJsaWVyIGluIHRoaXMgY29udHJpYnV0 aW9uIG9yIHRvIHVzZSB0aGUgYmVmb3JlLW1lbnRpb25lZCBkcmFmdD8NCg0KLVNlY3Rpb24gNzoN CiAqIKGwUENFIFJlZHVuZGFuY3kgR3JvdXAgSWRlbnRpZmllciBUTFYiLCBJIHVuZGVyc3RhbmQg dGhlIG5lZWQgb2YgdGhpcy4gQnV0IEkgYW0gY29uZnVzZWQgYnkgdGhlIGV4cGxhbmF0aW9uIHBy ZXNlbnRlZCBpbiB0aGUgY3VycmVudCB0ZXh0LCBhYm91dCB0aGUgdXNhZ2Ugb2YgdGhpcyBvcHRp b25hbCBUTFYuIEhvdyBjYW4gaXQgaGVscCB0byBkZWNpZGUgd2hldGhlciB0byBkbyBzdGF0ZSBz eW5jaHJvbml6YXRpb24gb3Igbm90PyBCeSB0aGUgdGltZSwgdGhlIFBDQyBhbmQgUENFIGVzdGFi bGlzaCB0aGUgc2Vzc2lvbiBhbmQgc3RhcnQgZXhjaGFuZ2luZyBPUEVOLHRoZSBEQnYgaXMgdGhl IHBhcmFtZXRlciB0byBoZWxwIG1ha2UgYSBkZWNpc2lvbiwgcmlnaHQ/IA0KICogV2h5IHdlIG5l ZWQgdG8gbWFrZSB0aGlzIFNSUCBuZXdseSBkZWZpbmVkIGluIFNlY3Rpb24gNy4yIGFzIGEgTVVT VCBjYXJyaWVkIG9iamVjdD8gSWYgdGhlIFBDRSBpcyBwYXNzaXZlLCB0aGVyZSBpcyBubyBzdWNo IGEgbmVlZCwgcmlnaHQ/DQogKiBHaXZlbiB0aGUgZmFjdCB0aGF0IFNZTkMgYml0IGlzIHVzZWQg Zm9yIG5ldyBmdW5jdGlvbnMgKGZvcmNlZCBmdWxsIHN0YXRlIHN5bmNocm9uaXphdGlvbiBhZnRl ciB0aGUgc3RhdGVmdWwgUENFIGlzIGZ1bGx5IGZ1bmN0aW9uYWwpLiBUaGUgc3RhdGVtZW50ICJU aGUgUyBGbGFnIE1VU1QgYmUgc2V0IHRvIDAgb3RoZXJ3aXNlLiIgbm8gbG9uZ2VyIGhvbGRzIHRy dWUuIFBsZWFzZSB1cGRhdGUgdGhlbS4NCiAqIEkgZG8gbm90IHNlZSBhbnkgZGV0YWlscyBvbiB0 aGUgIkxTUC1zaWctdHlwZSIgYXMgdGhhdCBvZiB0aGUgMy1iaXQgTyBiaXQuIEJ1dCByYXRoZXIg dGhleSBhcmUgbWVudGlvbmVkIGluIGEgbGF0ZXIgc2VjdGlvbi4gSWYgeW91IHByZWZlciBub3Qg dG8gZHVwbGljYXRlLCBhdCBsZWFzdCByZWZlciB0byB0aGF0IHNlY3Rpb24gYXMgY3VycmVudGx5 IGRlZmluZWQgZm9yIHRoaXMgZmllbGQuIEkgZG8gbm90IHRoaW5rIHRoaXMgY2hhbmdlIGhhcyBl dmVyIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZSwgcmlnaHQ/ICBTTyB3aGF0IGlzIHRoZSBpbnRlbnRp b24gZm9yIHRoaXMgbmV3IGZpbGVkPw0KICogU2VjdGlvbiA3LjMuMSBlbmNvZGluZyBvZiBMU1Ag aWRlbnRpZmllciBUTFYgaXMgd3JvbmcuIEV4dGVuZGVkIFR1bm5lbCBJRCBpcyB1c3VhbGx5IGZp bGxlZCB3aXRoIHNvdXJjZSBhZGRyZXNzLiBTbyBub3cgeW91IGVuZCB1cCB3aXRoIHR3byBzb3Vy Y2UgYWRkcmVzc2VzLCB3aGljaCBkbyBub3QgbWFrZSBzZW5zZS4gSSB0aGluayBSYW1vbiByYWlz ZWQgdGhlIGNvbW1lbnQgYmVmb3JlIGJ1dCB3YXMgaWdub3JlZC4gU2luY2UgaGUgbWFkZSBhIHZh bGlkIHBvaW50LCBzbyBwbGVhc2UgY29uc2lkZXIgdXBkYXRpbmcgdGhpcy4NCiAqIFdoYXQgaXMg dGhlIHJhdGlvbmFsZSB0byBhZGQgVHVubmVsIElEIFRMViBhbmQgU3ltYm9saWMgUGF0aCBOYW1l IFRMViBiZWZvcmUgaW4gTFNQQSBvYmplY3Q/IEFuZCBub3csIEkgc2VlIHRoYXQgdGhlIGZpcnN0 IFRMViBpcyBkZWxldGVkLCBhbmQgd2h5Pw0KDQotLS1FZGl0b3JpYWw6DQoNCkFic3RyYWN0Og0K LWV4cGFuZCBNUExTLVRFLCBHTVBMUyBhbmQgTFNQIHNpbmNlIHRoZXkgYXBwZWFyIGZpcnN0IHRp bWUgaW4gdGhlIGRyYWZ0Ow0KDQpJbnRyb2R1Y3Rpb246DQpzL2EgUGF0aCBDb250cm9sIEVsZW1l bnQvYSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQNCnMvYmV0d2VlbiBQQ0UgYW5kIFBDRS9iZXR3 ZWVuIFBDRXMNCg0KVGVybWlub2xvZ3k6DQpzL2lzIGFuIGV4dGVuc2lvbiBvZiBQYXNzaXZlIFN0 YXRlZnVsIFBDRS9pcyBhbiBleHRlbnNpb24gb2YgcGFzc2l2ZSBzdGF0ZWZ1bCBQQ0UNCnMvUmV2 b2NhdGlvbiBBbiBvcGVyYXRpb24gL1Jldm9jYXRpb246IEFuIG9wZXJhdGlvbg0Kcy9hbiBvcGVy YXRpb24gd2hlcmUgYW4gQWN0aXZlIFN0YXRlZnVsIFBDRSByZXF1ZXN0cyBhIFBDQyAvQW4gb3Bl cmF0aW9uIHdoZXJlIGFuIGFjdGl2ZSBzdGF0ZWZ1bCBQQ0UgcmVxdWVzdHMgYSBQQ0MNCnMvIGlu Zm9ybWF0aW9uIGFib3V0IGFuZCBhdHRyaWJ1dGVzIC8gaW5mb3JtYXRpb24gYWJvdXQgYXR0cmli dXRlcw0KDQpTZWN0aW9uIDMuMjoNCnMvUENDJ3MgTFNQcyBpbiB0aGUgZXZlbnQgUENFL1BDQydz IExTUHMgaW4gdGhlIGV2ZW50IG9mIFBDRQ0KDQpTZWN0aW9uIDQ6DQpzL1NldmVyYWwgbmV3IGZ1 bmN0aW9ucyB3aWxsIGJlIHJlcXVpcmVkIGluL1NldmVyYWwgbmV3IGZ1bmN0aW9ucyBhcmUgcmVx dWlyZWQNCg0KU2VjdGlvbiA1LjM6DQpzL0lmIHRoZSBQQ0VQIFNwZWFrZXJzIHN1cHBvcnQgdGhl IGV4dGVuc2lvbnMgb2YgdGhpcyBkcmFmdC9JZiB0aGUgUENFUCBzcGVha2VycyBkbyBub3Qgc3Vw cG9ydCB0aGUgZXh0ZW5zaW9ucyBvZiB0aGlzIGRyYWZ0DQoNClNlY3Rpb24gNS41LjU6DQpzL1Jl ZGVsZWdhdGlvbiBvbiBQQ0UgZmFpbHVyZS9SZWRlbGVnYXRpb24gb24gUENFIEZhaWx1cmUNCnMv d2l0aGluIHRoZSBSZWRlbGVnYXRpb24gVGltZW91dCwvd2l0aGluIHRoZSByZWRlbGVnYXRpb24g dGltZW91dCBpbnRlcnZhbCwNCg0KU2VjdGlvbiA1Ljg6DQpzL0EgUGVybWFuZW50IFBDRVAgc2Vz c2lvbiAvQSBwZXJtYW5lbnQgUENFUCBzZXNzaW9uDQoNClNlY3Rpb24gNi4yOg0Kcy90aGUgUEND IE1VU1QgcmVzcG9uZCB3aXRoIGFuIFBDRXJyIG1lc3NhZ2UvdGhlIFBDQyBNVVNUIHJlc3BvbmQg d2l0aCBhIFBDRXJyIG1lc3NhZ2UNCg0KU2VjdGlvbiA3LjM6DQpzL2R1cmluZyB3aGljaCB0aW1l IGZvciBhbiBSU1ZQLXNpZ25hbGVkIExTUC9kdXJpbmcgd2hpY2ggdGltZSBmb3IgYSBSU1ZQLXNp Z25hbGVkIExTUC4uLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCreivP7IyzogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW3BjZS1ib3VuY2VzQGlldGYub3JnXSC0 +rHtIEluYSBNaW5laSBbaW5hQGp1bmlwZXIubmV0XQ0Kt6LLzcqxvOQ6IDIwMTPE6jfUwjLI1SA1 OjU0DQq1vTogcGNlQGlldGYub3JnDQrW98ziOiBSZTogW1BjZV0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTA1LnR4dA0KDQpWZXJzaW9uIDA1IG9mIHRoZSBkcmFmdCBh ZGRyZXNzZXMgbWFueSBvZiB0aGUgaXNzdWVzIHJhaXNlZCBvbiB0aGUgbGlzdCwgaW4gcGFydGlj dWxhcjogc3VwcG9ydCBmb3IgbW9yZSByb2J1c3QgZXJyb3IgcmVwb3J0aW5nIGFuZCBjb3JyZWxh dGlvbiwgY2xhcmlmaWNhdGlvbnMgb24gdGhlIG1ha2UtYmVmb3JlLWJyZWFrIGJlaGF2aW9yIGFu ZCBiZWhhdmlvciB1bmRlciBmYWlsdXJlIGNvbmRpdGlvbnMuDQoNClJldmlldyBhbmQgY29tbWVu dHMgYXJlIHdlbGNvbWUuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwY2Ut Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpTZW50OiBNb25kYXksIEp1bHkgMDEsIDIwMTMg Mjo0NCBQTQ0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KQ2M6IHBjZUBpZXRmLm9yZw0KU3Vi amVjdDogW1BjZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTA1LnR4 dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgV29ya2luZyBHcm91cCBvZiB0aGUgSUVU Ri4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBQQ0VQIEV4dGVuc2lvbnMgZm9yIFN0YXRl ZnVsIFBDRQ0KICAgICAgICBBdXRob3IocykgICAgICAgOiBFZHdhcmQgQ3JhYmJlDQogICAgICAg ICAgICAgICAgICAgICAgICAgIEphbiBNZWR2ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAg SW5hIE1pbmVpDQogICAgICAgICAgICAgICAgICAgICAgICAgIFJvYmVydCBWYXJnYQ0KICAgICAg ICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtMDUudHh0DQog ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDYwDQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIw MTMtMDctMDENCg0KQWJzdHJhY3Q6DQogICBUaGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IENv bW11bmljYXRpb24gUHJvdG9jb2wgKFBDRVApIHByb3ZpZGVzDQogICBtZWNoYW5pc21zIGZvciBQ YXRoIENvbXB1dGF0aW9uIEVsZW1lbnRzIChQQ0VzKSB0byBwZXJmb3JtIHBhdGgNCiAgIGNvbXB1 dGF0aW9ucyBpbiByZXNwb25zZSB0byBQYXRoIENvbXB1dGF0aW9uIENsaWVudHMgKFBDQ3MpIHJl cXVlc3RzLg0KDQogICBBbHRob3VnaCBQQ0VQIGV4cGxpY2l0bHkgbWFrZXMgbm8gYXNzdW1wdGlv bnMgcmVnYXJkaW5nIHRoZQ0KICAgaW5mb3JtYXRpb24gYXZhaWxhYmxlIHRvIHRoZSBQQ0UsIGl0 IGFsc28gbWFrZXMgbm8gcHJvdmlzaW9ucyBmb3INCiAgIHN5bmNocm9uaXphdGlvbiBvciBQQ0Ug Y29udHJvbCBvZiB0aW1pbmcgYW5kIHNlcXVlbmNlIG9mIHBhdGgNCiAgIGNvbXB1dGF0aW9ucyB3 aXRoaW4gYW5kIGFjcm9zcyBQQ0VQIHNlc3Npb25zLiAgVGhpcyBkb2N1bWVudA0KICAgZGVzY3Jp YmVzIGEgc2V0IG9mIGV4dGVuc2lvbnMgdG8gUENFUCB0byBlbmFibGUgc3RhdGVmdWwgY29udHJv bCBvZg0KICAgTVBMUy1URSBhbmQgR01QTFMgTFNQcyB2aWEgUENFUC4NCg0KDQoNClRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlDQoNClRoZXJl J3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTA1DQoNCkEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS0wNQ0KDQoNCkludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBs aXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGNl From internet-drafts@ietf.org Fri Jul 12 09:37:50 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E9F21F9CCC; Fri, 12 Jul 2013 09:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfTz2Eoq87hm; Fri, 12 Jul 2013 09:37:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 079041F0D34; Fri, 12 Jul 2013 09:37:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130712163750.1347.27409.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2013 09:37:50 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-rwa-ext-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 16:37:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : PCEP Extension for WSON Routing and Wavelength Assignment Author(s) : Young Lee Ramon Casellas Filename : draft-ietf-pce-wson-rwa-ext-01.txt Pages : 21 Date : 2013-07-12 Abstract: This document provides the Path Computation Element communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-wson-rwa-ext-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-wson-rwa-ext-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From diego@tid.es Sat Jul 13 04:55:37 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E3E21F9D71; Sat, 13 Jul 2013 04:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNRuRghHp7C7; Sat, 13 Jul 2013 04:55:33 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4034421F9D0F; Sat, 13 Jul 2013 04:55:33 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MPV00IU9IGHU8@tid.hi.inet>; Sat, 13 Jul 2013 13:55:29 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 3B.FC.02911.13041E15; Sat, 13 Jul 2013 13:55:29 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MPV00IU6IGGU8@tid.hi.inet>; Sat, 13 Jul 2013 13:55:28 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.02.0328.009; Sat, 13 Jul 2013 13:55:27 +0200 Date: Sat, 13 Jul 2013 11:55:27 +0000 From: "Diego R. Lopez" X-Originating-IP: [10.95.64.115] To: "pce@ietf.org" Message-id: Content-id: <4A41669B14B10049B520682FCB07D2D7@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: Proposal on securing PCEP by means of TLS Thread-index: AQHOf7+uXh4JtZqUPkOFzvaC0qiQVA== X-AuditID: 0a5f4e69-b7f118e000000b5f-a6-51e140315e92 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsXCFe9nqGvo8DDQ4PkDfYu939YwWjTdv8Hu wOSxZMlPpgDGKC6blNSczLLUIn27BK6MpvXf2Qp+CFXcbT7L1MC4Q6iLkZNDQsBEomfvHFYI W0ziwr31bF2MXBxCAtsZJS58+MIIkhASeMYose5nHURiA6PEnCfrmEESLAKqEq837wbrZgOy HzX/ZgexhQWMJK5dmsUEMVVB4s+5xywgtoiAosT3G6vZQGxmAWWJVcdfANkcHLwC3hLH/upB hM0k1rfcB9vLKyAo8WPyPRaQEmYBdYkpU3IhSsQlmltvskDYihLTFjWAlTMKyEq8mz+fFWKT ucTy+d9ZQVpFBPQkjrwRhThGQGLJnvPMELaoxMvH/1gnMIrNQrJ4FpLFsxAWz0KyeBaSxQsY WVcxihUnFWWmZ5TkJmbmpBsY6WVk6mXmpZZsYoREUuYOxuU7VQ4xCnAwKvHwOog+CBRiTSwr rsw9xCjBwawkwpv9FyjEm5JYWZValB9fVJqTWnyIkYmDU6qBcff6zL31hs8vHN0jzliRu2an 3BV/wflVXypuGk59/u50tepU/RXGsy3P5Nybu55/uhr7bMHWPp7LE609r/m8av76LPHJnwq2 GKZLBuJpny7u+dg+W1pg0WeeR9v2fHv+f1ulhMzq9wd/X70V+T/dMUqD83DR+d8ZCaH2sy8w NOg6Hl295JTupyYlluKMREMt5qLiRAAV+icvggIAAA== Cc: "karp@ietf.org" Subject: [Pce] Proposal on securing PCEP by means of TLS X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 11:55:37 -0000 SGksDQoNCk9zY2FyIGFuZCBJIGhhdmUgcHJlcGFyZWQgYSBkcmFmdCBvbiBhcHBseWluZyBUTFMg dG8gUENFUCBzZWN1cml0eToNCg0KODwtLS0NCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtbG9wZXot cGNwLXBjZXBzDQpSZXZpc2lvbjogICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgIFNlY3VyZSBU cmFuc3BvcnQgZm9yIFBDRVANCkNyZWF0aW9uIGRhdGU6ICAgMjAxMy0wNy0xMA0KR3JvdXA6ICAg ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogOA0KVVJMOiAg ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sb3Bl ei1wY3AtcGNlcHMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbG9wZXotcGNwLXBjZXBzDQpIdG1saXplZDogICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvcGV6LXBjcC1wY2Vwcy0wMA0KDQoNCkFic3Ry YWN0Og0KICBUaGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IENvbW11bmljYXRpb24gUHJvdG9j b2wgKFBDRVApIGRlZmluZXMNCiAgdGhlIG1lY2hhbmlzbXMgZm9yIHRoZSBjb21tdW5pY2F0aW9u IGJldHdlZW4gYSBjbGllbnQgYW5kIGEgUENFLCBvcg0KICBhbW9uZyBQQ0VzLiAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZSB0aGUgdXNhZ2Ugb2YgVHJhbnNwb3J0IExheWVyDQogIFNlY3VyaXR5IHRv IGVuaGFuY2UgUENFUCBzZWN1cml0eSwgaGVuY2UgdGhlIFBDRVBTIGFjcm9ueW0gcHJvcG9zZWQN CiAgZm9yIGl0LiAgVGhlIGFkZGl0aW9uYWwgc2VjdXJpdHkgbWVjaGFuaXNtcyBhcmUgcHJvdmlk ZWQgYnkgdGhlDQogIHRyYW5zcG9ydCBwcm90b2NvbCBzdXBwb3J0aW5nIFBDRVAsIGFuZCB0aGVy ZWZvcmUgdGhleSBkbyBub3QgYWZmZWN0DQogIGl0cyBmbGV4aWJpbGl0eSBhbmQgZXh0ZW5zaWJp bGl0eS4NCg0KODwtLS0NCg0KQ29tbWVudHMgYW5kIGNvbnRyaWJ1dGlvbnMgd2lsbCBiZSBleHRy ZW1lbHkgd2VsY29tZS4NCg0KQXMgeW91IGNhbiBleHBlY3QsIHdlJ2QgbGlrZSB0byBoYXZlIHRo ZSBvcHBvcnR1bml0eSB0byBwcmVzZW50IGFuZCBkaXNjdXNzIGl0IGluIEJlcmxpbi4NCg0KQmUg Z29vZGUNCg0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyIN Cg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5l cy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAx MjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlv LiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOz biBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8u DQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUu IFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1z IHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNw eA0K From nkong@cnnic.cn Sun Jul 14 09:10:45 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6DE21F9D7D for ; Sun, 14 Jul 2013 09:10:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV9N3K8KeQeU for ; Sun, 14 Jul 2013 09:10:40 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id D2F6F21F9A49 for ; Sun, 14 Jul 2013 09:10:39 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [192.168.1.109]) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 15 Jul 2013 00:10:28 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ning Kong Date: Mon, 15 Jul 2013 00:10:36 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <31A03D17-8865-4BFE-9A0D-5A70D9632A40@cnnic.cn> To: bill.wu@huawei.com X-Mailer: Apple Mail (2.1508) Cc: pce@ietf.org Subject: [Pce] Comments on draft-wu-pce-dns-pce-discovery-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 16:10:45 -0000 Hi Qin, I'm interested in the topic of this draft. Please see my rough feedbacks = below. IMO, it's not necessary to consider defining new RR types in section = 4.3. You'd better try to use existing RR types (e.g. TXT, SRV, NAPTR) = for path computation scope, PCE domains and Neighbor PCE domains. Nits, #1, in the last paragraph of Section 1.1 complimentary should be corrected as complementary. #2, in the first paragraph of Section 6 RFC4641 should be updated by RFC6781. Cheers, Ning= From internet-drafts@ietf.org Sun Jul 14 13:40:03 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280FC21F9CF5; Sun, 14 Jul 2013 13:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy9vfP2gi8Qk; Sun, 14 Jul 2013 13:40:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E7321F9CD1; Sun, 14 Jul 2013 13:40:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130714204002.10997.79082.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 13:40:02 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 20:40:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : PCE-based Computation Procedure To Compute Shortest Cons= trained P2MP Inter-domain Traffic Engineering Label Switched Paths Author(s) : Quintin Zhao Dhruv Dhody Zafar Ali Daniel King Ramon Casellas Filename : draft-ietf-pce-pcep-inter-domain-p2mp-procedures-05.txt Pages : 20 Date : 2013-07-14 Abstract: The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes an experiment to provide procedures and extensions to the PCE communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-inter-domain-p2mp-proc= edures There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-inter-domain-p2mp-procedures= -05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-inter-domain-p2mp-pr= ocedures-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniel@olddog.co.uk Sun Jul 14 13:50:49 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DF021F9D4A for ; Sun, 14 Jul 2013 13:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.522 X-Spam-Level: X-Spam-Status: No, score=-101.522 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOQaLHom9sSr for ; Sun, 14 Jul 2013 13:50:44 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id BF53221F9CFF for ; Sun, 14 Jul 2013 13:50:41 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6EKodeE022781 for ; Sun, 14 Jul 2013 21:50:40 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6EKodNj022775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 14 Jul 2013 21:50:39 +0100 From: "Daniel King" To: References: <20130714204002.10997.79082.idtracker@ietfa.amsl.com> In-Reply-To: <20130714204002.10997.79082.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 21:50:36 +0100 Message-ID: <010301ce80d3$cb5911f0$620b35d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJ08gOx1cGG3Non7g/KNGVD5G27bZgXwulA Content-Language: en-gb Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 20:50:50 -0000 Hi All, Please find a new version of draft-ietf-pce-pcep-inter-domain-p2mp-procedures. This update addresses a number of comments/NITs from Oscar and Julien found during their review. Br, Dan (and draft-ietf-pce-pcep-inter-domain-p2mp-procedures co-authors). -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: 14 July 2013 21:40 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D Action: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths Author(s) : Quintin Zhao Dhruv Dhody Zafar Ali Daniel King Ramon Casellas Filename : draft-ietf-pce-pcep-inter-domain-p2mp-procedures-05.txt Pages : 20 Date : 2013-07-14 Abstract: The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes an experiment to provide procedures and extensions to the PCE communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-inter-domain-p2mp-proce dures There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-inter-domain-p2mp-procedures- 05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-inter-domain-p2mp-proce dures-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From adrian@olddog.co.uk Sun Jul 14 17:53:52 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACB721F9D9A for ; Sun, 14 Jul 2013 17:53:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTHbA+3xTmYI for ; Sun, 14 Jul 2013 17:53:44 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id EAC3421F9C15 for ; Sun, 14 Jul 2013 17:53:43 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6F0rggP029386 for ; Mon, 15 Jul 2013 01:53:42 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6F0rf9D029378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 15 Jul 2013 01:53:42 +0100 From: "Adrian Farrel" To: Date: Mon, 15 Jul 2013 01:53:41 +0100 Message-ID: <0a4301ce80f5$c0482720$40d87560$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6A9Y0X7KwnjQItRwWIQGahsTQdUQ== Content-Language: en-gb Subject: [Pce] New version of draft-farrkingel-pce-abno-architecture-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 00:53:52 -0000 Hi, FYI the new revision has some tidying up of the text and additions of new use cases for make-before-break and pseudowires. Thanks to Yuji Kamite, Yosuke Tanaka, and Ina Minei for contributing text. Cheers, Adrian > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 15 July 2013 01:48 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrkingel-pce-abno-architecture-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A PCE-based Architecture for Application-based Network > Operations > Author(s) : Daniel King > Adrian Farrel > Filename : draft-farrkingel-pce-abno-architecture-04.txt > Pages : 55 > Date : 2013-07-14 > > Abstract: > Services such as content distribution, distributed databases, or > inter-data center connectivity place a set of new requirements on the > operation of networks. They need on-demand and application-specific > reservation of network connectivity, reliability, and resources (such > as bandwidth) in a variety of network applications (such as point-to- > point connectivity, network virtualization, or mobile back-haul) and > in a range of network technologies from packet (IP/MPLS) down to > optical. An environment that operates to meet this type of > requirement is said to have Application-Based Network Operations > (ABNO). > > ABNO brings together many existing technologies for gathering > information about the resources available in a network, for > consideration of topologies and how those topologies map to > underlying network resources, for requesting path computation, and > for provisioning or reserving network resources. Thus, ABNO may be > seen as the use of a toolbox of existing components enhanced with a > few new elements. The key component within an ABNO is the Path > Computation Element (PCE), which can be used for computing paths and > is further extended to provide policy enforcement capabilities for > ABNO. > > This document describes an architecture and framework for ABNO > showing how these components fit together. It provides a cookbook of > existing technologies to satisfy the architecture and meet the needs > of the applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-farrkingel-pce-abno-architecture-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From bill.wu@huawei.com Sun Jul 14 18:35:48 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19C821F9C85 for ; Sun, 14 Jul 2013 18:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOpII-v-6MqA for ; Sun, 14 Jul 2013 18:35:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C24121F943C for ; Sun, 14 Jul 2013 18:35:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUZ97590; Mon, 15 Jul 2013 01:35:38 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 02:35:03 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 02:35:35 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 09:35:27 +0800 From: Qin Wu To: Ning Kong Thread-Topic: Comments on draft-wu-pce-dns-pce-discovery-00 Thread-Index: AQHOgKytPmDG4e0i5UqRFyBX9+Afzplk8zpw Date: Mon, 15 Jul 2013 01:35:26 +0000 Message-ID: References: <31A03D17-8865-4BFE-9A0D-5A70D9632A40@cnnic.cn> In-Reply-To: <31A03D17-8865-4BFE-9A0D-5A70D9632A40@cnnic.cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: Re: [Pce] Comments on draft-wu-pce-dns-pce-discovery-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 01:35:48 -0000 SGksTmluZzoNClRoYW5rIGZvciBjb21tZW50cyBmcm9tIEROUyBwZXJzcGVjdGl2ZS4NClBsZWFz ZSBzZWUgbXkgcmVwbHkgaW5saW5lIGJlbG93Lg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5pbmcgS29uZyBbbWFpbHRvOm5rb25nQGNubmljLmNu XSANClNlbnQ6IE1vbmRheSwgSnVseSAxNSwgMjAxMyAxMjoxMSBBTQ0KVG86IFFpbiBXdQ0KQ2M6 IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogQ29tbWVudHMgb24gZHJhZnQtd3UtcGNlLWRucy1wY2Ut ZGlzY292ZXJ5LTAwDQoNCg0KSGkgUWluLA0KDQpJJ20gaW50ZXJlc3RlZCBpbiB0aGUgdG9waWMg b2YgdGhpcyBkcmFmdC4gUGxlYXNlIHNlZSBteSByb3VnaCBmZWVkYmFja3MgYmVsb3cuDQoNCklN TywgaXQncyBub3QgbmVjZXNzYXJ5IHRvIGNvbnNpZGVyIGRlZmluaW5nIG5ldyBSUiB0eXBlcyBp biBzZWN0aW9uIDQuMy4gWW91J2QgYmV0dGVyIHRyeSB0byB1c2UgZXhpc3RpbmcgUlIgdHlwZXMg KGUuZy4gVFhULCBTUlYsIE5BUFRSKSBmb3IgcGF0aCBjb21wdXRhdGlvbiBzY29wZSwgUENFIGRv bWFpbnMgYW5kIE5laWdoYm9yIFBDRSBkb21haW5zLg0KDQpbUWluXTogR29vZCBwb2ludCwgdGhh dCdzIHdoYXQgSSBhbSB0aGlua2luZyBhcyB3ZWxsLiBJIHRoaW5rIHdlIGNhbiB1c2UgTkFQVFIr U1JWK0ErVFhUIGNvbnZlbnRpb24gdG8gZ2V0IGFsbCB0aGUgaW5mb3JtYXRpb24gd2Ugd2FudC4N CkROUyBUWFQgcmVjb3JkIGlzIGJlc3QgY2hvaWNlIHRvIGdldCBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIHRoYW4gUENFIElQIGFkZHJlc3MuDQoNCk5pdHMsDQojMSwgaW4gdGhlIGxhc3QgcGFyYWdy YXBoIG9mIFNlY3Rpb24gMS4xDQoJY29tcGxpbWVudGFyeSBzaG91bGQgYmUgY29ycmVjdGVkIGFz IGNvbXBsZW1lbnRhcnkuDQoNCg0KW1Fpbl06IEdvb2QgY2F0Y2guDQoNCiMyLCBpbiB0aGUgZmly c3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNg0KCVJGQzQ2NDEgc2hvdWxkIGJlIHVwZGF0ZWQgYnkg UkZDNjc4MS4NCg0KW1Fpbl06QWdyZWUsIHRoYW5rcy4NCg0KQ2hlZXJzLA0KTmluZw0K From bijy@sttri.com.cn Mon Jul 15 00:58:16 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECA721F84AA for ; Mon, 15 Jul 2013 00:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.235 X-Spam-Level: *** X-Spam-Status: No, score=3.235 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, SARE_RECV_IP_218078=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KKEZ0qV2BtN for ; Mon, 15 Jul 2013 00:58:10 -0700 (PDT) Received: from corp.21cn.com (corp.forptr.21cn.com [121.14.129.37]) by ietfa.amsl.com (Postfix) with ESMTP id BC56621F8F67 for ; Mon, 15 Jul 2013 00:57:49 -0700 (PDT) HMM_SOURCE_IP: 10.27.101.7:50983.1593830035 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from bijiayu-nb (entas7.inner-hermes.com [10.27.101.7]) by corp.21cn.com (HERMES) with ESMTP id 5BB2BAC05A; Mon, 15 Jul 2013 15:56:44 +0800 (CST) Received: from bijiayu-nb ([218.80.215.132]) by 21CN-ent7(MEDUSA 10.27.101.7) with ESMTP id 1373875004.19846 for bill.wu@huawei.com ; Mon Jul 15 15:56:48 2013 0/X-Total-Score: 0: 2/X-Total-Score: -120: 3/X-Brightmail-Tracker: AAAAAA== X-FILTER-SCORE: to=<838a8d8d4f98966189968298868a4f84908e918486618a8695874f909388>, score=<1373875008KKNKKRKKfKNRfbsW4zvKKKxxfxxXxxGxfXGMwUh4yxxx> X-REAL-FROM: bijy@sttri.com.cn X-Receive-IP: 218.80.215.132 bijy@sttri.com.cn Date: Mon, 15 Jul 2013 15:57:18 +0800 From: "Claire Bi" To: "bill.wu" Message-ID: <201307151557180154419@sttri.com.cn> X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon165726783114_=====" Cc: pce Subject: [Pce] Comments on draft-wu-pce-dns-pce-discovery-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 07:58:16 -0000 This is a multi-part message in MIME format. --=====003_Dragon165726783114_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGkgUWluLA0KIA0KSZJ2ZSByZXZpZXdlZCB0aGlzIGRyYWZ0LiBJIHRoaW5rIG9uZSBvZiB0aGUg YWR2YW50YWdlcyBvZiBETlMgYmFzZWQgUENFIGRpc2NvdmVyeSBpcyBpdHMgcXVlcnktcmVzcG9u c2UgbWVjaGFuaXNtLiBDb21wYXJlZCB3aXRoIE9TUEYgYmFzZWQgb3IgSVNJUyBiYXNlZCBQQ0Ug ZGlzY292ZXJ5LCB3aGljaCB1c2VzIGFkdmVydGlzZW1lbnQgbWVjaGFuaXNtLCB1c2luZyBxdWVy eS1yZXNwb25zZSBtZWNoYW5pc20gY2FuIGF2b2lkIHVubmVjZXNzYXJ5IGFkdmVydGlzZW1lbnQg YW5kIHJlZHVjZSBhIGxhcmdlIGFtb3VudCBvZiB1bndhbnRlZCB0cmFmZmljLCBlc3BlY2lhbGx5 IHdoZW4gUENFIGluZm9ybWF0aW9uIG5lZWRzIGZyZXF1ZW50IGNoYW5nZXMuIA0KIA0KSXQgd291 bGQgYmUgZ29vZCB0byBmdXJ0aGVyIGV4cGxhaW4gdGhlIHF1ZXJ5LXJlc3BvbnNlIG1lY2hhbmlz bSBvZiBETlMgYmFzZWQgUENFIGRpc2NvdmVyeSBpbiB0aGUgZHJhZnQuDQogDQoNClRoYW5rcyBh bmQgUmVnYXJkcywNCiANCkNsYWlyZQ0K --=====003_Dragon165726783114_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit

Hi Qin,

 

I’ve reviewed this draft. I think one of the advantages of DNS based PCE discovery is its query-response mechanism. Compared with OSPF based or ISIS based PCE discovery, which uses advertisement mechanism, using query-response mechanism can avoid unnecessary advertisement and reduce a large amount of unwanted traffic, especially when PCE information needs frequent changes.

 

It would be good to further explain the query-response mechanism of DNS based PCE discovery in the draft.

 

 

Thanks and Regards,

 

Claire

 
 
 
 
 
 
 
 
 
 
 --=====003_Dragon165726783114_=====-- From bill.wu@huawei.com Mon Jul 15 02:31:01 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B9B21F9F96 for ; Mon, 15 Jul 2013 02:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYGWkdMLHoUe for ; Mon, 15 Jul 2013 02:30:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F52321F9F7A for ; Mon, 15 Jul 2013 02:30:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVA35362; Mon, 15 Jul 2013 09:30:49 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 10:30:01 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 10:30:48 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 17:30:43 +0800 From: Qin Wu To: Claire Bi Thread-Topic: Comments on draft-wu-pce-dns-pce-discovery-00 Thread-Index: AQHOgTDcUSRhTTtqh0exqg75e/tsbplleQVQ Date: Mon, 15 Jul 2013 09:30:42 +0000 Message-ID: References: <201307151557180154419@sttri.com.cn> In-Reply-To: <201307151557180154419@sttri.com.cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43B61436nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: pce Subject: Re: [Pce] Comments on draft-wu-pce-dns-pce-discovery-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 09:31:01 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43B61436nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,Claire: You raise a good point. We will try to highlight this in the draft. Thank = you very much! Regards! -Qin From: Claire Bi [mailto:bijy@sttri.com.cn] Sent: Monday, July 15, 2013 3:57 PM To: Qin Wu Cc: pce Subject: Comments on draft-wu-pce-dns-pce-discovery-00 Hi Qin, I've reviewed this draft. I think one of the advantages of DNS based PCE di= scovery is its query-response mechanism. Compared with OSPF based or ISIS b= ased PCE discovery, which uses advertisement mechanism, using query-respons= e mechanism can avoid unnecessary advertisement and reduce a large amount o= f unwanted traffic, especially when PCE information needs frequent changes. It would be good to further explain the query-response mechanism of DNS bas= ed PCE discovery in the draft. Thanks and Regards, Claire --_000_B8F9A780D330094D99AF023C5877DABA43B61436nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,Claire:

You raise a good point. &= nbsp;We will try to highlight this in the draft. Thank you very much!<= /o:p>

Regards!

-Qin

From: Claire Bi [mailto:bijy@sttri.com.cn]
Sent: Monday, July 15, 2013 3:57 PM
To: Qin Wu
Cc: pce
Subject: Comments on draft-wu-pce-dns-pce-discovery-00

 

Hi Qin,

&nbs= p;

I’ve re= viewed this draft. I think one of the advantages of DNS based PCE discovery= is its query-response mechanism. Compared with OSPF based or ISIS based PCE discovery, which uses advertisement mechanism, using query-respo= nse mechanism can avoid unnecessary advertisement and reduce a large amount= of unwanted traffic, especially when PCE information needs frequent change= s.

&nbs= p;

It would be g= ood to further explain the query-response mechanism of DNS based PCE discov= ery in the draft.

&nbs= p;

 

Thanks and Re= gards,

&nbs= p;

Claire=

 

 

 

 

 

 

 

 

 

 

--_000_B8F9A780D330094D99AF023C5877DABA43B61436nkgeml501mbschi_-- From internet-drafts@ietf.org Mon Jul 15 05:42:37 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FFF21F9EB8; Mon, 15 Jul 2013 05:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymoe1tuHYvqk; Mon, 15 Jul 2013 05:42:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB7021F9E84; Mon, 15 Jul 2013 05:42:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715124237.26137.87661.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 05:42:37 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-gmpls-pcep-extensions-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 12:42:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : PCEP extensions for GMPLS Author(s) : Cyril Margaria Oscar Gonzalez de Dios Fatai Zhang Filename : draft-ietf-pce-gmpls-pcep-extensions-08.txt Pages : 35 Date : 2013-07-15 Abstract: This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-gmpls-pcep-extensions-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From olivier.dugeon@orange.com Mon Jul 15 09:27:57 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADD121E80BE for ; Mon, 15 Jul 2013 09:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTFAd7o+mwiz for ; Mon, 15 Jul 2013 09:27:52 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id CCCB221E80BD for ; Mon, 15 Jul 2013 09:27:35 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4103CA4411A for ; Mon, 15 Jul 2013 18:29:15 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 3696FA440E4 for ; Mon, 15 Jul 2013 18:29:15 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Jul 2013 18:27:31 +0200 Received: from [10.193.71.138] ([10.193.71.138]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Jul 2013 18:27:31 +0200 Message-ID: <51E422F2.10600@orange.com> Date: Mon, 15 Jul 2013 18:27:30 +0200 From: Olivier Dugeon Organization: Orange Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: pce@ietf.org References: <20130715161642.1235.15455.idtracker@ietfa.amsl.com> In-Reply-To: <20130715161642.1235.15455.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130715161642.1235.15455.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2013 16:27:31.0159 (UTC) FILETIME=[342A9E70:01CE8178] Subject: [Pce] Fwd: New Version Notification for draft-dugeon-pce-ted-reqs-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:27:57 -0000 Dear all, We have just submited a new version of our obsolete draft about the PCE Database requirements. Main modifications are as follow: - Change name to PCE Database Requirement to extend the scope - Include LSP database - Add a new section about the Database representation of the inter-domain part Comments are welcome. Regards, Olivier -------- Message original -------- Sujet: New Version Notification for draft-dugeon-pce-ted-reqs-02.txt Date : Mon, 15 Jul 2013 09:16:42 -0700 De : Pour : Richard Douville , "Oscar Gonzalez de Dios" , Julien Meuric , "Olivier Dugeon" , Ramon Casellas A new version of I-D, draft-dugeon-pce-ted-reqs-02.txt has been successfully submitted by Olivier Dugeon and posted to the IETF repository. Filename: draft-dugeon-pce-ted-reqs Revision: 02 Title: Path Computation Element (PCE) Database Requirements Creation date: 2013-07-15 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-dugeon-pce-ted-reqs-02.txt Status: http://datatracker.ietf.org/doc/draft-dugeon-pce-ted-reqs Htmlized: http://tools.ietf.org/html/draft-dugeon-pce-ted-reqs-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-dugeon-pce-ted-reqs-02 Abstract: The Path Computation Element (PCE) working group (WG) has produced a set of RFCs to standardize the behavior of the Path Computation Element as a tool to help MPLS-TE and GMPLS LSP tunnels placement. In the PCE architecture, a main assumption has been done concerning the information that the PCE needs to perform its computation. In a fist approach, the PCE embeds a Traffic Engineering Database (TED) containing all pertinent and suitable information regarding the network that is in the scope of a PCE. Nevertheless, the TED requirements as well as the TED information have not yet been formalized. In addition, some recent RFC (like the Backward Recursive Path Computation procedure or PCE Hierarchy) or WG draft (like draft-ietf-pce-stateful-pce ...) suffer from a lack of information in the TED, leading to a non optimal result or to some difficulties to deploy them. This memo tries to identify some Database, at large, requirements for the PCE. It is split in two main sections: the identification of the specific information to be stored in the PCE Database and how it may be populated. The IETF Secretariat From internet-drafts@ietf.org Mon Jul 15 14:07:36 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE3411E8122; Mon, 15 Jul 2013 14:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlrThyUB0CrL; Mon, 15 Jul 2013 14:07:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AB111E8210; Mon, 15 Jul 2013 14:07:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715210725.20105.14743.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:07:25 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-mib-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:07:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : PCE communication protocol (PCEP) Management Information= Base Author(s) : A S Kiran Koushik Stephan Emile Quintin Zhao Daniel King Jonathan Hardwick Filename : draft-ietf-pce-pcep-mib-05.txt Pages : 46 Date : 2013-07-15 Abstract: This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Jonathan.Hardwick@metaswitch.com Mon Jul 15 14:11:16 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4203811E818A for ; Mon, 15 Jul 2013 14:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=1.201, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU8XQ8MRk5M8 for ; Mon, 15 Jul 2013 14:11:11 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id E55E311E8122 for ; Mon, 15 Jul 2013 14:11:10 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.209.38) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 15 Jul 2013 22:11:07 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 22:11:09 +0100 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-pcep-mib-05.txt Thread-Index: AQHOgZ9YdmcvPGemGkGPzz2Rw7/3ZJlmO96g Date: Mon, 15 Jul 2013 21:11:09 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F049F@ENFICSMBX1.datcon.co.uk> References: <20130715210725.20105.14743.idtracker@ietfa.amsl.com> In-Reply-To: <20130715210725.20105.14743.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.145] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-mib-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:11:16 -0000 Dear PCE WG I have uploaded the latest version of the PCEP MIB. It resolves all commen= ts that I have received to date. Best regards Jon -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of inter= net-drafts@ietf.org Sent: 15 July 2013 22:07 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-mib-05.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : PCE communication protocol (PCEP) Management Information= Base Author(s) : A S Kiran Koushik Stephan Emile Quintin Zhao Daniel King Jonathan Hardwick Filename : draft-ietf-pce-pcep-mib-05.txt Pages : 46 Date : 2013-07-15 Abstract: This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-pcep-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From dhruv.dhody@huawei.com Wed Jul 17 10:57:37 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C149B21F8F78 for ; Wed, 17 Jul 2013 10:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDnbHTvp-Mcd for ; Wed, 17 Jul 2013 10:57:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 357D421E808A for ; Wed, 17 Jul 2013 10:57:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVD38620; Wed, 17 Jul 2013 17:57:24 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 18:56:44 +0100 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 18:57:09 +0100 Received: from blrprnc03ns (10.18.96.92) by szxeml413-hub.china.huawei.com (10.82.67.152) with Microsoft SMTP Server id 14.1.323.7; Thu, 18 Jul 2013 01:57:05 +0800 From: Dhruv Dhody To: Date: Wed, 17 Jul 2013 23:27:05 +0530 Organization: HTIPL Message-ID: <003c01ce8317$0caa58e0$25ff0aa0$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01CE8345.266294E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6DFwvw0rusks38Qbycai/9/SLibQ== Content-Language: en-us X-Originating-IP: [10.18.96.92] X-CFilter-Loop: Reflected Cc: pce@ietf.org Subject: [Pce] Comments for draft-ietf-pce-stateful-pce-05 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dhruv.dhody@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 17:57:37 -0000 ------=_NextPart_000_003D_01CE8345.266294E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, Please find comments on the new revision (-05). Regards, Dhruv ---Sec 2 Terminology: * There are lots of technical details in this section. IMO this section should just introduce the terms and point to relevant sections for more details. * State Timeout Interval: 'b)the PCC makes changes to the LSP state' - Do you mean that PCC takes control of the LSP state and get the LSP state either from a pre-configured default, or use local CSPF, or stateless/passive-stateful PCE etc and try to establish this new LSP state using make-before-break? Note the LSP state may turn out to be same as the one set by the active stateful PCE and this LSP state should not be flushed even though there is no change in the LSP state. * LSP State Database: This definition seems from the point of view of the PCC, IMHO a more generic definition would be better. ---Sec 5.4 State Synchronization: A small text may be added to suggest what should happen if PCC has no LSP state to synchronize. (Send PCRpt, PLSP-ID=0, SYNC=0) to notify sync end to the PCE which may still be waiting for state synchronization. ---Sec 5.4.1 State Synchronization Avoidance OLD: If a PCC's LSP State Database survived the restart, the PCC will include the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain the last LSP State Database version sent on an LSP State Report from the PCC in the previous PCEP session. NEW: If a PCC's LSP State Database survived the restart of a PCEP session, the PCC will include the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain the latest LSP State Database version sent on an LSP State Report from the PCC in the previous PCEP session. PCC should send the latest DB version to the PCE for state synchronization. ---Sec 5.5.4 Redundant Stateful PCEs: I suggest we use following terminology to avoid confusion, inline with [ietf-pce-questions-00] as well as other drafts. Primary or Backup PCE - Where a backup PCE exists to perform functions in the network, only in the event of a failure of the primary PCE. Load-Balanced PCE - share the computation load all the time. This way we could avoid confusion, such as the one mention in Xian's comment. ---Sec 6.1 The PCRpt Message * I also feel SRP should be an optional parameter as PCRpt is also sent without an update - e.g. passive; initial state sync; delegation; report to other stateful PCEs (all of them will use SRP-ID=0). * as defined in [RFC5440] which makes as a mandatory object, but in the first delegated message or for LSP down we will not have any path, in which case should be made optional. * Since PCRpt is also used for a delegation of a LSP which has been configured at the PCC, i feel object must be a part of PCRpt as an optional object to tell the source and destination just like PCReq * 'No state compression is allowed for state reporting (at PCC).' Can you clarify the intention for this? Do mean to say that for any LSP changes, that happen at PCC must be sent to PCE but in section 5.6.1 we say 'the PCC may choose to only send the PCRpt indicating the latest status ('Up' or 'Down').' ---Sec 6.2 The PCUpd Message * If stateful PCE cannot setup path or wants to set the LSP state non-operational/down, there will be no path and hence IMO should be optional here too. * OLD A PCC MAY respond with multiple LSP State Reports to report LSP setup progress of a single LSP. In that case, the SRP-ID-number MUST be included while the state of the LSP is "pending", afterwards the reserved value 0x00000000 SHOULD be used.. NEW A PCC MAY respond with multiple LSP State Reports to report LSP setup progress of a single LSP. In that case, the SRP-ID-number MUST be included in the first report message, afterwards the reserved value 0x00000000 SHOULD be used. Because PCC may choose to only send the PCRpt indicating the latest status ('Up' or 'Down') [section 5.6.1] ---Sec 6.3 The PCErr Message * RBNF is needed * Making SRP mandatory for all stateful PCE capable session is unnecessary. ---Sec 7.2 SRP Object * Is there any role of SRP in make-before-break success / failure cases? ---Sec 7.4 Optional TLVs for the LSPA Object A small text for need for TLVs in LSPA object would be useful? ----------------------Editorial: Introduction: s/Path Computation Element Protocol (PCEP./Path Computation Element Protocol (PCEP). Section 5.1 Expand: CLI Section 5.3 s/(PCE pr PCC)/(PCE or PCC) Sec 5.4 Figure 3: Successful state synchronization - the (Sync done) marker is at the wrong place. Sec 5.4.1 OLD: Note that a PCE MAY force State Synchronization by not including the LSP-DB-VERSION TLV in its OPEN object. NEW: Note that a PCC/PCE MAY force State Synchronization by not including the LSP-DB-VERSION TLV in its OPEN object. Sec 5.6.1 s/a single PC Reply/a single PCRep message Sec 6.2 s/LSP-IDENTIFIERS-TLV or the old path/LSP-IDENTIFIERS-TLV of the old path Sec 7.2 s/PCEerr messages/PCErr messages Sec 7.3 5-7 - Reserved: these values MUST be set to 0 on transmission and MUST be ignored on receipt. The above description is used for bit, not for values! Sec 7.3.5 OLD Since a PCE does not send LSP updates to a PCC, a PCC should never encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were it to receive one from a PCE. NEW Since a PCE does not update DB version, a PCC should never encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were it to receive one from a PCE. IMO 'send LSP updates' gets confusing with sending of PCUpd update message. Sec 8.5 TUNNEL-ID should be removed **************************************************************************** *** Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, Ph. +91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ------=_NextPart_000_003D_01CE8345.266294E0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please find comments on the new revision = (-05).

 

Regards,

Dhruv

 

---Sec 2 Terminology:

* There are lots of technical details in this section. IMO this = section should just introduce the terms and point to relevant sections = for more details.

* State Timeout Interval: 'b)the PCC makes changes to the LSP state' = -  Do you mean that PCC takes control of the LSP state and get the = LSP state either from a pre-configured default, or use local CSPF, or = stateless/passive-stateful PCE etc and try to establish this new LSP = state using make-before-break? Note the LSP state may turn out to be = same as the one set by the active stateful PCE and this LSP state should = not be flushed even though there is no change in the LSP state. =

* LSP State Database: This definition seems from the point of view of = the PCC, IMHO a more generic definition would be better. =

 

---Sec 5.4 State Synchronization:

A small text may be added to suggest what should happen if PCC has no = LSP state to synchronize. (Send PCRpt, PLSP-ID=3D0, SYNC=3D0) to notify = sync end to the PCE which may still be waiting for state = synchronization.

 

---Sec 5.4.1 State Synchronization Avoidance

OLD:

   If a

   PCC's LSP State Database survived the restart, the PCC = will include

   the LSP-DB-VERSION TLV in its OPEN object and the TLV = will contain

   the last LSP State Database version sent on an LSP State = Report from

   the PCC in the previous PCEP = session.

NEW:

   If a

   PCC's LSP State Database survived the restart of a PCEP = session, the PCC will include

   the LSP-DB-VERSION TLV in its OPEN object and the TLV = will contain

   the latest LSP State Database version sent on an LSP = State Report from

   the PCC in the previous PCEP session.   =

 

PCC should send the latest DB version to the PCE for state = synchronization.

 

---Sec 5.5.4 Redundant Stateful PCEs:

I suggest we use following terminology to avoid confusion, inline = with [ietf-pce-questions-00] as well as other drafts. =

Primary or Backup PCE - Where a backup PCE exists to perform = functions in the network, only in the event of a failure of the primary = PCE.

Load-Balanced PCE - share the computation load all the = time.

This way we could avoid confusion, such as the one mention in Xian's = comment.

 

---Sec 6.1 The PCRpt Message

* I also feel SRP should be an optional parameter as PCRpt is also = sent without an update – e.g. passive; initial state sync; = delegation; report to other stateful PCEs (all of them will use = SRP-ID=3D0).

* <path> as defined in [RFC5440] which makes <ERO> as a = mandatory object, but in the first delegated message or for LSP down we = will not have any path, in which case <ERO> should be made = optional.

* Since PCRpt is also used for a delegation of a LSP which has been = configured at the PCC, i feel <ENDPOINT> object must be a part of = PCRpt as an optional object to tell the source and destination just like = PCReq

* 'No state compression is allowed for state reporting (at PCC).' Can = you clarify the intention for this? Do mean to say that for any LSP = changes, that happen at PCC must be sent to PCE but in section 5.6.1 we = say 'the PCC may choose to only send the PCRpt indicating the latest = status ('Up' or 'Down').'

 

---Sec 6.2 The PCUpd Message

* If stateful PCE cannot setup path or wants to set the LSP state = non-operational/down, there will be no path and hence IMO <ERO> = should be optional here too.

* OLD

   A PCC MAY respond with multiple LSP = State

   Reports to report LSP setup progress of a single = LSP.  In that case,

   the SRP-ID-number MUST be included while the state of = the LSP is

   "pending", afterwards the reserved value = 0x00000000 SHOULD be used..

NEW

   A PCC MAY respond with multiple LSP = State

   Reports to report LSP setup progress of a single = LSP.  In that case,

   the SRP-ID-number MUST be included in the first report = message,

   afterwards the reserved value 0x00000000 SHOULD be = used.

 

Because PCC may choose to only send the PCRpt indicating the latest = status ('Up' or 'Down') [section 5.6.1]   =

 

---Sec 6.3 The PCErr Message

* RBNF is needed

* Making SRP mandatory for all stateful PCE capable session is = unnecessary.

 

---Sec 7.2 SRP Object

* Is there any role of SRP in make-before-break success / failure = cases?

 

---Sec 7.4 Optional TLVs for the LSPA Object

A small text for need for TLVs in LSPA object would be useful? =

   

----------------------Editorial:

 

Introduction:

s/Path Computation Element Protocol (PCEP./Path Computation Element = Protocol (PCEP).    

 

Section 5.1

Expand: CLI

 

Section 5.3

s/(PCE pr PCC)/(PCE or PCC)

 

Sec 5.4

Figure 3: Successful state synchronization - the (Sync done) marker = is at the wrong place.

 

Sec 5.4.1

OLD:

   Note that a PCE MAY force State Synchronization by not = including the

   LSP-DB-VERSION TLV in its OPEN = object.

NEW:

   Note that a PCC/PCE MAY force State Synchronization by = not including the

   LSP-DB-VERSION TLV in its OPEN = object.

 

Sec 5.6.1

s/a single PC Reply/a single PCRep message

 

Sec 6.2

s/LSP-IDENTIFIERS-TLV or the old path/LSP-IDENTIFIERS-TLV of the old = path

 

Sec 7.2

s/PCEerr messages/PCErr messages

 

Sec 7.3

5-7 - Reserved:  these values MUST be set to 0 on transmission = and

         MUST be ignored on = receipt.

The above description is used for bit, not for = values!   

 

Sec 7.3.5

OLD  

   Since a PCE does not send LSP updates to a PCC, a = PCC should never

   encounter this TLV.  A PCC SHOULD ignore the = LSP-DB-VERSION TLV, were

   it to receive one from a PCE.

NEW

   Since a PCE does not update DB version, a PCC should = never

   encounter this TLV.  A PCC SHOULD ignore the = LSP-DB-VERSION TLV, were

   it to receive one from a PCE.    =

   

IMO 'send LSP updates' gets confusing with sending of PCUpd update = message.        =

 

Sec 8.5

TUNNEL-ID should be removed

 

*****************= **************************************************************<= span lang=3DEN-IN = style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif";color:#48484= 8'>
= Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, = Ph. +91-9845062422

This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient's) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete = it!

 

------=_NextPart_000_003D_01CE8345.266294E0-- From dhruv.ietf@gmail.com Wed Jul 17 19:05:13 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F74F21F9D45 for ; Wed, 17 Jul 2013 19:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlNPdZJu+VTK for ; Wed, 17 Jul 2013 19:05:12 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5A15221F9C86 for ; Wed, 17 Jul 2013 19:05:12 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so5769045iec.33 for ; Wed, 17 Jul 2013 19:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=0DRi4F8Jr1nipy2Kj9pwXUicjVcUxv/PeefUdaV8Xys=; b=lB+eWF8fPP6KhB38nWDS4D8M3PeDQkb2Wx5jr2trRRs/8NhfAUJ85YvR/zKadblkPV VSi2Om/Pauk/HyvF2/11dN8FOZn5ulIlWkmikByyFGfYqlivDL9TqPSHmSLNQbhBMvJm bzqMOdMJX0fQAOPQFQ7nWoWeJYtos19WbJAXblFLXqwI87BQMawDtwKhC5x0H2KxgClx JYu6cr19iQlxlsZEEBHOR63TbTxuUJokgCysGxNzJ/JdnEB991Y2LMVUZn5UaV3eAaJA KO5yl6zn21Vth+jXO2hXvlJMFtshQypNSTHujvvOxN1PWZa0S/eosui3mUE9BZLLyLds 1xiw== MIME-Version: 1.0 X-Received: by 10.43.141.206 with SMTP id jf14mr5972520icc.8.1374113110766; Wed, 17 Jul 2013 19:05:10 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.152.176 with HTTP; Wed, 17 Jul 2013 19:05:10 -0700 (PDT) In-Reply-To: References: <20130705040734.6485.38423.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2013 07:35:10 +0530 X-Google-Sender-Auth: 7P01iqc_2pwgllO4VmKYqA1OEp0 Message-ID: From: Dhruv Dhody To: "pce@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2d478d93b9304e1bfa310 Subject: Re: [Pce] New Version Notification for draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 02:05:13 -0000 --001a11c2d478d93b9304e1bfa310 Content-Type: text/plain; charset=ISO-8859-1 Hi All, Wanted to clarify the motivation behind Auto-BW draft for stateful PCE. The aim of this extension is to (1) identify the LSP that would like to have this capability along with necessary information like BW range (2) provide current traffic flow information of such LSP to stateful PCE. We acknowledge that the stateful PCE may use other mechanism outside of PCEP to get this information but also believe that there is an inherent simplicity in doing this as a part of PCEP protocol. Comments and questions are always welcome. Dhruv On Mon, Jul 8, 2013 at 7:56 PM, Dhruv Dhody wrote: > Hi, > > Here is an update on the automatic bandwidth adjustment draft for stateful > PCE which allows the bandwidth adjustment of delegated LSP based on traffic > flow information collected via the PCEP protocol itself. > > Comments and questions are always welcome. > > Dhruv (on behalf of co-authors and contributors) > > > ---------- Forwarded message ---------- > From: > Date: Fri, Jul 5, 2013 at 9:37 AM > Subject: New Version Notification for > draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt > To: Dhruv Dhody , Dhruv Dhody < > dhruv.ietf@gmail.com>, Udayasree Palle > > > > A new version of I-D, draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt > has been successfully submitted by Dhruv Dhody and posted to the > IETF repository. > > Filename: draft-dhody-pce-stateful-pce-auto-bandwidth > Revision: 01 > Title: PCEP Extensions for MPLS-TE LSP Automatic Bandwidth > Adjustment with stateful PCE > Creation date: 2013-07-04 > Group: Individual Submission > Number of pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt > Status: > http://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidth > Htmlized: > http://tools.ietf.org/html/draft-dhody-pce-stateful-pce-auto-bandwidth-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-dhody-pce-stateful-pce-auto-bandwidth-01 > > Abstract: > The Path Computation Element Communication Protocol (PCEP) provides > mechanisms for Path Computation Elements (PCEs) to perform path > computations in response to Path Computation Clients (PCCs) requests. > The extensions described in [STATEFUL-PCE] provide stateful control > of Multiprotocol Label Switching (MPLS) Traffic Engineering Label > Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates > control over one or more locally configured LSPs to the PCE. > > This document describes the automatic bandwidth adjustment of such > LSPs under the stateful PCE model. > > > > > The IETF Secretariat > > > --001a11c2d478d93b9304e1bfa310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Al= l,=A0

<= /font>
Wante= d to clarify the motivation behind Auto-BW draft for stateful PCE. The aim = of this extension is to (1) identify the LSP that would like to have this c= apability along with necessary information like BW range (2) provide curren= t traffic flow information of such LSP to stateful PCE.=A0

=
We acknowledge th= at the stateful PCE may use other mechanism outside of PCEP to get this inf= ormation but also believe that there is an inherent simplicity in doing thi= s as a part of PCEP protocol. =A0 =A0

Comments and ques= tions are always welcome.=A0

Dhruv=A0=A0


On Mon,= Jul 8, 2013 at 7:56 PM, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
Hi,=A0

Here is an update on the=A0automati= c bandwidth adjustment=A0draft for stateful PCE which allows the bandwidth = adjustment of delegated LSP based on traffic flow information collected via= the PCEP protocol itself.=A0

Comments and questions are always welcome.=A0

Dhruv (on behalf of co-authors and=A0contributors)<= /font>


---------- Forwarded message ------= ----
From: <internet-drafts@i= etf.org>
Date: Fri, Jul 5, 2013 at 9:37 AM
Subject: New Version Notification for = draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt
To: Dhruv Dhody <<= a href=3D"mailto:dhruv.dhody@huawei.com" target=3D"_blank">dhruv.dhody@huaw= ei.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, Udayasree Palle <udayasree.palle@huawe= i.com>



A new version of I-D, draft-dhody-pce-stateful-pce-auto-bandwidth-01.txt has been successfully submitted by Dhruv Dhody and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dhody-pce-stateful-pce-auto-bandwidth
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 PCEP Extensions for MPLS-TE LSP Automatic Bandwi= dth Adjustment with stateful PCE
Creation date: =A0 2013-07-04
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 11
URL: =A0 =A0 =A0 =A0 =A0 =A0 http= ://www.ietf.org/internet-drafts/draft-dhody-pce-stateful-pce-auto-bandwidth= -01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidth
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-dhody-pce-stateful-pce-auto-bandwidth-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://ww= w.ietf.org/rfcdiff?url2=3Ddraft-dhody-pce-stateful-pce-auto-bandwidth-01

Abstract:
=A0 =A0The Path Computation Element Communication Protocol (PCEP) provides<= br> =A0 =A0mechanisms for Path Computation Elements (PCEs) to perform path
=A0 =A0computations in response to Path Computation Clients (PCCs) requests= .
=A0 =A0The extensions described in [STATEFUL-PCE] provide stateful control<= br> =A0 =A0of Multiprotocol Label Switching (MPLS) Traffic Engineering Label =A0 =A0Switched Paths (TE LSP) via PCEP, for a model where the PCC delegate= s
=A0 =A0control over one or more locally configured LSPs to the PCE.

=A0 =A0This document describes the automatic bandwidth adjustment of such =A0 =A0LSPs under the stateful PCE model.




The IETF Secretariat



--001a11c2d478d93b9304e1bfa310-- From olivier.dugeon@orange.com Thu Jul 18 01:34:08 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6F721E808D for ; Thu, 18 Jul 2013 01:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCgcN7nf8NeD for ; Thu, 18 Jul 2013 01:34:03 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8BB21F9F3A for ; Thu, 18 Jul 2013 01:34:00 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EA1D01074004 for ; Thu, 18 Jul 2013 10:34:59 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 00C751074003 for ; Thu, 18 Jul 2013 10:34:58 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 10:33:57 +0200 Received: from [10.193.71.138] ([10.193.71.138]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 10:33:57 +0200 Message-ID: <51E7A874.2080704@orange.com> Date: Thu, 18 Jul 2013 10:33:56 +0200 From: Olivier Dugeon Organization: Orange Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2013 08:33:57.0126 (UTC) FILETIME=[8B528260:01CE8391] Subject: [Pce] Comments on draft-crabbe-pce-pce-initiated-lsp-02 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 08:34:08 -0000 Dear authors, I read your draft carefullyand I have a global comment concerning LSP configuration on the Label Edge Router. Indeed, setting up the TE-LSP tunnel is not sufficient. The FEC must also be configured in order to correctly handle the traffic that input in the corresponding TE-LSPtunnel. I know and understand that take into account the FEC is somewhat out of scope the PCE charter and could be complicated, but, from an operational point of view, it will become very complex if I must used another protocol to configure the FEC. For example, used PCEP to setup the tunnel and then Netconf for the FEC. In this example, I win some time and simplify the solution by using only Netconf to setup the tunnel and the FEC. So, I would like to know if you think it would be appropriate to add support for the configuration of the FECinyour proposal draft? For example, the EndPoint Object allows simple FEC based on IP source and/or destination. Adding support for DSCP (EXP bits) could be useful as well as address mask for IP address e.g. I put all traffic that match DSCP= EFand subnet = a.b.c.d/z into this tunnel. Then, more complex FEC could be handle by adding informationon port number if necessary. Regards, Olivier -- Orange *Olivier Dugeon* OLNC/OLN/WTC/IEE Senior research engineer, QoS and network control Phone/Fax: +33 296 05 2880/1470 Mobile: +33 6 82 90 37 85 olivier.dugeon@orange.com From ina@juniper.net Thu Jul 18 10:32:51 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1162321F8F4F for ; Thu, 18 Jul 2013 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.933 X-Spam-Level: ** X-Spam-Status: No, score=2.933 tagged_above=-999 required=5 tests=[AWL=-2.044, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_56=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsmHoQf4GX2K for ; Thu, 18 Jul 2013 10:32:45 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id BE70621E8142 for ; Thu, 18 Jul 2013 10:32:40 -0700 (PDT) Received: from mail52-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 17:32:40 +0000 Received: from mail52-ch1 (localhost [127.0.0.1]) by mail52-ch1-R.bigfish.com (Postfix) with ESMTP id 4ACBA1E009F for ; Thu, 18 Jul 2013 17:32:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz9371Ic89bh936eI148cI542Iec9Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h1de096h8275dhz2fh2a8h683h839h941hd25hf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail52-ch1: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=ina@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail52-ch1 (localhost.localdomain [127.0.0.1]) by mail52-ch1 (MessageSwitch) id 1374168746556989_27504; Thu, 18 Jul 2013 17:32:26 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail52-ch1.bigfish.com (Postfix) with ESMTP id 7C0524E01C8 for ; Thu, 18 Jul 2013 17:32:26 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.50) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 18 Jul 2013 17:32:25 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 18 Jul 2013 10:32:24 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Thu, 18 Jul 2013 10:32:24 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.14) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 18 Jul 2013 10:45:32 -0700 Received: from mail91-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 17:32:22 +0000 Received: from mail91-va3 (localhost [127.0.0.1]) by mail91-va3-R.bigfish.com (Postfix) with ESMTP id E36E53202A6 for ; Thu, 18 Jul 2013 17:32:22 +0000 (UTC) Received: from mail91-va3 (localhost.localdomain [127.0.0.1]) by mail91-va3 (MessageSwitch) id 1374168710632289_436; Thu, 18 Jul 2013 17:31:50 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.250]) by mail91-va3.bigfish.com (Postfix) with ESMTP id 959404A00C9; Thu, 18 Jul 2013 17:31:50 +0000 (UTC) Received: from BLUPRD0511HT005.namprd05.prod.outlook.com (157.56.232.213) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 18 Jul 2013 17:31:44 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.142]) by BLUPRD0511HT005.namprd05.prod.outlook.com ([10.255.135.168]) with mapi id 14.16.0329.000; Thu, 18 Jul 2013 17:31:44 +0000 From: Ina Minei To: "Zhangxian (Xian)" , "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt Thread-Index: AQHOdqQ1coNUf2Eve0elhZ6tG3mFmplQXA9AgBCFY4CACKtqsA== Date: Thu, 18 Jul 2013 17:31:43 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD303827516@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <20130701214406.10273.42308.idtracker@ietfa.amsl.com>, <70BDAD02381BA54CA31315A2A26A7AD3037FAA51@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:32:51 -0000 SGVsbG8gWGlhbiwgDQoNClRoYW5rIHlvdSBmb3IgdGhlIHRob3JvdWdoIHJldmlldy4gUGxlYXNl IGZpbmQgYW5zd2VycyBpbmxpbmUgYmVsb3csIHRoZSBjb21tZW50cyBhY2NlcHRlZCB3ZXJlIGFs cmVhZHkgaW5jb3Jwb3JhdGVkIGluIHdoYXQgd2lsbCBiZWNvbWUgdmVyc2lvbiAwNiBvZiB0aGUg ZHJhZnQuIA0KDQpUaGFua3MgYSBsb3QgZm9yIHRoZSBjYXJlZnVsIHJlYWRpbmcgYW5kIHVzZWZ1 bCBmZWVkYmFjaywgDQoNCkluYSANCg0KW3NuaXBdDQoNCi1JbnRyb2R1Y3Rpb24NCiAqMm5kIHBh cmFncmFwaDogImJldHdlZW4gYW5kIGFjcm9zcyBQQ0VQIHNlc3Npb25zIiwgd2hhdCBkbyB5b3Ug aW50ZW5kIHRvIHNheT8gSXQgaXMgc2FtZSBhcyAid2l0aGluIGFuZCBhY3Jvc3MgUENFUCBzZXNz aW9ucyIgbWVudGlvbmVkIGxhdGVyPw0KW0luYV0gLSB5ZXMsIGFuZCBmaXhlZC4NCg0KLVRlcm1p bm9sb2d5DQogKmxhc3Qgc2VudGVuY2Ugb2YgZGVsZWdhdGlvbiBkZWZpbml0aW9uOiB3aGF0IGRv ZXMgaXQgd2FudCB0byBzYXk/IEl0IHNlZW1zIHRvIGltcGx5IHRoYXQgdGhlIGNvbnRyb2wgb2Yg TFNQIGNhbiBiZSBzaGlmdGVkIGZyb20gb25lIFBDQyB0byBhbm90aGVyIFBDQywgd2hpY2ggSSBi ZWxpZXZlIGlzIG5vdCB0cnVlLiBQbGVhc2UgY2xhcmlmeS4NCltJbmFdIFRoaXMgdGV4dCBpcyB1 bmNoYW5nZWQgc2luY2UgdmVyc2lvbiAwMy4gVGhlIGxhc3Qgc2VudGVuY2UgcmVhZHM6ICJBbiBM U1AgaXMgb3duZWQgYnkgYSBzaW5nbGUgUENDIGF0IGFueSBnaXZlbiBwb2ludCBpbiB0aW1lLiIg VGhpcyBjaGFuZ2Ugd2FzIHN1Z2dlc3RlZCBieSBKb24gSGFyZHdpY2ssIGFuZCBtZWFudCBhcyBh IGNsYXJpZmljYXRpb24gb2YgdGhlIHRleHQgZGlzY3Vzc2luZyBvd25lcnNoaXAgb2YgdGhlIExT UC4gSSdtIG5vdCBzdXJlIHdoeSBpdCBpbXBsaWVzIHRoYXQgdGhlIGNvbnRyb2wgY2FuIGJlIHNo aWZ0ZWQsIHRoYXQgaXMgbm90IHRoZSBpbnRlbnRpb24uIEFueSBzdWdnZXN0aW9uPw0KDQogKiJM U1AgUHJpb3JpdHk6IGEgc3BlY2lmaWMgcGFpciBvZiBNUExTIHNldHVwIGFuZCBob2xkIHByaW9y aXR5IHZhbHVlcyBhcyBkZWZpbmVkIGluIFtSRkMzMjA5XS4iLCBvbmx5IGFwcGxpZXMgdG8gTVBM Uz8gT3Igc2hvdWxkIGJlIGFwcGxpY2FibGUgYWxzbyB0byBHTVBMUz8NCltJbmFdIEFwcGxpY2Fi bGUgdG8gYm90aCwgYnV0IHRoaXMgdGVybWlub2xvZ3kgd2lsbCBiZSByZW1vdmVkIHdoZW4gdGhl IHVzZSBjYXNlcyBhcmUgcmVtb3ZlZCBvbmNlIHRoZSBhcHBsaWNhYmlsaXR5IGRyYWZ0IGlzIGFk b3B0ZWQuIEl0IHdhcyBpbmNsdWRlZCBmb3IgdGhlIHVzZSBjYXNlcyBpbiB0aGUgbW90aXZhdGlv biBzZWN0aW9uLiANCg0KICogYWRkICJQQ0VQIFNwZWFrZXIiIGluIHRoaXMgc2VjdGlvbj8gVGhp cyBwaHJhc2UgaXMgdXNlZCBxdWl0ZSBvZnRlbiANCltJbmFdIFBDRVAgc3BlYWtlciBpcyBhIHdl bGwga25vd24gdGVybSB1c2VkIGluIG11bHRpcGxlIFJGQ3MsIEkgZG9uJ3QgdGhpbmsgd2UgbmVl ZCB0byBhZGQgdG8gdGhlIHRlcm1pbm9sb2d5IChpdCBpcyB0aGVyZSBpbiA1NDQwIGZvciBleGFt cGxlKQ0KDQotU2VjdGlvbiA1LjQuMQ0KICogIldoZW4gU3RhdGUgU3luY2hyb25pemF0aW9uIGF2 b2lkYW5jZSBpcyBlbmFibGVkIG9uIGEgUENFUCBzZXNzaW9uLCBhIFBDQyBpbmNsdWRlcyB0aGUg TFNQLURCLVZFUlNJT04gVExWIGFzIGFuIG9wdGlvbmFsIFRMViBpbiB0aGUgTFNQIE9iamVjdCBv biBlYWNoIExTUCBTdGF0ZSIsIEkgZG8gbm90IHVuZGVyc3RhbmQgd2hhdCB0aGlzIHNlbnRlbmNl IHRyaWVzIHRvIHNheS4gV2hldGhlciB0byBza2lwIGEgc3RhdGUgc3luYy4gaXMgbm90IGFuIG9w dGlvbiwgYnV0IHJhdGhlciBkZWNpZGVkIGJ5IHRoZSBMU1Agc3RhdGUgREJ2LCByaWdodD8gDQpb SW5hXSBUaGUgc2VudGVuY2Ugc2F5cyB0aGF0IHRoZSBQQ0MgaW5jbHVkZXMgdGhlIFRMViBpbiB0 aGUgTFNQIG9iamVjdC4gTm90IHN1cmUgd2h5IHRoaXMgaW1wbGllcyBza2lwcGluZyBzdGF0ZSBz eW5jLiBJcyB0aGUgd29yZCAib3B0aW9uYWwgVExWIiB0aGUgc291cmNlIG9mIHRoZSBjb25mdXNp b24/DQoNCiAqIEZpZ3VyZSA3IGRvZXMgbm90IG1hdGNoIHRoZSB0ZXh0IGluIHRoaXMgc2VjdGlv bi4gIlB1cmdlIExTUCBzdGF0ZSIgaXMgZG9uZSBhdCB0aGUgZW5kIG9mIHRoZSBzdGF0ZSBzeW5j aHJvbml6YXRpb24sIGZyb20gdGhlIHRleHQgZGVzY3JpcHRpb24uIA0KW0luYV0gVGhhbmsgeW91 IGZvciBjYXRjaGluZyB0aGlzLCBmaXhlZC4NCg0KLVNlY3Rpb24gNS41LjQNCiAqICJ0aGUgYmFj a3VwIFBDRSBtYXkgaGF2ZSBvbmx5IGEgc3Vic2V0IG9mIExTUHMgZGVsZWdhdGVkIHRvIGl0LiAg VGhlIGJhY2t1cCBQQ0UgZG9lcyBub3QgdXBkYXRlIGFueSBMU1BzIHRoYXQgYXJlIG5vdCBkZWxl Z2F0ZWQgdG8gaXQsIiBXaGF0IGRvZXMgdGhlIGZpcnN0IHNlbnRlbmNlIGludGVuZCB0byBzYXk/ DQpbSW5hXSBJdCBtZWFucyB0aGF0IHRoZSBiYWNrdXAgbWF5IGJlIHByaW1hcnkgZm9yIGEgc3Vi c2V0IG9mIHRoZSBMU1BzIGluIHRoZSBuZXR3b3JrLiAoZXhhbXBsZSBiZWxvdykuIEkgdGhpbmsg dGhlIHdvcmQgIm9ubHkiIGlzIHRoZSBzb3VyY2Ugb2YgdGhlIGNvbmZ1c2lvbiwgY2xhcmlmaWVk IHRoZSB0ZXh0Lg0KDQogV2h5IGEgYmFja3VwIFBDRSB3aWxsIGhhdmUgTFNQcyBkZWxlZ2F0ZWQg dG8gaXQ/IEZvciB0aGUgMm5kIHNlbnRlbmNlLCBpcyBpdCB0cnlpbmcgdG8gZGVzY3JpYmUgdGhl IGJlaGF2aW9yIG9mIGJhY2t1cCBQQ0UgZHVyaW5nIHByaW1hcnkgUENFIGZhaWx1cmUgY29uZGl0 aW9uPyBJZiBub3QsIGkgZG8gbm90IHVuZGVyc3RhbmQgdW5kZXIgd2hhdCBjb25kaXRpb24gY2Fu IGEgYmFja3VwL3N0YW5kYnkgUENFIHVwZGF0ZSBMU1Agc3RhdHVzL3BhcmFtZXRlcnMuIFBsZWFz ZSBjbGFyaWZ5Lg0KW0luYV0gVHdvIFBDRXMsIFBDRTEgYW5kIFBDRTIgZXhpc3QgaW4gYSBuZXR3 b3JrLCBhbmQgMyBMU1BzIChMU1AxLCBMU1AyLCBMU1AzKSBleGlzdCBpbiB0aGUgbmV0d29yay4g TFNQMSBhbmQgTFNQMiBhcmUgZGVsZWdhdGVkIHRvIFBDRTEsIExTUDMgaXMgZGVsZWdhdGVkIHRv IFBDRTIuIFBDRTIgaXMgdGhlIGJhY2t1cCBmb3IgUENFMS4gU28gaW4gbm9ybWFsIG9wZXJhdGlv biwgdGhlIGJhY2t1cCBoYXMgb25seSBMU1AzIGRlbGVnYXRlZCB0byBpdCwgYW5kIGNhbm5vdCBj aGFuZ2UgTFNQMSBhbmQgTFNQMiwgYnV0IHdpbGwgcmVjZWl2ZSB0aGUgdXBkYXRlcyBvbiB0aGVp ciBzdGF0ZS4gSWYgUENFMSBmYWlscywgdGhlIFBDQyB3aWxsIHJlZGVsZWdhdGUgTFNQMSBhbmQg TFNQMiB0byBQQ0UyLiANCg0KLVNlY3Rpb24gNS41LjU6IA0KICogaG90LXN0YW5kYnkgUENFIGlz IG1lbnRpb25lZCwgd291bGQgYmUgZ29vZCB0byBleHBsYWluIGhvdyBpdCBpcyBkaWZmZXJlbnQg ZnJvbSB0aGUgYmFja3VwIFBDRS4NCltJbmFdIENsZWFuZWQgdXAgdGhlIHRleHQuIEhvdC1zdGFu ZGJ5IG1lYW5zIGl0IGlzIHJlYWR5IHRvIHRha2Ugb3Zlci4gDQoNCi1TZWN0aW9uIDYuMSAtIDYu MzoNCiAqIHRoZSBleHBsYW5hdGlvbiBvZiA8cGF0aD4gaW4gU2VjdGlvbiA2LjIgc2hvdWxkIGFs c28gYmUgaW5jbHVkZWQgaW4gU2VjdGlvbiA2LjE/IFRoZSBsZXZlbCBvZiBkZXRhaWxzIG9mIHRo ZSBSQk5GIGlzIG5vdCB0aGUgc2FtZSBpbiB0aGVzZSB0d28gc2VjdGlvbnMuICBEbyB5b3UgbWVh biB0aGUgdHdvIDxwYXRoPiBjb25zdHJ1Y3RzIGhhdmUgZGlmZmVyZW50IG1lYW5pbmc/IFRoYXQg d291bGQgYmUgY29uZnVzaW5nLg0KW0luYV0gVGhhbmsgeW91IGZvciBjYXRjaGluZy4gVGhlIGlu dGVudGlvbiBpcyBmb3IgdGhlbSB0byBiZSB0aGUgc2FtZSwgdGhpcyB3YXMgYW4gZWRpdGluZyBv dmVyc2lnaHQuIA0KDQogKiChsEluIHRoYXQgY2FzZSwgU1JQLUlELW51bWJlciBNVVNUIGJlIGlu Y2x1ZGVkIHdoaWxlIHRoZSBzdGF0ZSBvZiB0aGUgTFNQIGlzICJwZW5kaW5nIiwgYWZ0ZXJ3YXJk cyByZXNlcnZlZCB2YWx1ZSAweDAwMDAwMDAwIFNIT1VMRCBiZSB1c2VkLi4iIEkgZG8gbm90IHVu ZGVyc3RhbmQgd2hhdCB0aGlzIHNlbnRlbmNlIGlzIHRyeWluZyB0byBzYXksIGNvdWxkIHlvdSBl eHBsYWluIGEgYml0PyBUaGUgd29yZCAiYWZ0ZXJ3YXJkcyIgaXMgY29uZnVzaW5nLg0KW0luYV0g VGhlIHRleHQgaXMgZGlzY3Vzc2luZyBhIHNjZW5hcmlvIHdoZXJlIG11bHRpcGxlIHJlcG9ydCBt ZXNzYWdlcyBhcmUgZ2VuZXJhdGVkIGFzIGEgcmVzdWx0IG9mIGEgc2luZ2xlIHVwZGF0ZS4gVGhl IFNSUC1JRC1udW1iZXIgaXMgZWNob2VkIGluIHRoZSBmaXJzdCBvZiB0aGUgbWVzc2FnZXMsIHdo aWxlIHVuc29saWNpdGVkIHN1YnNlcXVlbnQgbWVzc2FnZXMgZ2V0IHRoZSB2YWx1ZSBvZiAwLiBO ZXcgdGV4dDoNCkEgUENDIE1BWSByZXNwb25kIHdpdGggbXVsdGlwbGUgTFNQIFN0YXRlIFJlcG9y dHMgdG8gcmVwb3J0DQogICAgICAgIExTUCBzZXR1cCBwcm9ncmVzcyBvZiBhIHNpbmdsZSBMU1Au IEluIHRoYXQgY2FzZSwgdGhlIFNSUC1JRC1udW1iZXIgTVVTVA0KICAgICAgICBiZSBpbmNsdWRl ZCBmb3IgdGhlIGZpcnN0IG1lc3NhZ2UsIGZvciBzdWJzZXF1ZW50IG1lc3NhZ2VzIHRoZQ0KICAg ICAgICByZXNlcnZlZCB2YWx1ZSAweDAwMDAwMDAwIFNIT1VMRCBiZSB1c2VkLg0KDQogKiBMYXN0 IHNlbnRlbmNlIGluIFNlY3Rpb24gNi4yIGlzIGluY29tcGxldGU/IElmIG11bHRpcGxlIEVycm9y IENvZGUgcG9zc2libGUsIGEgcmVmZXJlbmNlIHRvIHRoZSBzZWN0aW9uIHNwZWNpZnlpbmcgdGhl IGVycm9yIGNvZGUgd291bGQgYmUgdXNlZnVsLg0KW0luYV0gVGhhbmsgeW91IGZvciBjYXRjaGlu Zywgc2VjdGlvbiA3LjMuMyAobHNwLWVycm9yLWNvZGUgdGx2KSBpcyBhZGRlZCBhcyBhIHJlZmVy ZW5jZS4NCg0KDQogKiBJZiBQQ0UgaGFzIHRoZSBhYmlsaXR5IHRvIHB1dCBhIExTUCBpbiBub24t b3BlcmF0aW9uYWwgc3RhdGUoYXNzdW1lIGl0IHNob3VsZCBiZSBhY2NlcHRlZCBieSBhIFBDQyks IHdoeSBpdCB3b3VsZCBjYXVzZSBQQ0MgdG8gc2VuZCBhIFBDUnB0IGluY2x1ZGluZyBMU1AtRVJS T1ItVExWIGFzIHNwZWNpZmllZCBpbiBsYXN0IHNlbnRlbmNlIGluIFNlY3Rpb24gNi4xPw0KW0lu YV0gVGhlIHNlbnRlbmNlIHJlYWRzOiANCiJJZiB0aGUgTFNQIHRyYW5zaXRpb25lZCB0byBub24t b3BlcmF0aW9uYWwgc3RhdGUsIHRoZSBQQ0MgU0hPVUxEDQogICBpbmNsdWRlIHRoZSBMU1AtRVJS T1ItVExWIChTZWN0aW9uIDcuMy4zKSB3aXRoIHRoZSByZWxldmFudCBMU1AgRXJyb3INCiAgIENv ZGUgdG8gcmVwb3J0IHRoZSBlcnJvciB0byB0aGUgUENFLiINClRoaXMgdHJhbnNpdGlvbiBpcyBh IHJlc3VsdCBvZiBzb21lIGV2ZW50IHRoYXQgaGFwcGVuZWQgb24gdGhlIFBDQyAoZS5nLiBhbiBS U1ZQIGlzc3VlKSwgbm90IGJlY2F1c2Ugb2YgdGhlIFBDRSByZXF1ZXN0aW5nIHN0YXRlIHRyYW5z aXRpb24uIA0KDQotU2VjdGlvbiA2LjQgLSA2LjU6DQogKiJbSS1ELmlldGYtcGNlLWdtcGxzLXBj ZXAtZXh0ZW5zaW9uc10gaXMgZXh0ZW5kZWQgdG8gb3B0aW9uYWxseSBpbmNsdWRlIHRoZSBMU1Ag b2JqZWN0IGFmdGVyIHRoZSBFTkQtUE9JTlRTIG9iamVjdC4gIEZvciBpbGx1c3RyYXRpb24gcHVy cG9zZXMsIHRoZSBlbmNvZGluZyBmcm9tIFtSRkM1NDQwXSB3aWxsIGJlY29tZToiLCB3aGljaCBk cmFmdHMgeW91IGFyZSBiYXNlZD8gWW91IG1lbnRpb25lZCBleHRlbmRpbmcgR01QTFMtUENFUC1F eHRlbnNpb25zLCBidXQgdGhlIGVuY29kaW5nIGlzIHN0aWxsIGJhc2VkIG9uIFJGQzU0NDAuIFNh bWUgYXBwbGllcyBmb3IgU2VjdGlvbiA2LjUuIFRvIGF2b2lkIGNvbmZ1c2luZywgYmV0dGVyIGdl dCB0aGVtIGNvbnNpc3RlbnQuDQpbSW5hXSBUaGUgdGV4dCBzdGF0ZXMgImZvciBpbGx1c3RyYXRp b24gcHVycG9zZXMsIHRoZSBlbmNvZGluZyBmcm9tIHJmYzU0NDAgd2lsbCBiZWNvbWUuLi4iLiBU aGUgdGV4dCBkb2VzIG5vdCBhdHRlbXB0IHRvIHNob3cgd2hhdCB0aGUgZW5jb2RpbmcgZnJvbSB0 aGUgZ21wbHMgZHJhZnQgd2lsbCBiZWNvbWUgb25jZSB5b3UgaW5zZXJ0IHRoZSBsc3Agb2JqZWN0 IGFmdGVyIHRoZSBlbmQtcG9pbnRzIG9iamVjdC4gSSBjYW4gcmVtb3ZlIHRoZSByZWZlcmVuY2Ug dG8gdGhlIGdtcGxzLXBjZXAtZXh0ZW5zaW9ucyBhbmQgcmVmZXJlbmNlIHRoZSBnbXBscyBkcmFm dD8NCg0KICogSSB0aGluayBmb3IgZWFjaCBleHRlbnNpb24gcHJvdmlkZWQsIHRoZXJlIHNob3Vs ZCBiZSBhIG5lZWQvanVzdGlmaWNhdGlvbi4gSSBhbSBtdWNoIGluIGZhdm9yIG9mIHRoZXNlIGV4 dGVuc2lvbnMgc2luY2UgeW91IGNhbiBzZWUgdGhlIG1vdGl2YXRpb25zL3VzZSBjYXNlcyBkZXNj cmliZWQgaW4gW2RyYWZ0LXpoYW5nLXBjZS1wY2VwLXN0YXRlZnVsLXBjZS1nbXBsc10uIEhvd2V2 ZXIsIHRoZXNlIHR3byBzZWN0aW9ucyBzdGlsbCBsYWNrIG9mIHRoZSBtb3RpdmF0aW9uLiBNYXli ZSB5b3UgY2FuIHBvaW50IG1lIHRvIHJlbGV2YW50IHBvaW50cyBsaXN0ZWQgZWFybGllciBpbiB0 aGlzIGNvbnRyaWJ1dGlvbiBvciB0byB1c2UgdGhlIGJlZm9yZS1tZW50aW9uZWQgZHJhZnQ/DQpb SW5hXVNvcnJ5LCBJIGRvbid0IGZvbGxvdyB0aGUgY29tbWVudC4gQ2FuIHlvdSBwbGVhc2UgY2xh cmlmeT8NCg0KLVNlY3Rpb24gNzoNCiAqIKGwUENFIFJlZHVuZGFuY3kgR3JvdXAgSWRlbnRpZmll ciBUTFYiLCBJIHVuZGVyc3RhbmQgdGhlIG5lZWQgb2YgdGhpcy4gQnV0IEkgYW0gY29uZnVzZWQg YnkgdGhlIGV4cGxhbmF0aW9uIHByZXNlbnRlZCBpbiB0aGUgY3VycmVudCB0ZXh0LCBhYm91dCB0 aGUgdXNhZ2Ugb2YgdGhpcyBvcHRpb25hbCBUTFYuIEhvdyBjYW4gaXQgaGVscCB0byBkZWNpZGUg d2hldGhlciB0byBkbyBzdGF0ZSBzeW5jaHJvbml6YXRpb24gb3Igbm90PyBCeSB0aGUgdGltZSwg dGhlIFBDQyBhbmQgUENFIGVzdGFibGlzaCB0aGUgc2Vzc2lvbiBhbmQgc3RhcnQgZXhjaGFuZ2lu ZyBPUEVOLHRoZSBEQnYgaXMgdGhlIHBhcmFtZXRlciB0byBoZWxwIG1ha2UgYSBkZWNpc2lvbiwg cmlnaHQ/IA0KW0luYV0gVGhlIHJlZHVuZGFuY3kgZ3JvdXAgdGx2IHNlY3Rpb24gaXMgc3RpbGwg ZHVlIGZvciBjbGVhbnVwLCBidXQgd2FzIGRlZmVycmVkIHRvIHRoZSBuZXh0IHJldmlzaW9uLiBJ IHdpbGwgZGVmZXIgdGhpcyBkaXNjdXNzaW9uLiANCiANCg0KKiBXaHkgd2UgbmVlZCB0byBtYWtl IHRoaXMgU1JQIG5ld2x5IGRlZmluZWQgaW4gU2VjdGlvbiA3LjIgYXMgYSBNVVNUIGNhcnJpZWQg b2JqZWN0PyBJZiB0aGUgUENFIGlzIHBhc3NpdmUsIHRoZXJlIGlzIG5vIHN1Y2ggYSBuZWVkLCBy aWdodD8NCltJbmFdIFRoZSBTUlAgYWxsb3dzIGNvcnJlbGF0aW9uIG9mIGV2ZW50cyBhbmQgZXJy b3JzIGluIGEgcmVsaWFibGUgd2F5LiBUaGlzIGRyYWZ0IGlzIGZvY3VzZWQgb24gYWN0aXZlIHN0 YXRlZnVsLiBUaGUgbmVnb3RpYXRpb24gb2Ygc3VwcG9ydCBvZiBzdGF0ZWZ1bCBjYXBhYmlsaXR5 IGltcGxpZXMgYWN0aXZlIHN0YXRlZnVsICh0aGUgZXh0ZW5zaW9ucyBvZiB0aGlzIGRyYWZ0KS4g Rm9yIHBhc3NpdmUgc3RhdGVmdWwgdGhpcyBtYXkgbm90IGJlIGFkZGluZyBhbnkgdmFsdWUsIGJ1 dCBjdXJyZW50bHkgdGhlcmUgaXMgbm8gd2F5IHRvIGluZGljYXRlIHN1cHBvcnQgb2YgcGFzc2l2 ZSBtb2RlIG9ubHkuIA0KDQogKiBHaXZlbiB0aGUgZmFjdCB0aGF0IFNZTkMgYml0IGlzIHVzZWQg Zm9yIG5ldyBmdW5jdGlvbnMgKGZvcmNlZCBmdWxsIHN0YXRlIHN5bmNocm9uaXphdGlvbiBhZnRl ciB0aGUgc3RhdGVmdWwgUENFIGlzIGZ1bGx5IGZ1bmN0aW9uYWwpLiBUaGUgc3RhdGVtZW50ICJU aGUgUyBGbGFnIE1VU1QgYmUgc2V0IHRvIDAgb3RoZXJ3aXNlLiIgbm8gbG9uZ2VyIGhvbGRzIHRy dWUuIFBsZWFzZSB1cGRhdGUgdGhlbS4NCltJbmFdIFRoYW5rcyBmb3IgY2F0Y2hpbmc6IE5ldyB0 ZXh0ICJUaGUgUyBmbGFnIE1VU1QgYmUgc2V0IHRvIDAgaW4gb3RoZXIgUENScHQgbWVzc2FnZXMg c2VudCBieSB0aGUgUENDLiBUaGUgUyBmbGFnIE1BWSBiZSBzZXQgdG8gMSBieSB0aGUgUENFIGlu IGEgUENVcGQgbWVzc2FnZSAoc2VlIHNlY3Rpb24gNS40LjIpLiANCg0KDQogKiBJIGRvIG5vdCBz ZWUgYW55IGRldGFpbHMgb24gdGhlICJMU1Atc2lnLXR5cGUiIGFzIHRoYXQgb2YgdGhlIDMtYml0 IE8gYml0LiBCdXQgcmF0aGVyIHRoZXkgYXJlIG1lbnRpb25lZCBpbiBhIGxhdGVyIHNlY3Rpb24u IElmIHlvdSBwcmVmZXIgbm90IHRvIGR1cGxpY2F0ZSwgYXQgbGVhc3QgcmVmZXIgdG8gdGhhdCBz ZWN0aW9uIGFzIGN1cnJlbnRseSBkZWZpbmVkIGZvciB0aGlzIGZpZWxkLiBJIGRvIG5vdCB0aGlu ayB0aGlzIGNoYW5nZSBoYXMgZXZlciBiZWVuIGRpc2N1c3NlZCBiZWZvcmUsIHJpZ2h0PyAgU08g d2hhdCBpcyB0aGUgaW50ZW50aW9uIGZvciB0aGlzIG5ldyBmaWxlZD8NCltJbmFdIFRoZXJlIHdh cyBhIHJlcXVlc3QgdG8gbWFrZSB0aGlzIGdlbmVyaWMgZm9yIHN1cHBvcnQgb2YgTFNQcyB0aGF0 IGFyZSBub3QgbmVjZXNzYXJpbHkgUlNWUCBzaWduYWxlZCAoc2VlIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNpdmFiYWxhbi1wY2Utc2VnbWVudC1yb3V0aW5nLTAxIGZvciBhIHVz ZSBjYXNlKS4gVGhpcyBmaWVsZCB3aWxsIGxpa2VseSBiZWNvbWUgYSBUTFYgaW4gdGhlIG5leHQg cmV2aXNpb24sIHdpbGwgdXBkYXRlIHdoZW4gdGhpcyB0ZXh0IHdpbGwgY2hhbmdlLiANCg0KICog U2VjdGlvbiA3LjMuMSBlbmNvZGluZyBvZiBMU1AgaWRlbnRpZmllciBUTFYgaXMgd3JvbmcuIEV4 dGVuZGVkIFR1bm5lbCBJRCBpcyB1c3VhbGx5IGZpbGxlZCB3aXRoIHNvdXJjZSBhZGRyZXNzLiBT byBub3cgeW91IGVuZCB1cCB3aXRoIHR3byBzb3VyY2UgYWRkcmVzc2VzLCB3aGljaCBkbyBub3Qg bWFrZSBzZW5zZS4gSSB0aGluayBSYW1vbiByYWlzZWQgdGhlIGNvbW1lbnQgYmVmb3JlIGJ1dCB3 YXMgaWdub3JlZC4gU2luY2UgaGUgbWFkZSBhIHZhbGlkIHBvaW50LCBzbyBwbGVhc2UgY29uc2lk ZXIgdXBkYXRpbmcgdGhpcy4NCltJbmFdIEkgdGhpbmsgeW91IGFyZSBzdWdnZXN0aW5nIHRvIGlu Y2x1ZGUgdGhlIHR1bm5lbCByZW1vdGUgYWRkcmVzcyBpbiB0aGUgaWRlbnRpZmllciB0bHYsIHJp Z2h0PyBUaGlua2luZyBvZiBob3cgd2UgdXNlIHRoaXMgVExWIChhbHdheXMgdGFnZ2luZyBhbG9u ZyBhbiBMU1Agb2JqZWN0KSwgbm90IHN1cmUgd2h5IHdlIHdvdWxkIG5lZWQgdGhlIHJlbW90ZSBh ZGRyZXNzLiBXZSBkbyBuZWVkIHRoZSBvdGhlcnMgdG8gaWRlbnRpZnkgdGhlIGluc3RhbmNlIG9m IHRoZSBwYXRoLiBEbyB5b3UgaGF2ZSBhbm90aGVyIHVzZSBjYXNlIGluIG1pbmQ/DQoNCiAqIFdo YXQgaXMgdGhlIHJhdGlvbmFsZSB0byBhZGQgVHVubmVsIElEIFRMViBhbmQgU3ltYm9saWMgUGF0 aCBOYW1lIFRMViBiZWZvcmUgaW4gTFNQQSBvYmplY3Q/IEFuZCBub3csIEkgc2VlIHRoYXQgdGhl IGZpcnN0IFRMViBpcyBkZWxldGVkLCBhbmQgd2h5Pw0KW0luYV0gdHVubmVsIGlkIGlzIG5vdCBu ZWVkZWQgb25jZSB0aGVyZSBpcyBvbmx5IGEgc2luZ2xlIHBhdGggaW4gdGhlIGxzcCBvYmplY3Qu IFRoZXJlIHdhcyBhbiBvbGQgZGVwZW5kZW5jeSB3aXRoIHRoZSBwcm90ZWN0aW9uIGRyYWZ0LCB3 aGljaCBpcyBub3cgbm90IG5lY2Vzc2FyeSBhbmQgcmVtb3ZlZC4gDQoNCi0tLUVkaXRvcmlhbDoN Cg0KQWJzdHJhY3Q6DQotZXhwYW5kIE1QTFMtVEUsIEdNUExTIGFuZCBMU1Agc2luY2UgdGhleSBh cHBlYXIgZmlyc3QgdGltZSBpbiB0aGUgZHJhZnQ7DQoNCkludHJvZHVjdGlvbjoNCnMvYSBQYXRo IENvbnRyb2wgRWxlbWVudC9hIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCBzL2JldHdlZW4gUENF IGFuZCBQQ0UvYmV0d2VlbiBQQ0VzDQoNClRlcm1pbm9sb2d5Og0Kcy9pcyBhbiBleHRlbnNpb24g b2YgUGFzc2l2ZSBTdGF0ZWZ1bCBQQ0UvaXMgYW4gZXh0ZW5zaW9uIG9mIHBhc3NpdmUgc3RhdGVm dWwgUENFIHMvUmV2b2NhdGlvbiBBbiBvcGVyYXRpb24gL1Jldm9jYXRpb246IEFuIG9wZXJhdGlv biBzL2FuIG9wZXJhdGlvbiB3aGVyZSBhbiBBY3RpdmUgU3RhdGVmdWwgUENFIHJlcXVlc3RzIGEg UENDIC9BbiBvcGVyYXRpb24gd2hlcmUgYW4gYWN0aXZlIHN0YXRlZnVsIFBDRSByZXF1ZXN0cyBh IFBDQyBzLyBpbmZvcm1hdGlvbiBhYm91dCBhbmQgYXR0cmlidXRlcyAvIGluZm9ybWF0aW9uIGFi b3V0IGF0dHJpYnV0ZXMNCg0KU2VjdGlvbiAzLjI6DQpzL1BDQydzIExTUHMgaW4gdGhlIGV2ZW50 IFBDRS9QQ0MncyBMU1BzIGluIHRoZSBldmVudCBvZiBQQ0UNCg0KU2VjdGlvbiA0Og0Kcy9TZXZl cmFsIG5ldyBmdW5jdGlvbnMgd2lsbCBiZSByZXF1aXJlZCBpbi9TZXZlcmFsIG5ldyBmdW5jdGlv bnMgYXJlIHJlcXVpcmVkDQpbSW5hXSBhbGwgb2YgdGhlIGFib3ZlIG9rDQoNClNlY3Rpb24gNS4z Og0Kcy9JZiB0aGUgUENFUCBTcGVha2VycyBzdXBwb3J0IHRoZSBleHRlbnNpb25zIG9mIHRoaXMg ZHJhZnQvSWYgdGhlIFBDRVAgc3BlYWtlcnMgZG8gbm90IHN1cHBvcnQgdGhlIGV4dGVuc2lvbnMg b2YgdGhpcyBkcmFmdA0KW0luYV0gQWN0dWFsbHksIHRoZSB0ZXh0IGlzIGNvcnJlY3QuIElmIHRo ZSBzcGVha2VycyBkb24ndCBzdXBwb3J0IHRoaXMgZHJhZnQsIHRoZXkgY2Fubm90IHNlbmQgdGhl IHBjZXJyLiBJZiB0aGV5IHN1cHBvcnQgdGhpcyBkcmFmdCwgYnV0IGRpZG4ndCBuZWdvdGlhdGUg dGhlIHN1cHBvcnQsIHRoZXkgc2hvdWxkIHNlbmQgdGhpcyBlcnJvciAoaW5zdGVhZCBvZiBqdXN0 IGEgZ2VuZXJpYyBlcnJvciBtZXNzYWdlKQ0KDQpTZWN0aW9uIDUuNS41Og0Kcy9SZWRlbGVnYXRp b24gb24gUENFIGZhaWx1cmUvUmVkZWxlZ2F0aW9uIG9uIFBDRSBGYWlsdXJlIHMvd2l0aGluIHRo ZSBSZWRlbGVnYXRpb24gVGltZW91dCwvd2l0aGluIHRoZSByZWRlbGVnYXRpb24gdGltZW91dCBp bnRlcnZhbCwNCg0KU2VjdGlvbiA1Ljg6DQpzL0EgUGVybWFuZW50IFBDRVAgc2Vzc2lvbiAvQSBw ZXJtYW5lbnQgUENFUCBzZXNzaW9uDQoNClNlY3Rpb24gNi4yOg0Kcy90aGUgUENDIE1VU1QgcmVz cG9uZCB3aXRoIGFuIFBDRXJyIG1lc3NhZ2UvdGhlIFBDQyBNVVNUIHJlc3BvbmQgd2l0aCBhIFBD RXJyIG1lc3NhZ2UNCg0KU2VjdGlvbiA3LjM6DQpzL2R1cmluZyB3aGljaCB0aW1lIGZvciBhbiBS U1ZQLXNpZ25hbGVkIExTUC9kdXJpbmcgd2hpY2ggdGltZSBmb3IgYSBSU1ZQLXNpZ25hbGVkIExT UC4uLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7I yzogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW3BjZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEluYSBN aW5laSBbaW5hQGp1bmlwZXIubmV0XQ0Kt6LLzcqxvOQ6IDIwMTPE6jfUwjLI1SA1OjU0DQq1vTog cGNlQGlldGYub3JnDQrW98ziOiBSZTogW1BjZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1wY2Ut c3RhdGVmdWwtcGNlLTA1LnR4dA0KDQpWZXJzaW9uIDA1IG9mIHRoZSBkcmFmdCBhZGRyZXNzZXMg bWFueSBvZiB0aGUgaXNzdWVzIHJhaXNlZCBvbiB0aGUgbGlzdCwgaW4gcGFydGljdWxhcjogc3Vw cG9ydCBmb3IgbW9yZSByb2J1c3QgZXJyb3IgcmVwb3J0aW5nIGFuZCBjb3JyZWxhdGlvbiwgY2xh cmlmaWNhdGlvbnMgb24gdGhlIG1ha2UtYmVmb3JlLWJyZWFrIGJlaGF2aW9yIGFuZCBiZWhhdmlv ciB1bmRlciBmYWlsdXJlIGNvbmRpdGlvbnMuDQoNClJldmlldyBhbmQgY29tbWVudHMgYXJlIHdl bGNvbWUuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwY2UtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnDQpTZW50OiBNb25kYXksIEp1bHkgMDEsIDIwMTMgMjo0NCBQTQ0K VG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KQ2M6IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogW1Bj ZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTA1LnR4dA0KDQoNCkEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBQ YXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KICAg ICAgICBUaXRsZSAgICAgICAgICAgOiBQQ0VQIEV4dGVuc2lvbnMgZm9yIFN0YXRlZnVsIFBDRQ0K ICAgICAgICBBdXRob3IocykgICAgICAgOiBFZHdhcmQgQ3JhYmJlDQogICAgICAgICAgICAgICAg ICAgICAgICAgIEphbiBNZWR2ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgSW5hIE1pbmVp DQogICAgICAgICAgICAgICAgICAgICAgICAgIFJvYmVydCBWYXJnYQ0KICAgICAgICBGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtMDUudHh0DQogICAgICAgIFBh Z2VzICAgICAgICAgICA6IDYwDQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTMtMDctMDEN Cg0KQWJzdHJhY3Q6DQogICBUaGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IENvbW11bmljYXRp b24gUHJvdG9jb2wgKFBDRVApIHByb3ZpZGVzDQogICBtZWNoYW5pc21zIGZvciBQYXRoIENvbXB1 dGF0aW9uIEVsZW1lbnRzIChQQ0VzKSB0byBwZXJmb3JtIHBhdGgNCiAgIGNvbXB1dGF0aW9ucyBp biByZXNwb25zZSB0byBQYXRoIENvbXB1dGF0aW9uIENsaWVudHMgKFBDQ3MpIHJlcXVlc3RzLg0K DQogICBBbHRob3VnaCBQQ0VQIGV4cGxpY2l0bHkgbWFrZXMgbm8gYXNzdW1wdGlvbnMgcmVnYXJk aW5nIHRoZQ0KICAgaW5mb3JtYXRpb24gYXZhaWxhYmxlIHRvIHRoZSBQQ0UsIGl0IGFsc28gbWFr ZXMgbm8gcHJvdmlzaW9ucyBmb3INCiAgIHN5bmNocm9uaXphdGlvbiBvciBQQ0UgY29udHJvbCBv ZiB0aW1pbmcgYW5kIHNlcXVlbmNlIG9mIHBhdGgNCiAgIGNvbXB1dGF0aW9ucyB3aXRoaW4gYW5k IGFjcm9zcyBQQ0VQIHNlc3Npb25zLiAgVGhpcyBkb2N1bWVudA0KICAgZGVzY3JpYmVzIGEgc2V0 IG9mIGV4dGVuc2lvbnMgdG8gUENFUCB0byBlbmFibGUgc3RhdGVmdWwgY29udHJvbCBvZg0KICAg TVBMUy1URSBhbmQgR01QTFMgTFNQcyB2aWEgUENFUC4NCg0KDQoNClRoZSBJRVRGIGRhdGF0cmFj a2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlDQoNClRoZXJlJ3MgYWxzbyBh IGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTA1DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS0wNQ0KDQoNCkludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQo= From ina@juniper.net Thu Jul 18 10:45:27 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B7A21F9E6B for ; Thu, 18 Jul 2013 10:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.466 X-Spam-Level: X-Spam-Status: No, score=0.466 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7lkQ8bhF1eU for ; Thu, 18 Jul 2013 10:45:22 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id C0B1F11E8199 for ; Thu, 18 Jul 2013 10:45:21 -0700 (PDT) Received: from mail206-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 17:45:13 +0000 Received: from mail206-ch1 (localhost [127.0.0.1]) by mail206-ch1-R.bigfish.com (Postfix) with ESMTP id 0C8A71C01CB for ; Thu, 18 Jul 2013 17:45:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h1de096h8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail206-ch1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=ina@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail206-ch1 (localhost.localdomain [127.0.0.1]) by mail206-ch1 (MessageSwitch) id 1374169511316521_31984; Thu, 18 Jul 2013 17:45:11 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail206-ch1.bigfish.com (Postfix) with ESMTP id 47E1D40004F for ; Thu, 18 Jul 2013 17:45:11 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.52) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 18 Jul 2013 17:45:09 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 18 Jul 2013 10:45:09 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Thu, 18 Jul 2013 10:45:08 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.207) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 18 Jul 2013 10:49:45 -0700 Received: from mail65-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 17:45:06 +0000 Received: from mail65-am1 (localhost [127.0.0.1]) by mail65-am1-R.bigfish.com (Postfix) with ESMTP id C84561C02AA for ; Thu, 18 Jul 2013 17:45:06 +0000 (UTC) Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1 (MessageSwitch) id 1374169504913706_10271; Thu, 18 Jul 2013 17:45:04 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.236]) by mail65-am1.bigfish.com (Postfix) with ESMTP id D089660048; Thu, 18 Jul 2013 17:45:04 +0000 (UTC) Received: from BLUPRD0511HT005.namprd05.prod.outlook.com (157.56.232.213) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 18 Jul 2013 17:45:03 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.142]) by BLUPRD0511HT005.namprd05.prod.outlook.com ([10.255.135.168]) with mapi id 14.16.0329.000; Thu, 18 Jul 2013 17:44:59 +0000 From: Ina Minei To: Olivier Dugeon , "pce@ietf.org" Thread-Topic: [Pce] Comments on draft-crabbe-pce-pce-initiated-lsp-02 Thread-Index: AQHOg5GY+ABIlE/r80yTVh3EuD5FL5lqtFlw Date: Thu, 18 Jul 2013 17:44:58 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD30382754A@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <51E7A874.2080704@orange.com> In-Reply-To: <51E7A874.2080704@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Pce] Comments on draft-crabbe-pce-pce-initiated-lsp-02 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:45:28 -0000 Olivier,=20 Thank you for reading the new version. This draft is restricted to LSP init= iation. Mapping traffic to LSPs is a separate problem and is being discusse= d separately from this, unfortunately no proposal was available in time for= this IETF. You may also be interested in http://www.ietf.org/id/draft-tan= aka-pce-stateful-pce-data-ctrl-00.txt Will be happy to continue the discussion at the IETF,=20 Ina=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Olivi= er Dugeon Sent: Thursday, July 18, 2013 1:34 AM To: pce@ietf.org Subject: [Pce] Comments on draft-crabbe-pce-pce-initiated-lsp-02 Dear authors, I read your draft carefullyand I have a global comment concerning LSP confi= guration on the Label Edge Router. Indeed, setting up the TE-LSP tunnel is = not sufficient. The FEC must also be configured in order to correctly handl= e the traffic that input in the corresponding TE-LSPtunnel. I know and understand that take into account the FEC is somewhat out of sco= pe the PCE charter and could be complicated, but, from an operational point= of view, it will become very complex if I must used another protocol to co= nfigure the FEC. For example, used PCEP to setup the tunnel and then Netcon= f for the FEC. In this example, I win some time and simplify the solution b= y using only Netconf to setup the tunnel and the FEC. So, I would like to know if you think it would be appropriate to add suppor= t for the configuration of the FECinyour proposal draft? For example, the E= ndPoint Object allows simple FEC based on IP source and/or destination. Add= ing support for DSCP (EXP bits) could be useful as well as address mask for= IP address e.g. I put all traffic that match DSCP=3D EFand subnet =3D a.b.= c.d/z into this tunnel. Then, more complex FEC could be handle by adding in= formationon port number if necessary. Regards, Olivier --=20 Orange *Olivier Dugeon* OLNC/OLN/WTC/IEE Senior research engineer, QoS and network control Phone/Fax: +33 296 05 2880/1470 Mobile: +33 6 82 90 37 85 olivier.dugeon@orange.com _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From zali@cisco.com Thu Jul 18 10:56:30 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1A421F9A1D for ; Thu, 18 Jul 2013 10:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLJlyUYpm5Aj for ; Thu, 18 Jul 2013 10:56:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 997BB21E814C for ; Thu, 18 Jul 2013 10:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2584; q=dns/txt; s=iport; t=1374170173; x=1375379773; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=4wA6u2fSX4co3hTjwaDlH5TYv6GJatxOTCu0VoOTuaA=; b=IoY2fMXpQYujtzTLH8Qs78ajz+sYMbVx7jvgt29/BBNTlvn9q66IvDlS ccEkDZJ0OMGXfiLivtd34N0nAz3xwiu+xkaKVF9DJ9QikD0lmgBEc66NC 38Bx7iTjdAd66FwBbquVddZYwLZRuBHpOWYIZ6HD5/hwg7pu6OeWILZQK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFACkr6FGtJV2d/2dsb2JhbABagwY1UMBDgRIWdIIkAQEBAQMBAQFrFwYBCBEDAQILCxIuCxQJCAIEARIIEwOHcgy2NY9eOAYEgwRuA5QGhQCQJIMSgio X-IronPort-AV: E=Sophos;i="4.89,695,1367971200"; d="scan'208";a="236543135" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 18 Jul 2013 17:56:08 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6IHu8b4027066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 17:56:08 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 12:56:08 -0500 From: "Zafar Ali (zali)" To: Olivier Dugeon , "pce@ietf.org" Thread-Topic: [Pce] Comments on draft-crabbe-pce-pce-initiated-lsp-02 Thread-Index: AQHOg5GVKNBCuuXZlEWWBRVEKfDaj5lqycYA Date: Thu, 18 Jul 2013 17:56:08 +0000 Message-ID: In-Reply-To: <51E7A874.2080704@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.242.44] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] Comments on draft-crabbe-pce-pce-initiated-lsp-02 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:56:30 -0000 Hi Olivier: You may like to look at http://datatracker.ietf.org/doc/draft-ali-pce-remote-initiated-gmpls-lsp/. It has a section on LSP Usage. So far it addresses the following requirements. We can discuss more on this. - The target IGP instance for the Remote-initiated LSP needs to be specified. - Should the as Remote-initiated LSP be advertised an IPv4 FA/ RA, IPv6 FA/ RA or as unnumbered FA/ RA. - If Remote-initiated LSP is to be advertised an IPv4 FA/ RA, IPv6 FA/ RA, what is the local and remote IP address is to be used for the advertisement. =20 Thanks Regards =8A Zafar -----Original Message----- From: Olivier Dugeon Organization: Orange Labs Date: Thursday, July 18, 2013 4:33 AM To: "pce@ietf.org" Subject: [Pce] Comments on draft-crabbe-pce-pce-initiated-lsp-02 >Dear authors, > >I read your draft carefullyand I have a global comment concerning LSP >configuration on the Label Edge Router. Indeed, setting up the TE-LSP >tunnel is not sufficient. The FEC must also be configured in order to >correctly handle the traffic that input in the corresponding TE-LSPtunnel. > >I know and understand that take into account the FEC is somewhat out of >scope the PCE charter and could be complicated, but, from an operational >point of view, it will become very complex if I must used another >protocol to configure the FEC. For example, used PCEP to setup the >tunnel and then Netconf for the FEC. In this example, I win some time >and simplify the solution by using only Netconf to setup the tunnel and >the FEC. > >So, I would like to know if you think it would be appropriate to add >support for the configuration of the FECinyour proposal draft? For >example, the EndPoint Object allows simple FEC based on IP source and/or >destination. Adding support for DSCP (EXP bits) could be useful as well >as address mask for IP address e.g. I put all traffic that match DSCP=3D >EFand subnet =3D a.b.c.d/z into this tunnel. Then, more complex FEC could >be handle by adding informationon port number if necessary. > >Regards, > >Olivier >--=20 > >Orange > >*Olivier Dugeon* >OLNC/OLN/WTC/IEE >Senior research engineer, QoS and network control >Phone/Fax: +33 296 05 2880/1470 >Mobile: +33 6 82 90 37 85 >olivier.dugeon@orange.com > >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce From ina@juniper.net Thu Jul 18 12:32:38 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADE511E81D6 for ; Thu, 18 Jul 2013 12:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.363 X-Spam-Level: * X-Spam-Status: No, score=1.363 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ-s7T2chLAc for ; Thu, 18 Jul 2013 12:32:31 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 37F6711E81CC for ; Thu, 18 Jul 2013 12:32:31 -0700 (PDT) Received: from mail204-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 19:32:29 +0000 Received: from mail204-ch1 (localhost [127.0.0.1]) by mail204-ch1-R.bigfish.com (Postfix) with ESMTP id 3967540028E for ; Thu, 18 Jul 2013 19:32:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 10 X-BigFish: VPS10(zzc85fhec9Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h17326ah18c673h1c8fb4h1de097h1de096h8275bh8275dh11f642sz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail204-ch1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=ina@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail204-ch1 (localhost.localdomain [127.0.0.1]) by mail204-ch1 (MessageSwitch) id 1374175929935653_20686; Thu, 18 Jul 2013 19:32:09 +0000 (UTC) Received: from CH1EHSMHS040.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail204-ch1.bigfish.com (Postfix) with ESMTP id D13121E004A for ; Thu, 18 Jul 2013 19:32:09 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.52) by CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 18 Jul 2013 19:32:09 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 18 Jul 2013 12:32:08 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Thu, 18 Jul 2013 12:32:08 -0700 Received: from DB8EHSOBE028.bigfish.com (213.199.154.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 18 Jul 2013 12:45:15 -0700 Received: from mail152-db8-R.bigfish.com (10.174.8.250) by DB8EHSOBE028.bigfish.com (10.174.4.91) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 19:32:05 +0000 Received: from mail152-db8 (localhost [127.0.0.1]) by mail152-db8-R.bigfish.com (Postfix) with ESMTP id A7D1820254 for ; Thu, 18 Jul 2013 19:32:05 +0000 (UTC) Received: from mail152-db8 (localhost.localdomain [127.0.0.1]) by mail152-db8 (MessageSwitch) id 1374175873219874_5351; Thu, 18 Jul 2013 19:31:13 +0000 (UTC) Received: from DB8EHSMHS016.bigfish.com (unknown [10.174.8.240]) by mail152-db8.bigfish.com (Postfix) with ESMTP id 0B1F54A0053; Thu, 18 Jul 2013 19:30:54 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by DB8EHSMHS016.bigfish.com (10.174.4.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 18 Jul 2013 19:30:53 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.142]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0329.000; Thu, 18 Jul 2013 19:30:52 +0000 From: Ina Minei To: "dhruv.dhody@huawei.com" , "draft-ietf-pce-stateful-pce@tools.ietf.org" Thread-Topic: Comments for draft-ietf-pce-stateful-pce-05 Thread-Index: Ac6DFwvw0rusks38Qbycai/9/SLibQAyRjJA Date: Thu, 18 Jul 2013 19:30:51 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3038275F7@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <003c01ce8317$0caa58e0$25ff0aa0$@dhody@huawei.com> In-Reply-To: <003c01ce8317$0caa58e0$25ff0aa0$@dhody@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: multipart/alternative; boundary="_000_70BDAD02381BA54CA31315A2A26A7AD3038275F7BLUPRD0511MB436_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "pce@ietf.org" Subject: Re: [Pce] Comments for draft-ietf-pce-stateful-pce-05 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:32:38 -0000 --_000_70BDAD02381BA54CA31315A2A26A7AD3038275F7BLUPRD0511MB436_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dhruv, Thank you for the careful review, please find answers inline. The comments = accepted are already incorporated in what will become version 06 of the dra= ft. Thank you, Ina [snip] ---Sec 2 Terminology: * There are lots of technical details in this section. IMO this section sho= uld just introduce the terms and point to relevant sections for more detail= s. [Ina] I think you mean the section on state cleanup - shortened by removing= the cases and the reference on the duration of the timer (these are discus= sed in the text) * State Timeout Interval: 'b)the PCC makes changes to the LSP state' - Do = you mean that PCC takes control of the LSP state and get the LSP state eith= er from a pre-configured default, or use local CSPF, or stateless/passive-s= tateful PCE etc and try to establish this new LSP state using make-before-b= reak? Note the LSP state may turn out to be same as the one set by the acti= ve stateful PCE and this LSP state should not be flushed even though there = is no change in the LSP state. [Ina] yes, that is exactly right. I have added this in a subsequent section * LSP State Database: This definition seems from the point of view of the P= CC, IMHO a more generic definition would be better. [Ina] Yes, you are right. How about "information about all lsps and their a= ttributes". ---Sec 5.4 State Synchronization: A small text may be added to suggest what should happen if PCC has no LSP s= tate to synchronize. (Send PCRpt, PLSP-ID=3D0, SYNC=3D0) to notify sync end= to the PCE which may still be waiting for state synchronization. [Ina] Ok, done. ---Sec 5.4.1 State Synchronization Avoidance OLD: If a PCC's LSP State Database survived the restart, the PCC will include the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain the last LSP State Database version sent on an LSP State Report from the PCC in the previous PCEP session. NEW: If a PCC's LSP State Database survived the restart of a PCEP session, the PCC= will include the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain the latest LSP State Database version sent on an LSP State Report from the PCC in the previous PCEP session. [Ina] Ok. PCC should send the latest DB version to the PCE for state synchronization. ---Sec 5.5.4 Redundant Stateful PCEs: I suggest we use following terminology to avoid confusion, inline with [iet= f-pce-questions-00] as well as other drafts. Primary or Backup PCE - Where a backup PCE exists to perform functions in t= he network, only in the event of a failure of the primary PCE. Load-Balanced PCE - share the computation load all the time. This way we could avoid confusion, such as the one mention in Xian's commen= t. [Ina] But the text talks about a load-balanced pce where one is also perfor= ming a backup function. ---Sec 6.1 The PCRpt Message * I also feel SRP should be an optional parameter as PCRpt is also sent wit= hout an update - e.g. passive; initial state sync; delegation; report to ot= her stateful PCEs (all of them will use SRP-ID=3D0). [Ina] If it is made optional, there is no way to ensure that it is present = in the cases when it is needed. * as defined in [RFC5440] which makes as a mandatory object, b= ut in the first delegated message or for LSP down we will not have any path= , in which case should be made optional * Since PCRpt is also used for a delegation of a LSP which has been configu= red at the PCC, i feel object must be a part of PCRpt as an opti= onal object to tell the source and destination just like PCReq [Ina] I will discuss these proposals with the co-authors at the upcoming ie= tf and get back afterwards. * 'No state compression is allowed for state reporting (at PCC).' Can you c= larify the intention for this? Do mean to say that for any LSP changes, tha= t happen at PCC must be sent to PCE but in section 5.6.1 we say 'the PCC ma= y choose to only send the PCRpt indicating the latest status ('Up' or 'Down= ').' [Ina] If you received two requests LSP1 - new bw and LSP1 new path you hav= e to send two reports, one for each of these operations. If there is one re= quest, but the lsp goes through multiple phases to arrive there, you can re= port just the final phase. ---Sec 6.2 The PCUpd Message * If stateful PCE cannot setup path or wants to set the LSP state non-opera= tional/down, there will be no path and hence IMO should be optional h= ere too. * OLD A PCC MAY respond with multiple LSP State Reports to report LSP setup progress of a single LSP. In that case, the SRP-ID-number MUST be included while the state of the LSP is "pending", afterwards the reserved value 0x00000000 SHOULD be used.. NEW A PCC MAY respond with multiple LSP State Reports to report LSP setup progress of a single LSP. In that case, the SRP-ID-number MUST be included in the first report message, afterwards the reserved value 0x00000000 SHOULD be used. [Ina] Yes, I changed along these lines following Xian's comment Because PCC may choose to only send the PCRpt indicating the latest status = ('Up' or 'Down') [section 5.6.1] ---Sec 6.3 The PCErr Message * RBNF is needed [Ina] Good point, thank you for bringing this up. * Making SRP mandatory for all stateful PCE capable session is unnecessary. [Ina] Please explain the second point, while bearing in mind that this draf= t is for active stateful pce (negotiation of the capability means active st= ateful, there is no way to signal passive stateful) ---Sec 7.2 SRP Object * Is there any role of SRP in make-before-break success / failure cases? [Ina] Let's say you ask for a reoptimization, but the new path fails becaus= e there is an RSVP setup error. An error must be generated that relates thi= s failure to the PCupd message that required the optimization. ---Sec 7.4 Optional TLVs for the LSPA Object A small text for need for TLVs in LSPA object would be useful? [Ina]Not sure I follow. The lspa object has optional tlvs. The symbolic nam= e can be added as one of these optional tlvs. Was the question why is the = symbolic name one of the optional tlvs? ----------------------Editorial: Introduction: s/Path Computation Element Protocol (PCEP./Path Computation Element Protoco= l (PCEP). Section 5.1 Expand: CLI Section 5.3 s/(PCE pr PCC)/(PCE or PCC) Sec 5.4 Figure 3: Successful state synchronization - the (Sync done) marker is at t= he wrong place. Sec 5.4.1 OLD: Note that a PCE MAY force State Synchronization by not including the LSP-DB-VERSION TLV in its OPEN object. NEW: Note that a PCC/PCE MAY force State Synchronization by not including the LSP-DB-VERSION TLV in its OPEN object. Sec 5.6.1 s/a single PC Reply/a single PCRep message Sec 6.2 s/LSP-IDENTIFIERS-TLV or the old path/LSP-IDENTIFIERS-TLV of the old path Sec 7.2 s/PCEerr messages/PCErr messages [Ina] Thank you, fixed for all the above Sec 7.3 5-7 - Reserved: these values MUST be set to 0 on transmission and MUST be ignored on receipt. The above description is used for bit, not for values! [Ina] I don't agree, please see rfc3209 which makes use of plenty of reserv= ed values Sec 7.3.5 OLD Since a PCE does not send LSP updates to a PCC, a PCC should never encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were it to receive one from a PCE. NEW Since a PCE does not update DB version, a PCC should never encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were it to receive one from a PCE. IMO 'send LSP updates' gets confusing with sending of PCUpd update message. [Ina] Agree, reworded. Sec 8.5 TUNNEL-ID should be removed [Ina] - Thank you for catching ***************************************************************************= **** Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, Ph. += 91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! --_000_70BDAD02381BA54CA31315A2A26A7AD3038275F7BLUPRD0511MB436_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dhruv,

 

Thank you for the care= ful review, please find answers inline. The comments accepted are already i= ncorporated in what will become version 06 of the draft.

 

Thank you, =

 

Ina =

 

[snip]

 

---Sec 2 Terminology:

* There are lots of techn= ical details in this section. IMO this section should just introduce the te= rms and point to relevant sections for more details.

[Ina] I think you mean= the section on state cleanup - shortened by removing the cases and the ref= erence on the duration of the timer (these are discussed in the text)<= /o:p>

 

* State Timeout Interval:= 'b)the PCC makes changes to the LSP state' -  Do you mean that PCC ta= kes control of the LSP state and get the LSP state either from a pre-configured default, or use local CSPF, or stateless/passive-stateful= PCE etc and try to establish this new LSP state using make-before-break? N= ote the LSP state may turn out to be same as the one set by the active stat= eful PCE and this LSP state should not be flushed even though there is no change in the LSP state.

[Ina] yes, that is exa= ctly right. I have added this in a subsequent section

 

* LSP State Database: Thi= s definition seems from the point of view of the PCC, IMHO a more generic d= efinition would be better.

[Ina] Yes, you are rig= ht. How about “information about all lsps and their attributes”= .

 

 <= /p>

---Sec 5.4 State Synchron= ization:

A small text may be added= to suggest what should happen if PCC has no LSP state to synchronize. (Sen= d PCRpt, PLSP-ID=3D0, SYNC=3D0) to notify sync end to the PCE which may still be waiting for state synchronization.

[Ina] Ok, done.

 

---Sec 5.4.1 State Synchr= onization Avoidance

OLD:

   If a

   PCC's LSP St= ate Database survived the restart, the PCC will include

   the LSP-DB-V= ERSION TLV in its OPEN object and the TLV will contain

   the last LSP= State Database version sent on an LSP State Report from<= /p>

   the PCC in t= he previous PCEP session.

NEW:

   If a

   PCC's LSP St= ate Database survived the restart of a PCEP session, the PCC will include

   the LSP-DB-V= ERSION TLV in its OPEN object and the TLV will contain

   the latest L= SP State Database version sent on an LSP State Report from

   the PCC in t= he previous PCEP session.  

[Ina] Ok.

 

PCC should send the lates= t DB version to the PCE for state synchronization.

 <= /p>

---Sec 5.5.4 Redundant St= ateful PCEs:

I suggest we use followin= g terminology to avoid confusion, inline with [ietf-pce-questions-00] as we= ll as other drafts.

Primary or Backup PCE - W= here a backup PCE exists to perform functions in the network, only in the e= vent of a failure of the primary PCE.

Load-Balanced PCE - share= the computation load all the time.

This way we could avoid c= onfusion, such as the one mention in Xian's comment.

[Ina] But the text tal= ks about a load-balanced pce where one is also performing a backup function= .

 <= /p>

---Sec 6.1 The PCRpt Mess= age

* I also feel SRP should = be an optional parameter as PCRpt is also sent without an update – e.= g. passive; initial state sync; delegation; report to other stateful PCEs (all of them will use SRP-ID=3D0).

[Ina] If it is made op= tional, there is no way to ensure that it is present in the cases when it i= s needed.

 

* <path> as defined= in [RFC5440] which makes <ERO> as a mandatory object, but in the fir= st delegated message or for LSP down we will not have any path, in which case <ERO> should be made optional

* Since PCRpt is also use= d for a delegation of a LSP which has been configured at the PCC, i feel &l= t;ENDPOINT> object must be a part of PCRpt as an optional object to tell the source and destination just like PCReq

[Ina] I will discuss t= hese proposals with the co-authors at the upcoming ietf and get back afterw= ards.

 

* 'No state compression i= s allowed for state reporting (at PCC).' Can you clarify the intention for = this? Do mean to say that for any LSP changes, that happen at PCC must be sent to PCE but in section 5.6.1 we say 'the PCC may choose= to only send the PCRpt indicating the latest status ('Up' or 'Down').'

[Ina] If you received = two requests LSP1 – new bw  and LSP1 new path you have to send t= wo reports, one for each of these operations. If there is one request, but = the lsp goes through multiple phases to arrive there, you can report just the final phase.

 <= /p>

---Sec 6.2 The PCUpd Mess= age

* If stateful PCE cannot = setup path or wants to set the LSP state non-operational/down, there will b= e no path and hence IMO <ERO> should be optional here too.=

 

 

* OLD

   A PCC MAY re= spond with multiple LSP State

   Reports to r= eport LSP setup progress of a single LSP.  In that case,

   the SRP-ID-n= umber MUST be included while the state of the LSP is

   "pendin= g", afterwards the reserved value 0x00000000 SHOULD be used..

NEW

   A PCC MAY re= spond with multiple LSP State

   Reports to r= eport LSP setup progress of a single LSP.  In that case,

   the SRP-ID-n= umber MUST be included in the first report message,

   afterwards t= he reserved value 0x00000000 SHOULD be used.

[Ina] Yes, I changed a= long these lines following Xian’s comment

 <= /p>

Because PCC may choose to= only send the PCRpt indicating the latest status ('Up' or 'Down') [section= 5.6.1]  

 <= /p>

---Sec 6.3 The PCErr Mess= age

* RBNF is needed

[Ina]  Good point= , thank you for bringing this up.

* Making SRP mandatory fo= r all stateful PCE capable session is unnecessary.

[Ina] Please explain t= he second point, while bearing in mind that this draft is for active statef= ul pce (negotiation of the capability means active stateful, there is no wa= y to signal passive stateful)

 <= /p>

---Sec 7.2 SRP Object

* Is there any role of SR= P in make-before-break success / failure cases?

[Ina] Let’s say = you ask for a reoptimization, but the new path fails because there is an RS= VP setup error. An error must be generated that relates this failure to the= PCupd message that required the optimization.

 <= /p>

---Sec 7.4 Optional TLVs = for the LSPA Object

A small text for need for= TLVs in LSPA object would be useful?

[Ina]Not sure I follow= . The lspa object has optional tlvs. The symbolic name can be added as one = of these optional tlvs.  Was the question why is the symbolic name one= of the optional tlvs?

   

----------------------= Editorial:

 <= /p>

Introduction:<= /span>

s/Path Computation Elemen= t Protocol (PCEP./Path Computation Element Protocol (PCEP).  &nbs= p; 

 <= /p>

Section 5.1

Expand: CLI

 <= /p>

Section 5.3

s/(PCE pr PCC)/(PCE or PC= C)

 <= /p>

Sec 5.4=

Figure 3: Successful stat= e synchronization - the (Sync done) marker is at the wrong place.

 <= /p>

Sec 5.4.1

OLD:

   Note that a = PCE MAY force State Synchronization by not including the<= /p>

   LSP-DB-VERSI= ON TLV in its OPEN object.

NEW:

   Note that a = PCC/PCE MAY force State Synchronization by not including the

   LSP-DB-VERSI= ON TLV in its OPEN object.

 <= /p>

Sec 5.6.1

s/a single PC Reply/a sin= gle PCRep message

 <= /p>

Sec 6.2=

s/LSP-IDENTIFIERS-TLV or = the old path/LSP-IDENTIFIERS-TLV of the old path

 <= /p>

Sec 7.2=

s/PCEerr messages/PCErr m= essages

[Ina] Thank you, fixed fo= r all the above

 

Sec 7.3=

5-7 - Reserved:  the= se values MUST be set to 0 on transmission and

    &= nbsp;    MUST be ignored on receipt.

The above description is = used for bit, not for values!   

[Ina] I don’t ag= ree, please see rfc3209 which makes use of plenty of reserved values

 <= /p>

Sec 7.3.5

OLD  

   Since a= PCE does not send LSP updates to a PCC, a PCC should never

   encounter th= is TLV.  A PCC SHOULD ignore the LSP-DB-VERSION TLV, were

   it to receiv= e one from a PCE.

NEW

   Since a PCE = does not update DB version, a PCC should never

   encounter th= is TLV.  A PCC SHOULD ignore the LSP-DB-VERSION TLV, were

   it to receiv= e one from a PCE.   

   

IMO 'send LSP updates' ge= ts confusing with sending of PCUpd update message.    &= nbsp;  

[Ina] Agree, reworded.

 

Sec 8.5=

TUNNEL-ID should be remov= ed

[Ina] – Thank yo= u for catching

 <= /p>

********************************************= ***********************************
Dhruv Dhody, System Archi= tect, Huawei Technologies, Bangalore, India, Ph. +91-9845062422

This e-mail and attach= ments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any = use of the information contained herein in any way (including, but not limi= ted to, total or partial disclosure, reproduction, or dissemination) by per= sons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the send= er by phone or email immediately and delete it!

 

--_000_70BDAD02381BA54CA31315A2A26A7AD3038275F7BLUPRD0511MB436_-- From dhruv.dhody@huawei.com Fri Jul 19 03:00:21 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D878C21E8098 for ; Fri, 19 Jul 2013 03:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNuPCoPUfniW for ; Fri, 19 Jul 2013 03:00:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEC421E8095 for ; Fri, 19 Jul 2013 03:00:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVF33966; Fri, 19 Jul 2013 10:00:12 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 10:59:24 +0100 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 11:00:06 +0100 Received: from blrprnc03ns (10.18.96.92) by SZXEML454-HUB.china.huawei.com (10.82.67.197) with Microsoft SMTP Server id 14.1.323.7; Fri, 19 Jul 2013 17:59:59 +0800 From: Dhruv Dhody To: "'Ina Minei'" , References: <003c01ce8317$0caa58e0$25ff0aa0$@dhody@huawei.com> <70BDAD02381BA54CA31315A2A26A7AD3038275F7@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD3038275F7@BLUPRD0511MB436.namprd05.prod.outlook.com> Date: Fri, 19 Jul 2013 15:29:58 +0530 Organization: HTIPL Message-ID: <00b401ce8466$babea530$303bef90$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01CE8494.D476E130" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6DFwvw0rusks38Qbycai/9/SLibQAyRjJAABcUO7A= Content-Language: en-us X-Originating-IP: [10.18.96.92] X-CFilter-Loop: Reflected Cc: pce@ietf.org Subject: Re: [Pce] Comments for draft-ietf-pce-stateful-pce-05 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dhruv.dhody@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 10:00:22 -0000 ------=_NextPart_000_00B5_01CE8494.D476E130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ina, Thanks for your mail, Please find response to the few items, rest is snipped. From: Ina Minei [mailto:ina@juniper.net] Sent: Friday, July 19, 2013 1:01 AM To: dhruv.dhody@huawei.com; draft-ietf-pce-stateful-pce@tools.ietf.org Cc: pce@ietf.org Subject: RE: Comments for draft-ietf-pce-stateful-pce-05 Dhruv, Thank you for the careful review, please find answers inline. The comments accepted are already incorporated in what will become version 06 of the draft. Thank you, Ina [snip] ---Sec 5.5.4 Redundant Stateful PCEs: I suggest we use following terminology to avoid confusion, inline with [ietf-pce-questions-00] as well as other drafts. Primary or Backup PCE - Where a backup PCE exists to perform functions in the network, only in the event of a failure of the primary PCE. Load-Balanced PCE - share the computation load all the time. This way we could avoid confusion, such as the one mention in Xian's comment. [Ina] But the text talks about a load-balanced pce where one is also performing a backup function. [Dhruv Dhody>] Yes by load-balanced PCE I meant one that share and also act as backup to each other. I feel it would be good if we could align our terminology - Option 1: Primary-Backup and Load-Balanced or Option 2: use the term pure-backup for the first case). ---Sec 6.1 The PCRpt Message * I also feel SRP should be an optional parameter as PCRpt is also sent without an update - e.g. passive; initial state sync; delegation; report to other stateful PCEs (all of them will use SRP-ID=0). [Ina] If it is made optional, there is no way to ensure that it is present in the cases when it is needed. [Dhruv Dhody>]We have option - 1: SRP object mandatory & SRP_ID can be 0; option-2: SRP object optional but when present SRP_ID can never be 0. When the PCRpt is in response to PCUpd (it carry SRP object and has a valid SRP-ID) and when it is unsolicited the object is not present at all. I do not understand the argument that we should make an object mandatory just to make sure that it is present in that one case (i.e. when in response for PCUpd) * 'No state compression is allowed for state reporting (at PCC).' Can you clarify the intention for this? Do mean to say that for any LSP changes, that happen at PCC must be sent to PCE but in section 5.6.1 we say 'the PCC may choose to only send the PCRpt indicating the latest status ('Up' or 'Down').' [Ina] If you received two requests LSP1 - new bw and LSP1 new path you have to send two reports, one for each of these operations. If there is one request, but the lsp goes through multiple phases to arrive there, you can report just the final phase. [Dhruv Dhody>] I understand it now and agree, but may be a clarifying text would help to avoid the confusion that I had. ---Sec 6.3 The PCErr Message * Making SRP mandatory for all stateful PCE capable session is unnecessary. [Ina] Please explain the second point, while bearing in mind that this draft is for active stateful pce (negotiation of the capability means active stateful, there is no way to signal passive stateful) [Dhruv Dhody>] I am confused. In my understanding, presence of the 'Stateful PCE Capability TLV' in OPEN would mean support for stateful PCE (section 5.3). If both party set the U bit (LSP-UPDATE-CAPABILITY) then its Active stateful PCE otherwise its a Passive stateful PCE with support for sending and receiving PCRpt messages only. Regarding making the object mandatory (response is as above) ---Sec 7.2 SRP Object * Is there any role of SRP in make-before-break success / failure cases? [Ina] Let's say you ask for a reoptimization, but the new path fails because there is an RSVP setup error. An error must be generated that relates this failure to the PCupd message that required the optimization. [Dhruv Dhody>] Thanks and I agree, do you think if this could be explained in draft as well? ---Sec 7.4 Optional TLVs for the LSPA Object A small text for need for TLVs in LSPA object would be useful? [Ina]Not sure I follow. The lspa object has optional tlvs. The symbolic name can be added as one of these optional tlvs. Was the question why is the symbolic name one of the optional tlvs? [Dhruv Dhody>] Yes, rephrased - When will one carry this TLV in LSPA? ----------------------Editorial: Sec 7.3 5-7 - Reserved: these values MUST be set to 0 on transmission and MUST be ignored on receipt. The above description is used for bit, not for values! [Ina] I don't agree, please see rfc3209 which makes use of plenty of reserved values [Dhruv Dhody>] What I meant was remove "these values MUST be set to 0 on transmission and MUST be ignored on receipt.". Just say - 5-7 - Reserved for private/future use Regards, Dhruv **************************************************************************** *** Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, Ph. +91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ------=_NextPart_000_00B5_01CE8494.D476E130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ina,

 

Thanks for your mail, Please find response to the few items, rest is = snipped.  

 

From:= = Ina Minei [mailto:ina@juniper.net]
Sent: Friday, July 19, = 2013 1:01 AM
To: dhruv.dhody@huawei.com; = draft-ietf-pce-stateful-pce@tools.ietf.org
Cc: = pce@ietf.org
Subject: RE: Comments for = draft-ietf-pce-stateful-pce-05

 

Dhruv,

 

Thank you for the = careful review, please find answers inline. The comments accepted are = already incorporated in what will become version 06 of the draft. =

 

Thank you, =

 

Ina =

 

[snip]

 

---Sec 5.5.4 Redundant Stateful PCEs:

I suggest we use following terminology to avoid confusion, inline = with [ietf-pce-questions-00] as well as other drafts. =

Primary or Backup PCE - Where a backup PCE exists to perform = functions in the network, only in the event of a failure of the primary = PCE.

Load-Balanced PCE - share the computation load all the = time.

This way we could avoid confusion, such as the one mention in Xian's = comment.

[Ina] But the text talks about a load-balanced = pce where one is also performing a backup function. =

[Dhruv Dhody>] Yes by load-balanced PCE I meant one that share and = also act as backup to each other. I feel it would be good if we could = align our terminology - Option 1: Primary-Backup and Load-Balanced or = Option 2: use the term pure-backup for the first case). =

 

---Sec 6.1 The PCRpt Message

* I also feel SRP should be an optional parameter as PCRpt is also = sent without an update – e.g. passive; initial state sync; = delegation; report to other stateful PCEs (all of them will use = SRP-ID=3D0).

[Ina] If it is made optional, there is no way to = ensure that it is present in the cases when it is needed. =

[Dhruv Dhody>]We have option – 1: SRP object mandatory & =  SRP_ID can be  0; option-2: SRP object optional but when = present SRP_ID can never be 0.

When the PCRpt is in response to PCUpd (it carry SRP object and has a = valid SRP-ID) and when it is unsolicited the object is not present at = all.

 

I do not understand the argument that we should make an object = mandatory just to make sure that it is present in that one case (i.e. = when in response for PCUpd)

 

* 'No state compression is allowed for state reporting (at PCC).' Can = you clarify the intention for this? Do mean to say that for any LSP = changes, that happen at PCC must be sent to PCE but in section 5.6.1 we = say 'the PCC may choose to only send the PCRpt indicating the latest = status ('Up' or 'Down').'

[Ina] If you received = two requests LSP1 – new bw  and LSP1 new path you have to = send two reports, one for each of these operations. If there is one = request, but the lsp goes through multiple phases to arrive there, you = can report just the final phase.

[Dhruv Dhody>] I understand it now and agree, but may be a = clarifying text would help to avoid the confusion that I = had.

 

---Sec 6.3 The PCErr Message

* Making SRP mandatory for all stateful PCE capable session is = unnecessary.

[Ina] Please explain the second point, while = bearing in mind that this draft is for active stateful pce (negotiation = of the capability means active stateful, there is no way to signal = passive stateful)

[Dhruv Dhody>] I am confused. In my understanding, presence of the = ‘Stateful PCE Capability TLV’ in OPEN would mean support for = stateful PCE (section 5.3). If both party set the U bit = (LSP-UPDATE-CAPABILITY) then its Active stateful PCE otherwise its a = Passive stateful PCE with support for sending and receiving PCRpt = messages only.

Regarding making the object mandatory (response is as = above)

 

---Sec 7.2 SRP Object

* Is there any role of SRP in make-before-break success / failure = cases?

[Ina] Let’s say you ask for a = reoptimization, but the new path fails because there is an RSVP setup = error. An error must be generated that relates this failure to the PCupd = message that required the optimization.

[Dhruv Dhody>] Thanks and I agree, do you think if this could be = explained in draft as well?

 

---Sec 7.4 Optional TLVs for the LSPA Object

A small text for need for TLVs in LSPA object would be useful? =

[Ina]Not sure I follow. The lspa object has = optional tlvs. The symbolic name can be added as one of these optional = tlvs.  Was the question why is the symbolic name one of the = optional tlvs?

[Dhruv Dhody>] Yes, rephrased - When will one carry this TLV in = LSPA?

   

----------------------Editorial:

Sec 7.3

5-7 - Reserved:  these values MUST be set to 0 on transmission = and

         MUST be ignored on = receipt.

The above description is used for bit, not for = values!   

[Ina] I don’t = agree, please see rfc3209 which makes use of plenty of reserved = values

[Dhruv Dhody>] What I meant was remove “these values MUST be set to 0 on transmission and MUST be ignored on = receipt.”. Just say - 5-7 – Reserved for private/future use

 

 

Regards,

Dhruv

*****************= **************************************************************<= span lang=3DEN-IN = style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif";color:#48484= 8'>
= Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, = Ph. +91-9845062422

This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient's) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete = it!

 

------=_NextPart_000_00B5_01CE8494.D476E130-- From daniel@olddog.co.uk Fri Jul 19 09:27:41 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6554311E8177 for ; Fri, 19 Jul 2013 09:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYot7c6Z7s3H for ; Fri, 19 Jul 2013 09:27:36 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD6521F9D56 for ; Fri, 19 Jul 2013 09:27:36 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6JGQtiO027091; Fri, 19 Jul 2013 17:26:55 +0100 Received: from Mal (host86-133-205-106.range86-133.btcentralplus.com [86.133.205.106]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6JGQsQD027068; Fri, 19 Jul 2013 17:26:55 +0100 From: "Daniel King" To: "'Qin Wu'" References: <201307151557180154419@sttri.com.cn> In-Reply-To: Date: Fri, 19 Jul 2013 17:27:03 +0100 Message-ID: <012d01ce849c$cdbe04b0$693a0e10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQF3udG5CocN41Y2p0LQBk8L0GahugHKjHIqmgtuQdA= Content-Language: en-gb Cc: 'pce' Subject: Re: [Pce] Comments on draft-wu-pce-dns-pce-discovery-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 16:27:41 -0000 Hi Qin,=20 Interesting proposal, I think you need to focus a little more on the motivation and use cases. Do you see/have PCE deployments where non-IGP discovery is required, and static configuration is not suitable? Also = did you consider other methods of PCE discovery before you selected DNS, if = so, why is DNS better?=20 Actually, we (Adrian and I) did consider PCE discovery in the PCE = Questions I-D, which recently became a WG document: http://tools.ietf.org/html/draft-ietf-pce-questions-00 Maybe you want to reference it in your document. Br, Dan.=20 From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Qin Wu Sent: 15 July 2013 10:31 To: Claire Bi Cc: pce Subject: Re: [Pce] Comments on draft-wu-pce-dns-pce-discovery-00 Hi,Claire: You raise a good point. =A0We will try to highlight this in the draft. = Thank you very much! Regards! -Qin From: Claire Bi [mailto:bijy@sttri.com.cn]=20 Sent: Monday, July 15, 2013 3:57 PM To: Qin Wu Cc: pce Subject: Comments on draft-wu-pce-dns-pce-discovery-00 Hi Qin, I=92ve reviewed this draft. I think one of the advantages of DNS based = PCE discovery is its query-response mechanism. Compared with OSPF based or = ISIS based PCE discovery, which uses advertisement mechanism, using query-response mechanism can avoid unnecessary advertisement and reduce = a large amount of unwanted traffic, especially when PCE information needs frequent changes.=20 It would be good to further explain the query-response mechanism of DNS based PCE discovery in the draft. =A0 Thanks and Regards, Claire From bill.wu@huawei.com Mon Jul 22 01:58:50 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90CC21E80BD for ; Mon, 22 Jul 2013 01:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXUdwiXSrGID for ; Mon, 22 Jul 2013 01:58:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C10C21E8064 for ; Mon, 22 Jul 2013 01:32:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATQ95302; Mon, 22 Jul 2013 08:31:24 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 09:30:23 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 09:31:13 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 16:31:07 +0800 From: Qin Wu To: Daniel King Thread-Topic: [Pce] Comments on draft-wu-pce-dns-pce-discovery-00 Thread-Index: AQHOgTDcUSRhTTtqh0exqg75e/tsbplleQVQgAY4F4CABLJAgA== Date: Mon, 22 Jul 2013 08:31:07 +0000 Message-ID: References: <201307151557180154419@sttri.com.cn> <012d01ce849c$cdbe04b0$693a0e10$@olddog.co.uk> In-Reply-To: <012d01ce849c$cdbe04b0$693a0e10$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'pce' Subject: Re: [Pce] Comments on draft-wu-pce-dns-pce-discovery-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 08:58:50 -0000 Hi,Dan: Thank you for reviewing draft-wu-pce-dns-pce-discovery and sharing your vie= ws. Please see my rely inline below. Regards! -Qin -----Original Message----- >From: Daniel King [mailto:daniel@olddog.co.uk]=20 >Sent: Saturday, July 20, 2013 12:27 AM >To: Qin Wu >Cc: 'pce' >Subject: RE: [Pce] Comments on draft-wu-pce-dns-pce-discovery-00 >Hi Qin,=20 >Interesting proposal, I think you need to focus a little more on the >motivation and use cases. [Qin]: Agree, we need to justify more on why DNS based mechanism is needed. We will post a update to bring these justifications in. > Do you see/have PCE deployments where non-IGP >discovery is required, and static configuration is not suitable? [Qin]: Good questions, yes, we do see such PCE deployments exist: e.g., a.In Inter-AS PCE discovery, BRPC is used to Cooperate PCEs to compute inte= r-domain path, However in some cases, the PCEs do not participate in a common IGP, in such= case, IGP based PCE discovery is difficult to be used. b.In Hierarchy PCE case, parent PCE and child PCE also may participant in d= ifferent IGP, handling changes in parent PCE identities and coping with failure events is= very challenging for Configuration system, In such case,DNS based PCE discovery bring a lot of b= enefit. c.In the case when NMS/OSS is used, PCE server may gain topology info from = OSS/NMS and do not run IGP=20 PCC may not be a router and instead be a management system and do not run I= GP, in such case, we=20 also can resort to DNS based PCE discovery. d.So does inter-layer PCE discovery, PCEs in different layer may participan= t in different IGP.=20 >Also did >you consider other methods of PCE discovery before you selected DNS, if so= , >why is DNS better?=20 [Qin]:Good question again. The other methods in my mind are DHCP based mech= anism and XMPP based mechanism, However I don't think they are competing with DNS based PCE discovery: e.g.,DHCP based PCE discovery it could be Part of DNS process. We can use DHCP to discover search path of= the resolver=20 As for XMPP based PCE discovery, It Still relies on DNS to discover URI of XMPP Proxy XMPP Proxy can be used to translate PCE discovery information=20 in IGP into info in the XMPP message and advertise it to the XMPP client. However deploying such XMPP Proxy is very costly and doesn't scale very wel= l comparing with DNS based PCE discovery. >Actually, we (Adrian and I) did consider PCE discovery in the PCE Question= s >I-D, which recently became a WG document: >http://tools.ietf.org/html/draft-ietf-pce-questions-00 >Maybe you want to reference it in your document. [Qin]: Agree, that is something which motivates us to write this draft. we will add this reference in the next version. Thanks for your good sugge= stions. >Br, Dan.=20 >From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Qin = Wu >Sent: 15 July 2013 10:31 >To: Claire Bi >Cc: pce >Subject: Re: [Pce] Comments on draft-wu-pce-dns-pce-discovery-00 Hi,Claire: You raise a good point. =A0We will try to highlight this in the draft. Than= k you very much! Regards! -Qin From: Claire Bi [mailto:bijy@sttri.com.cn]=20 Sent: Monday, July 15, 2013 3:57 PM To: Qin Wu Cc: pce Subject: Comments on draft-wu-pce-dns-pce-discovery-00 Hi Qin, I've reviewed this draft. I think one of the advantages of DNS based PCE discovery is its query-response mechanism. Compared with OSPF based or ISIS based PCE discovery, which uses advertisement mechanism, using query-response mechanism can avoid unnecessary advertisement and reduce a large amount of unwanted traffic, especially when PCE information needs frequent changes.=20 It would be good to further explain the query-response mechanism of DNS based PCE discovery in the draft. =A0 Thanks and Regards, Claire From Internet-Drafts@ietf.org Mon Jul 22 10:05:21 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF9C21F826B; Mon, 22 Jul 2013 10:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8LQ-296sHRr; Mon, 22 Jul 2013 10:05:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C04F21F86BE; Mon, 22 Jul 2013 09:53:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.53 Message-ID: <20130722165329.7168.49320.idtracker@ietfa.amsl.com> Date: Mon, 22 Jul 2013 09:53:29 -0700 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-gmpls-aps-req-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:05:21 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Requirements for GMPLS applications of PCE Author(s) : T. Otani, et al Filename : draft-ietf-pce-gmpls-aps-req Pages : 12 Date : July 22, 2013 The initial effort of the PCE (Path computation element) WG was mainly focused on MPLS. As a next step, this draft describes functional requirements for GMPLS application of PCE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-gmpls-aps-req-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-gmpls-aps-req"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-07-22095329.I-D@ietf.org> --NextPart-- From julien.meuric@orange.com Tue Jul 23 05:54:20 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F365E11E812A for ; Tue, 23 Jul 2013 05:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pnyy0jEjO+Qd for ; Tue, 23 Jul 2013 05:54:15 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3277411E80CC for ; Tue, 23 Jul 2013 05:54:15 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 51D56410393 for ; Tue, 23 Jul 2013 14:54:14 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 4AB19410225 for ; Tue, 23 Jul 2013 14:54:14 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Jul 2013 14:54:14 +0200 Received: from [10.193.71.188] ([10.193.71.188]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Jul 2013 14:54:13 +0200 Message-ID: <51EE7CF5.6020605@orange.com> Date: Tue, 23 Jul 2013 14:54:13 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2013 12:54:13.0895 (UTC) FILETIME=[BBB51970:01CE87A3] Subject: [Pce] Slides for PCE Meeting X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Julien Meuric , 'JP Vasseur' , Daniel King List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 12:54:20 -0000 Hi all. Our revised agenda for the meeting in Berlin is on line: h ttp://www.ietf.org/proceedings/87/agenda/agenda-87-pce If you have a slot, please provide the chairs *and* secretary with your slides by Monday 29th. Let me remind that presentations should focus on change and pending issues so as to leave room for discussion. Take into account the allocated (as opposed to requested) time for your slot. Some WGs go by the "no slide, no slot" principle: we may abide by it if necessary. Regards, JP & Julien From Jonathan.Hardwick@metaswitch.com Tue Jul 23 07:22:53 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB1211E8226 for ; Tue, 23 Jul 2013 07:22: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejp0ZVWrCAEB for ; Tue, 23 Jul 2013 07:22:48 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8FB11E8222 for ; Tue, 23 Jul 2013 07:22:40 -0700 (PDT) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 23 Jul 2013 15:22:17 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.02.0342.003; Tue, 23 Jul 2013 15:22:25 +0100 From: Jonathan Hardwick To: "draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org" Thread-Topic: Comments on draft-ietf-pce-gmpls-pcep-extensions-08 Thread-Index: Ac6HsAzdUISi4eHgQZqcl365JKGg0Q== Date: Tue, 23 Jul 2013 14:22:25 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5@ENFICSMBX1.datcon.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.191] Content-Type: multipart/alternative; boundary="_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5ENFICSMBX1datco_" MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: [Pce] Comments on draft-ietf-pce-gmpls-pcep-extensions-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:22:53 -0000 --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5ENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello I have reviewed this draft and have the following comments and questions. Best regards Jon Section 2 RBNF The RBNF implies that BANDWITH and GENERALIZED-BANDWIDTH can be mixed on a = single request & response. That looks wrong to me, I think that either one= or the other should be supplied but not both. If both really can be used,= please could you add text explaining why? Same comment for LOAD-BALANCING and GENERALIZED-LOAD-BALANCING. Section 2.1 RP object The bits used for the RG flag are not defined until section 5.4. Please at= least xref from 2.1 to 5.4 for the definition. Better still, define them = in section 2.1. "The RG flag is backward-compatible with [RFC5440]: the value sent by an impleme= ntation (PCC or PCE) not supporting it will indicate a node granularity." Pre-existing implementations may calculate at node or link granularity so I= don't think you can assume that a back-level implementation will always re= turn node-level granularity. So, backwards-compatibility does not work as = you expect. My suggestion is to make 0 the reserved value for the RG flags (not 3). Th= en the backwards compatibility problem is resolved, since the value RG=3D= =3D0 implies that the sender is a back-level node and so is ignoring the RG= field. "If a PCE honored the the requested routing granularity for a request, it SHOULD indicate the selected routing granularity in the RP object included in the response" Suggest changing the above excerpt to: "The PCE MUST indicate the selected routing granularity in the RP object included in the response" Justification: I think you mean MUST, not SHOULD. Otherwise the PCC can't = rely on the RG flag, rendering it useless. Also, why should the PCE do thi= s only if it honoured the RG? I think the PCE should be free to use policy= to choose to route at a different RG than that given in the request, and w= hatever RG is chooses to do the routing at, it should return that RG in the= response. Along the same lines: "The PCE MAY return finer granularity on the route based on its policy. The PCC can decide if the ERO is acceptable based on its content." Suggest changing the above excerpt to "The PCE MAY return any granularity it likes on the route based on its policy. The PCC can decide if the ERO is acceptable based on its content." Comment on the following statement: "The PCE MAY try to follow this granularity and MAY return a NO-PATH if the requested granularity cannot be provided." If the PCE cannot supply a path at the given granularity then it is either = a problem with the PCE's capabilities or a policy issue. As such, NO-PATH = is not appropriate; the PCE should respond with PCErr with a suitable error= code. Section 2.2 and 2.3 GENERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING I think it is better to specify a format for the GENERALIZED-BANDWIDTH and = GENERALIZED-LOAD-BALANCING objects that allows a single instance of the obj= ect to specify both forwards and reverse bandwidth. By having two objects = you complicate matters because you then need to specify (and write extra co= de for!) all the consistency rules between the objects (e.g. you don't say = what happens if the max-LSPs field differs between the forwards and reverse= direction GEN-LB object). This in turn will make implementation more fidd= ly and potentially less interoperable. How about including the reverse-dir= ection TSPEC in the same object as the forwards-direction TSPEC if the R bi= t is set? You state that multiple objects with the same TSPEC type are dealt with by = ignoring all but the first. Why do you allow multiple objects with a diffe= rent TSPEC type? And what is the PCE to so with a request containing diffe= rent types of TSPEC? I think that all TSPECs need to have the same type. Section 2.4.1 Generalized-Endpoint object type To aid clarity, suggest rewording this: "A PCE not supporting those TLVs but not being able to fulfill the label restriction MUST respond with a response with NO-PATH with the bit "No endpoint label resource" or "No endpoint label resource in range" in the NO-PATH- VECTOR TLV, the response SHOULD include the ENDPOINT object in the response with only the TLV where it could not met the constraint." to this: "A PCE supporting those TLVs but not being able to fulfil the label restriction MUST send a response with a NO-PATH object which has the bit "No endpoint label resource" or "No endpoint label resource in range" set in the NO-PATH- VECTOR TLV. The response SHOULD include an ENDPOINT object containing only the TLV where the PCE could not meet the constraint." Section 2.4.2.5 Labels TLV Suggest changing "This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET TLV Set." to "This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET TLV Set and ignored on receipt." Delete orphaned text which says "Table 5" - no table present in this sectio= n. Section 2.5 Stipulate that IP address subobject MUST be a link subobject. Clarify that >1 label subobject may follow each link-address or unnumbered-= link subobject. Section 2.6 XRO Better to just define the X bit than refer to RFC 5521. The definition is = simple enough. You say the C-Type is "copied from the label object" - what label object? = Isn't this just a number which identifies the type of the labels? Does the label field specify a single label or an array of labels? (Suppos= e single label but it is not quite clear.) Section 2.7 PROTECTION-ATTRIBUTE TLV I am not sure that re-using the format from RFC 4872/4873 is the right way = to go. It leaves us with a format containing many elements that are superf= luous (or at least, not obviously applicable) to path computation. It woul= d help if you could add some text explaining why each field is applicable t= o path computation. For example, on the PROTECTION-ATTRIBUTE TLV flags: * S bit: since the PCE server does not assign resources, it seems t= hat this bit will not be used in PCEP, correct? * N bit: I think this is irrelevant to PCEP. * O bit: ditto. * I bit: ditto. * R bit: ditto. Unless I have misunderstood, I think It would be better not to define these= bits in the object format. If you must have them then I think you should = at least stipulate that they are ignored on receipt. You say "LSP Flags can be considered for routing policy based on the protec= tion type." I think you must mean the Link Flags, since these specify the = link attributes that the path requires. I am not sure what use the LSP fla= gs are to the PCE; please could you explain? Same comment applies to segme= nt recovery flags. Where you say "The other attributes are only meaningful for a stateful PCE"= , please could you say why a stateful PCE might make use of them, or point = me at a draft where this is discussed? --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5ENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello

 

I have reviewed this draft and have the following co= mments and questions.

 

Best regards

Jon

 

 

Section 2 RBNF

The RBNF implies that BANDWITH and GENERALIZED-BANDW= IDTH can be mixed on a single request & response.  That looks wron= g to me, I think that either one or the other should be supplied but not bo= th.  If both really can be used, please could you add text explaining why?

Same comment for LOAD-BALANCING and GENERALIZED-LOAD= -BALANCING.

 

 

Section 2.1 RP object

The bits used for the RG flag are not defined until = section 5.4.  Please at least xref from 2.1 to 5.4 for the definition.=   Better still, define them in section 2.1.

 

“The RG flag is backward-compatible with
[RFC5440]: =
the value sent by an implementation (PCC or PCE) not
   supporting it will indicate a node granularity.”

 

Pre-existing implementations may calculate at node o= r link granularity so I don’t think you can assume that a back-level = implementation will always return node-level granularity.  So, backwar= ds-compatibility does not work as you expect.

 

My suggestion is to make 0 the reserved value for th= e RG flags (not 3).  Then the backwards compatibility problem is resol= ved, since the value RG=3D=3D0 implies that the sender is a back-level node= and so is ignoring the RG field.

 

“If a PCE honored the the requested routing granularity for a re=
quest,
it SHOULD indicate the selected routing granularity in the RP object
included in the response”

 

Suggest changing the above excerpt to:

 

“The PCE MUST indicate the selected routing granularity in the R=
P object
included in the response”

 

Justification: I think you mean MUST, not SHOULD.&nb= sp; Otherwise the PCC can’t rely on the RG flag, rendering it useless= .  Also, why should the PCE do this only if it honoured the RG?  = I think the PCE should be free to use policy to choose to route at a different RG than that given in the request, and whatever RG= is chooses to do the routing at, it should return that RG in the response.=   Along the same lines:

 

“The PCE MAY return
finer granularity on the route based on its policy.  The PCC can<=
o:p>
decide if the ERO is acceptable based on its content.”

 

Suggest changing the above excerpt to

 

“The PCE MAY return
any granularity it likes on the route based on its policy.  The P=
CC can
decide if the ERO is acceptable based on its content.”

 

Comment on the following statement:

 

“The PCE MAY try to follow this granularity and MAY return a NO-=
PATH
if the requested granularity cannot be provided.”

 


If the PCE cannot supply a path at the given granula=
rity then it is either a problem with the PCE’s capabilities or a pol=
icy issue.  As such, NO-PATH is not appropriate; the PCE should respon=
d with PCErr with a suitable error code.


 


 


Section 2.2 and 2.3 GENERALIZED-BANDWIDTH and GEN=
ERALIZED-LOAD-BALANCING


I think it is better to specify a format for the GEN=
ERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING objects that allows a sin=
gle instance of the object to specify both forwards and reverse bandwidth.&=
nbsp; By having two objects you complicate
 matters because you then need to specify (and write extra code for!) all t=
he consistency rules between the objects (e.g. you don’t say what hap=
pens if the max-LSPs field differs between the forwards and reverse directi=
on GEN-LB object).  This in turn will
 make implementation more fiddly and potentially less interoperable.  =
How about including the reverse-direction TSPEC in the same object as the f=
orwards-direction TSPEC if the R bit is set?


 


You state that multiple objects with the same TSPEC =
type are dealt with by ignoring all but the first.  Why do you allow m=
ultiple objects with a different TSPEC type?  And what is the PCE to s=
o with a request containing different types
 of TSPEC?  I think that all TSPECs need to have the same type.


 


 


Section 2.4.1 Generalized-Endpoint object type


To aid clarity, suggest rewording this:

 


“A PCE not supporting those


   TLVs but not being able to fulfill the label =
restriction MUST respond


   with a response with NO-PATH with the bit &qu=
ot;No endpoint label


   resource" or "No endpoint label res=
ource in range" in the NO-PATH-


   VECTOR TLV, the response SHOULD include the E=
NDPOINT object in the


   response with only the TLV where it could not=
 met the constraint.”


 


to this:


 


“A PCE supporting those


   TLVs but not being able to fulfil the label r=
estriction MUST send


   a response with a NO-PATH object which has th=
e bit "No endpoint label


   resource" or "No endpoint label res=
ource in range" set in the NO-PATH-


   VECTOR TLV.  The response SHOULD include=
 an ENDPOINT object



   containing only the TLV where the PCE co=
uld not meet the constraint.”


 


 


Section 2.4.2.5 Labels TLV


Suggest changing


 


“This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET=



      TLV Set.”=



 


to


 


“This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET=



      TLV Set and ignored on rece=
ipt.”


 


Delete orphaned text which says “Table 5”=
; – no table present in this section.


 


 


Section 2.5


Stipulate that IP address subobject MUST be a link s=
ubobject.


Clarify that >1 label subobject may follow each l=
ink-address or unnumbered-link subobject.


 


 


Section 2.6 XRO


Better to just define the X bit than refer to RFC 55=
21.  The definition is simple enough.


 


You say the C-Type is “copied from the label o=
bject” – what label object?  Isn’t this just a numbe=
r which identifies the type of the labels? 



 


Does the label field specify a single label or an ar=
ray of labels?  (Suppose single label but it is not quite clear.)=



 


 


Section 2.7 PROTECTION-ATTRIBUTE TLV


I am not sure that re-using the format from RFC 4872=
/4873 is the right way to go.  It leaves us with a format containing m=
any elements that are superfluous (or at least, not obviously applicable) t=
o path computation.  It would help if you
 could add some text explaining why each field is applicable to path comput=
ation.


 


For example, on the PROTECTION-ATTRIBUTE TLV flags:<=
o:p>


·        
S bit: since the PCE server does not assign =
resources, it seems that this bit will not be used in PCEP, correct?


·        
N bit: I think this is irrelevant to PCEP.


·        
O bit: ditto.


·        
I bit: ditto.


·        
R bit: ditto.


 


Unless I have misunderstood, I think It would be bet=
ter not to define these bits in the object format.  If you must have t=
hem then I think you should at least stipulate that they are ignored on rec=
eipt.


 


You say “LSP Flags can be considered for routi=
ng policy based on the protection type.”  I think you must mean =
the Link Flags, since these specify the link attributes that the path requi=
res.  I am not sure what use the LSP flags are to the
 PCE; please could you explain?  Same comment applies to segment recov=
ery flags.


 


Where you say “The other attributes are only meanin=
gful for a stateful PCE”, please could you say why a stateful PCE mig=
ht make use of them, or point me at a draft where this is discussed?


 


 
--_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5ENFICSMBX1datco_-- From bill.wu@huawei.com Tue Jul 23 21:50:16 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E02C21F9F44; Tue, 23 Jul 2013 21:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Owzc6NnuDA+P; Tue, 23 Jul 2013 21:50:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E926E21F9D02; Tue, 23 Jul 2013 21:50:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVJ10383; Wed, 24 Jul 2013 04:50:08 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 05:48:29 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 05:49:24 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 12:49:19 +0800 From: Qin Wu To: "Diego R. Lopez" , "pce@ietf.org" Thread-Topic: Proposal on securing PCEP by means of TLS Thread-Index: AQHOf7+uXh4JtZqUPkOFzvaC0qiQVJlzUhSw Date: Wed, 24 Jul 2013 04:49:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "karp@ietf.org" Subject: Re: [Pce] Proposal on securing PCEP by means of TLS X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 04:50:16 -0000 SGksRGllZ286DQpWZXJ5IGludGVyZXN0aW5nIGRyYWZ0LiBUTFMgc2VlbXMgdG8gYnJpbmcgbW9y ZSBiZW5lZml0IGZvciBrZXkgbWFuYWdlbWVudC4NCg0KV291bGQgaXQgYmUgZ29vZCB0byBkaXNj dXNzIHNlY3VyaW5nIFBDRVAgYnkgVENQLUFPIGFzIHdlbGwgc2luY2UgVENQLU1ENSBoYXMgYmVl biBvYnNvbGV0ZWQgYnkgVENQLUFPPw0KDQpBbHNvIGl0IGlzIGJldHRlciB0byBkaXNjdXNzIGhv dyBUTFMvVENQIGNhbiBiZSB1c2VkIHRvIGRlYWwgd2l0aCBWdWxuZXJhYmlsaXRpZXMgY29uY2Vy bnMgcmFpc2VkIGluIFJGQzU0NDAuDQoNCkFub3RoZXIgY29tbWVudCBpcyB3aGVuIGJvdGggUEND IGFuZCBQQ0Ugc3VwcG9ydCBib3RoIFRMUy9UQ1AgYW5kIFRDUCwgaG93IGRvZXMgUENDIHNlbGVj dCB0cmFuc3BvcnQgcHJvdG9jb2w/IFRDUCBpcyBtYW5kYXRvcnkgb3IgYm90aCBhcmUgbWFuZGF0 b3J5PyBEb2VzIGl0IHJlbHkgb24gbWFudWFsIGNvbmZpZ3VyYXRpb24gb3IgZHluYW1pYyBkaXNj b3Zlcnk/DQoNClJlZ2FyZHMhDQotUWluDQooc29ycnkgZm9yIGR1cGxpY2F0ZSBtZXNzYWdlIGlm IHlvdSByZWNlaXZlZCBiZWZvcmUgc2luY2UgSXQgbG9va3MgdGhpcyBlbWFpbCB3YXMgc2VudCBi ZWZvcmUgYW5kIHVuZm9ydHVuYXRlbHkgZmlsdGVyZWQgb3V0KQ0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHBjZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGNlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEaWVnbyBSLiBMb3Bleg0KU2VudDogU2F0dXJkYXksIEp1 bHkgMTMsIDIwMTMgNzo1NSBQTQ0KVG86IHBjZUBpZXRmLm9yZw0KQ2M6IGthcnBAaWV0Zi5vcmcN ClN1YmplY3Q6IFtQY2VdIFByb3Bvc2FsIG9uIHNlY3VyaW5nIFBDRVAgYnkgbWVhbnMgb2YgVExT DQoNCkhpLA0KDQpPc2NhciBhbmQgSSBoYXZlIHByZXBhcmVkIGEgZHJhZnQgb24gYXBwbHlpbmcg VExTIHRvIFBDRVAgc2VjdXJpdHk6DQoNCjg8LS0tDQpGaWxlbmFtZTogICAgICAgIGRyYWZ0LWxv cGV6LXBjcC1wY2Vwcw0KUmV2aXNpb246ICAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgICBTZWN1 cmUgVHJhbnNwb3J0IGZvciBQQ0VQDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTMtMDctMTANCkdyb3Vw OiAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDgNClVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt bG9wZXotcGNwLXBjZXBzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxvcGV6LXBjcC1wY2Vwcw0KSHRtbGl6ZWQ6ICAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb3Blei1wY3AtcGNlcHMtMDANCg0KDQpB YnN0cmFjdDoNCiAgVGhlIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCBDb21tdW5pY2F0aW9uIFBy b3RvY29sIChQQ0VQKSBkZWZpbmVzDQogIHRoZSBtZWNoYW5pc21zIGZvciB0aGUgY29tbXVuaWNh dGlvbiBiZXR3ZWVuIGEgY2xpZW50IGFuZCBhIFBDRSwgb3INCiAgYW1vbmcgUENFcy4gIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmUgdGhlIHVzYWdlIG9mIFRyYW5zcG9ydCBMYXllcg0KICBTZWN1cml0 eSB0byBlbmhhbmNlIFBDRVAgc2VjdXJpdHksIGhlbmNlIHRoZSBQQ0VQUyBhY3JvbnltIHByb3Bv c2VkDQogIGZvciBpdC4gIFRoZSBhZGRpdGlvbmFsIHNlY3VyaXR5IG1lY2hhbmlzbXMgYXJlIHBy b3ZpZGVkIGJ5IHRoZQ0KICB0cmFuc3BvcnQgcHJvdG9jb2wgc3VwcG9ydGluZyBQQ0VQLCBhbmQg dGhlcmVmb3JlIHRoZXkgZG8gbm90IGFmZmVjdA0KICBpdHMgZmxleGliaWxpdHkgYW5kIGV4dGVu c2liaWxpdHkuDQoNCjg8LS0tDQoNCkNvbW1lbnRzIGFuZCBjb250cmlidXRpb25zIHdpbGwgYmUg ZXh0cmVtZWx5IHdlbGNvbWUuDQoNCkFzIHlvdSBjYW4gZXhwZWN0LCB3ZSdkIGxpa2UgdG8gaGF2 ZSB0aGUgb3Bwb3J0dW5pdHkgdG8gcHJlc2VudCBhbmQgZGlzY3VzcyBpdCBpbiBCZXJsaW4uDQoN CkJlIGdvb2RlDQoNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVy bm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50 aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5 MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0 YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2Vw Y2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFi YWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVz c2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0 ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVy LmFzcHgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQ Y2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGNlDQo= From venugopalreddyk@huawei.com Wed Jul 24 06:38:39 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F6411E8133 for ; Wed, 24 Jul 2013 06:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S-Vd3b0hD5i for ; Wed, 24 Jul 2013 06:38:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF4411E80E0 for ; Wed, 24 Jul 2013 06:38:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVJ58973; Wed, 24 Jul 2013 13:38:30 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 14:37:32 +0100 Received: from SZXEML463-HUB.china.huawei.com (10.82.67.206) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 14:38:28 +0100 Received: from blrprnc09ns (10.18.96.98) by szxeml463-hub.china.huawei.com (10.82.67.206) with Microsoft SMTP Server id 14.1.323.7; Wed, 24 Jul 2013 21:38:24 +0800 From: KONDREDDY VENUGOPAL REDDY To: , Date: Wed, 24 Jul 2013 19:08:24 +0530 Message-ID: <003e01ce8873$125bb660$37132320$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01CE88A1.2C13F260" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6IcxGFQT9L3MXLT3ecggJDIh9UUA== Content-Language: en-us X-Originating-IP: [10.18.96.98] X-CFilter-Loop: Reflected Subject: [Pce] Few comments for draft-ietf-pce-stateful-pce-05 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:38:39 -0000 ------=_NextPart_000_003F_01CE88A1.2C13F260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Please find few comments for stateful PCE draft-05. 1. In the current draft, we don't have mechanism to carry Primary's PLSP-ID while delegating backup LSP. It would be required for a backup LSP to know its primary LSP paths. 2. There are chances where PcRpt/PcUpd message getting fragmented. Suggest, we can extend the PCEP fragmentation mechanism described in RFC 6006 to PcRpt and PcUpdate messages as well. We can have F bit in SRP object or else in LSP object(mandatory object) so as to support PCEP fragmentation. 3. Suggest to extend PcReport to carry all the objects in PcRequest(except RP) because, a. LSP object doesn't have mechanism to specify LSP's endpoint. b. There may be a case where PCC wishes to specify IRO/XRO while delegating LSP to a PCE. Regards, Venu ------=_NextPart_000_003F_01CE88A1.2C13F260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please find = few comments for stateful PCE draft-05.

 

 

1.       In = the current draft, we don’t have mechanism to carry = Primary’s PLSP-ID while delegating backup LSP. It would be = required for a backup LSP to know its primary LSP = paths.

2.       = There are chances where PcRpt/PcUpd message = getting fragmented. Suggest, we can extend the PCEP fragmentation = mechanism described in RFC 6006 to PcRpt and PcUpdate messages as well. = We can have  F bit in SRP object or else in LSP object(mandatory = object) so as to support PCEP fragmentation.

3.       = Suggest to extend PcReport to carry all the = objects in PcRequest(except RP) because,

a.       LSP = object doesn’t  have mechanism to specify LSP’s = endpoint.

b.      = There may be a case where PCC wishes to specify = IRO/XRO while delegating LSP to a PCE.

 

Regards,

Venu

------=_NextPart_000_003F_01CE88A1.2C13F260-- From cyril.margaria@coriant.com Thu Jul 25 07:41:55 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA9F21F9A8F for ; Thu, 25 Jul 2013 07:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt1VMtENqD6i for ; Thu, 25 Jul 2013 07:41:50 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 028B421F8F6D for ; Thu, 25 Jul 2013 07:41:49 -0700 (PDT) Received: from mail193-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Thu, 25 Jul 2013 14:41:45 +0000 Received: from mail193-ch1 (localhost [127.0.0.1]) by mail193-ch1-R.bigfish.com (Postfix) with ESMTP id B07D1380087; Thu, 25 Jul 2013 14:41:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT002.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371Ic89bhc85dh1418I31c5I1447Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de097h1de096h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail193-ch1: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT002.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail193-ch1 (localhost.localdomain [127.0.0.1]) by mail193-ch1 (MessageSwitch) id 1374763295220589_1854; Thu, 25 Jul 2013 14:41:35 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail193-ch1.bigfish.com (Postfix) with ESMTP id 30BFF30004A; Thu, 25 Jul 2013 14:41:35 +0000 (UTC) Received: from DB3PRD0411HT002.eurprd04.prod.outlook.com (157.56.253.53) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 25 Jul 2013 14:41:34 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.251]) by DB3PRD0411HT002.eurprd04.prod.outlook.com ([10.255.73.37]) with mapi id 14.16.0329.000; Thu, 25 Jul 2013 14:41:30 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: Jonathan Hardwick , "draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org" Thread-Topic: Comments on draft-ietf-pce-gmpls-pcep-extensions-08 Thread-Index: Ac6HsAzdUISi4eHgQZqcl365JKGg0QBjjtbQ Date: Thu, 25 Jul 2013 14:41:30 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D0CC675@DB3PRD0411MB427.eurprd04.prod.outlook.com> References: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5@ENFICSMBX1.datcon.co.uk> In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5@ENFICSMBX1.datcon.co.uk> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.159.77.165] Content-Type: multipart/alternative; boundary="_000_523C37072C291347B9730C9291CCA07D0CC675DB3PRD0411MB427eu_" MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "pce@ietf.org" Subject: Re: [Pce] Comments on draft-ietf-pce-gmpls-pcep-extensions-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:41:55 -0000 --_000_523C37072C291347B9730C9291CCA07D0CC675DB3PRD0411MB427eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jonathan, Thanks for the review, please see inline . Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Tuesday, July 23, 2013 4:22 PM To: draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org Cc: pce@ietf.org Subject: Comments on draft-ietf-pce-gmpls-pcep-extensions-08 Hello I have reviewed this draft and have the following comments and questions. Best regards Jon Section 2 RBNF The RBNF implies that BANDWITH and GENERALIZED-BANDWIDTH can be mixed on a = single request & response. That looks wrong to me, I think that either one= or the other should be supplied but not both. If both really can be used,= please could you add text explaining why? Same comment for LOAD-BALANCING and GENERALIZED-LOAD-BALANCING. [[Margaria.C]] This is for backward-compatibility : for instance for reopti= mization request the BANDWIDTH MUST be provided. We did not want to change = existing logic but to enhance the information. The GENERALIZED-BANDWIDTH i= s present as a detailed expression of the BANDWIDTH. Section 2.1 RP object The bits used for the RG flag are not defined until section 5.4. Please at= least xref from 2.1 to 5.4 for the definition. Better still, define them = in section 2.1. [[Margaria.C]] OK "The RG flag is backward-compatible with [RFC5440]: the value sent by an impleme= ntation (PCC or PCE) not supporting it will indicate a node granularity." Pre-existing implementations may calculate at node or link granularity so I= don't think you can assume that a back-level implementation will always re= turn node-level granularity. So, backwards-compatibility does not work as = you expect. [[Margaria.C]] In that case the ERO contains nodes, the intent is more to a= sk for a more detailed route rather than to force a less detailed route. Th= e values should be read as node (or better) , not node-only ERO (Wording ca= n be added). Do you see a use case for node-only ERO (or link-only ERO) ? My suggestion is to make 0 the reserved value for the RG flags (not 3). Th= en the backwards compatibility problem is resolved, since the value RG=3D= =3D0 implies that the sender is a back-level node and so is ignoring the RG= field. "If a PCE honored the the requested routing granularity for a request, it SHOULD indicate the selected routing granularity in the RP object included in the response" Suggest changing the above excerpt to: "The PCE MUST indicate the selected routing granularity in the RP object included in the response" Justification: I think you mean MUST, not SHOULD. Otherwise the PCC can't = rely on the RG flag, rendering it useless. [[Margaria.C]] In the absence of flag the PCC should check. The SHOULD is h= ere to allow PCEs supporting the other object but not filling this bit, but= in any case they can put 0 (PCC has to check then), so a MUST can be added= . Also, why should the PCE do this only if it honoured the RG? I think the P= CE should be free to use policy to choose to route at a different RG than t= hat given in the request, and whatever RG is chooses to do the routing at, = it should return that RG in the response. [[Margaria.C]] OK Along the same lines: "The PCE MAY return finer granularity on the route based on its policy. The PCC can decide if the ERO is acceptable based on its content." Suggest changing the above excerpt to "The PCE MAY return any granularity it likes on the route based on its policy. The PCC can decide if the ERO is acceptable based on its content." [[Margaria.C]] OK Comment on the following statement: "The PCE MAY try to follow this granularity and MAY return a NO-PATH if the requested granularity cannot be provided." If the PCE cannot supply a path at the given granularity then it is either = a problem with the PCE's capabilities or a policy issue. As such, NO-PATH = is not appropriate; the PCE should respond with PCErr with a suitable error= code. [[Margaria.C]] The PCE may also miss TE information (loose routing over a d= omain or missing label information) , so a NO-PATH is valid in that case (i= f policy dictate it should not return a lower granularity). I will add the PCErr for the case you mentioned. Section 2.2 and 2.3 GENERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING I think it is better to specify a format for the GENERALIZED-BANDWIDTH and = GENERALIZED-LOAD-BALANCING objects that allows a single instance of the obj= ect to specify both forwards and reverse bandwidth. By having two objects = you complicate matters because you then need to specify (and write extra co= de for!) all the consistency rules between the objects (e.g. you don't say = what happens if the max-LSPs field differs between the forwards and reverse= direction GEN-LB object). This in turn will make implementation more fidd= ly and potentially less interoperable. How about including the reverse-dir= ection TSPEC in the same object as the forwards-direction TSPEC if the R bi= t is set? [[Margaria.C]] Its a good point, I will consider it. You state that multiple objects with the same TSPEC type are dealt with by = ignoring all but the first. Why do you allow multiple objects with a diffe= rent TSPEC type? [[Margaria.C]] To be permissive, this is done in other protocols And what is the PCE to so with a request containing different types of TSP= EC? I think that all TSPECs need to have the same type. [[Margaria.C]] This is to address draft-ietf-pce-inter-layer-ext, I do not = think we should disallow requesting an Ethernet LSP using a SDH or OTN laye= r (and specifying if we do prefer ODU 0 or ODUFLex) Section 2.4.1 Generalized-Endpoint object type To aid clarity, suggest rewording this: "A PCE not supporting those TLVs but not being able to fulfill the label restriction MUST respond with a response with NO-PATH with the bit "No endpoint label resource" or "No endpoint label resource in range" in the NO-PATH- VECTOR TLV, the response SHOULD include the ENDPOINT object in the response with only the TLV where it could not met the constraint." to this: "A PCE supporting those TLVs but not being able to fulfil the label restriction MUST send a response with a NO-PATH object which has the bit "No endpoint label resource" or "No endpoint label resource in range" set in the NO-PATH- VECTOR TLV. The response SHOULD include an ENDPOINT object containing only the TLV where the PCE could not meet the constraint." [[Margaria.C]] OK Section 2.4.2.5 Labels TLV Suggest changing "This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET TLV Set." to "This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET TLV Set and ignored on receipt." [[Margaria.C]] OK Delete orphaned text which says "Table 5" - no table present in this sectio= n. [[Margaria.C]] OK Section 2.5 Stipulate that IP address subobject MUST be a link subobject. Clarify that >1 label subobject may follow each link-address or unnumbered-= link subobject. [[Margaria.C]] OK Section 2.6 XRO Better to just define the X bit than refer to RFC 5521. The definition is = simple enough. [[Margaria.C]] I would do both. You say the C-Type is "copied from the label object" - what label object? = Isn't this just a number which identifies the type of the labels? [[Margaria.C]] Yes, I will correct. Does the label field specify a single label or an array of labels? (Suppos= e single label but it is not quite clear.) [[Margaria.C]] A single label, for multiple label this should be repeated Section 2.7 PROTECTION-ATTRIBUTE TLV I am not sure that re-using the format from RFC 4872/4873 is the right way = to go. It leaves us with a format containing many elements that are superf= luous (or at least, not obviously applicable) to path computation. It woul= d help if you could add some text explaining why each field is applicable t= o path computation. [[Margaria.C]] --> keeping the same format is done for simplicity of the de= finition, and this object is used as policy input. For example, on the PROTECTION-ATTRIBUTE TLV flags: =B7 S bit: since the PCE server does not assign resources, it seems= that this bit will not be used in PCEP, correct? =B7 N bit: I think this is irrelevant to PCEP. =B7 O bit: ditto. =B7 I bit: ditto. =B7 R bit: ditto. Unless I have misunderstood, I think It would be better not to define these= bits in the object format. If you must have them then I think you should = at least stipulate that they are ignored on receipt. [[Margaria.C]] So it woud be better to state "contains the value of the PRO= TECTION object defined by RFC4872" and its used for policy input. You say "LSP Flags can be considered for routing policy based on the protec= tion type." I think you must mean the Link Flags, since these specify the = link attributes that the path requires. I am not sure what use the LSP fla= gs are to the PCE; please could you explain? Same comment applies to segme= nt recovery flags. Where you say "The other attributes are only meaningful for a stateful PCE"= , please could you say why a stateful PCE might make use of them, or point = me at a draft where this is discussed? Some semantic are covered in draft-tanaka-pce-stateful-pce-mbb-01 , draft-= crabbe-pce-stateful-pce-protection-00 and they also were present in draft-i= etf-pce-stateful-pce . --_000_523C37072C291347B9730C9291CCA07D0CC675DB3PRD0411MB427eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

 

Thanks for the review,= please see inline .

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: Jonathan= Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Tuesday, July 23, 2013 4:22 PM
To: draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org
Cc: pce@ietf.org
Subject: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

 

Hello

 

I have reviewed this draft and = have the following comments and questions.

 

Best regards<= /p>

Jon

 

 

Section 2 RBNF

The RBNF implies that BANDWITH = and GENERALIZED-BANDWIDTH can be mixed on a single request & response.&= nbsp; That looks wrong to me, I think that either one or the other should b= e supplied but not both.  If both really can be used, please could you add text explaining why?

Same comment for LOAD-BALANCING= and GENERALIZED-LOAD-BALANCING.

&n= bsp;

[= [Margaria.C]] This is for backward-compatibility : for instance for reoptim= ization request the BANDWIDTH MUST be provided. We did not want to change e= xisting  logic but to enhance the information. The GENERALIZED-BANDWIDTH is present as a detailed expression of the BANDW= IDTH.  

&n= bsp;

 

Section 2.1 RP object

The bits used for the RG flag a= re not defined until section 5.4.  Please at least xref from 2.1 to 5.= 4 for the definition.  Better still, define them in section 2.1.<= /o:p>

&n= bsp;

[= [Margaria.C]] OK

&n= bsp;

“The RG flag is backward-compatible with
[RFC5440]: the value sent by an implementation (PCC or PCE) not
   supporting it will indicate a node g=
ranularity.”

 

Pre-existing implementations ma= y calculate at node or link granularity so I don’t think you can assu= me that a back-level implementation will always return node-level granulari= ty.  So, backwards-compatibility does not work as you expect.

&n= bsp;

[= [Margaria.C]] In that case the ERO contains nodes, the intent is more to as= k for a more detailed route rather than to force a less detailed route. The= values should be read as node (or better) , not node-only ERO (Wording can be added).  Do you see a use case fo= r node-only ERO (or link-only ERO) ?

&n= bsp;

My suggestion is to make 0 the = reserved value for the RG flags (not 3).  Then the backwards compatibi= lity problem is resolved, since the value RG=3D=3D0 implies that the sender= is a back-level node and so is ignoring the RG field.

 

“If a PCE honored the the requested routing=
 granularity for a request,
it SHOULD indicate the selected routing granulari=
ty in the RP object
included in the response”=

 

Suggest changing the above exce= rpt to:

 

“The PCE MUST indicate the selected routing=
 granularity in the RP object
included in the response”=

 

Justification: I think you mean= MUST, not SHOULD.  Otherwise the PCC can’t rely on the RG flag,= rendering it useless. 

[= [Margaria.C]] In the absence of flag the PCC should check. The SHOULD is he= re to allow PCEs supporting the other object but not filling this bit, but = in any case they can put 0 (PCC has to check then), so a MUST can be added.

Also, why should the PCE do thi= s only if it honoured the RG?  I think the PCE should be free to use p= olicy to choose to route at a different RG than that given in the request, = and whatever RG is chooses to do the routing at, it should return that RG in the response.

[= [Margaria.C]] OK

<= o:p> 

  Along the same lines:

 

“The PCE MAY return
finer granularity on the route based on its polic=
y.  The PCC can
decide if the ERO is acceptable based on its cont=
ent.”

 

Suggest changing the above exce= rpt to

 

“The PCE MAY return
any granularity it likes on the route based on it=
s policy.  The PCC can
decide if the ERO is acceptable based on its cont=
ent.”

&n= bsp;

[= [Margaria.C]] OK

Comment on the following statem= ent:

 

“The PCE MAY try to follow this granularity=
 and MAY return a NO-PATH
if the requested granularity cannot be provided.&=
#8221;

 

If the PCE cannot supply a path= at the given granularity then it is either a problem with the PCE’s = capabilities or a policy issue.  As such, NO-PATH is not appropriate; = the PCE should respond with PCErr with a suitable error code.

[= [Margaria.C]] The PCE may also miss TE information (loose routing over a do= main or missing label information) , so a NO-PATH is valid in that case (if= policy dictate it should not return a lower granularity).

I= will add the PCErr for the case you mentioned.

 

 

Section 2.2 and 2.3 GENERALI= ZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING

I think it is better to specify= a format for the GENERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING obje= cts that allows a single instance of the object to specify both forwards an= d reverse bandwidth.  By having two objects you complicate matters because you then need to specify (and write= extra code for!) all the consistency rules between the objects (e.g. you d= on’t say what happens if the max-LSPs field differs between the forwa= rds and reverse direction GEN-LB object).  This in turn will make implementation more fiddly and potentially less int= eroperable.  How about including the reverse-direction TSPEC in the sa= me object as the forwards-direction TSPEC if the R bit is set?

[= [Margaria.C]] Its a good point, I will consider it.

 

You state that multiple objects= with the same TSPEC type are dealt with by ignoring all but the first.&nbs= p; Why do you allow multiple objects with a different TSPEC type? 

[= [Margaria.C]] To be permissive, this is done in other protocols

 And what is the PCE to so= with a request containing different types of TSPEC?  I think that all= TSPECs need to have the same type.

[= [Margaria.C]] This is to address draft-ietf-pce-inter-layer-ext, I do not t= hink we should disallow requesting an Ethernet LSP using a SDH or OTN layer= (and specifying if we do prefer ODU 0 or ODUFLex)

 

 

Section 2.4.1 Generalized-En= dpoint object type

To aid clarity, suggest rewordi= ng this:

 

“A PCE not supporting those

   TLVs but not being able to ful= fill the label restriction MUST respond

   with a response with NO-PATH w= ith the bit "No endpoint label

   resource" or "No end= point label resource in range" in the NO-PATH-

   VECTOR TLV, the response SHOUL= D include the ENDPOINT object in the

   response with only the TLV whe= re it could not met the constraint.”=

 

to this:

 

“A PCE supporting those

   TLVs but not being able to ful=
fil the label restriction MUST send


   a response with a NO-PATH obje=
ct which has the bit "No endpoint label


   resource" or "No end=
point label resource in range" set in the NO-PATH-

   VECTOR TLV.  The response=
 SHOULD include an ENDPOINT object



   containing only the TLV w=
here the PCE could not meet the constraint.R=
21;


 


[=
[Margaria.C]]
OK


&n=
bsp;


Section 2.4.2.5 Labels TLV


Suggest changing


 


“This Bit SHOULD be set to 0 in a SUGGESTED=
-LABEL-SET


      TLV Set.”


 


to


 


“This Bit SHOULD be set to 0 in a SUGGESTED=
-LABEL-SET


      TLV Set and =
ignored on receipt.”

[=
[Margaria.C]]
OK


Delete orphaned text which says=
 “Table 5” – no table present in this section.=



[=
[Margaria.C]] OK


 


 


Section 2.5


Stipulate that IP address subob=
ject MUST be a link subobject.


Clarify that >1 label subobj=
ect may follow each link-address or unnumbered-link subobject.


 


[=
[Margaria.C]]
OK


Section 2.6 XRO


Better to just define the X bit=
 than refer to RFC 5521.  The definition is simple enough.<=
/span>


[=
[Margaria.C]]
I would do both=
.


You say the C-Type is “co=
pied from the label object” – what label object?  Isn̵=
7;t this just a number which identifies the type of the labels? 



[=
[Margaria.C]]
Yes, I will cor=
rect.


Does the label field specify a =
single label or an array of labels?  (Suppose single label but it is n=
ot quite clear.)


[=
[Margaria.C]]
A single label,=
 for multiple label this should be repeated



 


Section 2.7 PROTECTION-ATTRI=
BUTE TLV


I am not sure that re-using the=
 format from RFC 4872/4873 is the right way to go.  It leaves us with =
a format containing many elements that are superfluous (or at least, not ob=
viously applicable) to path computation. 
 It would help if you could add some text explaining why each field is appl=
icable to path computation.


[=
[Margaria.C]]
=E0 keeping the =
same format is done for simplicity of the definition, and this object is us=
ed as policy input.


For example, on the PROTECTION-=
ATTRIBUTE TLV flags:


=B7        
S bit: since the PCE se=
rver does not assign resources, it seems that this bit will not be used in =
PCEP, correct?


=B7        
N bit: I think this is =
irrelevant to PCEP.


=B7        
O bit: ditto.


=B7        
I bit: ditto.


=B7        
R bit: ditto.


 


Unless I have misunderstood, I =
think It would be better not to define these bits in the object format.&nbs=
p; If you must have them then I think you should at least stipulate that th=
ey are ignored on receipt.


&n=
bsp;


[=
[Margaria.C]] So it woud be better to state “contains the value of th=
e PROTECTION object defined by RFC4872” and its used for policy input=
.


&n=
bsp;


You say “LSP Flags can be=
 considered for routing policy based on the protection type.”  I=
 think you must mean the Link Flags, since these specify the link attribute=
s that the path requires.  I am not sure what use the
 LSP flags are to the PCE; please could you explain?  Same comment app=
lies to segment recovery flags.


 


Where you say “The other attributes =
are only meaningful for a stateful PCE”, please could you say why a s=
tateful PCE might make use of them, or point me at a draft where this is di=
scussed?


Some se=
mantic are covered in draft-tanaka-pce-stateful-pce-mbb-01 ,  draft-cr=
abbe-pce-stateful-pce-protection-00 and they also were present in draft-iet=
f-pce-stateful-pce .



 
--_000_523C37072C291347B9730C9291CCA07D0CC675DB3PRD0411MB427eu_-- From Jonathan.Hardwick@metaswitch.com Tue Jul 30 02:15:03 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC09C21E80F9 for ; Tue, 30 Jul 2013 02:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJbsFlUQvPn4 for ; Tue, 30 Jul 2013 02:14:53 -0700 (PDT) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD1921F9E2B for ; Tue, 30 Jul 2013 02:09:05 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.209.38) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 30 Jul 2013 10:08:19 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.02.0342.003; Tue, 30 Jul 2013 10:08:46 +0100 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: Comments on draft-ietf-pce-gmpls-pcep-extensions-08 Thread-Index: Ac6HsAzdUISi4eHgQZqcl365JKGg0QBjjtbQAPEjCdA= Date: Tue, 30 Jul 2013 09:08:46 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863A@ENFICSMBX1.datcon.co.uk> References: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5@ENFICSMBX1.datcon.co.uk> <523C37072C291347B9730C9291CCA07D0CC675@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: <523C37072C291347B9730C9291CCA07D0CC675@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.143] Content-Type: multipart/alternative; boundary="_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863AENFICSMBX1datco_" MIME-Version: 1.0 Cc: "draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org" , "Margaria, Cyril \(Coriant - DE/Munich\)" Subject: Re: [Pce] Comments on draft-ietf-pce-gmpls-pcep-extensions-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:15:04 -0000 --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863AENFICSMBX1datco_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cyril and I had an offline conversation about these comments. This email i= s to document the discussion for the benefit of the mailing list. See [JEH= -MC] comments below. We have one question for the WG, as follows. If anyone has an opinion on t= his, please could you provide it to the mailing list? --- [JEH-MC] Jon believes that this draft should relax the restriction of RFC 5= 440 that the BANDWIDTH object is mandatory, in the case where a GENERALIZED= -BANDWIDTH is supplied instead. This would mean changing existing procedur= es, the initial mechanism was not to change RFC5440 object presence rule. = Cyril is fine with the proposal from Jonathan, but we would like to get WG = and implementers feedback. --- Regards Jon & Cyril From: Margaria, Cyril (Coriant - DE/Munich) [mailto:cyril.margaria@coriant.= com] Sent: 25 July 2013 16:42 To: Jonathan Hardwick; draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org Cc: pce@ietf.org Subject: RE: Comments on draft-ietf-pce-gmpls-pcep-extensions-08 Hi Jonathan, Thanks for the review, please see inline . Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Tuesday, July 23, 2013 4:22 PM To: draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org Cc: pce@ietf.org Subject: Comments on draft-ietf-pce-gmpls-pcep-extensions-08 Hello I have reviewed this draft and have the following comments and questions. Best regards Jon Section 2 RBNF The RBNF implies that BANDWITH and GENERALIZED-BANDWIDTH can be mixed on a = single request & response. That looks wrong to me, I think that either one= or the other should be supplied but not both. If both really can be used,= please could you add text explaining why? Same comment for LOAD-BALANCING and GENERALIZED-LOAD-BALANCING. [[Margaria.C]] This is for backward-compatibility : for instance for reopti= mization request the BANDWIDTH MUST be provided. We did not want to change = existing logic but to enhance the information. The GENERALIZED-BANDWIDTH i= s present as a detailed expression of the BANDWIDTH. [JEH-MC] Jon believes that this draft should relax the restriction of RFC 5= 440 that the BANDWIDTH object is mandatory, in the case where a GENERALIZED= -BANDWIDTH is supplied instead. This would mean changing existing procedur= es, the initial mechanism was not to change RFC5440 object presence rule. = Cyril is fine with the proposal from Jonathan, but we would like to get WG = and implementers feedback. Section 2.1 RP object The bits used for the RG flag are not defined until section 5.4. Please at= least xref from 2.1 to 5.4 for the definition. Better still, define them = in section 2.1. [[Margaria.C]] OK "The RG flag is backward-compatible with [RFC5440]: the value sent by an impleme= ntation (PCC or PCE) not supporting it will indicate a node granularity." Pre-existing implementations may calculate at node or link granularity so I= don't think you can assume that a back-level implementation will always re= turn node-level granularity. So, backwards-compatibility does not work as = you expect. [[Margaria.C]] In that case the ERO contains nodes, the intent is more to a= sk for a more detailed route rather than to force a less detailed route. Th= e values should be read as node (or better) , not node-only ERO (Wording ca= n be added). Do you see a use case for node-only ERO (or link-only ERO) ? [JEH-MC] We agreed that it would make the PCC's life easier if it could tel= l just by looking at the RG flag in the response whether the PCE understand= s and uses the RG flag. This suggests that RG=3D0 sent by the PCE should n= ot convey any information about granularity, meaning that the PCC has to ch= eck the ERO's granularity by hand. If the PCE supplies a non-zero RG flag = then the semantic is that the returned ERO's granularity is "at least" the = granularity conveyed by the RG (so that if any part of the ERO is at node g= ranularity then "RG=3Dnode granularity" is used). My suggestion is to make 0 the reserved value for the RG flags (not 3). Th= en the backwards compatibility problem is resolved, since the value RG=3D= =3D0 implies that the sender is a back-level node and so is ignoring the RG= field. "If a PCE honored the the requested routing granularity for a request, it SHOULD indicate the selected routing granularity in the RP object included in the response" Suggest changing the above excerpt to: "The PCE MUST indicate the selected routing granularity in the RP object included in the response" Justification: I think you mean MUST, not SHOULD. Otherwise the PCC can't = rely on the RG flag, rendering it useless. [[Margaria.C]] In the absence of flag the PCC should check. The SHOULD is h= ere to allow PCEs supporting the other object but not filling this bit, but= in any case they can put 0 (PCC has to check then), so a MUST can be added= . Also, why should the PCE do this only if it honoured the RG? I think the P= CE should be free to use policy to choose to route at a different RG than t= hat given in the request, and whatever RG is chooses to do the routing at, = it should return that RG in the response. [[Margaria.C]] OK Along the same lines: "The PCE MAY return finer granularity on the route based on its policy. The PCC can decide if the ERO is acceptable based on its content." Suggest changing the above excerpt to "The PCE MAY return any granularity it likes on the route based on its policy. The PCC can decide if the ERO is acceptable based on its content." [[Margaria.C]] OK Comment on the following statement: "The PCE MAY try to follow this granularity and MAY return a NO-PATH if the requested granularity cannot be provided." If the PCE cannot supply a path at the given granularity then it is either = a problem with the PCE's capabilities or a policy issue. As such, NO-PATH = is not appropriate; the PCE should respond with PCErr with a suitable error= code. [[Margaria.C]] The PCE may also miss TE information (loose routing over a d= omain or missing label information) , so a NO-PATH is valid in that case (i= f policy dictate it should not return a lower granularity). I will add the PCErr for the case you mentioned. Section 2.2 and 2.3 GENERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING I think it is better to specify a format for the GENERALIZED-BANDWIDTH and = GENERALIZED-LOAD-BALANCING objects that allows a single instance of the obj= ect to specify both forwards and reverse bandwidth. By having two objects = you complicate matters because you then need to specify (and write extra co= de for!) all the consistency rules between the objects (e.g. you don't say = what happens if the max-LSPs field differs between the forwards and reverse= direction GEN-LB object). This in turn will make implementation more fidd= ly and potentially less interoperable. How about including the reverse-dir= ection TSPEC in the same object as the forwards-direction TSPEC if the R bi= t is set? [[Margaria.C]] Its a good point, I will consider it. [JEH-MC] This is with Cyril to think about. He will provide an explanation= back to the list if he decides not to do this. You state that multiple objects with the same TSPEC type are dealt with by = ignoring all but the first. Why do you allow multiple objects with a diffe= rent TSPEC type? [[Margaria.C]] To be permissive, this is done in other protocols And what is the PCE to so with a request containing different types of TSP= EC? I think that all TSPECs need to have the same type. [[Margaria.C]] This is to address draft-ietf-pce-inter-layer-ext, I do not = think we should disallow requesting an Ethernet LSP using a SDH or OTN laye= r (and specifying if we do prefer ODU 0 or ODUFLex) [JEH-MC] A paragraph will be added on the usage of multiple TSPEC types in = the Inter-layer scenario. This will be done in consultation with the inter= -layer draft authors. Section 2.4.1 Generalized-Endpoint object type To aid clarity, suggest rewording this: "A PCE not supporting those TLVs but not being able to fulfill the label restriction MUST respond with a response with NO-PATH with the bit "No endpoint label resource" or "No endpoint label resource in range" in the NO-PATH- VECTOR TLV, the response SHOULD include the ENDPOINT object in the response with only the TLV where it could not met the constraint." to this: "A PCE supporting those TLVs but not being able to fulfil the label restriction MUST send a response with a NO-PATH object which has the bit "No endpoint label resource" or "No endpoint label resource in range" set in the NO-PATH- VECTOR TLV. The response SHOULD include an ENDPOINT object containing only the TLV where the PCE could not meet the constraint." [[Margaria.C]] OK Section 2.4.2.5 Labels TLV Suggest changing "This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET TLV Set." to "This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET TLV Set and ignored on receipt." [[Margaria.C]] OK Delete orphaned text which says "Table 5" - no table present in this sectio= n. [[Margaria.C]] OK Section 2.5 Stipulate that IP address subobject MUST be a link subobject. Clarify that >1 label subobject may follow each link-address or unnumbered-= link subobject. [[Margaria.C]] OK Section 2.6 XRO Better to just define the X bit than refer to RFC 5521. The definition is = simple enough. [[Margaria.C]] I would do both. You say the C-Type is "copied from the label object" - what label object? = Isn't this just a number which identifies the type of the labels? [[Margaria.C]] Yes, I will correct. Does the label field specify a single label or an array of labels? (Suppos= e single label but it is not quite clear.) [[Margaria.C]] A single label, for multiple label this should be repeated Section 2.7 PROTECTION-ATTRIBUTE TLV I am not sure that re-using the format from RFC 4872/4873 is the right way = to go. It leaves us with a format containing many elements that are superf= luous (or at least, not obviously applicable) to path computation. It woul= d help if you could add some text explaining why each field is applicable t= o path computation. [[Margaria.C]] --> keeping the same format is done for simplicity of the de= finition, and this object is used as policy input. For example, on the PROTECTION-ATTRIBUTE TLV flags: =B7 S bit: since the PCE server does not assign resources, it seems= that this bit will not be used in PCEP, correct? =B7 N bit: I think this is irrelevant to PCEP. =B7 O bit: ditto. =B7 I bit: ditto. =B7 R bit: ditto. Unless I have misunderstood, I think It would be better not to define these= bits in the object format. If you must have them then I think you should = at least stipulate that they are ignored on receipt. [[Margaria.C]] So it woud be better to state "contains the value of the PRO= TECTION object defined by RFC4872" and its used for policy input. [JEH-MC] Since the intent of providing this attribute is largely to allow f= or policy on the stateful PCE, we agreed that it is best to keep the existi= ng format. You say "LSP Flags can be considered for routing policy based on the protec= tion type." I think you must mean the Link Flags, since these specify the = link attributes that the path requires. I am not sure what use the LSP fla= gs are to the PCE; please could you explain? Same comment applies to segme= nt recovery flags. [[Margaria.C]] In fact this can be both. The link flags can be used as-is, = the LSP flags (LSP (protection) flags, from RFC4872) will indicate the TE-L= SP protection type, this protection type is a good example of routing polic= y input. I can modify the text as follows : "For example LSP (protection) Flags or Link flags fields can be used by imp= lementation for routing policy input." A more concrete example could be added "A PCE could prefer specific link fo= r a given protection type, for instance path with short delays for 1+1 prot= ected path if they correspond to a different SLA class". But this may be to= o much. Where you say "The other attributes are only meaningful for a stateful PCE"= , please could you say why a stateful PCE might make use of them, or point = me at a draft where this is discussed? Some semantic are covered in draft-tanaka-pce-stateful-pce-mbb-01 , draft-= crabbe-pce-stateful-pce-protection-00 and they also were present in draft-i= etf-pce-stateful-pce . --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863AENFICSMBX1datco_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Cyril and I had an off= line conversation about these comments.  This email is to document the= discussion for the benefit of the mailing list.  See [JEH-MC] comments below.

 

We have one question f= or the WG, as follows.  If anyone has an opinion on this, please could= you provide it to the mailing list?

 

---<= /p>

[JEH-MC]= Jon believes that this draft should relax th= e restriction of RFC 5440 that the BANDWIDTH object is mandatory, in the ca= se where a GENERALIZED-BANDWIDTH is supplied instead.  This would mean changing existing procedures, the initial m= echanism was not to change RFC5440 object presence rule.  Cyril is fin= e with the proposal from Jonathan, but we would like to get WG and implemen= ters feedback.

---<= /p>

 

Regards

Jon & Cyril

 

 

From: Margaria, Cyril (Coriant - DE/Munich) [mailto:cyril.m= argaria@coriant.com]
Sent: 25 July 2013 16:42
To: Jonathan Hardwick; draft-ietf-pce-gmpls-pcep-extensions@tools.ie= tf.org
Cc: pce@ietf.org
Subject: RE: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

 

Hi Jona= than,

&n= bsp;

Thanks = for the review, please see inline .

&n= bsp;

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Tuesday, July 23, 2013 4:22 PM
To: draft-ietf-pce-gmpls-pcep-extensions@tools.ietf.org
Cc: pce@ietf.org
Subject: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

 

Hello

 

I have reviewed this draft and have the following co= mments and questions.

 

Best regards

Jon

 

 

Section 2 RBNF

The RBNF implies that BANDWITH and GENERALIZED-BANDW= IDTH can be mixed on a single request & response.  That looks wron= g to me, I think that either one or the other should be supplied but not bo= th.  If both really can be used, please could you add text explaining why?

Same comment for LOAD-BALANCING and GENERALIZED-LOAD= -BALANCING.

 

[[Margaria.C]] T= his is for backward-compatibility : for instance for reoptimization request= the BANDWIDTH MUST be provided. We did not want to change existing  l= ogic but to enhance the information. The GENERALIZED-BANDWIDTH is present as a detailed expression of the BANDWIDTH= .  

 

[JEH-MC]= Jon believes that this draft should relax th= e restriction of RFC 5440 that the BANDWIDTH object is mandatory, in the ca= se where a GENERALIZED-BANDWIDTH is supplied instead.  This would mean changing existing procedures, the initial m= echanism was not to change RFC5440 object presence rule.  Cyril is fin= e with the proposal from Jonathan, but we would like to get WG and implemen= ters feedback.

 

 

Section 2.1 RP object

The bits used for the RG flag are not defined until = section 5.4.  Please at least xref from 2.1 to 5.4 for the definition.=   Better still, define them in section 2.1.

 

[[Margaria.C]] O= K

 

“The RG flag is backward-compatible with
[RFC5440]: =
the value sent by an implementation (PCC or PCE) not
   supporting it will indicate a node granularity.”

 

Pre-existing implementations may calculate at node o= r link granularity so I don’t think you can assume that a back-level = implementation will always return node-level granularity.  So, backwar= ds-compatibility does not work as you expect.

 

[[Margaria.C]] I= n that case the ERO contains nodes, the intent is more to ask for a more de= tailed route rather than to force a less detailed route. The values should = be read as node (or better) , not node-only ERO (Wording can be added).  Do you see a use case for node-only ERO = (or link-only ERO) ?

 

[JEH-MC]= We agreed that it would make the PCC’s= life easier if it could tell just by looking at the RG flag in the respons= e whether the PCE understands and uses the RG flag.  This suggests that RG=3D0 sent by the PCE should not convey an= y information about granularity, meaning that the PCC has to check the ERO&= #8217;s granularity by hand.  If the PCE supplies a non-zero RG flag t= hen the semantic is that the returned ERO’s granularity is “at least” the granularity conveyed by the RG (so that if a= ny part of the ERO is at node granularity then “RG=3Dnode granularity= ” is used).

 

 

My suggestion is to make 0 the reserved value for th= e RG flags (not 3).  Then the backwards compatibility problem is resol= ved, since the value RG=3D=3D0 implies that the sender is a back-level node= and so is ignoring the RG field.

 

“If a PCE honored the the requested routing granularity for a re=
quest,
it SHOULD indicate the selected routing granularity in the RP object
included in the response”

 

Suggest changing the above excerpt to:

 

“The PCE MUST indicate the selected routing granularity in the R=
P object
included in the response”

 

Justification: I think you mean MUST, not SHOULD.&nb= sp; Otherwise the PCC can’t rely on the RG flag, rendering it useless= . 

[[Margaria.C]] I= n the absence of flag the PCC should check. The SHOULD is here to allow PCE= s supporting the other object but not filling this bit, but in any case the= y can put 0 (PCC has to check then), so a MUST can be added.

Also, why should the PCE do this only if it honoured= the RG?  I think the PCE should be free to use policy to choose to ro= ute at a different RG than that given in the request, and whatever RG is ch= ooses to do the routing at, it should return that RG in the response.

[[Margaria.C]] O= K

 

  Along the same lines:

 

“The PCE MAY return
finer granularity on the route based on its policy.  The PCC can<=
o:p>
decide if the ERO is acceptable based on its content.”

 

Suggest changing the above excerpt to

 

“The PCE MAY return
any granularity it likes on the route based on its policy.  The P=
CC can
decide if the ERO is acceptable based on its content.”

 

[[Margaria.C]] O= K

Comment on the following statement:

 

“The PCE MAY try to follow this granularity and MAY return a NO-=
PATH
if the requested granularity cannot be provided.”

 


If the PCE cannot supply a path at the given granula=
rity then it is either a problem with the PCE’s capabilities or a pol=
icy issue.  As such, NO-PATH is not appropriate; the PCE should respon=
d with PCErr with a suitable error code.


[[Margaria.C]] T=
he PCE may also miss TE information (loose routing over a domain or missing=
 label information) , so a NO-PATH is valid in that case (if policy dictate=
 it should not return a lower granularity).


I will add the P=
CErr for the case you mentioned.


 


 


Section 2.2 and 2.3 GENERALIZED-BANDWIDTH and GEN=
ERALIZED-LOAD-BALANCING


I think it is better to specify a format for the GEN=
ERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING objects that allows a sin=
gle instance of the object to specify both forwards and reverse bandwidth.&=
nbsp; By having two objects you complicate
 matters because you then need to specify (and write extra code for!) all t=
he consistency rules between the objects (e.g. you don’t say what hap=
pens if the max-LSPs field differs between the forwards and reverse directi=
on GEN-LB object).  This in turn will
 make implementation more fiddly and potentially less interoperable.  =
How about including the reverse-direction TSPEC in the same object as the f=
orwards-direction TSPEC if the R bit is set?


[[Margaria.C]] I=
ts a good point, I will consider it.


 


[JEH-MC]=
 This is with Cyril to think about.  He =
will provide an explanation back to the list if he decides not to do this.<=
o:p>


 


You state that multiple objects with the same TSPEC =
type are dealt with by ignoring all but the first.  Why do you allow m=
ultiple objects with a different TSPEC type? 


[[Margaria.C]] T=
o be permissive, this is done in other protocols



 And what is the PCE to so with a request conta=
ining different types of TSPEC?  I think that all TSPECs need to have =
the same type.


[[Margaria.C]] T=
his is to address draft-ietf-pce-inter-layer-ext, I do not think we should =
disallow requesting an Ethernet LSP using a SDH or OTN layer (and specifyin=
g if we do prefer ODU 0 or ODUFLex)



 


[JEH-MC]=
 A paragraph will be added on the usage of mu=
ltiple TSPEC types in the Inter-layer scenario.  This will be done in =
consultation with the inter-layer draft authors.


 


 


Section 2.4.1 Generalized-Endpoint object type


To aid clarity, suggest rewording this:

 


“A PCE not supporting those


   TLVs but not being able to fulfill the label =
restriction MUST respond


   with a response with NO-PATH with the bit &qu=
ot;No endpoint label


   resource" or "No endpoint label res=
ource in range" in the NO-PATH-


   VECTOR TLV, the response SHOULD include the E=
NDPOINT object in the


   response with only the TLV where it could not=
 met the constraint.”


 


to this:


 


“A PCE supporting those


   TLVs but not being able to fulfil the label r=
estriction MUST send


   a response with a NO-PATH object which has th=
e bit "No endpoint label


   resource" or "No endpoint label res=
ource in range" set in the NO-PATH-


   VECTOR TLV.  The response SHOULD include=
 an ENDPOINT object



   containing only the TLV where the PCE co=
uld not meet the constraint.”


 


[[Margaria.C]] <=
/span>OK


 


Section 2.4.2.5 Labels TLV


Suggest changing


 


“This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET=



      TLV Set.”=



 


to


 


“This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET=



      TLV Set and ignored on rece=
ipt.”


[[Margaria.C]] <=
/span>OK


Delete orphaned text which says “Table 5”=
; – no table present in this section.


[[Margaria.C]] O=
K


 


 


Section 2.5


Stipulate that IP address subobject MUST be a link s=
ubobject.


Clarify that >1 label subobject may follow each l=
ink-address or unnumbered-link subobject.


 


[[Margaria.C]] <=
/span>OK


Section 2.6 XRO


Better to just define the X bit than refer to RFC 55=
21.  The definition is simple enough.


[[Margaria.C]] <=
/span>I would do both.


You say the C-Type is “copied from the label o=
bject” – what label object?  Isn’t this just a numbe=
r which identifies the type of the labels? 



[[Margaria.C]] <=
/span>Yes, I will correct.


Does the label field specify a single label or an ar=
ray of labels?  (Suppose single label but it is not quite clear.)=



[[Margaria.C]] <=
/span>A single label, for multiple la=
bel this should be repeated



 


Section 2.7 PROTECTION-ATTRIBUTE TLV


I am not sure that re-using the format from RFC 4872=
/4873 is the right way to go.  It leaves us with a format containing m=
any elements that are superfluous (or at least, not obviously applicable) t=
o path computation.  It would help if you
 could add some text explaining why each field is applicable to path comput=
ation.


[[Margaria.C]] <=
/span>=E0 keeping the same format is done for simplic=
ity of the definition, and this object is
 used as policy input.


For example, on the PROTECTION-ATTRIBUTE TLV flags:<=
o:p>


=B7        
S bit: since the PCE server does not assign =
resources, it seems that this bit will not be used in PCEP, correct?


=B7        
N bit: I think this is irrelevant to PCEP.


=B7        
O bit: ditto.


=B7        
I bit: ditto.


=B7        
R bit: ditto.


 


Unless I have misunderstood, I think It would be bet=
ter not to define these bits in the object format.  If you must have t=
hem then I think you should at least stipulate that they are ignored on rec=
eipt.


 


[[Margaria.C]] S=
o it woud be better to state “contains the value of the PROTECTION ob=
ject defined by RFC4872” and its used for policy input.


 


[JEH-MC]=
 Since the intent of providing this attribute=
 is largely to allow for policy on the stateful PCE, we agreed that it is b=
est to keep the existing format.


 


 


You say “LSP Flags can be considered for routi=
ng policy based on the protection type.”  I think you must mean =
the Link Flags, since these specify the link attributes that the path requi=
res.  I am not sure what use the LSP flags are to the
 PCE; please could you explain?  Same comment applies to segment recov=
ery flags.


 


[[Margaria.C]] I=
n fact this can be both. The link flags can be used as-is, the LSP flags (L=
SP (protection) flags, from RFC4872) will indicate the TE-LSP protection ty=
pe, this protection type is a good example
 of routing policy input. I can modify the text as follows : 


“For examp=
le LSP (protection) Flags or Link flags fields can be used by implementatio=
n for routing policy input.”


A more concrete =
example could be added “A PCE could prefer specific link for a given =
protection type, for instance path with short delays for 1+1 protected =
path if they correspond to a different SLA class”.
 But this may be too much. 


 


 


Where you say “The other attributes are only meanin=
gful for a stateful PCE”, please could you say why a stateful PCE mig=
ht make use of them, or point me at a draft where this is discussed?


Some semantic are cove=
red in draft-tanaka-pce-stateful-pce-mbb-01 ,  draft-crabbe-pce-statef=
ul-pce-protection-00 and they also were present in draft-ietf-pce-stateful-=
pce .



 
--_000_09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863AENFICSMBX1datco_-- From ramon.casellas@cttc.es Tue Jul 30 02:34:39 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D8721F9C81 for ; Tue, 30 Jul 2013 02:34:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa76Jkr1gQ+E for ; Tue, 30 Jul 2013 02:34:37 -0700 (PDT) Received: from villa.puc.rediris.es (villa.puc.rediris.es [IPv6:2001:720:418:ca00::7]) by ietfa.amsl.com (Postfix) with ESMTP id 57D0E11E8144 for ; Tue, 30 Jul 2013 02:32:29 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1V46I4-0006bz-2m; Tue, 30 Jul 2013 11:32:24 +0200 Received: from [192.168.101.86] (unknown [192.168.101.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 278481FD41; Tue, 30 Jul 2013 11:32:20 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <51F78824.4060907@cttc.es> Date: Tue, 30 Jul 2013 11:32:20 +0200 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jonathan Hardwick , "pce@ietf.org" References: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5@ENFICSMBX1.datcon.co.uk> <523C37072C291347B9730C9291CCA07D0CC675@DB3PRD0411MB427.eurprd04.prod.outlook.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863A@ENFICSMBX1.datcon.co.uk> In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863A@ENFICSMBX1.datcon.co.uk> Content-Type: multipart/alternative; boundary="------------090500010009080806080905" X-Spamina-Bogosity: Ham Subject: Re: [Pce] Comments on draft-ietf-pce-gmpls-pcep-extensions-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:34:39 -0000 This is a multi-part message in MIME format. --------------090500010009080806080905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 07/30/2013 11:08 AM, Jonathan Hardwick wrote: > > Cyril and I had an offline conversation about these comments. This > email is to document the discussion for the benefit of the mailing > list. See *[JEH-MC]* comments below. > > We have one question for the WG, as follows. If anyone has an opinion > on this, please could you provide it to the mailing list? > > --- > > *[JEH-MC]*Jon believes that this draft should relax the restriction of > RFC 5440 that the BANDWIDTH object is mandatory, in the case where a > GENERALIZED-BANDWIDTH is supplied instead. This would mean changing > existing procedures, the initial mechanism was not to change RFC5440 > object presence rule. Cyril is fine with the proposal from Jonathan, > but we would like to get WG and implementers feedback. > > Jon, Cyril, all In this case, I would go back to one of my initial suggestions: do not add GENERALIZED_BANDWIDTH and add a TLV to the BW objects, which can be ignored. In other words, the creation of GEN_BW was justified due to: a) do not touch rfc5440 b) if RFC5440 does not state that BW object can have TLVs, then they can't and it is fixed length. My personal preference always was to add a TLV or a new object type for BW. If we allow ourselves a liberal interpretation of rfc5440 then let's assume we can add a tlv... Just my opinion, of course, and not a particularly strong one Ramon -- Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division Optical Networks and Systems Department -- http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya Parc Mediterrani de la Tecnologia (PMT) - Edifici B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01 --------------090500010009080806080905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 07/30/2013 11:08 AM, Jonathan Hardwick wrote:

Cyril and I had an offline conversation about these comments.  This email is to document the discussion for the benefit of the mailing list.  See [JEH-MC] comments below.

 

We have one question for the WG, as follows.  If anyone has an opinion on this, please could you provide it to the mailing list?

 

---

[JEH-MC] Jon believes that this draft should relax the restriction of RFC 5440 that the BANDWIDTH object is mandatory, in the case where a GENERALIZED-BANDWIDTH is supplied instead.  This would mean changing existing procedures, the initial mechanism was not to change RFC5440 object presence rule.  Cyril is fine with the proposal from Jonathan, but we would like to get WG and implementers feedback.



Jon, Cyril, all

In this case, I would go back to one of my initial suggestions: do not add GENERALIZED_BANDWIDTH and add a TLV to the BW objects, which can be ignored.

In other words, the creation of GEN_BW was justified due to:  a) do not touch rfc5440 b) if RFC5440 does not state that BW object can have TLVs, then they can't and it is fixed length.

My personal preference always was to add a TLV or a new object type for BW.  If we allow ourselves a liberal interpretation of rfc5440 then let's assume we can add a tlv...

Just my opinion, of course, and not a particularly strong one

Ramon

-- 
Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division
Optical Networks and Systems Department -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya
Parc Mediterrani de la Tecnologia (PMT) - Edifici B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01
--------------090500010009080806080905-- From lsmt@ietf.org Tue Jul 30 03:25:54 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DB421F9AC6; Tue, 30 Jul 2013 03:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L4xvvoN187F; Tue, 30 Jul 2013 03:25:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FAA21F9E27; Tue, 30 Jul 2013 03:25:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: JP Vasseur , Julien Meuric X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730102552.12484.93896.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 03:25:52 -0700 X-Mailman-Approved-At: Tue, 30 Jul 2013 04:43:52 -0700 Cc: Scott Mansfield , Path Computation Element Discussion List Subject: [Pce] New Liaison Statement, "Liaison Statement on the SG15 OTNT Standardization Work Plan - pce" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 10:25:54 -0000 Title: Liaison Statement on the SG15 OTNT Standardization Work Plan - pce Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1277/ Please reply by 2014-03-07 From: ITU-T SG 15 (Yoshinori Koike ) To: Path Computation Element (JP Vasseur , Julien Meuric ) Cc: Stewart Bryant ,Adrian Farrel = ,Path Computation Element Discussion List ,John Drake ,Scott Mansfield Reponse Contact: = Technical Contact: = Purpose: For comment Body: = Attachments: Liaison Statement on the SG15 OTNT Standardization Work Plan https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-pce-liaison-statement-on-the-sg15-otnt-standardization-work-plan-pce= -attachment-1.pdf Draft Revised Optical Transport Networks & Technologies Standardization= Work Plan, Issue 17 https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-pce-liaison-statement-on-the-sg15-otnt-standardization-work-plan-pce= -attachment-2.pdf From zhangfatai@huawei.com Tue Jul 30 05:42:02 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D98811E81CB for ; Tue, 30 Jul 2013 05:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk9RG7bDD5Ue for ; Tue, 30 Jul 2013 05:41:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 90AF721F8C20 for ; Tue, 30 Jul 2013 05:41:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVO41322; Tue, 30 Jul 2013 12:41:53 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 13:41:32 +0100 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 13:41:35 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.007; Tue, 30 Jul 2013 20:41:29 +0800 From: Fatai Zhang To: Ramon Casellas , Jonathan Hardwick , "pce@ietf.org" Thread-Topic: [Pce] Comments on draft-ietf-pce-gmpls-pcep-extensions-08 Thread-Index: Ac6HsAzdUISi4eHgQZqcl365JKGg0QBjjtbQAPEjCdD//4ObAP//RcfA Date: Tue, 30 Jul 2013 12:41:28 +0000 Message-ID: References: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5@ENFICSMBX1.datcon.co.uk> <523C37072C291347B9730C9291CCA07D0CC675@DB3PRD0411MB427.eurprd04.prod.outlook.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863A@ENFICSMBX1.datcon.co.uk> <51F78824.4060907@cttc.es> In-Reply-To: <51F78824.4060907@cttc.es> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.201] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84EE429ADSZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Pce] =?utf-8?b?562U5aSNOiAgQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1wY2Ut?= =?utf-8?q?gmpls-pcep-extensions-08?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:42:02 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF84EE429ADSZXEML552MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHRoaW5rIGEgbmV3IG9iamVjdCB0eXBlIGNvdWxkIGJlIGJldHRlciBhbmQg c2ltcGxlLg0KDQpUaGFua3MNCg0KRmF0YWkNCg0KDQrlj5Hku7bkuro6IHBjZS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBSYW1vbiBDYXNlbGxh cw0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0N+aciDMw5pelIDE3OjMyDQrmlLbku7bkuro6IEpvbmF0 aGFuIEhhcmR3aWNrOyBwY2VAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtQY2VdIENvbW1lbnRzIG9u IGRyYWZ0LWlldGYtcGNlLWdtcGxzLXBjZXAtZXh0ZW5zaW9ucy0wOA0KDQpPbiAwNy8zMC8yMDEz IDExOjA4IEFNLCBKb25hdGhhbiBIYXJkd2ljayB3cm90ZToNCkN5cmlsIGFuZCBJIGhhZCBhbiBv ZmZsaW5lIGNvbnZlcnNhdGlvbiBhYm91dCB0aGVzZSBjb21tZW50cy4gIFRoaXMgZW1haWwgaXMg dG8gZG9jdW1lbnQgdGhlIGRpc2N1c3Npb24gZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBtYWlsaW5n IGxpc3QuICBTZWUgW0pFSC1NQ10gY29tbWVudHMgYmVsb3cuDQoNCldlIGhhdmUgb25lIHF1ZXN0 aW9uIGZvciB0aGUgV0csIGFzIGZvbGxvd3MuICBJZiBhbnlvbmUgaGFzIGFuIG9waW5pb24gb24g dGhpcywgcGxlYXNlIGNvdWxkIHlvdSBwcm92aWRlIGl0IHRvIHRoZSBtYWlsaW5nIGxpc3Q/DQoN Ci0tLQ0KW0pFSC1NQ10gSm9uIGJlbGlldmVzIHRoYXQgdGhpcyBkcmFmdCBzaG91bGQgcmVsYXgg dGhlIHJlc3RyaWN0aW9uIG9mIFJGQyA1NDQwIHRoYXQgdGhlIEJBTkRXSURUSCBvYmplY3QgaXMg bWFuZGF0b3J5LCBpbiB0aGUgY2FzZSB3aGVyZSBhIEdFTkVSQUxJWkVELUJBTkRXSURUSCBpcyBz dXBwbGllZCBpbnN0ZWFkLiAgVGhpcyB3b3VsZCBtZWFuIGNoYW5naW5nIGV4aXN0aW5nIHByb2Nl ZHVyZXMsIHRoZSBpbml0aWFsIG1lY2hhbmlzbSB3YXMgbm90IHRvIGNoYW5nZSBSRkM1NDQwIG9i amVjdCBwcmVzZW5jZSBydWxlLiAgQ3lyaWwgaXMgZmluZSB3aXRoIHRoZSBwcm9wb3NhbCBmcm9t IEpvbmF0aGFuLCBidXQgd2Ugd291bGQgbGlrZSB0byBnZXQgV0cgYW5kIGltcGxlbWVudGVycyBm ZWVkYmFjay4NCg0KDQpKb24sIEN5cmlsLCBhbGwNCg0KSW4gdGhpcyBjYXNlLCBJIHdvdWxkIGdv IGJhY2sgdG8gb25lIG9mIG15IGluaXRpYWwgc3VnZ2VzdGlvbnM6IGRvIG5vdCBhZGQgR0VORVJB TElaRURfQkFORFdJRFRIIGFuZCBhZGQgYSBUTFYgdG8gdGhlIEJXIG9iamVjdHMsIHdoaWNoIGNh biBiZSBpZ25vcmVkLg0KDQpJbiBvdGhlciB3b3JkcywgdGhlIGNyZWF0aW9uIG9mIEdFTl9CVyB3 YXMganVzdGlmaWVkIGR1ZSB0bzogIGEpIGRvIG5vdCB0b3VjaCByZmM1NDQwIGIpIGlmIFJGQzU0 NDAgZG9lcyBub3Qgc3RhdGUgdGhhdCBCVyBvYmplY3QgY2FuIGhhdmUgVExWcywgdGhlbiB0aGV5 IGNhbid0IGFuZCBpdCBpcyBmaXhlZCBsZW5ndGguDQoNCk15IHBlcnNvbmFsIHByZWZlcmVuY2Ug YWx3YXlzIHdhcyB0byBhZGQgYSBUTFYgb3IgYSBuZXcgb2JqZWN0IHR5cGUgZm9yIEJXLiAgSWYg d2UgYWxsb3cgb3Vyc2VsdmVzIGEgbGliZXJhbCBpbnRlcnByZXRhdGlvbiBvZiByZmM1NDQwIHRo ZW4gbGV0J3MgYXNzdW1lIHdlIGNhbiBhZGQgYSB0bHYuLi4NCg0KSnVzdCBteSBvcGluaW9uLCBv ZiBjb3Vyc2UsIGFuZCBub3QgYSBwYXJ0aWN1bGFybHkgc3Ryb25nIG9uZQ0KDQpSYW1vbg0KDQoN Cg0KLS0NCg0KUmFtb24gQ2FzZWxsYXMsIFBoLkQuIC0tIFNlbmlvciBSZXNlYXJjaCBBc3NvY2lh dGUgLS0gTmV0d29ya3MgRGl2aXNpb24NCg0KT3B0aWNhbCBOZXR3b3JrcyBhbmQgU3lzdGVtcyBE ZXBhcnRtZW50IC0tIGh0dHA6Ly93aWtpb25hLmN0dGMuZXMNCg0KQ1RUQyAtIENlbnRyZSBUZWNu b2zDsmdpYyBkZSBUZWxlY29tdW5pY2FjaW9ucyBkZSBDYXRhbHVueWENCg0KUGFyYyBNZWRpdGVy cmFuaSBkZSBsYSBUZWNub2xvZ2lhIChQTVQpIC0gRWRpZmljaSBCNA0KDQpBdi4gQ2FybCBGcmll ZHJpY2ggR2F1c3MsIDcgLSAwODg2MCBDYXN0ZWxsZGVmZWxzIChCYXJjZWxvbmEpIC0gU3BhaW4N Cg0KVGVsLjogKzM0IDkzIDY0NSAyOSAwMCBleHQgMjE2OC0tIEZheC4gKzM0IDkzIDY0NSAyOSAw MQ0K --_000_F82A4B6D50F9464B8EBA55651F541CF84EE429ADSZXEML552MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg 6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofm nKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueaz qOahhuaWh+acrDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OmJsYWNrO30NCnAuSFRNTFByZWZvcm1hdHRlZCwgbGkuSFRNTFByZWZvcm1hdHRlZCwgZGl2LkhU TUxQcmVmb3JtYXR0ZWQNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJZm9u dC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOiMxRjQ5N0Q7DQoJdGV4dC10cmFu c2Zvcm06bm9uZTsNCgl0ZXh0LXNoYWRvdzpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5v bmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9v blRleHQsIGRpdi5CYWxsb29uVGV4dA0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SGkgYWxsLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBhIG5ldyBvYmplY3QgdHlw ZSBjb3VsZCBiZSBiZXR0ZXIgYW5kIHNpbXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiMxRjQ5N0QiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3 RCI+RmF0YWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPiBwY2UtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0 ZXh0Ij7ku6PooaggPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+UmFtb24gQ2Fz ZWxsYXM8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij4gMjAxMzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6 d2luZG93dGV4dCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjc8L3NwYW4+5pyIPHNwYW4gbGFuZz0i RU4tVVMiPjMwPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAxNzozMjxicj4NCjwvc3Bh bj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiBKb25hdGhhbiBIYXJkd2ljazsgcGNlQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4 u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJl OiBbUGNlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXBjZS1nbXBscy1wY2VwLWV4dGVuc2lvbnMt MDg8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDA3 LzMwLzIwMTMgMTE6MDggQU0sIEpvbmF0aGFuIEhhcmR3aWNrIHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiM5NDM2MzQiPkN5cmlsIGFuZCBJIGhhZCBhbiBvZmZsaW5lIGNvbnZl cnNhdGlvbiBhYm91dCB0aGVzZSBjb21tZW50cy4mbmJzcDsgVGhpcyBlbWFpbCBpcyB0byBkb2N1 bWVudCB0aGUgZGlzY3Vzc2lvbiBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIG1haWxpbmcgbGlzdC4m bmJzcDsgU2VlDQo8Yj5bSkVILU1DXTwvYj4gY29tbWVudHMgYmVsb3cuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM5NDM2MzQiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojOTQzNjM0Ij5XZSBoYXZlIG9uZSBx dWVzdGlvbiBmb3IgdGhlIFdHLCBhcyBmb2xsb3dzLiZuYnNwOyBJZiBhbnlvbmUgaGFzIGFuIG9w aW5pb24gb24gdGhpcywgcGxlYXNlIGNvdWxkIHlvdSBwcm92aWRlIGl0IHRvIHRoZSBtYWlsaW5n IGxpc3Q/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM5NDM2 MzQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj OTQzNjM0Ij4tLS08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6Izk0MzYzNCI+W0pFSC1NQ108L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6Izk0MzYzNCI+IEpvbiBiZWxpZXZlcyB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIHJlbGF4 IHRoZSByZXN0cmljdGlvbiBvZiBSRkMgNTQ0MCB0aGF0IHRoZSBCQU5EV0lEVEggb2JqZWN0IGlz IG1hbmRhdG9yeSwgaW4gdGhlIGNhc2Ugd2hlcmUgYSBHRU5FUkFMSVpFRC1CQU5EV0lEVEgNCiBp cyBzdXBwbGllZCBpbnN0ZWFkLiZuYnNwOyBUaGlzIHdvdWxkIG1lYW4gY2hhbmdpbmcgZXhpc3Rp bmcgcHJvY2VkdXJlcywgdGhlIGluaXRpYWwgbWVjaGFuaXNtIHdhcyBub3QgdG8gY2hhbmdlIFJG QzU0NDAgb2JqZWN0IHByZXNlbmNlIHJ1bGUuICZuYnNwO0N5cmlsIGlzIGZpbmUgd2l0aCB0aGUg cHJvcG9zYWwgZnJvbSBKb25hdGhhbiwgYnV0IHdlIHdvdWxkIGxpa2UgdG8gZ2V0IFdHIGFuZCBp bXBsZW1lbnRlcnMgZmVlZGJhY2suDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMi Pjxicj4NCkpvbiwgQ3lyaWwsIGFsbDxicj4NCjxicj4NCkluIHRoaXMgY2FzZSwgSSB3b3VsZCBn byBiYWNrIHRvIG9uZSBvZiBteSBpbml0aWFsIHN1Z2dlc3Rpb25zOiBkbyBub3QgYWRkIEdFTkVS QUxJWkVEX0JBTkRXSURUSCBhbmQgYWRkIGEgVExWIHRvIHRoZSBCVyBvYmplY3RzLCB3aGljaCBj YW4gYmUgaWdub3JlZC48YnI+DQo8YnI+DQpJbiBvdGhlciB3b3JkcywgdGhlIGNyZWF0aW9uIG9m IEdFTl9CVyB3YXMganVzdGlmaWVkIGR1ZSB0bzombmJzcDsgYSkgZG8gbm90IHRvdWNoIHJmYzU0 NDAgYikgaWYgUkZDNTQ0MCBkb2VzIG5vdCBzdGF0ZSB0aGF0IEJXIG9iamVjdCBjYW4gaGF2ZSBU TFZzLCB0aGVuIHRoZXkgY2FuJ3QgYW5kIGl0IGlzIGZpeGVkIGxlbmd0aC48YnI+DQo8YnI+DQpN eSBwZXJzb25hbCBwcmVmZXJlbmNlIGFsd2F5cyB3YXMgdG8gYWRkIGEgVExWIG9yIGEgbmV3IG9i amVjdCB0eXBlIGZvciBCVy4mbmJzcDsgSWYgd2UgYWxsb3cgb3Vyc2VsdmVzIGEgbGliZXJhbCBp bnRlcnByZXRhdGlvbiBvZiByZmM1NDQwIHRoZW4gbGV0J3MgYXNzdW1lIHdlIGNhbiBhZGQgYSB0 bHYuLi48YnI+DQo8YnI+DQpKdXN0IG15IG9waW5pb24sIG9mIGNvdXJzZSwgYW5kIG5vdCBhIHBh cnRpY3VsYXJseSBzdHJvbmcgb25lPGJyPg0KPGJyPg0KUmFtb248YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlJhbW9uIENhc2VsbGFz LCBQaC5ELiAtLSBTZW5pb3IgUmVzZWFyY2ggQXNzb2NpYXRlIC0tIE5ldHdvcmtzIERpdmlzaW9u PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PcHRpY2Fs IE5ldHdvcmtzIGFuZCBTeXN0ZW1zIERlcGFydG1lbnQgLS0gPGEgaHJlZj0iaHR0cDovL3dpa2lv bmEuY3R0Yy5lcyI+aHR0cDovL3dpa2lvbmEuY3R0Yy5lczwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkNUVEMgLSBDZW50cmUgVGVjbm9sw7JnaWMg ZGUgVGVsZWNvbXVuaWNhY2lvbnMgZGUgQ2F0YWx1bnlhPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5QYXJjIE1lZGl0ZXJyYW5pIGRlIGxhIFRlY25vbG9n aWEgKFBNVCkgLSBFZGlmaWNpIEI0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5Bdi4gQ2FybCBGcmllZHJpY2ggR2F1c3MsIDcgLSAwODg2MCBDYXN0ZWxs ZGVmZWxzIChCYXJjZWxvbmEpIC0gU3BhaW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPlRlbC46ICYjNDM7MzQgOTMgNjQ1IDI5IDAwIGV4dCAyMTY4LS0g RmF4LiAmIzQzOzM0IDkzIDY0NSAyOSAwMSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F82A4B6D50F9464B8EBA55651F541CF84EE429ADSZXEML552MBXchi_-- From cyril.margaria@coriant.com Tue Jul 30 09:34:41 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416C021F9AAE for ; Tue, 30 Jul 2013 09:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM54itljcbk8 for ; Tue, 30 Jul 2013 09:34:33 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 407CB11E8225 for ; Tue, 30 Jul 2013 09:33:16 -0700 (PDT) Received: from mail204-db8-R.bigfish.com (10.174.8.226) by DB8EHSOBE008.bigfish.com (10.174.4.71) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 16:33:13 +0000 Received: from mail204-db8 (localhost [127.0.0.1]) by mail204-db8-R.bigfish.com (Postfix) with ESMTP id 8F1F7820255; Tue, 30 Jul 2013 16:33:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT005.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(z5109h5105hzbb2dI98dI9371Ic89bhdbeehc857h14ffIde40hdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de096h1954cbh8275bh8275dh1de097hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh34h1155h) Received-SPF: pass (mail204-db8: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT005.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail204-db8 (localhost.localdomain [127.0.0.1]) by mail204-db8 (MessageSwitch) id 1375201990394150_16331; Tue, 30 Jul 2013 16:33:10 +0000 (UTC) Received: from DB8EHSMHS028.bigfish.com (unknown [10.174.8.239]) by mail204-db8.bigfish.com (Postfix) with ESMTP id 4E760680046; Tue, 30 Jul 2013 16:33:10 +0000 (UTC) Received: from DB3PRD0411HT005.eurprd04.prod.outlook.com (157.56.253.53) by DB8EHSMHS028.bigfish.com (10.174.4.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 16:33:09 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.251]) by DB3PRD0411HT005.eurprd04.prod.outlook.com ([10.255.73.40]) with mapi id 14.16.0341.000; Tue, 30 Jul 2013 16:33:09 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: Fatai Zhang , Ramon Casellas , Jonathan Hardwick , "pce@ietf.org" Thread-Topic: =?utf-8?B?W1BjZV0g562U5aSNOiAgQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1wY2UtZ21w?= =?utf-8?Q?ls-pcep-extensions-08?= Thread-Index: AQHOjSI3vpmzPE61rU+aKYfXmOaFk5l9YIIA Date: Tue, 30 Jul 2013 16:33:08 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D0D04AF@DB3PRD0411MB427.eurprd04.prod.outlook.com> References: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5@ENFICSMBX1.datcon.co.uk> <523C37072C291347B9730C9291CCA07D0CC675@DB3PRD0411MB427.eurprd04.prod.outlook.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863A@ENFICSMBX1.datcon.co.uk> <51F78824.4060907@cttc.es> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [130.129.21.250] Content-Type: multipart/mixed; boundary="_004_523C37072C291347B9730C9291CCA07D0D04AFDB3PRD0411MB427eu_" MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Pce] =?utf-8?b?562U5aSNOiAgQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1wY2Ut?= =?utf-8?q?gmpls-pcep-extensions-08?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 16:34:44 -0000 --_004_523C37072C291347B9730C9291CCA07D0D04AFDB3PRD0411MB427eu_ Content-Type: multipart/alternative; boundary="_000_523C37072C291347B9730C9291CCA07D0D04AFDB3PRD0411MB427eu_" --_000_523C37072C291347B9730C9291CCA07D0D04AFDB3PRD0411MB427eu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUENFIFdHLA0KDQpUaGUgUHJvYmxlbSB3ZSBoYWQgd2l0aCB0aGUgQkFORFdJRFRIIChhbmQg TE9BRC1CQUxBTkNJTkcgQlRXKSBvYmplY3QgaXMgdGhhdCBSRkM1NDQwIHNlY3Rpb24gNy43IGRl ZmluZXMNCuKAnFRoZSBCQU5EV0lEVEggb2JqZWN0IGJvZHkgaGFzIGEgZml4ZWQgbGVuZ3RoIG9m IDQgYnl0ZXMu4oCdDQoNClJGQzU0NDAgZGVmaW5lcyB0d28gT1QgOiAxIGFuZCAyLiBUaGUgdGV4 dCBjYW4gYmUgaW50ZXJwcmV0ZWQgYXMgYWxsIE9UIChjdXJyZW50IGFuZCBmdXR1cmUpIHNob3Vs ZCBoYXZlIGxlbmd0aCA9IDQsIHRoaXMgaXMgbm90IGZ1dHVyZSBmcmllbmRseS4NCg0KTm93IHNl dmVyYWwgb3B0aW9ucyBjYW4gYmUgY29uc2lkZXJlZCA6DQoNCjEpICAgICAgR01QTFMtcGNlcCBl eHRlbnNpb25zIDogbmV3IG9iamVjdCwga2VlcCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiB1bnRv dWNoZWQsIGF0IHRoZSBleHBlbnNlIG9mIHRoZSBnbXBscyBvbmVzIChtb3JlIGNvbXBsZXggcnVs ZXMpDQoNCjIpICAgICAgQWxsb3cgVExWIGluIHRoZSBCQU5EV0lEVEgNCg0KMykgICAgICBUcmVh dCB0aGlzIGFzIGFuIGVycmF0YSB0byBSRkM1NDQwIOKAnOKAnFRoZSBCQU5EV0lEVEggb2YgT1Qg MSBhbmQgT1QgMiAgb2JqZWN0IGJvZHkgaGF2ZSBhIGZpeGVkIGxlbmd0aCBvZiA0IGJ5dGVzLuKA nSwgYW5kIGRlZmluZSBuZXcgT1QgZm9yIEdNUExTDQoNClRoZSBDb25zIG9mIDEgaXMgZGlzY3Vz c2VkIGJlbG93Lg0KVGhlIGNvbnMgb2YgdGhlIFRMViB3b3VsZCBiZSB0byBjaGFuZ2UgZXhpc3Rp bmcgb2JqZWN0IGRlZmluaXRpb24gYW5kIG1ha2UgdGhlIHByb3RvY29sIGRlZmluaXRpb24gcmF0 aGVyIGF3a3dhcmQgOiBkaWZmZXJlbnQgT2JqZWN0IGZvcm1hdCBkZXBlbmRpbmcgb24gT1BFTiAo Zm9yIGV4YW1wbGUpIG5lZ290aWF0aW9uIGFuZCB3b3VsZCBub3QgaGVscCBmb3IgbmV3IENUeXBl cw0KDQpXaXRoIDMpIHRoZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiBmb3IgZXhpc3RpbmcgQ1R5 cGUgd2lsbCBzZWUgbm8gY2hhbmdlLCBpdCBtYXkgYmUgYSBwcm9ibGVtIGZvciBuZXcgQ1R5cGVz IChhbnlob3cgbm90IHN1cHBvcnRlZCksIGJ1dCBhbiBpbXBsZW1lbnRhdGlvbiBtYXkgcmV0dXJu IGFuIFVua25vdyBvYmplY3QsIHVua25vd24gb2JqZWN0IHR5cGUgT1IgdHJlYXRlZCBhcyBpbnZh bGlkIG9iamVjdC4gVGhpcyBjYW4gYmUgc29sdmVkIGJ5IG5lZ290aWF0aW5nIHRoZSB1c2Ugb2Yg T1Q+MiBmb3IgQkFORFdJRFRIIChhbmQgTE9BRC1CQUxBTkNJTkcpDQoNCkZvciB0aGUgc2FrZSBv ZiBkaXNjdXNzaW9uIEkgYXR0YWNoIGEgc2xpZGVzZXQgaWYgYnkgYW55IGNoYW5jZSB0aGVyZSBp cyBzb21lIHRpbWUgbGVmdCBkdXJpbmcgdGhlIHNlc3Npb24sDQoNCg0KDQoNCg0KDQoNCg0KTWl0 IGZyZXVuZGxpY2hlbiBHcsO8w59lbiAvIEJlc3QgUmVnYXJkcw0KQ3lyaWwgTWFyZ2FyaWENCkZy b206IHBjZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBGYXRhaSBaaGFuZw0KU2VudDogVHVlc2RheSwgSnVseSAzMCwgMjAxMyAyOjQx IFBNDQpUbzogUmFtb24gQ2FzZWxsYXM7IEpvbmF0aGFuIEhhcmR3aWNrOyBwY2VAaWV0Zi5vcmcN ClN1YmplY3Q6IFtQY2VdIOetlOWkjTogQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1wY2UtZ21wbHMt cGNlcC1leHRlbnNpb25zLTA4DQoNCkhpIGFsbCwNCg0KSSB0aGluayBhIG5ldyBvYmplY3QgdHlw ZSBjb3VsZCBiZSBiZXR0ZXIgYW5kIHNpbXBsZS4NCg0KVGhhbmtzDQoNCkZhdGFpDQoNCg0K5Y+R 5Lu25Lq6OiBwY2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBSYW1vbiBDYXNlbGxhcw0K5Y+R 6YCB5pe26Ze0OiAyMDEz5bm0N+aciDMw5pelIDE3OjMyDQrmlLbku7bkuro6IEpvbmF0aGFuIEhh cmR3aWNrOyBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz4NCuS4u+mimDogUmU6IFtQ Y2VdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGNlLWdtcGxzLXBjZXAtZXh0ZW5zaW9ucy0wOA0K DQpPbiAwNy8zMC8yMDEzIDExOjA4IEFNLCBKb25hdGhhbiBIYXJkd2ljayB3cm90ZToNCkN5cmls IGFuZCBJIGhhZCBhbiBvZmZsaW5lIGNvbnZlcnNhdGlvbiBhYm91dCB0aGVzZSBjb21tZW50cy4g IFRoaXMgZW1haWwgaXMgdG8gZG9jdW1lbnQgdGhlIGRpc2N1c3Npb24gZm9yIHRoZSBiZW5lZml0 IG9mIHRoZSBtYWlsaW5nIGxpc3QuICBTZWUgW0pFSC1NQ10gY29tbWVudHMgYmVsb3cuDQoNCldl IGhhdmUgb25lIHF1ZXN0aW9uIGZvciB0aGUgV0csIGFzIGZvbGxvd3MuICBJZiBhbnlvbmUgaGFz IGFuIG9waW5pb24gb24gdGhpcywgcGxlYXNlIGNvdWxkIHlvdSBwcm92aWRlIGl0IHRvIHRoZSBt YWlsaW5nIGxpc3Q/DQoNCi0tLQ0KW0pFSC1NQ10gSm9uIGJlbGlldmVzIHRoYXQgdGhpcyBkcmFm dCBzaG91bGQgcmVsYXggdGhlIHJlc3RyaWN0aW9uIG9mIFJGQyA1NDQwIHRoYXQgdGhlIEJBTkRX SURUSCBvYmplY3QgaXMgbWFuZGF0b3J5LCBpbiB0aGUgY2FzZSB3aGVyZSBhIEdFTkVSQUxJWkVE LUJBTkRXSURUSCBpcyBzdXBwbGllZCBpbnN0ZWFkLiAgVGhpcyB3b3VsZCBtZWFuIGNoYW5naW5n IGV4aXN0aW5nIHByb2NlZHVyZXMsIHRoZSBpbml0aWFsIG1lY2hhbmlzbSB3YXMgbm90IHRvIGNo YW5nZSBSRkM1NDQwIG9iamVjdCBwcmVzZW5jZSBydWxlLiAgQ3lyaWwgaXMgZmluZSB3aXRoIHRo ZSBwcm9wb3NhbCBmcm9tIEpvbmF0aGFuLCBidXQgd2Ugd291bGQgbGlrZSB0byBnZXQgV0cgYW5k IGltcGxlbWVudGVycyBmZWVkYmFjay4NCg0KDQpKb24sIEN5cmlsLCBhbGwNCg0KSW4gdGhpcyBj YXNlLCBJIHdvdWxkIGdvIGJhY2sgdG8gb25lIG9mIG15IGluaXRpYWwgc3VnZ2VzdGlvbnM6IGRv IG5vdCBhZGQgR0VORVJBTElaRURfQkFORFdJRFRIIGFuZCBhZGQgYSBUTFYgdG8gdGhlIEJXIG9i amVjdHMsIHdoaWNoIGNhbiBiZSBpZ25vcmVkLg0KDQpJbiBvdGhlciB3b3JkcywgdGhlIGNyZWF0 aW9uIG9mIEdFTl9CVyB3YXMganVzdGlmaWVkIGR1ZSB0bzogIGEpIGRvIG5vdCB0b3VjaCByZmM1 NDQwIGIpIGlmIFJGQzU0NDAgZG9lcyBub3Qgc3RhdGUgdGhhdCBCVyBvYmplY3QgY2FuIGhhdmUg VExWcywgdGhlbiB0aGV5IGNhbid0IGFuZCBpdCBpcyBmaXhlZCBsZW5ndGguDQoNCk15IHBlcnNv bmFsIHByZWZlcmVuY2UgYWx3YXlzIHdhcyB0byBhZGQgYSBUTFYgb3IgYSBuZXcgb2JqZWN0IHR5 cGUgZm9yIEJXLiAgSWYgd2UgYWxsb3cgb3Vyc2VsdmVzIGEgbGliZXJhbCBpbnRlcnByZXRhdGlv biBvZiByZmM1NDQwIHRoZW4gbGV0J3MgYXNzdW1lIHdlIGNhbiBhZGQgYSB0bHYuLi4NCg0KSnVz dCBteSBvcGluaW9uLCBvZiBjb3Vyc2UsIGFuZCBub3QgYSBwYXJ0aWN1bGFybHkgc3Ryb25nIG9u ZQ0KDQpSYW1vbg0KDQoNCi0tDQoNClJhbW9uIENhc2VsbGFzLCBQaC5ELiAtLSBTZW5pb3IgUmVz ZWFyY2ggQXNzb2NpYXRlIC0tIE5ldHdvcmtzIERpdmlzaW9uDQoNCk9wdGljYWwgTmV0d29ya3Mg YW5kIFN5c3RlbXMgRGVwYXJ0bWVudCAtLSBodHRwOi8vd2lraW9uYS5jdHRjLmVzDQoNCkNUVEMg LSBDZW50cmUgVGVjbm9sw7JnaWMgZGUgVGVsZWNvbXVuaWNhY2lvbnMgZGUgQ2F0YWx1bnlhDQoN ClBhcmMgTWVkaXRlcnJhbmkgZGUgbGEgVGVjbm9sb2dpYSAoUE1UKSAtIEVkaWZpY2kgQjQNCg0K QXYuIENhcmwgRnJpZWRyaWNoIEdhdXNzLCA3IC0gMDg4NjAgQ2FzdGVsbGRlZmVscyAoQmFyY2Vs b25hKSAtIFNwYWluDQoNClRlbC46ICszNCA5MyA2NDUgMjkgMDAgZXh0IDIxNjgtLSBGYXguICsz NCA5MyA2NDUgMjkgMDENCg== --_000_523C37072C291347B9730C9291CCA07D0D04AFDB3PRD0411MB427eu_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDMgOSAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0K CXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QE1pbmdMaVUiOw0KCXBhbm9zZS0xOjIgMiAzIDkgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDgg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIFVJIEdvdGhpYyI7DQoJcGFub3Nl LTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBN UyBVSSBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiAwIDcgMiA1IDggMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBj bTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLkhUTUwsIGxp LkhUTUwsIGRpdi5IVE1MDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuYSwgbGkuYSwgZGl2LmENCgl7 bXNvLXN0eWxlLW5hbWU65om55rOo5qGG5paH5pysOw0KCW1zby1zdHlsZS1saW5rOiLmibnms6jm oYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH 5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnm s6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBv cnRhbnQ7DQoJY29sb3I6IzFGNDk3RDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtc2hh ZG93Om5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0K CWNvbG9yOiM5OTMzNjY7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LXNoYWRvdzpub25l Ow0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjEzOTk1NDgyMTE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi01MjgxNjQwMjYgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij5IaSBQQ0Ug V0csIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojOTkzMzY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+VGhlIFByb2JsZW0gd2Ug aGFkIHdpdGggdGhlIEJBTkRXSURUSCAoYW5kIExPQUQtQkFMQU5DSU5HIEJUVykgb2JqZWN0IGlz IHRoYXQgUkZDNTQ0MCBzZWN0aW9uIDcuNyBkZWZpbmVzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+4oCcVGhl IEJBTkRXSURUSCBvYmplY3QgYm9keSBoYXMgYSBmaXhlZCBsZW5ndGggb2YgNCBieXRlcy7igJ08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6Izk5MzM2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPlJGQzU0NDAgZGVmaW5lcyB0d28g T1QgOiAxIGFuZCAyLiBUaGUgdGV4dCBjYW4gYmUgaW50ZXJwcmV0ZWQgYXMgYWxsIE9UIChjdXJy ZW50IGFuZCBmdXR1cmUpIHNob3VsZCBoYXZlIGxlbmd0aCA9IDQsIHRoaXMgaXMgbm90IGZ1dHVy ZSBmcmllbmRseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPk5vdyBzZXZl cmFsIG9wdGlvbnMgY2FuIGJlIGNvbnNpZGVyZWQgOiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iY29sb3I6Izk5MzM2NiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MSk8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij5HTVBMUy1wY2VwIGV4dGVuc2lvbnMgOiBuZXcgb2Jq ZWN0LCBrZWVwIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uIHVudG91Y2hlZCwgYXQgdGhlIGV4cGVu c2Ugb2YgdGhlIGdtcGxzIG9uZXMgKG1vcmUgY29tcGxleCBydWxlcykNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIp PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+QWxsb3cgVExWIGluIHRoZSBCQU5EV0lEVEgN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjMpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+VHJlYXQgdGhpcyBh cyBhbiBlcnJhdGEgdG8gUkZDNTQ0MCDigJzigJxUaGUgQkFORFdJRFRIDQo8Yj5vZiBPVCAxIGFu ZCBPVCAyPC9iPiAmbmJzcDtvYmplY3QgYm9keSBoYXZlIGEgZml4ZWQgbGVuZ3RoIG9mIDQgYnl0 ZXMu4oCdLCBhbmQgZGVmaW5lIG5ldyBPVCBmb3IgR01QTFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiM5OTMzNjYiPlRoZSBDb25zIG9mIDEgaXMgZGlzY3Vzc2VkIGJlbG93LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj OTkzMzY2Ij5UaGUgY29ucyBvZiB0aGUgVExWIHdvdWxkIGJlIHRvIGNoYW5nZSBleGlzdGluZyBv YmplY3QgZGVmaW5pdGlvbiBhbmQgbWFrZSB0aGUgcHJvdG9jb2wgZGVmaW5pdGlvbiByYXRoZXIg YXdrd2FyZCA6IGRpZmZlcmVudCBPYmplY3QgZm9ybWF0IGRlcGVuZGluZyBvbiBPUEVOIChmb3Ig ZXhhbXBsZSkgbmVnb3RpYXRpb24gYW5kIHdvdWxkIG5vdCBoZWxwIGZvciBuZXcNCiBDVHlwZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6Izk5MzM2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPldpdGggMykgdGhlIGV4aXN0aW5n IGltcGxlbWVudGF0aW9uIGZvciBleGlzdGluZyBDVHlwZSB3aWxsIHNlZSBubyBjaGFuZ2UsIGl0 IG1heSBiZSBhIHByb2JsZW0gZm9yIG5ldyBDVHlwZXMgKGFueWhvdyBub3Qgc3VwcG9ydGVkKSwg YnV0IGFuIGltcGxlbWVudGF0aW9uIG1heSByZXR1cm4gYW4gVW5rbm93IG9iamVjdCwgdW5rbm93 biBvYmplY3QgdHlwZSBPUg0KIHRyZWF0ZWQgYXMgaW52YWxpZCBvYmplY3QuIFRoaXMgY2FuIGJl IHNvbHZlZCBieSBuZWdvdGlhdGluZyB0aGUgdXNlIG9mIE9UJmd0OzIgZm9yIEJBTkRXSURUSCAo YW5kIExPQUQtQkFMQU5DSU5HKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+ Rm9yIHRoZSBzYWtlIG9mIGRpc2N1c3Npb24gSSBhdHRhY2ggYSBzbGlkZXNldCBpZiBieSBhbnkg Y2hhbmNlIHRoZXJlIGlzIHNvbWUgdGltZSBsZWZ0IGR1cmluZyB0aGUgc2Vzc2lvbiw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 Izk5MzM2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6Izk5MzM2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkz MzY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRF IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk5MzM2NiI+TWl0IGZyZXVuZGxpY2hlbiBH csO8w59lbiAvIEJlc3QgUmVnYXJkczwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOiM5OTMzNjYiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkRF IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk5MzM2NiI+Q3lyaWwgTWFyZ2FyaWE8L3Nw YW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojOTkzMzY2 Ij4NCjwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImNvbG9yOiM5OTMzNjYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBwY2UtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5GYXRhaSBa aGFuZzxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDMwLCAyMDEzIDI6NDEgUE08YnI+ DQo8Yj5Ubzo8L2I+IFJhbW9uIENhc2VsbGFzOyBKb25hdGhhbiBIYXJkd2ljazsgcGNlQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtQY2VdIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBVSSBHb3RoaWMmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij7nrZTlpI08L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+OiBDb21tZW50cyBvbiBkcmFmdC1pZXRm LXBjZS1nbXBscy1wY2VwLWV4dGVuc2lvbnMtMDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjoj MUY0OTdEIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBhIG5ldyBvYmplY3QgdHlwZSBj b3VsZCBiZSBiZXR0ZXIgYW5kIHNpbXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0 OTdEIj5GYXRhaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6TWlu Z0xpVTtjb2xvcjp3aW5kb3d0ZXh0Ij7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij46 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovk vZM7Y29sb3I6d2luZG93dGV4dCI+DQo8YSBocmVmPSJtYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5v cmciPnBjZS1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnBjZS1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxiPjxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+5Luj6KGoPC9zcGFuPjwvYj48Yj48 c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L 5L2TO2NvbG9yOndpbmRvd3RleHQiPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+UmFtb24gQ2FzZWxs YXM8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5Ok1pbmdMaVU7Y29sb3I6d2luZG93dGV4dCI+5Y+R6YCB5pe26Ze0PC9z cGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovk vZM7Y29sb3I6d2luZG93dGV4dCI+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPiAyMDEzPC9zcGFuPjxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+5bm0PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij43 PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+5pyIPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5k b3d0ZXh0Ij4zMDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPuaX pTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7 Y29sb3I6d2luZG93dGV4dCI+DQogMTc6MzI8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgt Q04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij7mlLbku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij46 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovk vZM7Y29sb3I6d2luZG93dGV4dCI+IEpvbmF0aGFuDQogSGFyZHdpY2s7IDxhIGhyZWY9Im1haWx0 bzpwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFu Zz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdv dGhpYyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij7kuLs8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9 IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVO2NvbG9y OndpbmRvd3RleHQiPumimDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPjo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0 ZXh0Ij4NCiBSZTogW1BjZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1wY2UtZ21wbHMtcGNlcC1l eHRlbnNpb25zLTA4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIDA3LzMwLzIwMTMgMTE6MDggQU0sIEpvbmF0aGFuIEhhcmR3aWNrIHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojOTQzNjM0Ij5DeXJpbCBhbmQgSSBoYWQgYW4gb2ZmbGluZSBjb252ZXJzYXRp b24gYWJvdXQgdGhlc2UgY29tbWVudHMuJm5ic3A7IFRoaXMgZW1haWwgaXMgdG8gZG9jdW1lbnQg dGhlIGRpc2N1c3Npb24gZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBtYWlsaW5nIGxpc3QuJm5ic3A7 IFNlZQ0KPGI+W0pFSC1NQ108L2I+IGNvbW1lbnRzIGJlbG93Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTQzNjM0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6Izk0MzYzNCI+V2UgaGF2ZSBvbmUgcXVlc3Rpb24gZm9yIHRoZSBXRywgYXMgZm9s bG93cy4mbmJzcDsgSWYgYW55b25lIGhhcyBhbiBvcGluaW9uIG9uIHRoaXMsIHBsZWFzZSBjb3Vs ZCB5b3UgcHJvdmlkZSBpdCB0byB0aGUgbWFpbGluZyBsaXN0Pzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTQzNjM0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6Izk0MzYzNCI+LS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NDM2MzQiPltKRUgtTUNdPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iY29sb3I6Izk0MzYzNCI+IEpvbiBiZWxpZXZlcyB0aGF0IHRoaXMgZHJh ZnQgc2hvdWxkIHJlbGF4IHRoZSByZXN0cmljdGlvbiBvZiBSRkMgNTQ0MCB0aGF0IHRoZSBCQU5E V0lEVEggb2JqZWN0IGlzIG1hbmRhdG9yeSwgaW4gdGhlIGNhc2Ugd2hlcmUgYSBHRU5FUkFMSVpF RC1CQU5EV0lEVEggaXMgc3VwcGxpZWQNCiBpbnN0ZWFkLiZuYnNwOyBUaGlzIHdvdWxkIG1lYW4g Y2hhbmdpbmcgZXhpc3RpbmcgcHJvY2VkdXJlcywgdGhlIGluaXRpYWwgbWVjaGFuaXNtIHdhcyBu b3QgdG8gY2hhbmdlIFJGQzU0NDAgb2JqZWN0IHByZXNlbmNlIHJ1bGUuICZuYnNwO0N5cmlsIGlz IGZpbmUgd2l0aCB0aGUgcHJvcG9zYWwgZnJvbSBKb25hdGhhbiwgYnV0IHdlIHdvdWxkIGxpa2Ug dG8gZ2V0IFdHIGFuZCBpbXBsZW1lbnRlcnMgZmVlZGJhY2suDQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTrlrovkvZMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj48YnI+DQpK b24sIEN5cmlsLCBhbGw8YnI+DQo8YnI+DQpJbiB0aGlzIGNhc2UsIEkgd291bGQgZ28gYmFjayB0 byBvbmUgb2YgbXkgaW5pdGlhbCBzdWdnZXN0aW9uczogZG8gbm90IGFkZCBHRU5FUkFMSVpFRF9C QU5EV0lEVEggYW5kIGFkZCBhIFRMViB0byB0aGUgQlcgb2JqZWN0cywgd2hpY2ggY2FuIGJlIGln bm9yZWQuPGJyPg0KPGJyPg0KSW4gb3RoZXIgd29yZHMsIHRoZSBjcmVhdGlvbiBvZiBHRU5fQlcg d2FzIGp1c3RpZmllZCBkdWUgdG86Jm5ic3A7IGEpIGRvIG5vdCB0b3VjaCByZmM1NDQwIGIpIGlm IFJGQzU0NDAgZG9lcyBub3Qgc3RhdGUgdGhhdCBCVyBvYmplY3QgY2FuIGhhdmUgVExWcywgdGhl biB0aGV5IGNhbid0IGFuZCBpdCBpcyBmaXhlZCBsZW5ndGguPGJyPg0KPGJyPg0KTXkgcGVyc29u YWwgcHJlZmVyZW5jZSBhbHdheXMgd2FzIHRvIGFkZCBhIFRMViBvciBhIG5ldyBvYmplY3QgdHlw ZSBmb3IgQlcuJm5ic3A7IElmIHdlIGFsbG93IG91cnNlbHZlcyBhIGxpYmVyYWwgaW50ZXJwcmV0 YXRpb24gb2YgcmZjNTQ0MCB0aGVuIGxldCdzIGFzc3VtZSB3ZSBjYW4gYWRkIGEgdGx2Li4uPGJy Pg0KPGJyPg0KSnVzdCBteSBvcGluaW9uLCBvZiBjb3Vyc2UsIGFuZCBub3QgYSBwYXJ0aWN1bGFy bHkgc3Ryb25nIG9uZTxicj4NCjxicj4NClJhbW9uPGJyPg0KPGJyPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5SYW1vbiBDYXNlbGxhcywgUGguRC4gLS0gU2VuaW9yIFJlc2VhcmNoIEFzc29j aWF0ZSAtLSBOZXR3b3JrcyBEaXZpc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+T3B0aWNhbCBOZXR3b3JrcyBhbmQgU3lzdGVtcyBEZXBhcnRtZW50IC0tIDxhIGhy ZWY9Imh0dHA6Ly93aWtpb25hLmN0dGMuZXMiPmh0dHA6Ly93aWtpb25hLmN0dGMuZXM8L2E+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DVFRDIC0gQ2VudHJlIFRlY25v bMOyZ2ljIGRlIFRlbGVjb211bmljYWNpb25zIGRlIENhdGFsdW55YTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UGFyYyBNZWRpdGVycmFuaSBkZSBsYSBUZWNub2xvZ2lh IChQTVQpIC0gRWRpZmljaSBCNDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+QXYuIENhcmwgRnJpZWRyaWNoIEdhdXNzLCA3IC0gMDg4NjAgQ2FzdGVsbGRlZmVscyAoQmFy Y2Vsb25hKSAtIFNwYWluPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5U ZWwuOiAmIzQzOzM0IDkzIDY0NSAyOSAwMCBleHQgMjE2OC0tIEZheC4gJiM0MzszNCA5MyA2NDUg MjkgMDEgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_523C37072C291347B9730C9291CCA07D0D04AFDB3PRD0411MB427eu_-- --_004_523C37072C291347B9730C9291CCA07D0D04AFDB3PRD0411MB427eu_ Content-Type: application/octet-stream; name="pce-pcep-bandwidth.pptx" Content-Description: pce-pcep-bandwidth.pptx Content-Disposition: attachment; filename="pce-pcep-bandwidth.pptx"; size=72239; creation-date="Tue, 30 Jul 2013 15:32:10 GMT"; modification-date="Tue, 30 Jul 2013 16:29:52 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCmVNfCegIAABQTAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM WNuOmzAQfa/Uf0B+rYKTbbu7rUL2oZenXlba7Qe4MCFuwbbsSbr5+xoTghOxgRRQ+gI44Jnj45nx mczvnvIs2IA2XIqIzMIpCUDEMuEijciPx8+TWxIYZCJhmRQQkS0Ycrd4+WL+uFVgAjtbmIisENV7 Sk28gpyZUCoQ9s1S6pyhHeqUKhb/ZinQq+n0msZSIAicYGGDLObfLQDNEwjumcZvLLd+qFJITWZ/ NOXtbWgtkuBDObXwHhGmVMZjhhY73YjkyO9ELpc8hkTG69x6C5UGY+/u8zwLnfFXhVHaDcH15RB8 YVu5xh0T5eBmFDSl7U6sNGC6vSAmIRHMQxkw9fNsaES16TaS6i8NrZ+v/jdAry8HyGXgV2bQlp8y ycvB4JvmOWrbNffpDs3g1Djj5yB4M/TmdEJQFMp7LZUZ2vvecCcOGgrMOHz0K3rjHEz9MI1zVHXD hFYDAHXX/sXOmekULbucHad2nIOg/6L/Rah4rPenoDvrDTk6zvq7xZ4rbw2Yxqnkh5g+wpKtMww+ PVltW8rpXwrSI8nK80IFuxdWdjbM0ZCZozktMncnrUM702lbs+LKVBHb4OG0jm4RxH5sjnE8VAI9 zBkX1SKe6w+crKoEhDfonwH+Mm2v4Nluw4QsNdReBsdQGG5z/lz8Dw7Gc3QKk+29nJCgNoR7RwsU iZVAMlFWm4BGDq18IPuZwQNuMxhcy3imTzGwb2MbqtLs4tsSrw3KvPfOlGbO2BcvfA6a2tm0N5aj zPU8tW3ThsOfUWTv3nAbAg/sAS3vLshK3br6bezgQrx2c4qkfT2JpYbzSalOymJ2Q7RS95/W4i8A AAD//wMAUEsDBBQABgAIAAAAIQBHvxrQEwEAAHUDAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArNNL S8QwEADgu+B/CLlv010fiGy6FxH2JlJ/wJhM22jzIJnK7r83FHwUahXcYzKPfMmQ7e5ge/aGMRnv JF8XJWfolNfGtZI/1ferG84SgdPQe4eSHzHxXXV+tn3EHigXpc6ExHIXlyTviMKtEEl1aCEVPqDL kcZHC5SXsRUB1Cu0KDZleS3i9x68mvRkey153OsLzupjyCf/p7ewSKCBQCgfcRVilkUy+S6shtgi Sa69esjbacwospqLedDmtCDqBvvswPQzlM9Y8RKw/Qm0/jvIN41ReOfVYNHRzBDENOPLFAKJEDHl snHsSy90dUqQGhJ5+8vIxpwl0uUpSXggdBr1MgpC+BCJyWep3gEAAP//AwBQSwMEFAAGAAgAAAAh ANq29V0ZAQAAngIAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc6ySzUrEMBCA 74LvEHJv066gItvuZRUW9KLrA4Rk2oZNk5CZ1e3bmwrVFla87G1+yDffJFlvTr1lHxDReFfxMi84 A6e8Nq6t+Pv+KbvnDEk6La13UPEBkG/q66v1K1hJ6RB2JiBLFIcV74jCgxCoOugl5j6AS53Gx15S SmMrglQH2YJYFcWtiHMGrxdMttMVjzt9w9l+CGny/2zfNEbB1qtjD47OjBBdIkVr3CFBZWyBfrDk vcXcADXfmp/JVIHQUTaUjdUspVnbB4tjFDI4Ebjx0lBMrBevk+ZjakQnLRfn91ldch/nCfDNGg2T RMXzXPyWcRaXeXqLv7TKS2rhaPQsB3+khdesjmKW3E1mYvGr6i8AAAD//wMAUEsDBBQABgAIAAAA IQBbCFNM2QAAAM4BAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHOskcFqwzAM hu+DvYPRvXaaQzdGnV5KobDT1j2AsZXENLGM5Y7l7ecdBg4UdtlNv4Q+faD94WuexCcm9hQ0bGUD AoMl58Og4eNy2jyD4GyCMxMF1LAgw6F7fNi/4WRyWeLRRxaFEljDmHN8UYrtiLNhSRFDmfSUZpNL TIOKxl7NgKptmp1KNQO6FVOcnYZ0di2IyxLL5b/Z1Pfe4pHsbcaQ75xQgTLy++QdFqpJA2YNUlZt rupWFndQ97W2/6nFP0avZqFbXnlVfVZVePo1U6svdN8AAAD//wMAUEsDBBQABgAIAAAAIQAzDh4E wQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHOEj0GrwjAQhO+C/yHs 3aS+g4o07UUE4Z1Ef8CSbNtgm4RsfLz+e3OsIHicHeabnbr9n0bxR4ld8Bq2sgJB3gTrfK/hfjtv DiA4o7c4Bk8aZmJom/WqvtKIuYR4cJFFoXjWMOQcj0qxGWhCliGSL04X0oS5yNSriOaBPamfqtqp tGRA88YUF6shXewWxG2Opfk7O3SdM3QK5jmRzx8qFI/O0i/O4ZkLFlNPWYOUyzsvxV6W90E1tXqb 27wAAAD//wMAUEsDBBQABgAIAAAAIQAzDh4EwQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTQueG1sLnJlbHOEj0GrwjAQhO+C/yHs3aS+g4o07UUE4Z1Ef8CSbNtgm4RsfLz+e3OsIHic Heabnbr9n0bxR4ld8Bq2sgJB3gTrfK/hfjtvDiA4o7c4Bk8aZmJom/WqvtKIuYR4cJFFoXjWMOQc j0qxGWhCliGSL04X0oS5yNSriOaBPamfqtqptGRA88YUF6shXewWxG2Opfk7O3SdM3QK5jmRzx8q FI/O0i/O4ZkLFlNPWYOUyzsvxV6W90E1tXqb27wAAAD//wMAUEsDBBQABgAIAAAAIQDVwieI2QAA AM4BAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHOskcFqwzAMhu+DvYPRvXba wjZGnV5GodDT1j2AsZXELLGM5Zbm7ecdBg4UdtlNv4Q+faDd/jaN4oqJPQUNa9mAwGDJ+dBr+Dwf Vi8gOJvgzEgBNczIsG8fH3bvOJpclnjwkUWhBNYw5BxflWI74GRYUsRQJh2lyeQSU6+isV+mR7Vp mieVaga0C6Y4Og3p6DYgznMsl/9mU9d5i29kLxOGfOeECpSRP0bvsFBN6jFrkLJqc1VvZXEHdV9r /Z9a/GN0MjNd8sKr6rOqwvOvmVp8of0GAAD//wMAUEsDBBQABgAIAAAAIQC8vfq42QAAAM4BAAAg AAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTYueG1sLnJlbHOskcFqwzAMhu+DvYPRvXZayjZGnV5G odDT1j2AsZXELLGM5Zbm7ecdBg4UdtlNv4Q+faDd/jaN4oqJPQUNa9mAwGDJ+dBr+DwfVi8gOJvg zEgBNczIsG8fH3bvOJpclnjwkUWhBNYw5BxflWI74GRYUsRQJh2lyeQSU6+isV+mR7VpmieVaga0 C6Y4Og3p6DYgznMsl/9mU9d5i29kLxOGfOeECpSRP0bvsFBN6jFrkLJqc1VvZXEHdV9r/Z9a/GN0 MjNd8sKr6rOqwvOvmVp8of0GAAD//wMAUEsDBBQABgAIAAAAIQAGYF5aYQEAAIQHAAAfAAgBcHB0 L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAALyVTU/DMAyG70j8hyp3lnZffGjdLghpByQE4wdkrddVtEkUm8H+PaFMJZsmc4m4pLKb vH70yk5mi8+2SXbgsDY6F9kgFQnowpS1rnLxunq4uhEJktKlaoyGXOwBxWJ+eTF7hkaRP4Tb2mLi VTTmYktk76TEYgutwoGxoP2fjXGtIh+6SlpVvKkK5DBNp9KFGmJ+pJksy1y4Zenrr/bWV/5b22w2 dQH3pnhvQdOZElIbAnxUSOC8rHIVUC6CJIY7soFnF/I8VjaKyUVq3cAL7Rvvbs8VJDmSqCDY1CX8 InQhyu4z5CCuY7rBQEw5iGwYk4J8DwdWdKHsVrYxojIwTrAQWUwjOojToQmSh/742cFiTaNjecHD FHdAB5QJ2yVRzdnV8PHkjA3mtk9xFJN/smLMQWT+to93uVoHeGJFn+IoxjEhmIkZcRC3MSFIVUE/ fEfSL/1oyKO3c/4FAAD//wMAUEsDBBQABgAIAAAAIQD28hFtzgIAAFwOAAAUAAAAcHB0L3ByZXNl bnRhdGlvbi54bWzsl1Fv2jAQx98n7TtEfp3akBCSgAhVu65SpVZCo/sAV8eBqI4T2YZBP/3OidsY 6CZep/IW+393Pv90ZzvTq23FvQ2TqqxFRoLLAfGYoHVeimVGfj3dXaTEUxpEDrwWLCM7psjV7OuX aTNpJFNMaNDo6mEYoSaQkZXWzcT3FV2xCtRl3TCBWlHLCjQO5dLPJfzG8BX3w8Eg9isoBbH+8hT/ uihKym5ruq5w+S6IZLzNQ63KRr1Fa06J5u5iPyUFG7ZYPyum72qhFdIhM9y24vkjKM3kff6g9MGM V+YZCYMoidJhnATEkxMzg7YB8WdT/yN3UWumDkLuzfVBUhtkT+6zcDO6z7tcRrGTRGj82xze5bEj D4/kJHTk6FgeOvLoWHYBxEdy7K6dGLnj425j8erRbUbGQRQNBlicdJeROB2l7UDvGixJRSVjItra 7Fs21u3d0ri9xWgR0LXSt6DBwtOwVD3msc3lwChnBay5fmJbvdA7zmZTmODcfC7t18+59DiYzsnZ xe2PNoprwjc8aNAG+BKbjSM7zTOCuyqwwK7byWdQDMsMJqqhN6ywX3OqvQ20tobSgXpdYBm2cx/Z WRUTNem9MGn6HDuvW6XmZX5Xct4GMD3LvnPZraW3Xc1iZNfKNJrwDPoCKOK/liXgVugKJLaK2Q6m CBMGjs23Slww6ASqDgSqelCYYrs/S8oEws/QQKtAPmQkGiUm9zPCd/6G7V8QGm4W4bBH2PXBGWFf wv9AaLhZhFGPMBgmQXwuwxM72YCzDEcOwzRM8Rg/1+FJdWjAWYZxzzAMUyxDlyEe80/wvHh9u+76 O4bBg7iRL+YZg5cUnuF2iN4rvLPwRTZfC4oHuHnmtLfW/3VfGCyWUOIQSqLh/oXxeQkZLJZQ2hMy ePBt5fTh5yVksFhCY4dQPEr2T/vPS8hgad/piODgMYyPd/dnavYHAAD//wMAUEsDBBQABgAIAAAA IQAAe0dDygUAAFkaAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTUueG1s7FnNcts2EL53pu+A4bV1ZNP6 s8ZSxlbiNDOO47GU8RkiIZE1CLAA9JdT7j322l76AH2DvkymfY9+C1K/lls30/w4zUUCQWCxu9jv w2J5/HiWSTYRxqZatYODR/sBEyrScapG7eBV/2yvGTDruIq51Eq0g7mwwePO118d5y0rY4bZyrZ4 O0icy1uVio0SkXH7SOdC4d1Qm4w7PJpRJTZ8CqmZrIT7+/VKxlMVlPPNfebr4TCNxBMdjTOhXCHE CMkdNLdJmtuFtPw+0nIjLMT42RsqdWBZ1JMx/du8b4Sglpo8M3kvvzT+9cXk0rA0hr8CpngGtwSV 8kU5zD8qDEOjsjV9tJDEW7OhyTrHvAXb2KwdwPlz+sUk3hIzx6KiM1r1RsnLHWOj5OmO0ZXFAtBg uShZVVh025zGQQMqFBZdiQjbPpKChUvjihkcEs51dGOZ0jC38ILuJhgtTozR00Tw2FJ3YXx0MVks RR6hxfOEuXkOv7nUSRHAlzC0Gh5Vj+qN8KhWTixGe/ctBFi/BQu7lo6r1hoIKu+9MGzW0dxwYTMM j6iTkSMbdQz1A9b9UwjOW252quM5+X+Af79/vCWt67m5FF4ovMdbUINxOQJkJADDz9WpufGOIC8g yi/HKnLUQYNjMbwqIsFPpC54AT8QIjG+HQi196oHoL1uB4de0Tg1zm86s5nrSsGx0r4XZrVM47NU SpLg4Sa60rAJl+1gMCoWlOPshY6LvhqMXVi7HI6gxOR1SYL7HRnyCLvy528//vH7TwHLUxclZzxL JXQJ4b6EGytg195B6KMCUmAEaeI6PS3HhMW9QxLu/BL+lVDxJTccLnj41q5s8fYhFhCei5hBs8DW 3Qir34bX4Qa8GAkDGIqNXAHt3vAqMKeWkKPAZoMp4gEby8dO+yjaIp4SNMQ+zcMmQWkTP/VmvbnA T61xQDHlMboCYm6seyZ0xqjRDgzYwy/EJ+fWkU4I/XIIhYvSFMJ+EanYtB0c1cKan7D2JkudQMyk GbSiKC61Inp5qmI/2fFUFm0sIJXfjrugTMccVEu0eR2wqeFgLvvDmBvwj3yuQFhHB9UqSML5B08p ATPrbwbrb9Q462qADmcAVxGkgs0Wza7DE/GNznLuzlUvjxZbSl7oz665yUtXORD9he4lPBe7PFaM 9Q4sGInct5uQMm7OgdNmrVHD2qmKccABq2WH54s8OhXDsnUZuYIiiA8X+2mXI/4Va4U+PG6E8TzF 7qYvOq/VGtV8k6k96Ypws/Ns7c01aJTSEJzrd/LQLRK6OuvWsInsqTHcbfGQIbt3cu6noj1nrQ2d CTSk9PLI+eg7vHtjCyh23r75uZ8Idnpy8eT6+ZP+d0wPvgcPsA2b/u7sK/ZhtYYwgBHwtX4Glmt1 KX94Z8E7BLIDwDh+ILqGjLiAJXwi3l3jHU7gbJjORMykUCOXMD1kVTaYO2H/S08/evvmly15q2P1 dorwkcG5Uq04xD4tPH58xmWXcmxZazMM3zNxDcZnWrm1s+LEpByJ+MY5cVhdS1jL1GEwRh5lfB7b Dt6++bU4dx7kSXcipZ7iCiamm67/Z37dETO7iJYC/T2f1u9C4ju0XyeyD6D1tyzWuPridu6vvKzM Ofa0knOWZrkUVKDwlYUvNPe5JJZdFJm+kNxGJvYBoJYq3ACn2tykagtKn34yP2ID4aZCqC1OAG2I CAaNmMZFCPlymSVHklvLprgWe3Kx4zzXxn0GBL+dPK4yqv9zsvclh3GdF6lLR/6gRAKpxEi7lDvB OMNNkkr7uIrgrsBOrzcxQp8rkHN2CTCVPu6B2xnQg4qw2wVEX0csvjygufgYEUnzgucvJ5758I0F zIjCL7pycAluxTR0NQRVyTTDC6q2O4UanC+7c0zGsD44KfY363iMGzZVioapQrUN9S6Brz1UJlMC bka1EnVDcjGKW9mV1r5Sg5VykoT/UjS1yuXQxIehzl8AAAD//wMAUEsDBBQABgAIAAAAIQBqonNV eAQAAKEPAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTYueG1s3FfNbuM2EL4X6DsQvGdty5FjG5EXm+xm USCbDZIseqYl2hZCUQJJO3FPvffYN+gD9A36MkX7Hv2GlGQ7f5td9BDkktDU/HA+fjOcOXx7Wyi2 ksbmpU54702XM6nTMsv1POFfrk72hpxZJ3QmVKllwtfS8reTH384rMZWZQza2o5FwhfOVeNOx6YL WQj7pqykxrdZaQrh8NPMO5kRN7BaqE7U7Q46hcg1r/XNc/TL2SxP5fsyXRZSu2DESCUcTm4XeWUb a9VzrFVGWpjx2jtHmiCy9FJl9N9WV0ZKWunVR1NdVufGfz5bnRuWZ8CLMy0KwMI79YdazP/UEMOi c0d93lgS49uZKSaHYozY2G3CAf6a/kJJjOWtY2nYTDe76eLzA7Lp4sMD0p3GAU7QOqWoQkT3wzno HeAIIaILmeLa50qyqA0uaAhYOC3Ta8t0iXADCuXxAtLynTHlzUKKzNJ2CD49WzWuCBFyXi2YW1fA zeVOSQ4sEeh+NNofDQ6iUVwrBmkPX2PA+ito4mqB248PQCqPXhQNB1juQDiMohFtMgLyYABRL7CN TzBcjd3tUZmtCf8p/vv7E2Nl3aVbK+mNAj0xxjGYUHOkjELCiFN9ZK49EIQCWH6+1KmjDRLO5Owi MMEr0hZQwB8YUZBPuNR7Xy6RaL8kvO8PmuXG+UtntnDHSgp46npjtlR5dpIrRRZ8usljZdhKqIRP 58GhWhafyizsxQi2ibYVBymhvG1JCn8jM5HiVv7987d//vqdsyp36eJEFLnCWSLAtxDGSsS114s8 K2AFQdBJ3OR9btOlpTrSOSPuXjpZWfLjvDdIYQ3wcJ8NyFgGMj5OyVHUG92nZH+HkozsgUAh+A05 n03JwFPd0pTIwKY3wBBgiKUrPfJ3krUmGmVsD5zdv0e6Qa/bki7uRiNiKHnasLcy1n2UZcFokXCD lPOexOrUuiDaiBDGuqR79yRUmt0kfBRHsVfY+lLkToJWeZHwIV19nQqUkx905pWdyFVY4yxK+yv5 Dv4XwpyCr0hbOGG5zlBPQY16w9OzSo/krF6dpy4wktKvQcK2EtPlSandFgnfmVwguVrO1YFMl7hW 47cT/vevf9SQ1nVB6uxcGIF0eyCzfIloM8sfa11sefwZiUsPH16SR5nf0H7jqOG1J3eoDP8nMpQ0 IcU2Lr8aW82db022fv/lp1p3MACvn6jvcTyI6hfglaUa4u5RqqkVaj1aj5efchFdFWtT7jtpGb9M VvaHuA2E5x+AXlPeN43bTtfxelkZ9/b78fYDUG982wOwKXNoFB5pje6waac1Cg/b5KeiUpLmA9/Y s5mU2VSk1w+0IffK9YuKg+2cGJx64l37CiyELEHa9q3hdXot4T5RU3x7GSY4LJuhLlXmk6g+rzzP MKuiXUIDja0KTz9Zg+hGBM1qXuADTS1Ooy3z44uAMsSudDMFZkvMsFSPZ7lGA8YZxksnDPohLTFd o4Chl7wKI09xUZbOty0YhMgSPNamaVW7wxID9uQ/AAAA//8DAFBLAwQUAAYACAAAACEAmrek0WQF AACyFQAAFQAAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbOxYW08jNxR+bqX+B2teKzYXCAsRYQUUdisF NiKs9tnjcZIBjz21PUngqf+h/7C/pN/xXJJwE1KLilpeZjz2sX3Ody7z2Qeflplic2ldavQg6nxo R0xqYZJUTwfRt6uzrb2IOc91wpXRchDdShd9Ovzpx4O871TCMFu7Ph9EM+/zfqvlxExm3H0wudQY mxibcY9PO20lli+waqZa3XZ7t5XxVEfVfPuS+WYySYX8xYgik9qXi1ipuIfmbpbmrl4tf8lquZUO y4TZGyodwjIxVgm9XX5lpaSWnn+2+Tgf2TB8MR9ZlibAK2KaZ4AlalUDlVj41BBDo3Vv+rReifeX E5sdHvA+bGPLQQTwb+mJSbwvl56JslOsesXs6yOyYnb6iHSr3gAaNJuSVaVFD83p1uZcSgGfT5Vk 3cYyEmd+eWygUyciDV0+NOLGMW1OZpCWR9aaxUzyxJFEabm4mNf7rMNR9zlaNF6cmwQg8sKbsPA9 WLb3Ou12iU2n191BcwOgvW53f5fGCab9zk4l0FjP+7l1/rM0GaPGILKwLuzD50PnSc+VCNmlzVmq VNhDabbAor1uL0xYG8lSLy1TaTaI9qBdrRSZf6qTMNnzVJVtbKB0iAQymOAnIJNb2i3GGyAgB6Ha zNi7iC0sRxC73wpuZcTUrxqABsMi5sPHTu9jFwbb9ZF4fUQX2YlRIUC5Flh1EAlvI1Z+nHh8E2Am y7kf6nEuap8SQlfL79zmFVgecXhhxjOey8cwK2UDhKUhZJJyfuxvlQwoINoALyzMuB2GbdG4DA01 h4rQI9UJcjE0uZqiDqmIJXJyxePxXeNSZn0pLflQH9ubYNzEaH8UpsTcEVZIaF0NY2EKS9ScUaEF li+jVpG5pJPLxUh4NueEU+PC4KqVxLGc3JcN4QcxzF+NHk38M3LVaFycKHu1DLDExfiuaZ7BjObj AoW2ip+4jE/eBxqXZTEJWNJWCCM8gOtNkaWZuU5LSGHxIJJ669sYhRvoIRsARFziHJ7FINLYguq6 TW+Qd9qMQytiN9ICfYoMCsBKioIDXZpquUrv5JfwSXirlH4JYWxkjZmEdpJaH+oVc5k/UZKHFUlZ SoG17KqSAkAalSaUcjQc/iASOJWOiaeV14oMRaLs69XpRk6gHw6JhxDcWElOJkj0GsFiqCuEC9qq aod4Yf42lxMuYMvP2fWW8lV94fcGJC8HhLs3IFyodsEdZIM/HBtV0I9pq8OouiA28Cx1LPOBxN6T glB4naRQj+dBE+BPR+lGDDXh9bej8bUi7YeN+ForC/8bBFAbUYcYZ1oumImvkfT3MJE6GXHLUUHf i+XbKZYrr4TqiLoInlrzIjRLnvo0W91+yFa3qQ6Dv5ek819iq+0dEMLA5Dvd/d5DurrbaTd0tdfu 7uM4VP0+at77zlfBT/1bYKvdvd7HHpxZM9StqiMwlXX+1zBJeLPx54ohxgVRvDXacGRTDpabp17M zniWKlCm7R0Qrxm3TgYuXNFEnK1s6B5Ef/7+R8lAnqODD+p+N4TjC/58D39RuiFD7jZb0/47SDVd EeDMvWEBDpCNAeHkSKyHDjxEgT6fj4ZjNjo5HTGcKaSmKwfH+k+VbUx9jCq9e6Sip/+AR0aqcJv8 9Dn+sE2FanVEeJpBvXIc9aGDzBFDqcNhb8rSLFc4A1SXOSzm4mbBbVKdbtNYyQ068B+Oq7fiIRwG gXpGyY2mkM6Rn2yhpGO4EmShEmxxyDCXS47SxHDTwTKDB91JKLnccBkuw1YM7q3Vt5VqT9OYwGbK u0Q06+tFoew5z7/OQ33ErSkulHCQRVcOuFD9SXQlQmvgWvIvAAAA//8DAFBLAwQUAAYACAAAACEA SQ9x1SsEAABsDwAAFQAAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbORX227bOBB9X2D/YaCnXaDxRbET 24gdNM66LZCmQeIiz7REW9pSpEDSrtWnfsgu0H/pn/RLekhJcZ2kl0Wd3QD7YkvUcDhzOHNm5uh4 nQlacW1SJYdBu9EKiMtIxalcDIPX08leLyBjmYyZUJIPg4Kb4Hj06y9H+cCImLBbmgEbBom1+aDZ NFHCM2YaKucS3+ZKZ8ziVS+asWZvoTUTzbDVOmhmLJVBtV//yH41n6cRP1XRMuPSlko0F8zCcpOk uam15T+iLdfcQI3fvWXSCJ5FVyJ2/yafas7dk1w90/lVfqH95/PVhaY0Bl4BSZYBlqBZfajE/KuE GB6at7Yvak1ssJ7rbHTEBvCN1sMA4BfuF5vYgK8tReVitFmNklf3yEbJH/dIN+sDYMHNoc6r0qO7 7uy3Dju1R5c8wrUvBKfwxrlyB4OGMxW9MSQV3C1RUOME0vyp1uptwlls3HLpfHS+qo9yiLjD84Rs kQM3m1rBA2AJRzthv9M/OAz73WpjKe3hqxUYfwW1XzfA7ffarVaJXhj2DvC4BWEvDPtukRyQ7XZn 3wk742pFOKPUnA/s+kTFhbuAGf79BbKBMPbKFoJ7rYCPDWAHMbFAzghkDDuTJ/qNR8LBgDC/WMrI ugUnHPP5ZRkKfqNbAgz4gRIB+WHA5d7rK2TaO8DgPYlTbf2tk8nsWHCGk1pemVEijSepEE6Dzzc+ FppWTAyD2aI8UCyzlyou17rQV3t7I+59/0ITkIAxTqMdnTw9P71+MX3u4LFe0H+YPVKTYWVl2uOF lG5h+UihdPd9nTBLqSGbcMq1mgmeHd+ynsv4gmmGkH480buxyUcschQ5XeeyT2/HO9+kvu5d6tt3 LIF6UDPYLqnP0csOmK/V6Tlmc8TWDT13fJ36Ov3ujqjve4w3W56jXSgptqLs+2P+GzxXZL5IzFmE QnENTnVNCap8ntoombAsFXA6BKknTBsOsvWF6ksmu5yMu51O6wkZFDO0CXTYONxORUiXdO64w3H6 Azvm78aOPr3/a4r8upVX/wShSlHJ1afT56Rmf8JJclFFCTPEaJ6ueUyCy4VNSM2pQ7PCcvPzhzY+ vf97S8suUNwk8DapPESAbM6qyaIOg4ePAF+1dxbahNYildxQSOO9KVoqQ7+1Ce06hb//7BVNlLT3 ZqCPvdkSHZ/2yTcMPn6o2qn/LtdjBd9Rt1iei4Ksoir5K4TiCp8npNC4yYLmS7vUvFpt/L+wGjMp FbiCE4YMJANoYgsADB9fKfH/TjbeLd2+gpfDGB7r+SwS+iXLX608cWLstFyjFcZSjkrhig9ENyLo B9IMH1xFt/LMoLfFJMKwGWJTWQ908RLjaApQkFipxXCCSdEyjfoiOQZlNAkq5i7VML1kl0pZH/qV Jmd5qdo9VcfhEbPy6DMAAAD//wMAUEsDBBQABgAIAAAAIQCv3y/7jQUAAJsXAAAVAAAAcHB0L3Ns aWRlcy9zbGlkZTQueG1s7FhLchs3EN2nKndAYeFNQtOkRImmTbkk2rJdRcsskY7X4AxIjokBJgCG H628zzI3yAFyg1wmldwjrzEz/Eiy4038qahURWGARgP9uvG6gcdPVqliC2ldYnSXN+4/4EzqyMSJ nnb5m9F5rc2Z80LHQhktu3wtHX9y8v13j7OOUzHDbO06ostn3medet1FM5kKd99kUmNsYmwqPD7t tB5bsYTWVNWbDx4c1VORaF7Ot58y30wmSSSfmihPpfaFEiuV8Ni5myWZq7Rln6Its9JBTZi9t6UT WBYNVUz/XTayUlJLL57bbJgNbBi+WAwsS2LgxZkWKWDh9XKgFAufGmJo1K9Nn1aaRGc1senJY9GB bWzV5QB/Tb+YJDpy5VlUdEbb3mj2+hbZaPbsFul6tQB2sFmUrCosumlOszLnUkbw+VRJ1txYRuLM r84M9tTgtEOX9U00d0yb3gzS8tRas5xJETuSKCyPLhbVOrtwVH2OlI6Xr0wMEEXuTVB8DZbD1jFC JmDTbLaP0NwDqN1sPqRORjAdH0E0CGysF53MOv9cmpRRo8strAvriEXfedrnVoTs0uY8USqsoTRb dvnDVrMVJuyMpImXlqkk7fI2Vqw2ReY/03GY7EWiijYWUDpEAhlM8BOQ8ZpWG+M/QMAZxNZmxl5x trQCQex+zoWVnKmXGoA+bBwewkYfPgIinNndkfHuiM7TnlEhQIWOoLXLI285Kz56Ht8EmEkz4ft6 mEWVTwmh0eqtsFkJlkccXpjhTGTyNswK2QBhYQiZpJwf+rWSAQVEG+CFhamw/bAsGpehoRbYIvaR 6BhnMTSFmoKHFGexnIzEeHhVWg4p6wtpKfr6zM6DcROj/WmYMhaOsMKB1uUwplBYgnMGuY6gvoha RebSnlwWDSLPFoJw2rgwuGorcSYn12Wr6ML87ejpxH9Erhwd5z1lR6sAyzgfXm2a5zBj83EBoi3j Z1zEp+gAjcuCTAKWtBTCCD/AdZ6nSWreJQWksLjLpa69GYK4gd5BOBrjAufwm3e5xhLE6zaZ49xp MwwtzubSAn2KDArAUoqCA12auFwlV/JF+CS8VUIpIYwNrDGT0Hap7ykpgh7aIgX+zpkqjwLgNyqJ 6aDRcMgbEugU7hhPS1/lKaih6GtVhwwaNuIh8PY0yckEx7vCLe/rEteclirbIUqYX2dyIiJY8EP6 rqZ8ySpiZ+Dv33/5649fOcsSH83ORZooUAxYMpoJ6yRCqtZoBoYUncjtzCOFkQsUGHxEJvqToVE5 ZatakxgH8YLf4EWp44GwAh7+2pwZJ9aH5MPu3FrEycatW6cFR4LmkGYrWkezSLMfTrYHN5PtAUUM yo8iZ36ZZFtmWCpE2gdtyruBi6pqpH2EvyrZto4bdCrLOK+y9l22RXb1X0OubbZbxy3Qc5Vfa2VH YNzd7LXJg1Q8Vf7c5rePZR91PeE0Q3hsMslHGIRy9R5p6g0Lu3W6M/IWOZxuJCjxP8jEgYaJUKm+ InYtalJ2ed5roXJi3jChlFmyUf8nB0TY2enF07cvn45e7JExNBQFCynZVi3/ayRZjWm5ZKAAqeme 6H5ky8TP0Dk1PglXKPbkDsX9yuBGPLI7hP4FoR5Ci3U+K07jnErvHao5tYnA7WOPZg4Odyq+Mh+i lEcNGArBLv/z/W9FlvwmiTIVaza2UsxxwhMHTp6yJM2UpGeWcLhx3j9n7N75xJ+8EnPJBBv0ng3Y onG/cYNwSwqOE7wb0BWXmfE73HvYPeUfFa9u96b+0Wf12y3Bv62RcTO/djH9wnXCdmtV+V5l/s1T xX+Y9Ler3wGD+wVVXUXd9k0Bc/PCF+59xaMxmtU7cqTsK5G9XoTKFM/jeDnEUwe6MpxcMh+iWxHS gffnfwAAAP//AwBQSwMEFAAGAAgAAAAhAKYT257dBAAAZRIAABUAAABwcHQvc2xpZGVzL3NsaWRl MS54bWzsWF1u4zYQfm6B3oHQc7K25X8jdrD22kEKr9dwvCjQN4aiLSEUJVD0316hj71Hb9DbtPfo R1KyE9fZZHebtsDui02JnOHMNzPkfLq43MaCrLnKokR2vcqrske4ZEkQyWXXez8fnbc8kmkqAyoS ybvejmfeZe+H7y/STiYCAmmZdWjXC7VOO6VSxkIe0+xVknKJuUWiYqrxqJalQNENtMai5JfLjVJM I+nl8uo58sliETH+JmGrmEvtlCguqIblWRilWaEtfY62VPEMaqz0A5N68IzdiMD8Z+lccW5Gcn2l 0pt0quz0ZD1VJAqAl0ckjQGLV8on8mX2UWIZBqUj8WWhiXa2CxX3LmgHvpFt1wP4O/MLIdrhW02Y e8kOb1n47sRaFg5PrC4VG8CC/abGK+fR393xy3WY4DyacYawLwUn/t45J0GhYZywu4zIBO46FJJB iNX8tVLJJuQ0yMxr5zybrIutDCJm8zQkepcCN6bVPNKCe4ATvtb8dq3daPrtei7rBCyChY7MRqFw bY9do9xulB2AtXrTL9vdDyg2m02/ZuYNlpVardnCg7GvUIQ9nOa0o7f9JNiZGNzi38aQdkSmb/RO cBsbIEg7sINwOpZ9dWcxMAAgwacryXTuPe3AXfxgpcBs1+Py/P2NR4JIaRtTksV6IDhF7eVh172r 4WQ4ez2+/nn45pL0UXqbKNDhd8ZUbQ22OrkMplTR2bNVQxxmw83CPeuxicZHE2Kf4oeEqL5gQmSr 238oIarlmomxqahKu1XBoWPMPmREq16t7TPCrzb8fMUXZkRM1dhWciQDHDB2SMUSAUau43D9SMLY jFuNEqnnW2vq7WqCQ9dlaZ71p/OJCj22+fUhPB9McGJ/6Hq+9f50ppmdskREwSgSwj6Yc5sPhCJr KroeZQy228IHHA9WmgNX2updUIYKnkcxz8iEb8gsiSmO9DTSLBzROBIGeVwfLKQq4xYJFwB6T/zP 33754/dfj6T8e0LnFb+wA2VkbNW96WBIfro6KohvyACZM3I9nI9Iq3n2AB1X+/YAcOfWtyx9+Sz9 cSV2BBdR9Yz0uRKomv9hTJ46KWzF6t5sNKjjtCTnD3147H57Sqsp4xCI3A1ExO6I6phmSl0H9mZB su4rHU3jQp8/wO1T9uQKrSVusPu37LP3jrhefPbOn7Xjf+RoyvhX4ecyTkX2VXiKiKb/sqOgK1wa FnmM8GON6lNnRN72mHLdt9svfG19samf3F2j03F0a27oXj/ZEst8QEEdaSKmWQcxqngGhwPvejbb Miga/nmfPZHbzdskQO9GVzqxio94qCVQrnX2/RZo1XHrXAabMr21IVPVRqNZKQ7uQlGqMn3Fk5iY AY52kEm7EV2PM51HNl9iHJOJaUTtXSMk2XS9dt2vW4F7M3GkOXhUFHc9tLZ7owzbHMrACmsaCTfG JSKk9f0xVucAfQ0IRlFukqN7ZuIk23MSrM8X+WjKtOuX64U5pltO3QrTc7mG9bG02vfmOSCn2Jkl ae4rBIbFhwkm1FuavlsrYwi+twAY9O54lYKAGm1YelgCyhfFmDBcT0sEwFJwCmEsm8viS0awwmVp WMsikoDaI/hEoqlC+CTHFyJkKpJmbmm7jmdJonOOnhpN2DFXbUb5dhjiI1HvLwAAAP//AwBQSwME FAAGAAgAAAAhALMTn4qTBAAAeg4AACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54 bWzEV81y2zYQvnem74Bhz7T4J1LiWMrIktwcHNsTOQ8Ag5DEKQiyIKRYyXQmL9RTT801b5InyS5A 6ieWZ1TXaS8UCS2+xe737S55/uqhEGTNVZ2XcuD4Z55DuGRllsvFwHl3d+n2HFJrKjMqSskHzobX zqvhzz+dV2ktsiu6KVeaAIasUzpwllpXaadTsyUvaH1WVlzCf/NSFVTDo1p0MkXfA3YhOoHnxZ2C 5tJp9qtT9pfzec74pGSrgkttQRQXVMP562Ve1S1adQpapXgNMGb34ZH0poJoa85ec5o5xBiqNSz5 zhBiZzOREUkLWJhKRu/5B5qVJOMEdrD8y1/SWNXVneIc7eX6V1XNqltlNl+vbxXJMwRrQJxO80dj Zh4lmMFN57vtixaJpg9zVQzPaQpZIQ8DB8jb4BU20ZQ/aMLsItutsuXNEVu2nB6x7rQO4ARbp8B7 ZSN6HE7QhuOTuy9/6pUot3FZYwqbr0r2W01kCZFiAmyA7HrdwmHU6KBaEkuCzrXgjZ3902Skta9N VtujbnORBEHohyYhUeTFfe+7tCRJEkSwSDA5fhgHXtI1TlokcGKhq1Q/XJTZBpN6D7/AHZVsWYJe Ne6gqaj1TG8EMA33a+HDiQgVCygoATqgacbnb2Gp/jBwwCX4vDfUMwoZoEI0bpudQPghIqSbppAS uACIoFiZvHanM6jMQo8Fp+CoiU4PX9MFJUzkjFRUUVJAKUPFUEW4ILzWuTAy1ZYeUKwAO61AsehW G+fGF5fZLQDguRuX0n03a44KR4L0tGkxmULKnlYGEGGrJSBvqGJQLAqrRYNIX0QjyIsDJQV6byX1 LKkEfS9OQDYHFXQola7n+b2kSYQtwFOkcm8xj0mloOrKFG8uM+hGeIts36+uoeWak+wJCNqm4RpF YqWGtnAboOosVNRNwAzycQKe39vHQ5AGL9zh9X0ooVPx4n08BGnwoh2eHyY+mp12QHSNXcJEiSgN YHcPsBf0MI5nACJKAxjvAIOgBwd8FiCiNIDJHmAShadzchAyojSAvR0gop1OygEgojSA/T3AuJs8 kxREsQTtNULTthAetLntT8bvC7Yx7B9PNjFQzD9uVFHbqN5yBq89C8FJhOqDkd+OqCNDDMbZeAnW fKRU+X4Jrwz1rhFtN+Icx0TtzbZMQxOHsbCkYt72L6v21hh6i9zOxnbWCYkF8fSAMk3jSKtB1m0v 2RYUDqvj3M3hFQdfUj564Sj0fP/CDfvjsRtNxp476l1Ebn888rrxNO5FU+8Pp5nWGdVc5wW/zBcr xW9W2kGnO8oz7k6mtheCZ3NQPQy9My85Czw/3E0hcI87H80hC0CyXOn2teY5RHcfE23m/w8ieq6V Zfr3FVWaw4MdVidMq/+E7Edp5mbc/+s0x4/THP/AeoJvkutVcTTTAbo11WQE//+XVX/an0yTaeKa SzSJQ/eiO7p0+0lvcjHygu64O9mWVS1yeDeA0E6opq+f/v7l66fPL1pKptnYrxm4xc8f0xOFekOr mzV0EJrCFx8Ie2yWKvjGs+lmOxPEaL8Zh98AAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcB AAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1sLnJlbHOEj8EKwjAQ RO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv 4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak 1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfV NuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk 2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZC I+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvz f3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAI AAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMu eG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/Wsa xZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmG SL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZU sJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA cHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJlbHOEj8EKwjAQRO+C/xD2 btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYg OKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnO gPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsB AAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj 6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFF FoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfo EMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQBp ol8hHgEAAMcHAAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJl bHPE1d1qwyAUB/D7wd5Bzv1ikrbpBzW9GYPCrkb3ABJPPliionYsbz8pDBIojkLAm4CK5/z4K+Z4 +hl68o3GdkoyyJIUCMpKiU42DD4vby87INZxKXivJDIY0cKpfH46fmDPnd9k205b4qtIy6B1Th8o tVWLA7eJ0ij9Sq3MwJ0fmoZqXn3xBmmepgU10xpQzmqSs2BgzsL3v4zad/6/tqrrrsJXVV0HlO5O C2r7TuA7H9XV+bLcNOgYJMl03k4Hu8Tzgd6XrWLKViHZNqZsG5Jl+ZI0568Zzg7yNkNv3yzkWJTx 6K3KQ7JsyYAelQUzK2LKimBmcUMLpraJmdommJp/6+M9rVkasq1j0tYh2T6mbP8no7Pfb/kLAAD/ /wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDYueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+b YwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXi WcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxj Ip9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLx vgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHOE j8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LIC Qd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJT ryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95 LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw 4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7E sG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZ GsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsD BBQABgAIAAAAIQCZ9pmu1QAAAL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xp ZGUyLnhtbC5yZWxzrJDBasMwDIbvg72D0X1WksMYo04vY9DDLqN7AGMriWliG0st69vPUAYJFHbZ SfwS+vSh3f57mdWFCocUDbS6AUXRJR/iaODr+P70AorFRm/nFMnAlRj2/ePD7pNmK3WJp5BZVUpk A5NIfkVkN9FiWadMsU6GVBYrNZYRs3UnOxJ2TfOMZc2AfsNUB2+gHHwH6njN9fLf7DQMwdFbcueF otw5gTwHTxVoy0hiQOtbh2+l01UW8L5H+58eMQnxh2WhsrFZ9RlXof01w83b+x8AAAD//wMAUEsD BBQABgAIAAAAIQBKr3U51AAAAL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xp ZGUxLnhtbC5yZWxzrJDBasMwDIbvg72D0X1W0sMYo04vY9BDL6V7AGEriWliG8sb7dvXUBgJFHbZ SfwS+vSh7e4yT+qHs/gYDLS6AcXBRufDYODr9PnyBkoKBUdTDGzgygK77vlpe+SJSl2S0SdRlRLE wFhKekcUO/JMomPiUCd9zDOVGvOAieyZBsZN07xiXjKgWzHV3hnIe7cBdbqmevlvdux7b/kj2u+Z Q3lwAmXyjiuQ8sDFgNb3jtxLq6ss4GOP9j89QiwsB5LCeWWz6Asuwq8Zrt7e3QAAAP//AwBQSwME FAAGAAgAAAAhAE8gMhhbCAAAtDcAACEAAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54 bWzsW1ty47gV/Z+q7IHFfKbUFl8ipWp5ym1bM13l7nGNPJVviIQkxhTJASE/ZipVvYfsILtI8pel 9EpyLkBSoh5uuaOeHo/0Y4HA5QVweB8Hl/Trbx9miXHHRRFnad+0XrVNg6dhFsXppG/+dDNoBaZR SJZGLMlS3jcfeWF+e/qnb17nvSKJ3rFCcmFAR1r0WN+cSpn3Tk6KcMpnrHiV5TzF2DgTMyZxKSYn kWD30D1LTux2u3MyY3FqlveLXe7PxuM45BdZOJ/xVGolgidMYv3FNM6LSlu+i7Zc8AJq1N2NJZ1i f+Ewieh3NNF/r8Xpa9YrsiSOBnGSqAvaKD9PhHHHkr45mljmyenrkxUpPh7zUF4VksZIH2lSDVJc 5DeCc2qld9+JfJjTKGZ/f3ctjDjCQzGNlM2APelWA6WYukwhpvU2bp9UmljvYSxmtFhAZzz0TTzh R/qLm1iPP0gj1J3hojec/rBBNpxebpDGZvUE2FA9Ke1K72jDdtp2p9rRj8CFpZOEG3a9OX0HIMyv svC2MNIM29UoZOdTSPMzIbL7KWdRQd1684CrmooQocnzqSEfc+AmY5nwUk4PYq1pLV8AcWN0/y6L IMvmMjMJmRXUXM+HwSrobN/tOEETv8C2ux0aJxQty3XauKCVLRTlopDf8WxmUKNvCmxdTcTuSstg vUqE5k8zMjL1kJLUuO+bXc/21A1LI7OY3C+JZ30zwIx6TtYjbC7TSN0sWZzoNtaSpMrwaMeEkHx4 k0WPNNsIv0ABgQBLm2biF9O4FwywFz/PmeCmkbxNgXbXcl1sUqoLBYlpiOWR0fJIOp+dZ3ALGDBL Q2jtm6EU1cW5xDUhls1yJq/SYR6SKK2GcLh5+CsTeQmWhJ2+z4ZTlvNNmGlZhbbeCClJCjmUjwlX KMAaoRY7TO6woNL4gQHrCeqEVfXNiLcuLhHtZvI84QzRsBSTp+dJHN4aMjN4FEujDHrKqhAbMQU9 Zqmmh0q0MRssrEIXTe0NT/qEv+4TDlmQcvj9+wThZCK8wPcrF9qDa1jwAXIThXkVWxq+4cKKux21 s6NvNH1D/mE8g568coxig2co91hyRmV+8MNdnXHIwyyNjITf8WQH9SqxPEP9zTQWu2tXhvwM7YNs LuR058W72pN2xmYQj5/Q/ryY1EGsd9eDklrSFwpKEVyg+AUJiCXjMjipx4eF7yE4dWwEH+TQRnCy LcepE7frd2zv95q3QdaaPPLrZfHfPFKpfH6XWIq3sF7Exz8ibZOpWG5NtJDatQARnTL5q7RPf8ZJ pMj0r2+swcC5GFy0PPy0XMe+aJ1dXJ7hT9d3Lgfn3bOzy7+D4ijmGDHJZTzjg3gyF/yHuWZsq5RB MwxFw4kHOO1Xbf+V3bacRXjC9LQKnkbXTDBafINzRLGQFf3+HP5Avuqt+6qy9S/kq2NicvQEiCCC hZb+qjP75/urY9luRbQ3O2zQ9Y4O+0za/TUd1mDJBGSamD+5wGf47prX8LT109A09uE1G46inS9I u1EzeT+fbXIclVf/j0TX8Tznacc5Zjoc4V+e43y229Qpz/eDttd1gpbrDdotN3CD1plLGTAIfKdz 4XlB16lTXoHyFsfJXTnrJzLdxw//+vPHD//ea5pTp2VdEUOzqsGFiXjHcgMFtr6ZSBQU5ANa0S1a o4lNfTb1oRXdosXCEGU9SJSNqgfjuqeWcaoep5Jxqx6QXy3sVT1IsbqnU/UgfEyTOL0FZ6Uf0xhn yfe6o2rpaALHv2KP2Vy+jVDuoWP9Uo9iJrbl+m7gdHysTfSo8CfeRupw9IQsVl3LliW0rXqxn1q2 LC1slcVOa9mS8W+VBQa1bMk4tsqiylHLlnF2qywqz7Wsv4ZiE7PukqwqzW3HLKAYUOHbfVpvAPuq ZS11MnhCcePBVVWVpe2VD14+qLpUoSpwVJpUl5QbSwa7lDENIVW9yuDsKn0jYGdY/ThL5ZlKqiNW cFggyleoqV/P0xDVu7by3CIP3/AxKUXrOpS6QF2dbRqjZ2PY41a5cnQpbaMEWM7xRCkcvkjQgsw2 CuZUqE8VuR6zEOXWv8z+1kokSYIcs5UBzvRAWKwMhEWpW69KTVOzfwWjTbW+BfH4o8N4JmKWoJQ6 ZaLgygY09k18CJTSzJwjPmSbTXwIlBIf94jPOj4ESomPd8RnHR8CpcSnQ/jMmLjqm9Wbow3RaCWQ 072NyPz7jdu7BRxCoQTEXwCiXiIhjR0gIIRCCUiwAMRyfHpxcpCIEAwlIt0lRAI7wAvNg0SEYNDv D5e4Ib4awAu7NaKoI4zj2l0CK05xckP2b1Ud2sNADPbLIlFmwHQlu1vmmTsxydEcb/GF4ip98+OH f2qOt8QvVRlDxcIn+aUm2J/kl+k2fpm2tvDLtLUjv9To+0AfLw0W6NuB51PHS0D/H2vo2+R3e0d/ jWutclGNZfXlxBKYdrAUGl+aKdu7HZWeacprYK4S1xJMAKcqgnVcsF8QmBssk6LOl7fMVZarwbTb nk8P8yVa5n//s+7lvw2Wmxmx7VmucupPG+bODHmPOenrwbWZL9td31Jk6AhX87y+mU1r8rOTpx6W dW2m2k4QdHbMEocFV83Dl5h33svklIuah8Mer/X5peSv+q0+L1qXw5IgL0Sq6q5OKMsEETI3bDTE y/TqbLxG2FGIVrXTRRW4WfXVH06Wq1AfRqiQccsFfdZND3jvmXOtYrsvRt2smIDzHSw+m1lyZST1 AeNg8dlCfJv1lEM2oM1k1mqWVw4ZoC0MVR2UjiEaKWsLJ/Xx5Rwdh44xaAsLBTrqvHgEaAvv7Hh+ s7JzsFmsZprL5BIfvyw+FKCPYqr/tjv9HwAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEA AC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJlbHOEj8EKwjAQ RO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv 4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak 1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfV NuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOW ZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vm QiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L 83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYA CAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5 LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1r GsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZ hki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3Km VLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEAI9CoCdUAAAC/AQAAKgAA AHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlNC54bWwucmVsc6yQwWrDMAyG74W+g9F9 dtJDGaVOL2PQwy6jewBhK4lZYhtLG+vbz1AKCRR22Un8Evr0oePpZ57UNxUOKVpodQOKoks+xMHC x+X16RkUC0aPU4pk4UoMp267Ob7ThFKXeAyZVaVEtjCK5IMx7EaakXXKFOukT2VGqbEMJqP7xIHM rmn2piwZ0K2Y6uwtlLPfgbpcc738Nzv1fXD0ktzXTFEenDA8BU8ViGUgsaD1rcO3stdVFsxjj/Y/ PWIS4jdkobKyWfTZLEJ7NzOrt3e/AAAA//8DAFBLAwQUAAYACAAAACEANh88oMcDAAAKDAAAIQAA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbMxWzY7bNhC+F+g7EOpZ6x/Ja0VYO9j1 yu0h2d3GmwdgyLGtliJVklLsFgXyQj311F7zJnmSDinJRmKntdFN0Yss0TMfZ75vZsir55tCkBq0 yZWcBIOLfkBAMsVzuZoErx/nYRIQY6nkVCgJk2ALJng+/fqrqzI1gr+gW1VZghjSpHQSrK0t017P sDUU1FyoEiT+t1S6oBY/9arHNX2L2IXoDfv9y15Bcxm0/voUf7Vc5gxuFasKkLYB0SCoxfjNOi9N h1aeglZqMAjjvT8OyW5LzFa9+SEg3kjX+DkIppg3WwhOJC1w4fH9b7YSimwJWoJVxhuY8lEDOFNZ f6vLRfmgvd9d/aBJzh1O6x/02j9aM/8p0Qxfep+4rzokmm6Wuphe0RTJIJtJgJpt3ROdaAobS1iz yParbH1/xJatsyPWvW4DjGC3KcpdNhkdpjPs0hmQlpBdXo0xRecXiv1oiFSYqSOgSZDd1R2cy9pt UK5Jw73NrYDWrvnTM9LZG2TV02U3N4pvXepv8Ncv0lQYu7BbAZ4SDJymCI4PFEBQV9pgwmyBpV3Y mQCKpd/SZ6ff0RUlTOSMlFRTUmAvYMlRTUAQMDZHuTkQ2yrPcbWkVr//XV4hcRZ1a/cCyR8Q4NV+ Sxm+XviEaIohYTZd6PjasPt5jqOO4yF5STWjXGkXBlPSgsy5crhYmh2fZzKec6yYTpQnIBu1IaIW O1afmnwscqfCcepRAK948+gi8dmdUQYLWFWSKyLzGsRH0h7HHzoFzsB/BM1AnwwfnQk/q6hGjk6N Pj4T/vsql0fhcQA9ad3HXd2/AobH0EoA8bH+fa3jnJmt0RqutVZv10C52df3rkncgP1k6HCLM+Fn PDqoWAY4q11b+MngZ48zPhhCTnUhUXzfxQ1e19hHZ5J3qMXAHws05bDEGeH8Eadbdu/tCHPmvpSX eOy40+OXLEnicRQNwptRloXxfHgdJnHyLIyT4Ty6iaObbD74NWjHKKcWbF7APF9VGu4rG/gy3U0l DuFt1qjfTFQ3xKL+RX98MewPon3l4/bO80DeBoDwXNvuvGk6BPnoePDUuAH1+QE3OhR65ML6QkIv rW6U/sk1CuBHI/Y/DEGv3X8h9gHN4E+Pf03z5SHNl1+QZrwj3lXFUab9wPTd9D9pq/k4HoyeZQk2 U4bNNJ5FYTKLknB0mYyzeJRF17f7tjIi5yAxtRO66cO7P7758O7PJ20l31HNNRNf3ZXUt4rQL2l5 X/vzFm/gWNgzv1TinbsZUWxv4jC6O/z0LwAAAP//AwBQSwMEFAAGAAgAAAAhAG2dkjdrBAAA+BIA ACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWzsWM1y2zYQvnem74Bhz7QokpIo jqVM9eP2kNhu5DwATEISUxBgAUi22ulMXqinnNJr3iRP0gVAWLLFVPLE8ckXCQQ/LHa//cGCp69u S4rWRMiCs4HXPgk8RFjG84ItBt67qzM/8ZBUmOWYckYG3oZI79Xwxx9Oq1TS/DXe8JVCIIPJFA+8 pVJV2mrJbElKLE94RRi8m3NRYgWPYtHKBb4B2SVthUHQbZW4YF69Xhyzns/nRUYmPFuVhCkrRBCK Fegvl0UlnbTqGGmVIBLEmNX3VVKbCqxVN/zi+r2HDE6sYabtDcH0bEZzxHAJExMuEb9+TxSX5pWs rgQhGsTWv4hqVl0Ks+J8fSlQkWsJ9UqvVb+oYeaRAQwGrQfLF04STm/nohye4hSYQLcDDxy20b+w CKfkVqHMTmbb2Wx50YDNltMGdMttABrcbQq+rqxF++aEzpw2uvr8j1pRfmeXBWNY/Jpnv0vEOFiq CbAGZudrJ05brTeolqgmvlCU1Dj70jDi8BJYNXSp2xHPN9r0a/g3kzilUs3UhhJDCSiOUxAOP+AA inVcE+lPZxDXpRpTgiHua/rU8Fe8wCijRYYqLDAqIREg3rBAhCIiVUE5yglS1lAYUsAp8fkjOwXi FPit3ouw/BIEvN1uyfx3M2MQTkElsMapDkPL7tc5jhzHIXqDRYZzLrQaGWeKsCL/Rsbln5AqmM49 CE+IHeeer9CumXwQgnGnB8ls4rDdDQI9vheNcRAlMO8hHZNxJ+z0u1FNhZVkKLAR4FhpdKjem65p 2+QUTnMy1wRr/cPEbgr87wBgGDZg412sAwA2asAGu1gHAGy8j23f08EBANs5hHUAwHYPYR0AsL1D WAcAbHII6wCA7R/CWoDmus407RiTaLASgYS7jHrqxIMCpzOwOe1AIauEUcdpYuL5ESVgRhYrlnPE ijWh99K6WX5og/1oS6+IyIg4WrzJlEeoP15hARwdq338SO1/WxWsUTwcPk9a82JX86JnqHnGh+aE 0VXIDHaPmqaa142Tl6IHp8VL0Utfit7Bvuql6JmycqjR67ii95ZkcOlaUIJMgYYbh2uWG9ppaKzH S0CTn4XgN0uCc7lt4+4W6hvFgy47V9AEP+j+TO/2/6WQMtvA6y5cd+2P79n0+p1OramTmMMNS1+X /poGnSSM+iM/mYxjP+5Pev4oGPX99jhKRkk0jqdB+2+vvjfkWBFVlOSsWKwEuVgpT9fubeefE38y tUceKG+6VDWMgpOgdxIG7Wh73MP2euXemWYFoLwQyl2wbFsAlDkeYHjI0d19R3e0Wt/J0XMlrKf/ 0N0BgQfb6h/R6z+Ls/doJua69M009/Zp7n5HmuGLyPmqbGT6iA7jWZjeptVZEvbD0djvxOO+HyeT xB/1epHfD3tRpx0F4ag/vUsrSYucMDDtiGz68uHTT18+/PukqWQyyn5XgaH++mJShYo3uLpYQxHC KXxvgsAem6kKvjDZEpVtIVqG+2I1/A8AAP//AwBQSwMEFAAGAAgAAAAhAHo5FFLgAwAAQQwAACIA AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTAueG1szFbNcts2EL53pu+AYc+0SOrHMsdS Rpbk9pDYTqT0jgIriVMQZEFQkZLJTF6op56Sa94kT5IFQEjjSJ7KrdPphSKh3cXut/t9wOWzTS7I GlSVFXIQxGdRQECygmdyOQhez6/DfkAqTSWnopAwCLZQBc+GP/5wWaaV4M/ptqg1wRiySukgWGld pq1WxVaQ0+qsKEHif4tC5VTjp1q2uKJvMHYuWkkU9Vo5zWTQ+KtT/IvFImMwKVidg9QuiAJBNeZf rbKy8tHKU6KVCioMY73vp6S3JVaLwOj5JiDWTq1xJQ6GWDqbCU4kzXFh/vlPXYuCbImGjS4Mljpj VFi7qpwrAOMh1z+rclbeKet+s75TJOMmXBMmaDV/NGb2U6IZvrS+cV/6SDTdLFQ+vKQpwkI2gwC7 tzVPdKIppkOYW2T7Vba6PWLLVtMj1i2/AWaw2xQbX7qKDstJfDkxaXDZ1eWMKTo/L9jvFZEFVmoA cAWym7UPZ6o2G5Qr4rqgMy2gsXN/WkS8fYWoWrj05qrgW1P6b/hrF2kqKj3TWwEWEkycphgcH9gA Qc2QQxVOZzjkuR4LoEiCBj49/IUuKWEiY6SkipIcWYHDRxUBQaDSGXadA9HNAHBcLalWn/+Slwic xr41e4Hkdxjg1X5LGb6e2YJoiilhNT51fHXoPoxx22OckBdUMcoLZdO4P30WkB2o/wh2A2JACpUh QxwVApxZHCjfs8f0wvICwaa/Ij9M6cc6g40kYi12LXjqTlmIHuoTdsuOh3v4TGytj5iZGSxryQsi szWIe3NwPH7isDi50jkoBurk8O1Hhh/XVKGInZp955HhX9aZPBoe1epJSdLxJHkFDE+vpQBic0Xp 9kJzhBMoSuMVWsNIqeLNCiiv9tO+czRq/I1CcY0C8hZPHCoWniRWRqxQGeMDxbIMkEgES3kXz6vA UQGzDmsR2zOEphwWKCjGH5nkl817o3fG3I7yAo8qc9S8S7rTuDO6OA87STcOO+eTcXjRHyXh+Ko3 GbcnURSNzt8HjeZyqkFnOVxny1rBba0DE3CvmhzCydR138mvUbx2dBadnyVR3N5PPm5vPA/a6wIQ nintDyfHEMTD42ChMUfBw2rYPWx016T1nRq90Mp1+g9DFMAPp4h/I4m2d/9Fsw9gBnvU/GuYe4cw 974jzHi1vKnzo0hbwbRs+p/Qqh9H/ajXj8I4GXXDTj8ah1fR1XV4HU968UVyMY3ayY5Wlcg4SCzt BDZ9+fDxpy8fPj0plSyj3J0UX8011lJFqBe0vF3bUwgv7jjYY7tU4lXdSRTbm5gY/uo//AoAAP// AwBQSwMEFAAGAAgAAAAhALd0bA8WBQAA0RIAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5 b3V0OS54bWy8WNty4kYQfU9V/mFKeZbRDSQo4y0wdpIqr+1avB8wlgZQZXTJaGAhqVTtD+UpT8nr /sl+SbpHMwgZe0Mwuy+gS8/p6dvpHp2/WWecrJio0iIfWu6ZYxGWx0WS5vOh9f7h2o4sUkmaJ5QX ORtaG1ZZby6+/+68HFQ8uaGbYikJYOTVgA6thZTloNOp4gXLaHVWlCyHd7NCZFTCrZh3EkE/AHbG O57j9DoZTXNLrxeHrC9mszRmkyJeZiyXNYhgnErYf7VIy8qglYeglYJVAKNWt7ckNyVYW6bxw9oi Skys4IFrXYDl8ZQnJKcZPPg5o3OWk7jIifz0p1zyQklU5YNgDGXz1Y+inJb3Qi28Xd0LkiYIpAGs jn6hxdRtDmJw0XmyfG6Q6GA9E9nFOR2AP8h6aEHYNvgLi+iArSWJ64dx8zRe3D0jGy+unpHuGAWw g61SiHhZW7RvjmfMccmDdoOxqxamsPimiH+pSF6ApeiA2sD4dmXg0GpUUC5I7X6ZSs60XP1SecTI V8qrZqtbX7hh3/MiyFuwPYggy5wnfukGUS+AhwS90+31Qj9SSgwSKKmhy4Fcj4tkg059hH+IHc3j RQGZ+li7mldyKjccIk0HfMVd2BGhfA6lxCEP6CBhs3fwqPptaEG+g8pHY/lWHsIM1zs44GQ6AEfA DyzlFCuRVfbVFCoxk5ecUYDXJsmLn+ickpinMSmpoCSD0oUKoYIwTlglU16QhJnchEsOclJ8+itH tVIpV7pYntwDAO5Wq8zt91PtF9gSOMU4Q/kHA/VyPvgmHzzyloqYJoXAbZRFlcYpKMebVJUOaoCK MllwVJ5AmVpQVZDyJquOy5ae64Vht46sKaJWsgSuixmlvVLX4BeyRVXjbmhNimRU3KiiTfME+Acv Md6Py1sgWbVqJ3F8yBytUa9HWbj0MNtqqKAbohQ5BM9rLNAgGs9v8PpuoCrkIDyUxGJWm0IQjRc0 eK4fuliHh20QK2ULiCgasLsDGEGJHweIKBqw1wACZcAGj9ohomjAcAcwDFTkjjAZUTRg1AAi2uFB afkQUTRgfwew1w2PDAqi1BF/SlwID2m1ZagXeAXawL0oipmqgiQV0jQqyKL/zTaBYRu/xTYSarjA RHotvyD3A/kCiS8on2mq8VSKYodWrsCLqfKK6R6mnTzbmLo+tJ267zQNu8U1kQNtqlZikL461bit UsZuprPmSKpxW9SFIBrvSKpxW1l9Aqrpn5hpWngnIJoW3gl4poV3Appp4Z2AZVp4h5OMSqsTTktI HC/OSscwVNcw1DsWw2lqzhkJ/puZgCQvFyDNRkIUHxaMJlUz4mxHJkNBO4NzIvfoyq1bqhEGKtnn K55j1zX81Qx8ZvqFt+1RdWceqQeWbdeuuQNHgqcNYgZnJzwB/d4Pgd96k7HtjTzXDrxx1x6FfmiP xmP3+tLpee7l5A9LHwUSKplMM3adzpeC3S2lhXtpQp4we3KFHoX2oc5OONz6zpkTnnmO6zfDLqhH ob22VAOQ17ai3n6g1UD55RZ0dKBnUtSR/nVJhWRwU4/BB8zB3yTYe25m6lTxajeH+27ufcV6gk8d t8vsWU8fMAZ8E09vy6o7Gfs9P5rYTj8c2UEQ+XYUjfq253TdkdMP4Awz3pZVxVM4gIBpB1TT549/ //D54z8nLSVFNvWnErjE7ypqWuPiLS3vVorW4UMSJPalelTCp6OaouJGBDHMp6iLfwEAAP//AwBQ SwMEFAAGAAgAAAAhAPL1qS1GBQAATxMAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 OC54bWzMWMty2zYU3Xem/4Bh17IIPvQayxlbj3bh2G7kfABMQhJbEGRBSJHS6Ux+qKuu2m3+JF/S C4DQk4kox810I1HUwcHFfZx7yctXq5ShJRVFkvG+gy9cB1EeZXHCZ33n7eO40XFQIQmPCcs47Ttr Wjivrr7/7jLvFSy+JetsIRFw8KJH+s5cyrzXbBbRnKakuMhyyuG/aSZSIuGnmDVjQd4Bd8qanuu2 milJuFOuF3XWZ9NpEtFhFi1SyqUhEZQRCfYX8yQvLFtehy0XtAAavXrfJLnO4bTZ0y+PKwdpmFjC DexcwcmjCYsRJyncGGRcUp7EGYoyjuTHP+WCZRpU5I+CUgXnyx9FPskfhF57t3wQKIkVV8nhNMs/ Spj+yQEGF82D5TPLRHqrqUivLkkPXIJWfQcit1afsIj06EqiyNyMtnej+X0FNpqPKtBNuwFYsNkU gp6bEx0fx7PHweixdIM9lwETWHybRb8WiGdwUuUAc8Dobmnp1KnVBvkcmQjIRDJa4syf2iMWX2iv WlM3vgjCNqSXdojX9t3wwCu+63Z87DtI+Qbjllcids9smPOeXN1k8Vr59Am+IXSER/MMcvXJeJoV ciLXDAJNemzJMBiECJtBMTFIA9KL6fQN3Cre9x0wCWx6sgff4CHKcL3DAz4mPfADfMBSRlQt0qIx mkAtpnLAKAH68kzy6icyIyhiSYRyIghKoXihRohAlCFayIRlKKY2NeGSAU6Kj39xta3Um+u9KI8f gEBZW27JG28n2vekByaB460z4NIkwufTAbxrKsRDr4mISJwJZQZUiakXxQuVZEN/ZnIkMSS3zZ/6 eeGH7VDFWlVKVWKEGGNAmMQIO6GPIUtUktoM0wc3KWp9YRMDYPtRLLPhIAl8lZiGcgcAl16ZyrsJ 09nFWgBg/QpssIu1AMAGFViViBsbLACw4SmsBQC2dQprAYBtn8JaAGA7p7AWANjuKawBVJUXrETA sKmjly43UGBVd9XFBgbpGjcf1hKdz2cU/oTOFhw6D0+WlO0VczW/p2J+Bv8jFREVtel1pZxBP1gQ AT6qa31wpvU/LxJeSQ/d8UWVLrBK5+8pnVQZoGx+vsqZFqj6Dgg/NJA5YVMHZgfQPh1L3QqVGumL iS4GpczqllWsqp6IAz/ERgK2o8JeUwxaXey2vlr7UErErR5NEh7DoKUulWlPizuYJnU27sgd3pMw 1UkVFopUKV9JZTt7Lb49qT2Qz5KviwO1K6rFtyebBxJb8mG/jVt1CbtfkGHL1/E6qgvUMnCP70Cq Sz7P64B5z+E7kHPL1w50RzvfvgPJL/kUWe2A7J33oC1YvlbYfl48/tetAwrezh96JFEq8/lZLLQK 9YZG8Cw3YxRpNf2yMsGYPpgDml4Lkb2bUxIX25lrM7ip5xMzEG1m9lgeyRU284YFV+oV42oksfq1 PWD9AUutPzFVT+HJTT18/X7jdjpe6A0bXXhUaAQYh43uyB83cDi6GQ1Hg9Z14P3hlE8hMZFUJikd J7OFoPcLqVVsO5zHtDEcmf4EUqV1TV757oXbvvBc7G97M2yvNO2oARkCFCdC2sc108PPC3TrONDh 6Rb07EBPpTCR/k21cgo/zFxeYzD/JsE+cjPVTzRf7eb2sZtb/6Gb4UXL3SKt9HSNMeCbeHpTVuPu YBB0XL8x8IKgEXjDceM6HF83PH84GA9bIQ6HN5uyKlgCUwEcTdXEiWr69OHvHz59+OdFS0mLjXlL A5fqrY6e1ph4TfL7pZ4+4DUWJPZA38rhxZWRqGgLURz2RdjVvwAAAP//AwBQSwMEFAAGAAgAAAAh AJcXM5bFAgAAqAcAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWzMVVlu2zAQ /S/QOxDst6w1XgTbgdf+pEkQJwdgJMoSQlEsSSt2iwK5VnucnKQj0spSp0CANmh/bHL0Zjjz3gw5 PN6WDNVUqqLiI+x3PIwoT6q04OsRvrpcOn2MlCY8JazidIR3VOHj8ft3QxErlp6QXbXRCGJwFZMR zrUWseuqJKclUZ1KUA7fskqWRMNWrt1UkluIXTI38LyuW5KC472/fI1/lWVFQudVsikp1zaIpIxo yF/lhVBtNPGaaEJSBWGM9/OU9E5AtdeM8BuMDEzWYPDxGCpPVixFnJRgWHDUgJLKfFDiUlLaQHj9 UYqVOJcGf1qfS1Skjf/eD7v7D3uY2XKAwcL9xX3dRiLxNpPleEhioAFtRxjU2jW/4ERiutUoscbk 0ZrkZy9gk3zxAtptD4AMHg4FoYWt6LCcoC3ngibQJGtGUfRQmYUTcD+pkhuFeAW1WgqqWQ5oOpGy us0pSVVjtpUnp3V7TkNHc7LIkZUj1dCMX0BYwjIMfEKxvineMNaAzaL1V4Z+EjNuQ9u9iPV2WqW7 hrJr+DeUA0jpld4xEA/WNfP3vinNLqwoT8zA01M40EPiDFqiUfhrz18EYTD1nckgCpxo1vOdQXd2 5PTCo8j3/V7gT7xvuK2IaKqLki6L9UbSs42GNiKxhG6BpoIJTKkzX1h5ISEjsx6HXsfrdQLPD4eQ iYaqzfGNJ+XpOZEEUn4WAKWF1G1PABoyBqZaHmBpJf690OGh0EdvKHSmpVX684ZITWFjxW6bxHbG vxP7gGbKnasV/mOao0Oau29IM9zgp5vyRaaD5lhD8H8yVsv+bB4s5n3Hny5DJ4qipTPtdwdOOJ/O Fv3JIIgm3YexUqxIKYfSXjFN93ffP9zf/firo2Qmyj4FsGyeC3PbM/mJiLMa7ikSw/sIjT0zJgEv 4v72e4Q0MdoXdvwTAAD//wMAUEsDBBQABgAIAAAAIQBteFQAQQMAABcJAAAhAAAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDYueG1szFbLbtpAFN1X6j+M3LUxNiaABUTm1S7SEIXkA6b2BayO x+7MQKBVpfxQV1m12/xJvqR3xnZoCpGo+lA39njm3Nc599runm5SRtYgZJLxnuXW6hYBHmVxwhc9 6/pqYrctIhXlMWUZh561BWmd9l++6OaBZPEZ3WYrRdAHlwHtWUul8sBxZLSElMpalgPHs3kmUqrw USycWNAb9J0yx6vXT5yUJtwq7cUx9tl8nkQwyqJVClwVTgQwqjB/uUxyWXnLj/GWC5Doxlg/TUlt c6xWJYrBlLOtRQxUrHHTtfpYfTRjMeE0xY3Z/R3LCDCi7r+oFcvMucyvBIBG8vVrkc/yC2HMztcX giSxdlOaW055UMLMI0cYLpyfzBeVJxps5iLtd2mAjJBNz0LhtvqKRjSAjSJRsRntdqPl9AA2Wo4P oJ0qAGbwGBQ1z4uK9svxqnJcclXSUNVVgCkan2XRe0l4hpVqAooCo/N15U5XrQPkS/KDACWuODSM VHiJrJooajPI4q0u/R3ezSYNmFQztWVgKMHEaYDO8YICMKr7G6Q9nmF/p2rIgGL/l/Sp/hu6oCRi SURyKihJcSCw76jQKoNUCeodQ6U3LhnilLi/410kTqFuZSzg8QU6uNyF5Pb1zBREA0wJq6lSx2XB 7vMcNyqOLyHCmVwwIL72hd1YcXiAZeR7uEQ0hEJkN0ugsTyO/FghNx9xjiibW9iz2FCuYchooJXa E0Pzy3ihqxZH51YVeFAbY7BmrsHSIIY5cqXt0U+1rdellBpulJzj9Okp+tRsdsaj1qBpj3zPt/2w PbA7YTixB17otdyxFw6H/merbKeYKlBJCpNksRIwXSnraUPEYI/GmlGMUjaR6jfqtXqr5tXdxk5c DK9Be/IWDkicCFXNHWb/y0L7+0I3/6LQcyUKpT+sqFCAD4XY1YQ+M3magX8i9h7NYKbot2lu7tN8 8hdpxg/m+So9yLSnw/5PY9WZuONxve7ZfrvVtn1/4NthpxPa7qDd7oST1rDRaD6OlWRJDBxLO2Ka Hm6/vnq4/fZHR8m8OovPLS71l9m8E5l4S/PpGl9CNMDfEWzsodnK8QekoDvaQbSP6oem/x0AAP// AwBQSwMEFAAGAAgAAAAhAGPl4+DFBQAA+RwAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5 b3V0NS54bWzsWcty4kYU3acq/9ClrDF6IR5lPGUYSBYe2xmYD2hLDSjRK60Gw6RSNT+UVVbJdv5k viT3dquRMJCSbTI1CzZYlk4f3Uffo6uryzfrOCIrxvMwTfqGdWEahCV+GoTJvG98mI4bHYPkgiYB jdKE9Y0Ny403V99/d5n18ii4oZt0KQhwJHmP9o2FEFmv2cz9BYtpfpFmLIFrs5THVMC/fN4MOH0E 7jhq2qbpNWMaJkaxntdZn85moc/epv4yZolQJJxFVID9+SLMcs2W1WHLOMuBRq7eNUlsMvBWPKbT 9fQxvXv4xSASzFdw2jKuwH9/EgUkoTGcGKZxRjn1w89/JfJank05Y4hKVj/ybJLdc7nkdnXPSRgg RbHUaBYXCpj8NwEYHDSfLJ9rJtpbz3h8dUl7EA+y7huQtg3+wiLaY2tBfHXSL8/6i7sDWH8xOoBu 6huABdubQsYz5dG+O7Z2xyLTz3+KZZRu/VJgCotvUv/XnCQpeIoBUA76tytNh17jDbIFKcIfiogV OHVRRkTjc4iqDJdYD9Jgg64/wF95kvaiXEzEJoIkwPEqsmQKaC9gs/cquJXT4G8VDm7SHpgCP5Cu iGItsLwxmkAtxGIYMQq1UgRbXP1E55T4UegT3AMkhuKBPUo5YRFhuQijlASMCBUWOIwAJzjslEu4 rYAsF/diSXAPBGCdvmXS+DCR7tMemAS+a0fhUOXieEYcnRGbvKPcp0HKpRmwOU6SG4y0AVsZ9plO 5ZEUYRyfbFe31Ybyl3vWajkty3LQzXLnuqZrWh2QHty/ntNte3YRB0Uk/VebRYdE557QxF+koCUP irKa12IbkJjyG1kzYRJA+eMh3v1heQsaJw1Ru4TkH/uG7aKlD9rNyq6Rhzbsq4JQe1WL1dxnRSq0 A8x0Stau5UoL6rBanX1WpCpY3ZLVctqWh+BatBK5GwLkKmhbFdqO3ZE2vJQWuQpar6S17Q6Y8Apr kaugbVdo264j9+FLrUWugrZT0iJn/ZQdiC1yFbTdCq3Xar8qZcgl5aZaE1Lr8Caw67aiJu9+Qu1D 0TmqfKB/z1Y3V6ubs6NufpoIloTBKxUOy35Bo1mhb0p78Fks44cH1UcQZuq4vtlW2+20W/+hb063 ZUHV1BU4qU/VDO493ErZAiw+2sqnHxxqlalKHNbWFqsBgNXaUcFKidliNQCwWhCqWNyuW6wGAFZX +VGsBgBWl+5RrAYAVtfjUawGAFYX2VGsBgBWVY5uHmR8pXpuffumS0vWF/zoIpfP62c0OBM2XyZB SpJwxaKdpkWV7lN+WS/P4J8y7jNem77oFWpr1HBJOchPXetdVaq16X9ehslBemhnTtrRtbTmuTua J07b0aH2/YYRY7yQPxlv2XjXlj/PbZk22Avd27H+zmqDKJ77u75x7u+gxz73d33DOfd3t3o84mmt a+1o3Qn7u12Nk6L/Yo071uOVGnfu8fC5stsznXu8uqOjGq9PT3uwc4+nxmqHO9Rvtsdra917z3yY us8jRqStMG3Wc9IDk1SYqQ4XgGbXnKePC0aDXI+rKgv1C2xlwBoImGjuvuxa6o1Ng6UmPn3bjRJ8 8cEZJHaE5VhSz+DgKrx1vnL+OoPpOk7Kf7/udMeD4fWocT12Wg13MPQaA8/0Gl3LGb81x+Ph6Nr6 wyhGxgEVTIQxG4fzJWd3S2GgLeUoI2CNtyPV4YPx0lBx5ZgXZvvCNi2nfLuB2+PKvRZeEZAg5ELP 1tUeg3joWaQMDQbm+HgWZpvq00GZaDkjqOTrlImeCejm91t7q8bo9qskey/MTM6+Xx3m7n6YPcz+ /xRm+CR2u4wPRrrGEOmrRHpbViPLGQ3c8QDqwRk0XK8zbHQ9Ez74mS3P9ZzOcFgpqzwKYVIOrtWo pi+f/v7hy6d/TlpKsqLUJzU4xC9vMocRf0ezu5V8V4cPjvDOOpSnMvjEqCTKLyHIoT9ZXv0LAAD/ /wMAUEsDBBQABgAIAAAAIQDwiUSe1QAAAL8BAAAqAAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25v dGVzU2xpZGUzLnhtbC5yZWxzrJDBasMwDIbvg72D0X12UugYo04vY9DDLqV9AGMriVkiG0sb69vP UAoJFHbZSfwS+vSh3f5nntQ3Fo6JLLS6AYXkU4g0WDif3p9eQLE4Cm5KhBYuyLDvHh92R5yc1CUe Y2ZVKcQWRpH8agz7EWfHOmWkOulTmZ3UWAaTnf90A5pN0zybsmRAt2KqQ7BQDmED6nTJ9fLf7NT3 0eNb8l8zktw5YXiKASvQlQHFgtbXDl/LVldZMPc92v/0oCTIH44Fy8pm0WezCO3NzKze3v0CAAD/ /wMAUEsDBBQABgAIAAAAIQDYKjOIDwQAACENAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDExLnhtbMxXwZLiNhC9pyr/oHLOHmxjMKYGtoCB5LA7M1nY3BWrAVdk2ZFlFpJK1f5QTnva XPdP9kvSkmzIAJNikplULmDL3U/d73W37OtX24yTDcgyzcXA8a88h4BIcpaK1cB5t5i5PYeUigpG eS5g4OygdF4Nv/7quuiXnL2mu7xSBDFE2acDZ61U0W+1ymQNGS2v8gIEPlvmMqMKb+WqxSR9j9gZ bwWe121lNBVO7S8v8c+XyzSBmzypMhDKgkjgVGH85TotygatuAStkFAijPF+GJLaFZgtEqMWqeIw EmyxdYixlxt84jtDpCCZc0YEzXBh8fl3VfFcc6nShHKyIwq2Kjd2ZbGQANpDbL6Vxby4l8b9dnMv Sco0XA3jtOoHtZm5FWiGF60j91WDRPvbpcyG17SP9JDtwEEVd/oXnWgfoyCJXUwOq8n67oxtsp6e sW41G2AE+02xAAqb0Wk6QZOOT4552SdovSiivM6Tn0oickxZM2EzTW43Da5OX+9UrImVRWlJHJLL FMWzKtVe1tQQ1XiXhuwmgz1F3W4Qh54lKojCbrv3kK3A60Tmueas0+v4naBjNmmQcBMLXfTVdpyz neb6R/xHSXURDBygP+C/heWlmqsdB6MI8kb7mBL+oDGnutegdKdz7LVMTThQ7MVaPTX8jq4oSXia kIJKSjJsTuwBKglwAqVKsegYEFXXH8PVgir5+aO4Rt0Ulk29Fwh2jwBvD1sK9928zglDwoSaRExu mvLHJW43EgfkDZUJZbk0Yeia3zeBBscuaaT8R2JrSo+0xpbBem4q5XLNw06EU8f0xjnJu54f9/Tz l5IcK5HwDd9r+9wlYLh/rACwDEzd2Z8mEkPiE4pxDqtKsJyIdAP8QYGdxw9s+V+c6QJkAvJi+PYT 4ScVlVifl0YfPhH++yoVZ+FxCj9r94VN972FBE/nFQdiYv37ZsMZO1mjNYykzN+vgbLy0Eb7LtWn zNHAZQon0y94olK+dOruM/PJTFptbC6ORy4XdpY/NifNMGwmox6H2Bx+Pa4ZLHFSaf+/LOvrepBq c1PKSzyC9RH662Q2G/WiTtuNvZuJG47bPTceBTfuOA7DyMP7iTf+zamPEEYVqDSDWbqqJNxVynk4 jhm4N1OrPgZkAlXDtnflRVeB57cPlY/ba88TeS0AYalUzaFrO+RpY7ZzKrQ5hl5I6KWSVumfdaMA 3thRe8Gs/U/EPqEZzBn2r2nuntLc1eq/EM346nxbZWeZNgPz/9RWY9/347EXu/E08t1w5LXd3qQd uVEcjsfxLOqG02jfViVPGQhM7YJu+vLh0zdfPvzxrK2ExDXv2nipX8+Nhly+ocXdxpxC+GGChT0x SwV+iugRg6YHE43RfNoM/wQAAP//AwBQSwMEFAAGAAgAAAAhAAj5PUCZAgAAXQYAAB8AAABwcHQv bm90ZXNTbGlkZXMvbm90ZXNTbGlkZTEueG1snFXbbtowGL6ftHewfJ+mUFZKRKiANtOkrkWFPoBn GxLVsT3bUOi0d99vm4Bo2Yp2QxznP30Hm/71uhZoxY2tlMxx6+wcIy6pYpVc5PhpViRXGFlHJCNC SZ7jDbf4evD5U19nUjluEeRLm5Ecl87pLE0tLXlN7JnSXMK3uTI1cfBqFikz5AXq1iJtn59fpjWp JN7mm1Py1XxeUX6j6LLm0sUihgviYHZbVto21fQp1bThFsqE7IORBoCNTgXzT6tnhnO/kquvRk/1 xITP96uJQRUDxjCSpAZicLr9sA0LrxLCYJG+SV80lUi2npt60CcZYEPrHAP9G/8LSSTja4do3KT7 XVo+HIml5e2R6LRpABPsmnpUEdEROO12D2aIkB45BeUXgqPuDl1MIVDiTtFni6QCvJEGNS4hmg+N US8lJ8z67Yie3q+aXp4S312XyG00EGcFu1/W4LLXHP9cEuO4wUAt4P6yzY4pgcSmig1CEPBgUQkR m8Q9nbn1SLGNJ/AHPIMAJBPWTd1G8EAswCfZXLCg4K+iN+y1W5e9pDvqXCSd7k0nGV2OxklRFMNO t9XpFsXVb7ybtmJcwry+hAETCMCcY8aTm9uoGkwWmrhBqw/8O5A/NAuKSjYhhjy+yUOsMq5RGKJh PkDb4IBlFOzfsu2cuJet7ScCMzfsH5ftUblDAa0G4Q+3DjQF0WfgzVtWhajI/q6J9/p7ib/Vi4/V FDLWikqeiLv93q4XJ+H+P7t6T2392bj7FH+CAw/A7eX9wKZgJ8TJnRyZ5yCJP2NwiU6WMmoUvMbf +orL5GmK975CtnZjwQnc8eFy+ZvJAufxyoNlcwtSYb4T/bCCg0syuNzhiI7DloZJtvLvQyAx/DUM /gAAAP//AwBQSwMEFAAGAAgAAAAhADBHhy9UBAAALA4AACEAAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0MS54bWy8V0uO4zYQ3QfIHQhlrba+liy0PfA3WXS6G+OeA7Al2hZCfUJSHjtBgLlQ Vlkl27nJnCRFUrTcsQM4znRvbFkuPrLeq3ol3b7bFRRtCeN5VQ4t98axECnTKsvL9dD68LSwYwtx gcsM06okQ2tPuPVu9O03t3XCaXaH91UjEGCUPMFDayNEnfR6PN2QAvObqiYl/LeqWIEF/GTrXsbw R8AuaM9znH6vwHlptevZJeur1SpPyaxKm4KUQoMwQrGA8/NNXnODVl+CVjPCAUatfnkksa8hW5EL SiykwtgWbrjWCDJPlzRDJS7gxizHdcVzkW8xyggSn38XDa1UFK+fGCEyvtx+z+pl/cjU4vvtI0N5 JsFaEKvX/tGGqZ8lhMFF7x/L1wYJJ7sVK0a3OAFO0G5ogXR7+QmLcEJ2AqX6ZtrdTTcPZ2LTzfxM dM9sACc4bAqq1zqj03Q8k46LnloaTF46GMPiuyr9iaOygkwlATrB9H5r4GTWcoN6g7QEqWBPSgXD hfxfkWKWcEWsOe2Bjn4cxo7mxHN9J/DCl8xEUeQFMkDy4waR4+iI47w1dJ2I3aTK9pLXZ/hWuuCE crEUe0oU38AKTuBk8AHqUizbh3B7voT2KcSUEgzt1WojRj/gNUYpzVNUY4ZRAf0GZY0ZIhQRLnJa HRUTXFKIE+zzH+UtnE5A/u1epMweAeB9t2Vpf1gqVnECRwKezNHhUkv37wL6RkAPLZtnU8pfQUPe PGsNoeyhJo3sWutLtHT9yO23Yvpx3AfveClmH5RUaisxo9CT0bJiTFmo9HVpGUbOiikVpFvqQk2h ArM71VZ5mYFLqEtM1yAkFKWlqqG5B1dUBZCRFcigt2wBWiyvwwrCSB4dXQEoUVpAvwMcuIGq4SsA JUoLGHSAB6avQJQwLWJ4hBh7sZLmCkQJ0yL2O0TPi0He62iUMC1idIQYBf61wkiYFjHuECXctcpI mBZxcITYDyPVA1fwKGFUMxjPkvCvYVnQ6a1vvJlrBca13pMUHlTWlKBAtj6MaTNWzgweGEHTDUST MWPVxw3BGe+M6bBQzl7J3NE8ygQ4+i/wcIHpChpZ+Zm2GhN81tBoKa1BerDGu9SEpFBnrQWc7UTM FTyWyAeLX+NoPJ5Mvak9nQSeHcwmjj2J5wvbWUTuYjybx9F88JvVTtgMCyLygizydcPIQyMsuWk3 xjJiz+babuHwyuzEyHdunOjGc1y/G0mwvVx5MpQ0AMpyJsyjCJz+P4+n8FRoNdJfSegVeLxS+ucG M0Hghxb7gun1JmKf0EzU7P/fNPdPae6/Yj/BW8R9U5xl2pPbqm5S7iX7a9m2j24jaIE3bav5fDqP /MHAjqMwtIPAX9iD6cSznclk7EaLcRQOFoe24jSHpwZI7YJu+vLpz+++fPrrq7aSMhv9BgKX8pVF eSJlP+L6YQumhhN4R4PCnqpbNbyVabrTLkRimLe80d8AAAD//wMAUEsDBBQABgAIAAAAIQDqKxSi mgIAAF0GAAAfAAAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGU0LnhtbJxV227aMBi+n7R3sHyf BihQGhGqcug0qWtRaR/Asw2J6tiebShs2rvvt01AULai3RDH+U/fwaZ/s64EWnFjSyVz3LxoYMQl VayUixy/PN8lPYysI5IRoSTP8YZbfDP4/KmvM6kctwjypc1IjgvndJamlha8IvZCaS7h21yZijh4 NYuUGfIGdSuRthqNblqRUuJtvjknX83nJeVjRZcVly4WMVwQB7PbotS2rqbPqaYNt1AmZB+MNABs dCaYf1r9bDj3K7n6YvRMT034/LCaGlQyYAwjSSogBqfbD9uw8CohDBbpUfqirkSy9dxUgz7JABta 5xjo3/hfSCIZXztE4ybd79Li8UQsLSYnotO6AUywa+pRRUQn4Fy3O6B4hPTEKSi/EBxd7dDFFAIl 7hV9tUgqwBtpUKMCovmtMeqt4IRZvx3R04dV3ctT4rvrArmNBuKsYA/LClz2M8c/lsQ4bjBQC7g7 2+yYEkisq9ggBAEP3pVCxCZxT2duPVRs4wn8Ds8gAMmEdTO3ETwQC/BJNhcsKPirNew2W81OJ2k0 mtdJu9mYJL3e5VUyGrbGt53hpNtrT37j3bQl4xLm9SUMmEAA5hwznownUTWYLDRxg24f+Hcgf2gW FJVsSgx5OspDrDSuVhiiYT5AW+OAZRTs37Jdv5et5ScCM9fsn5btSblDAa0G4Q+3DjQF0Z/BmxNW hqjI/q6J9/p7ib9Wi4/VFDLWikqeh7sLR+bYrpdn4f4/u3pPbf1Zu/scf4IDD8Dt5f3ApmAnxMm9 HJrXIIk/Y3CJTpcyahS8xo99xWXyMsN7XyFbuZHgBO74cLn8zWSB83jlwbK+Bakw34h+XMHBJRlc 7nBER2FLwyRb+fchkBj+GgZ/AAAA//8DAFBLAwQUAAYACAAAACEAdTB9pJYCAABdBgAAHwAAAHBw dC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlMi54bWycVdtu2jAYvp+0d7B8n4aGYyNCtVCYJnUtKu0D eLYhUR3bsw2FTnv3/bEJiJataDfEcf7Td7AZXm8qgdbc2FLJDF9etDDikipWymWGnx6n0QAj64hk RCjJM7zlFl+PPn8a6lQqxy2CfGlTkuHCOZ3GsaUFr4i9UJpL+LZQpiIOXs0yZoa8QN1KxEmr1Ysr Ukq8yzfn5KvFoqT8RtFVxaULRQwXxMHstii1barpc6ppwy2U8dlHI40AG50LVj+tfjSc1yu5/mr0 XM+M/3y3nhlUMmAMI0kqIAbHuw+7MP8qIQwW8Zv0ZVOJpJuFqUZDkgI2tMkw0L+tfyGJpHzjEA2b 9LBLi/sTsbSYnIiOmwYwwb5pjSogOgGn3b7sNJAeOAXll4Kj/h5dSCFQ4lbRZ4ukAryBBjUuIJp/ MUa9FJwwW28H9PRu3fSqKam76wK5rQbirGB3qwpc9prhnytiHDcYqAXc3V12SPEkNlWsF4KAB6el EKFJ2NOp2+SKbWsCf8DTC0BSYd3cbQX3xAJ8ki4E8wr+6if9fJxfdaPOpN2JOkm/HQ0m016UJ8lg kFz18lY++I3305aMS5i3LmHABAIwZ5jx6GYSVIPJfBM3SobAvwP5fTOvqGQzYsjDmzzESuMahSEa 5gO0DQ5YBsH+LVv3vWxJPRGYuWH/tGwPyh0LaDUIf7x1pCmI/gjenLDSRwX2901qr7+X+Fu1/FhN IUOtoOSZuHvvcbfPwv1/dq09tfNn4+5z/AkOPAJ3kPcDm4KdECe3MjfPXpL6jMElOlvJoJH3Gn/r Ky6jpzk++ArZyo0FJ3DH+8vlbybznIcrD5bNLUiF+U70/RoOLknhcocjOvZbGibZyX8IgUT/1zD6 AwAA//8DAFBLAwQUAAYACAAAACEApGRwnpoCAABdBgAAHwAAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rl c1NsaWRlMy54bWycVdtu2jAYvp+0d7B8nwYoUBoRqnLoNKlrUWkfwLMNierYnm0obNq777dNQFC2 ot0Qx/lP38Gmf7OuBFpxY0slc9y8aGDEJVWslIscvzzfJT2MrCOSEaEkz/GGW3wz+PyprzOpHLcI 8qXNSI4L53SWppYWvCL2Qmku4dtcmYo4eDWLlBnyBnUrkbYajW5akVLibb45J1/N5yXlY0WXFZcu FjFcEAez26LUtq6mz6mmDbdQJmQfjDQAbHQmmH9a/Ww49yu5+mL0TE9N+PywmhpUMmAMI0kqIAan 2w/bsPAqIQwW6VH6oq5EsvXcVIM+yQAbWucY6N/4X0giGV87ROMm3e/S4vFELC0mJ6LTugFMsGvq UUVEJ+BctzugeIT0xCkovxAcXe3QxRQCJe4VfbVIKsAbaVCjAqL5rTHqreCEWb8d0dOHVd3LU+K7 6wK5jQbirGAPywpc9jPHP5bEOG4wUAu4O9vsmBJIrKvYIAQBD96VQsQmcU9nbj1UbOMJ/A7PIADJ hHUztxE8EAvwSTYXLCj4qzXsNlvNTidpNJrXSbvZmCS93uVVMhq2xred4aTba09+4920JeMS5vUl DJhAAOYcM56MJ1E1mCw0cYNOH/h3IH9oFhSVbEoMeTrKQ6w0rlYYomE+QFvjgGUU7N+yXb+XreUn AjPX7J+W7Um5QwGtBuEPtw40BdGfwZsTVoaoyP6uiff6e4m/VouP1RQy1opKnoe7C0fm2K6XZ+H+ P7t6T239Wbv7HH+CAw/A7eX9wKZgJ8TJvRya1yCJP2NwiU6XMmoUvMaPfcVl8jLDe18hW7mR4ATu +HC5/M1kgfN45cGyvgWpMN+IflzBwSUZXO5wREdhS8MkW/n3IZAY/hoGfwAAAP//AwBQSwMEFAAG AAgAAAAhAKug24orCwAAZkIAABQAAABwcHQvdGhlbWUvdGhlbWUxLnhtbOxb64+bSBL/ftL9D4jv 2cHGYBjFWfG8PSm7F2XmtJ/bGNtkMFiAk0n++q2q7sa0sbFnx/u4iz3STNOU+1FVv3p1z9sfnze5 9jmt6qwsZvroB0PX0iIpF1mxmun/fYzfOLpWN6xYsLws0pn+Na31H9/98x9v2X2zTjepBt8v6ns2 09dNs72/u6sT6Gb1D+U2LeDdsqw2rIHHanW3qNgXGHeT340Nw77bsKzQtYJtYNgwXbJd3mhhWmer Qn8nh49ymKNoauxI8uoBB0+Pfkcb0bcWTyOkravVPMgr7TPLZ7pBH/3u3ds7di8I8qZPF9NH0AmC xdP43HhEkDd9OsfAn3Y8ImBJAvvpz+37kRGZgrZDxJv9sU34uK5C3xnf7K1Z2RsflIh4c9KjV3jW IeJNq0cfelEYxcp6iIjT2z36cTgOHU+hJ6J1nhVPPWrDcOEjqFuSZZn/dJTcdYPAkIzfU4H0Wx3C KZZl0QxolI40G/aprGIgxIecNVmhNV+3oK0JaK1XZSzHVbH7lHX6eVdSH3TB/Mpwm6y46tj74WCm /eZoqxt1p/9ZLrMkpR0uszx/aL7m6fuaNlmXebaIoRO/R2hOWyRt19AUYlDoVhWj72hV2fyaNeuH NdsCgzgmV7UYelVr27IGQNLER8fGSYHJDUeuhWrIuVmz5udywbvNLqDbYQjeKzIVciITB7h0MnP6 uslGfFUn2aZubURLI91RttZuGWTY3xp0ttwE1dcYmumRDfYU167VCcvTBfKdGzspFpxatq8ionrN FqmQEe67L6MRCUnqCtlt0J0jMnJo6YNc68zm4rCvmO0SIXWnm5yYTkrvNVKSFkpKhphzCMe86IIz L7QvM921xpauJWw705dgk6C52YLU62KlayxfgSNPmoqr/VkwE+P30nTlxkD7OogbGbK/t2HFDmyr uglZveaqQa+ECuQFzsTXP7aArdfaANf037EK0wFl+MtWAXxURZsul2nSdIXd6UHe8UdhSstdk1YP 68UXbZ7vqo8MxI+qCvtZZHUz08ki4EM105Hb9Eo1zsIwHomUcDaWb9dMmFuEqEQyJydVbddAT53l wd6Orp029/KtEOSvtJWuGn9nW0F/khapuUAJJBB2V0xDvM70smrWJVih7TpL4gqCHbIdoC0aWBd0 1xoE//S3Sj/jX445PgaOlmerdfMxW2lVBv6oWVdp+gHMEmnfmcFGwnfxIeVApFGd5dZbvux5+jnN H9EG2ujbdW0Nqk7WRJgBojvUP/VZIGi+wiCnizfFhrS+l2Pgz458OJhhU6odpoBG8r9dInFLjXz4 9+nr0vd2N4Iv9mHWRKICJuu4AlfA/ncu4YWullus3o7HllwcSLG/Y+hsA6Ita9Ya/gL/l1VJvo9v H8uPYFs1yAVxMFAb0Oo3PPDQ0EDyzjkETryTKxMOxVkrolvkmnTWVwmj9iJo5z1gNq7sEnm/kNlt cKZOp2DxmswWHFZ4zftOshokewhR6FrKRIYEQyWIbo2gnH8CQYtqAqUC9RaeCAfbD5U2/wJJBCQm bNeUZOSel9UG35bLpfZMJu6rMHDgw54bLYHOEQQJ0CuDavmVZFc3/0pL+jr7DFaFdHe1kC22lq3k uZDNSugh10H4DSyB36B6JGV2j0rHiWG33SmGrBPPsuUCFcprRozN89EpTgR97L4qd8WCuLJO2SIq FpQQz/QCSkk6GvFNugDfkoJvwRZRNizLL6EE7vCQso07uCbVIGYU6LxcfAWBQ2kLsL4uq28wIXg4 OXn+7wISUbRwKAl6mJig/iCQ7pt5902x2wQl2BDQB1YkMCaPs8VD0HBRJuUGZPi+eNgmSIprQQY9 Pv/Kqq1wuA2o1i/lAybJRCDVBza1p+VK64GmxhnqFrzkm8IXec1DRWwv0uUH2OqGVe9JmaDxkRpZ sYBiEzV5WpCDT06Xj2z+8A02P5qAl4ANN1gjg7ofe1/41RPtD6sHHmUSc1aDrKjyIV4D6RryTqjk fdgVCQzPNwnR7Dbha04+gLGl0pswS3z1XQpfgnJP25q5bbJ/6y15UWJ7lE68ne8gtXx8Jv2Z7x6+ tU0s3LQPv4DWEUnD5hKOwI2PwLqn3SbblJ8y4kNOSfUifRNGkFEDo9ApCIhqnGQn1ahuquwJ7ElR PlBLpBNcwaG6s2F59i39icZFTkLODtQwWr1pgjxlFFWRPCk9KkDUeS65RcwcSOBOwLELCFCUozUr LVmzqk5JN/h0nBOkZVyfqLlXM9C+1pTmRSjFd7Opr8zCTwjxZlPRwN5s6s2mgvehStf/p00VphSs az90hSChYuDZHiiDA5eFDkHtxJ5EUtzOxWb67VwMj35edy4GCvUz22rz1WimwzEoxMfP0IKDUwiC VmPsG2MftOB0FGJhfqQJSRVvyB54z3taGlP2mJJmInsmsseSPZbssWWPDYEnnvdBPI9/dE1uFMrg YsuiMtUHSb/nDGzGFJj/nY6TXRt/xA7FebNgOUWK3UJu7Iex9YLj5Dh2XVuOLaSGg/ImnRQrR+p/ 9HFyHEaBr65/8Dg5mjqeFQje8EUPHCcHgQkFEEF9yXGybbfkUtMoPG51SNjhG2zMvx1sXnILAy8O xOotBrqq0UGEAoMAPgf0478SNoEXjQ/WMwgb3/XdaHopbNC3BhJk52Hjxfa0XcwNNoOXlyavhg3c vrFjWZ67wuWlF3mb7sUpjpVB2DhhYLea0cEWb/a9TRTEXqyqKRFx+knP+2FVrzXYHSLe7F9eOuLN BmEzjX3zctjAXTf7BbAxDA/rTbwqc4PNIGysV8MGRR/Km2VXgM2UPkJ654I0nFxV60HYoPVtFYnr 8llvE8m9cfrrw8ZTvMcgbMYh+huFfiBIi2MLLp0I6vPeBiPYG2zgdqwIRXnR4HhJwB6AjeVZjmD6 Va7Kdq7Airu0x67KIhLaC55nYAP2dGKPFTUahI0d2nGgwmwQNp4XGIFUvAtgE3r4o6yHXNIpb+N5 vuOr6xmEjT22J/5EGX8ANoaBvBTU52GD5C+EDSX9VBKg4gCVBKg4QCUBEJ5M3KFowHmAB2ZUG/jf LglMT8LGCkZ7Ll4BNnQbQKrgAGzCOBy7Mk0+Axsl6RVy2ecqhAglt/GjqWvLNQjx7en7QVpgePBR 1HTQ27wUNtEYUKaOPwgbL7BDSy1pDMBGMUDnYROa3ngkXdllQdp3CxvnJGwMwzTbqtMVYINRf+tF BmCDSXtrI8/ABld4EHQNehvD8A9zjzPeBvyNqtZXhY0X+k6kestB2AAH96aMw34ANsiblpPnYRPH 0dQYCRtxg81gbuOehA2qZEfNSR1F6qJYcFTyVjhXyG0iM/I7JYaOWtMSlLkR2u0aL/A2E9vxJr7i PTrj970N+poDb3Bd2HheeADLQdiY8TScSE98ddgYEVyWu8EmvSC3GfFr7cKbKDqp5OZXcDe2Y/tW KMQy4G7CUTgKpG6fcTeu4RqOaq4H3Y1juJEnE7YLojTIwD1fjYquipvAhh9p4fl6BnEzNZ3YVdc/ 4G7iOAjagOG8u4ncMGgLDjd3M+huRqf/f9YEw98erl0DN7biv8jOC1goeD3wXx1/0Pc3tmG5U4mx C/wNLMFufeMluHF858AfXBU3PpgSX6btF+DGCqzg8hK0cq51HjfI+NZ533AzjJvTFwXgf5yNkdX6 h1fHadbYjMbSdg/5mzgwHOmXzvgbJ5j6UxlaXIAbJ7bisaqnHVz24zTf9GJPnhny8a+KmwBQ46u4 H/Q3zsiyxmq6NeBvgsDHK9L8LOY8bpwAnLEk/55wA9fX1As2dFkNeukfNN79BgAA//8DAFBLAwQU AAYACAAAACEATqGqTIEGAAD4IgAAIQAAAHBwdC9ub3Rlc01hc3RlcnMvbm90ZXNNYXN0ZXIxLnht bOxa627bNhT+P2DvIGg/Bze2LMsXxCmSNO0KpF1Qp9hvWqJsIRSpkcytw4C+1vY4fZJ9h5R8SYLA c9JdUDeATZGHpM7Hc/l43P2XN6UIrrg2hZLjsPOiHQZcpior5Gwcfjx/3RqEgbFMZkwoycfhLTfh y4Pvv9uvRlJZbt4xY7kOsIo0IzYO59ZWo709k855ycwLVXGJsVzpklk86tleptk1Vi/FXtRuJ3sl K2RYz9ebzFd5XqT8lUovSy6tX0RzwSw0MPOiMs1q1SarVZobLONmr73SATRMJyKj7+nMf57pg302 MkoU2etCCPdAivJjoYMrJsbhdNYJ9w729+5I8TznqT01lsZoPVrJNWhhU51rzqklr97oalLRKHZ/ f3WmgyLDsYSBZCXQp7XdQC3mHiXE/Lpr02fNSmx0k+uSXhbQBTfjEGd8S5+YxEb8xgap70yXven8 5wdk0/nJA9JQ1m8AhRabklZeo/vq9DpR1Gj0AbgwORM8iBbK+RmAsDpV6YUJpIK6HgV1PIc0P9Ra Xc85ywx1e+UBV7MVIUKbV/PA3lbAbZ5pmPGncfjrJdOw13qKl8Nry8VUA/CD6fU7lWEau7QqJJA2 ATAa9juDNrAlGONeH9bttlnOrrSxb7gqA2qMQw3V3ersqrYMNmpEaFOpyMjcIQkZXI/DYS/quQkr I2VB7ieKchxic/yjPdmIsDmRmWtbVgjfxkkJ6Q593R5JacLL3hyp7JYEpvgGEAgMeNG50p/C4Foz HIIhBHkYiLcS2A87cQyNrXtwOoeBXh2Zro7Iy/JYwUlgzkymWHUc2qZ5bPFE4KmyYvZUTqqUBOld CJPzm1+YrmrgLGz2vZrMWcUfws/LOif0atAiwtiJvRXwMrSvRMdpzEYZzz9ATzKNzvLAFgIE2MpE WDQcRmZnTDOaJmCL45DL1sdJGGSFto0DYR5kYVgNomh6f3jUK7r3vaJL5+lc/vm9IgP6RQbfb1xo W3/oDgZx0sHbN/ovw8rOKygS/I+8ImBiBiagnWf9h9yj04kScBGfB5dZI97IPz4ohDHKok3+MBWC 73rXWkqB5DmizElWOCn4IDz4sQxjRPa2nNX+5FIZJmzrT51O3KVQTv6UDHqUVVwkb3K1zy4ULSHQ jaNhHfcXmXiZSJ6ca9bZjp5NF1yHss0ix62JbZOUXISsadEGobJ33xR6G5nCdgSCEsk6g/CR04Xn J5x0fbp00HEXf3dPuhcPEur0pAJ2UdvC1zjpHavYmlU473TsgOgj6MOCXoNXsZFecIWMt16dUBw6 00rljvGY0h4LzhBzay+3B8eiSC8CqwKO+BPUVyxiPbiKgcMYul9YR3CwvOcajnDgo9nepXTsvM32 E54qmQWCX3GxwVYu2m251fm80Jvv5Lxty51eq0tt5xsr5fLKtlsV+SM7IVr8PVaY3A91yVcMdbm9 c1fykc4B8oRI57PZAAEvAlNcS2c7jrgFR5zubk5NeQT1hP59H+l/RR8B23t/WT5ECBwJeYKbrF6l ds7yXGWGf9NZnnqhykXmioC/Je24PTw8SVrD3mHciqPuUevoJE5ar9Db7idJ1OsPf0cxxlW8DGqU HAUXd427yz88XXFVQyISXz7/8cOXz38uUz22fLDSUbOXTSodcIGmrIlmU0hNhX7HqgBV0nEoLC5k 9gat7AKt6Syivoj60Mou0GJpitosJOpG04Nx37OQ6TY9KEL4objpiZueXtODu4OXSZoepNi5KOQF al30FQa5Ej/5jqblo4mred8tJNUnLHDLt475BZydyiON5ZD1ciXtobtTT5lB5YwKmKh/n11KuoG2 3QGZKj3iOWGO1llqfTGZ7oBNDXFN4jAH+1uXXZGrR+/e3YMLrqnET2UuN/uRMjaOhfQFtVy711GR XToDy1mK+uihLhi0TudMG+6U8Xmdrcj8WMoWZz7hp+bOQGrqbfzLuh0XxTdXqIuI0ZZMny5qqju0 nxltgpgMAsB3l2i70i7M15eDdrbdlGCeatsEcY12vES70+13Errn7+B+3lBCGNdw91bgHkQD91vN Du7nhZswruFOlnBH0QDGvWrdiPfnbDrBzy5NnLmXOsEJXL5ZZtL1zOl/HPoHshxlMGF9BuNPdX9C pQaovwJQP+5SXl66/zcLEKFSAzRYAkTouDrowmG/WYAIlRqg4QpASa+/nkC+WYAIFTDJ+j+o1GS9 efTF1IO/AAAA//8DAFBLAwQUAAYACAAAACEAtM9YGbsAAAAkAQAALAAAAHBwdC9ub3Rlc01hc3Rl cnMvX3JlbHMvbm90ZXNNYXN0ZXIxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7S9iAiTXoRoVepHxDS bRpsk5BEsX9voBcLgpeFmWXfzNbNe57IC0M0znIoaQEErXK9sZrDvbseTkBikraXk7PIYcEIjdjv 6htOMuWjOBofSabYyGFMyZ8Zi2rEWUbqPNq8GVyYZcoyaOalekiNrCqKIwvfDBAbJml7DqHtSyDd 4nPyf7YbBqPw4tRzRpt+RLCUe2EGyqAxcaB0ddZZ0dwVmKjZ5jfxAQAA//8DAFBLAwQKAAAAAAAA ACEAbKM0qABUAAAAVAAAFwAAAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVn/9j/4AAQSkZJRgABAQEA YABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCADAAQADASIAAhEBAxEB/8QAHwAAAQUB AQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEG E1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLD xMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAA AAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKR obHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK/NZPj t+1p+018WPjb4O/ZE1b9n/4L/Cj9nL4hX3wb8V/Gz9oH4U/EH9oi9+Lvxi0fRvD+seNvCvw2+FXw 3+PH7NMHhHwV8MW1+28Oa58SfEfxU8U6p4m8f23ibwhY/DLw/p/hH/hLvEkqTlV9hTjKrWWHrYyc IOKdPB4ethcPiMVUlOUIQoUq+OwdBycuadfFYbD0Y1MRXo0p00o0/a1Jxp0nWp4aM581qmKrUsRW o4anGEZTqV6tLCYmqoRi1Chh8Riazp4bD161P9KaK/F347/tu/tv/BD9i34o+N/HHwh+Evw6/aj+ GH7UvwD/AGZbDxbrXhf4heM/2aPjBofxi+LfwT8BQ/tD/DTwcnjv4dfEP/hEL7RPitqMg+HOo/E+ fUvBfj/wrrfg29+IXjPTtLj8Uaz95/CHwf8Aty6L4ygvvj3+0V+yh8Svh6un38dz4X+EP7GPxf8A gh4yl1WSNRpl7B478Z/t5/tB6Jb6fZyh3v8ATJPhzc3Ooxssdvq2lMhlfSmlVg60JxeH5qcaWIan GFZ1spy3OqKjScViqM6mAzfLpSpYrD4eth6+IlhsXTw9fD4qnQid4JKUX7XnqwnRTi50/Y47EZfV k6nN9Xq044nCYrlq4avXp16VH2+GlWo1sPOt9X0V+L//AATw/wCCnfj/APar+JH7b3wW+NPw68Pf Dv4g/s/fGr9oW0+Aeq+HtP1ay8H/ABw/Z2+EXxV8TfBweKrVtV8VeI7288feAPH3hWXw/wDF+ytb nRLS0XxV4A1zTdC0nTPFtgh88sP+CiX7WvxL/Y4/4JI/FP4dj9nTwD8a/wDgon8T/BHgDx/rfjT4 S/Ev4l/C34f23iH4J/GH4palqXg/4b6H+0F8K/Ft5OupfDfTdMsYNa+LtzHb2OoXslxJeXCwNHlS n9Yo5fXoRdanmkOEp4GUHDlxH+umIxGDyaEKkpRpcyxmFxODx96ijgMVh61CvJVKVSMdalN0a2aU KzjSqZNPiKGYxnzN0P8AVfC/Xczm4wjKcoywTp4vB8sXLF4etQqUotVY3/eOivlr4W6N+2D4Ng8a 6x+0V8b/ANmv4taXbeGri68KaZ8Fv2Vfih+z9f6Xrdik91Pd+IdX8c/tlftLW/iPS7i3jS3i0vTd G8K3dtNuuX1m5Qi0X8g/CX7cH/BTJv8AgmN4e/4KmeI/iH+wl4i8F2PwH0/9p7xv+zbpH7J/x4+H /ibU/h5o4j8Q+O/AXhX9oPV/28fH+iaJ40k8G2WtQeEPFmsfAbXdGm8Uf2VFqfhL7BcT+U/aUk8Q 51YUqODp4KrjsTU51RwcMwqZlDDutaEqklyZVja9WdCnWhSo04upJVJqmFOjWrSo06NKVSvia88P hMPFw9ri6lOOF5lSbkqUf3mMoUY+3qUZSqybjF0ouov6IaK+AP21f2rvH3wi+BPwtvv2ddD8I+IP 2lP2n/iB8NvhT+zT4L+KVjq03hi88V+NraTxj4k1nxxoWi+JPCPiWfw/8OvhL4f8d+OfEdppOvaX ehvDsOnyX1kLs3EfEeL/ANvu91f/AIJN/EL/AIKJfB/Q9CPi3QP2RfiB8ddJ8D+ObW/vtI8OfFHw B4H1vUfEnw18eaZoWvaVqpm8F/EHQNY8FeMNK07xJp2ow3uj6lZw6rbXKC5SMXVjgsLnWMxMZU6P D9aWHzJSSVWniKeDqY+tRo0pNVMQ8Pho054idGM6NGeJwtGdRVaygjBU3mOIybDYSUatTPqdKtl7 u1CVDEYmGEwtatJq2Hp4yu8RDCe15Z1/qGYShFrB1mv02orzLwf401TxB8GvC3xDvbewi1rW/hlo njS7tbWK4TS49U1Lwra65Pb28Et1NdpYJdzPHFFJey3C24VHupJQZj+XXwT/AGlv20v2h/2Ef2ef 25U/aN/Yf/Zd8HeLf2ZtI+Mfxxi+LP7JXxi+K3hjwxq0NtrOu+LfFGj+MNO/b4+BUXhL4f6b4fgs tmh+IdN8V6rp82nalqd14zvoNRt9M0rfGweX4jNcPinCm8krUaWZ1ZVKcKGGVd5uoVZVak4RdGMs kxqqVI39mvZTklTnKcMcDJZjh8BiMKp1FmdJVcBSVOpKviW1gXGjClThN+2lHMKEowk1zWnCLdRQ hP8AZKiv5+LD9v7/AIKGaF/wTCvv2zPiJon7M+k/Ev4rftHfBTwh+y+bn4DfGPwb4fuP2afjp+0B 8Mfg38Pvi18aPgdqv7TXiLxdo3j3xj4W8Yan8VdN+H2ifHW1g0HQtV8HaNr2r/24niC0tv1Y+EPg /wDbl0XxlBffHv8AaK/ZQ+JXw9XT7+O58L/CH9jH4v8AwQ8ZS6rJGo0y9g8d+M/28/2g9Et9Ps5Q 73+mSfDm5udRjZY7fVtKZDK9ujOMq8aidH6vXeEre2hUpTp42GW5fmlbBVcPOCxVDFYejmmDw+Jp YihS9hjJVcPVcZYeu6aVSEqdOpTlGtGq5ypujOnVp1KEMbiMDHGUcRCbwuJwdeeFr18LiMNXrU8V hI08Th3Up18O6v1fRX4sfs8/HX/gp1+1T4Q+P3xX+F/xO/YV8M6P8Mv2nf2qvgh4A+DPjX9lP4+a hrXi7T/2evi74u+HXhqy8U/H/R/237LTPC+p+PLfw3ZrrHjPTf2dvEdl4PudSn1e1+H/AIpgsE0G 97bw/wDt1/tCftXfD39j66/Y2+FGneAvEX7R9v8AF+++M3xV+Onw58efGL4Ofsiah+zzqieCfij8 MPGmmfDTxj8IIviD8Utb+Lq6p8N/hzp4+Lfw00rXNN8L+M/iJDc6laeH4PCmsYUpOtQwVanGTePw mVY+hQk406rwWcYD+1MFim6ko0JUlgFPEYxUq1Spl8VTp46nh62MwFPFbVYexr4uhUlGKweLzXL6 tZXlSePybEV8LjcHHlTq+3dfD1aeDjOlBZi4VZYCWJhhsXLD/rjRXwr+wz+0x8Rfj3YftFfD74z6 P4KtfjT+yZ+0T4j/AGc/iV4m+F1nrmm/Cr4jX1h4L8CfE3wx4+8C6H4l1vxXr/g2HXPA3xK8Mp4l +HuteMfGmpeBvF1prmhnxf4m0+LTtcv/AM/fC/7Yn/BRPx9+z3+2J+1zovxa/YO8E/DX9mD4z/to eEdM+E3j39l745Nq/iTwV+yX8RfHPhi2h8TftEWn7cel6B4U1vxxong1Re+L7f8AZ+1nSfC2p6ib +PwVr9pajSriK1ejQSq1KlsL/q/Dip4xU60qUeH6kcmq0cx9jGm8bJVqOf5XWhhIYWWYKFeUKmEh Wo1aULpYevWap06TeKeef6tRwnPSVaeef8K0ZYCNR1FhE4VMjzGnLFSxMcC5UYyhip0q1KpP97KK +Eta/wCChXwM+Hvw/wDgh4i+Mem/FfwX8R/jP8F9E+Nx+AvgH4GfHb9pL4x+APCl3ouhah4k1Lx3 4B/Zy+F/xM8Y+F/C/g7Wtet/CWr+O/E/hvw/4TbxKjaOmoR6sW06O341/wCCkX7FvgPQv2f/ABDq nxpj8QWP7Vng3xB48/Zrtfhl4A+Kfxj8QfHLw/4WtfCN/r0fwx8KfCTwR428UeLvEljp/jjw/qQ8 E6Ro9z41u9N/tzULLw/c2XhPxZPonTXpyw9fEYeq6aq4TGyy7EKFWlWhTx0JYyDwvtaM50pVnLLs fyRhOXtFgsVKnzRw9Vx5cNVhi6eFq4fmqRxuE+v4VezqQqVsGqGHxM8TCjUjGt7Knh8XhataUoL2 MMTQlV5Pawv9xUV8g+E/29f2TfF/wV+LX7QcHxah8J/C74Cajr2jfHC/+LHgz4ifBLxd8INc8OWN hqeoaD8S/hb8YvCPgX4p+CNeuNM1bRdR0HQ/EfgzTtV8VWGu6BeeGLPWLfXdIkvfgXxX/wAFovgf of7W/gv4ZNrGseEPgHpX7Lnxw+O3x8vvi/8Asy/tVfCT4+/Dy+8G/EP9n/wd8LtftvhT8TfAXgf4 jJ8IvGFt8VPFzTeNx8H9f8M6ze+EtYl0fxrp9v4B8eQWqpU51sXQwVOLeIxOFqY2nFppLBwyfH55 SxU3b3MPjMvy7ETwNZr2eMqOjToSm6sWXUlGnhquLm0qNGvHCylde9iv7UwGT1sNTX26+Ex2ZYWn jaMW6mFjKUq0Yctn+3FFeDt+038Ck+PetfsxP8QtPj+OHh34N2/7QGueDJNM1+OHS/hFc+JJ/CUX i278VvpK+C48a5bvDNoP/CRHxNbWL22t3OjRaJeWmoz/ADN8Iv8Ago3+y98SPB37R3x5g/ac+HWp /s8fBnw38JviHqWual8IPiz8Grv4VfD/AOJ3we8N/FLw1qHjnxX8UtRW2+Kc/wARdD8Qab4y8FT+ BfAvgubTNI8QaH4GvND8Q+LQNR1HJSi6datzRVDD4aeLrV7r2NLD08bWy6dWrUTcadJY3C43CutU 5aEcTgMZhp1Y4mi6L0p051akaNKEqlapOnTp0YRlOrUqVaWGr0qcKcU5SnUoY3B16cUuadHF4apF OFek5/ojRX80v7c//Bwb4Z/Zx+LngPwh8GfAHivx5omt/B7xN4l8ZeCfij+yx+2T8Kfjj4S8Zaj8 dv2aPhZ8MvFd/wDDvxn8MfCXj7S/g3q3hr4u/EbWtK8Sat8MI/DPxf8AHngWy+Evw9+KOmeO5bnR 5/sHwf8A8FePhxp37TH7a3wi+MOn+PLTwj8A7z4A638MdN+FP7I/7YHxS+Mlj8M/in+zh4H+MXiT xj+0L8Pfhr8NviT4y+FVnpviXxNqWiadf/EH4f8AwmtdOXSr/wAM6rbXvijw/r729Q9+hTxN1TpV IZnJOq/ZSjLKsyp5Ziqc4VOWSqSqVYYrDaOOJwKqYmlKUaFdUlGLqVqtCmvazpQwtT901UVSnjMJ gMZSnScL+0hGGZYSjVnFctPFVPq7ftLJ/szRXJ+A/Hngr4peCvCnxI+G/ivQPHPgDxzoGl+KvBvj LwrqlnrfhzxP4c1uziv9I1vRNXsJZ7PUNN1CzniuLW6t5XjkjcEHOQOsq6lOpRqTpVYTpVaU5U6l OpGUKlOpCTjOE4SSlCcJJxlGSUoyTTSaMqdSFWEKtKcKlKpCNSnUpyU4VITSlCcJxbjKEotSjKLa kmmm0woooqCwooooAK/EnwdE/wCxLr/7Y/wA+Pnwh/ao1n9n79p74/8Axu/aO+En7QH7IPwz/af+ LerNbfH640TxB8SPhZ4sk/YzsfGH7TXwG+LHg7xvqPijUPCvxC0/QPCfgTXPBc+h3ng74m2XjzTd b8J6V+21FZ+z5a068VCUq2XYvKcRTrQdWjWy/G4vLcdiKUqfPC1T61lGArUqqleEqLpVI1sNXxGH rW581KFGTqKNHHYbM6EqVT2VSlj8HhcwweHrRnyzUorDZpjqFSnKElKniJTpSo4qnhsVQ/kv+N3w B+O/jX9iL9uvVNS+DP7cfjr9mD4p/tm/sA+KP2bv2dP2oNW/aK/bA/aLn/Zz+GHxM/Z5uPj94pv/ AIKfETxp+0Z8fPD/AIG8d6tpfxE8bJ8JvHlvYfFGLwrb3q+OfhL4KYWmgV+uH7Ilr/wTC8LfGOxT 9kz9gnVf2cPiv4i0LW9DX4h6d/wR7/aa/Y5tG8OpBHrmr6Drfxv8cfsf/CDwfpGmak+i2csei694 3sYNe1az0uxsbS/1c6dbP+sFFb0J+wU4J1HCUqbVX2jWOqKlkGUcPx+t4vlaxMq1DJqOJxbVCjGt iMXj+SFGlXp06OdW9WlRg1TjKkpe6qf+yqUsdiMe50cNzc1Oaq4mcY1J161Vqlh51alWtTqVK380 fgz9kr9oq0/ZC+Lfxw+FXwt8S6B+2X+zB/wUT/4KKftA/AHwd4z8Pal4M1X45/CX4k/Hv4jjx/8A BJLrX9Nt7lvh/wDtSfCK+iHgzxHFaahoP/Cb6d8KfiVpqahJ4U0m5TxG7+AOpL/wTA/4IFeEf2mf 2SPix8SfA/wd+MPwr1v9qb4E6p+yT8WP2iPEHgnwtafs1ftA6Hc/8LS/Z18K/C34g+Op9P0nxnrv hfT7y11T4eXP9n6zeaW9zbW03lOn9ZVFc2HpfVcNgsNBxqU8DPw9rUo14e1g6vh/ShToqSclNYXN /ZUqmMwVOpDC0K7xWKwtOnisxx9fE716zr4nHYmXPTlmFLjihWdGo6coUeNa+NxM1SdpQjWyirmW PeExLpuviI16VLGTq0cFgqWH/MH9ku2/YD0h/ix4a/Yp/Yy1n9mPxJ4h8B3N/wCMbyz/AOCXv7Qn 7CuleNLDRhdWWi6Zd+MfiZ+zB8DfDPjnV9OvvEFzJo3hW31zWtfggvdW1LT9JFlFql1F+JvhD/gm X8TPCX/BJL9iD40+G/Bf7W3jv4z/ALNvhT4SfG/4/wD/AATk+Mvx/wD2wPEXwm/ad8NfD3UrPxR4 x+BV/wDskeO/iZqfgXwd8RfDcmk2/jr4HeCfDfw10nwrL8U/Dfhzw14o+H3inQdX/sqD+vCitk50 6s8Vh6tSljVUyCvh8VKSqvC4jh3HZrj8E6UHGF8LVrZjS+tYOc5U68cLyyl7OtKFPKPJKEqGIpwr YSp9fhXoRTpuvRzLCYXBV+epepy4qnSw9T6rjacIVsK6sJ0lGrQjUl+H+u/Cz4y/8FCv24fC/wAa 9J8a/tafsXfBX9kT4D+HP+FF+K1+CPwz8FfEb4gfHL9qrw5Y+Jvi1fN4O/bI/Zx+LmlafbfCb4S2 Hgn4Zaze6d4Fi8QaJ468X/EnwTB4p0a60TxvoGp/KfjH9nD9o39nr9mn/gtt+wZY6R8f/wBo3wP8 Vf2cPjB+1P8AsqfFG5+FNlqWq+OvGv7SPgHxvofx1+BMDfAr4UfDv4NxfE61+OmhXPxG0D4W/D3w N4d1rVtI+MI12y8O6g82p3cP9NlFc+MwtHE4PH4CkpYfDZjled5TXTl9ZrrDZ3iZZlWVPEV1KpBY fNYYPE0Ip3WDwVHLXL2Dc10YPFVcLjMFjptV8Rl+Y5HmeGTSpUIYrJadHCKaw9Llp82My95lQxEr PlxWcY7H00q0oxX53/s2/tWfDr4n/DPwb8F9B8AftaeHvHumfA+x0++h+LH7B/7b/wACvCVvqXhz wPZWOqaY3xK+Nn7PXw++Gr6p9sR7bTdMj8Wvf65MpTQ7fUSMV+B3wY1nx7qH7On/AATR/YH/AGqv 2dv21fhp+yl8DP2Z/g78Zv2rLTQv2Av22/jLdftEfFvQtX/tD4X/ALJd+vwT+BfxAtvCvgPwLq2j wfE/9oew8ZwWt74qurfwD8L7OwOnXfxBa3/sBor0MRiamIzbE5u1TVfG5jgc0xVBxc8NLF5b/rLV wU6MOaNWnHC47iChmNCNSrXSxeUYVV/rGGrYjDy8/CUIYTLaWVwlN0sNga2XYaunGOIhhsTTyrD4 lVJcsqc6uIwmX18JOrTpUJ0qWPqVsI8NjMPhsVD8Lv8AgqF458Mftn/8E5fiBp/ww+Bv7S/xJ0HR P2iv2QD46+Fvjb9hn9rPwd428T+BPDP7TvwZ8YfEQ6N8B/i38CPC3xH+KvhKw+H9jrd54hPgzwL4 s0ebTrPVdMn864t7uyT3H9kS1/4JheFvjHYp+yZ+wTqv7OHxX8RaFrehr8Q9O/4I9/tNfsc2jeHU gj1zV9B1v43+OP2P/hB4P0jTNSfRbOWPRde8b2MGvatZ6XY2Npf6udOtn/WCiscPy4Z4lQU1HE4u vjZyhNQxHtcRlOW5XVpSrqFp4VrLY1Y0HSUlHE4mhKrPnVSO1Xmq0qFN8l8PBUoKUXKgoQxlbFUp RoOS5K8fbckqqqWlKlRqRp0/Z8j/AJ/v2Fv2m7b9kj4YftR/DL4kfs4/t1ar8WJf25v27/iJ4L8E +Cv2Bf2y/E2i/EbRviD+0T8QfFnwyfwt8a7L4HH9nq30z4g6ZqGlS6P4w8S/FrQPAmk22pwat4s8 UeHtEgvdStfon4U/BX9p/wDZc/4JKfEjwh4f1vTfA37Y+sfD79p/41R39j4b8W/GbSfhd8f/ANo3 x/8AE345XOlaT4Z+EHw6+I/jD4lQ/C7xh8SX0XT7TwL8MvH154pufDsc2k+F/Etrexafd/rxRWMa Uf7Ow+XVuarGjk2T5E5qc6KeCybK6OVU5U40pRqQr42lQo1cbVnWqpVcNh3l8cAvraxfR7f/AIUq mPUIuE8/zLiN4acY1YSx+Z5hjMdNVXVjOlUo4RY/G4XBwVCD9hjMVHGvHOWH+rfM/wCyN+y58Mf2 P/gf4a+DnwvtdVnt4rjUPFvjvxr4q1PUvEPxE+LfxU8XSrqvxD+LnxR8Wa2W13xZ8RPHviB7jV/E OtauwmQta6RYWumaJpWlaTYfzXfDf9nn9hWP4R/t1+Cf2sf+CWHxM+Mv7VXxD/ap/wCCg2oeEfEM /wDwSf8A2j/G3jfx/oXxG+MvxKu/grc+C/2x9P8A2ap/A3hW11/RdV0J/BHxMf48+FdA8AW13p/i G58Y+EbDTH1Wx/rpopYyl9exOMr16k4LHZPmGSVXhvZ4evhsLmGNybGOrltWNN0sDicKsloYfBuO GqYehQqzpxw/JGnGMYGrPL8Lg6NK1Wrgs3y/O41MQ6taGLxuAwmb4Z/2jB1VWxlLGVM4r4vGOWKh ia+JpwqyxLqSqTl/MvH4c/bJ+Dvib9n34eftBeIv2u/AfiTw/wD8E1P2a/hdqnxh/YM/ZJ8IftIf FD9qP9o7RLvxXp3xU+DXx1/au8V/s0/tJyfBrwr4G1NtDv8A4d674k8Q/s++C73XPi78Rvipd/Fz TF0e8uPDvLf8E3/gZ8bPD8//AAQPj8c/s/8Axq8C3n7N/wCzj/wUd+HHxkj+IXwu8a6M/wAJPHN9 f/Czw34es/Fmua1pAsdNHjuLSddk+H3iSTU2074kaEt3qnhTUtb0+W5lH9SNFd7xdSeMxWOqQpKt jMfmmPrRpRdOlGpmE+LpwpUueVWtGhh1xpmsFSq161NQw+XRwkMDGGPWY8lHDww8cPTouap4bA5f gKcKjjNOlgMoyrKedqMKdOFatHJsJip1KFOjKpWrYxYv65Tjlccq/m4/aB/Zm/aJ8f8AxO/4Kv6/ 4S+EfjzxTpmnftvf8Etv2ofAngm+0h9B0j9pfwP+y78P/wBnDxx8W/BHwt1jxhaWfg3xdrmpw/Dj V/CdmkGrQaNN8QNH0rwp4j1nTFW7SLc+KWhaf/wUY/4KJeF4dL/Zr/ak8Nfs6eIf+CZH7cP7MvxD +Onxn/Zi+NX7OGk6n4m+M3ij4B/Y/h3a2/xq8CeAviRYal4d0M6vrmga1rfhPTvCmv3+peIV+GWt eKtT8H/ESLw5/RXRXnwoU1haGCq808Lh8Fj8PCNOXsazxOacAR8Osbip4hKc1GeS0cLiKFCkqSoY +hKtGrKFetTl6EsXWU6VejL2OKpf2TBVrc8VRyXiXCcVYCKpO0FUp5lh60Z1pc7q4bFyo1Iy+r4W VL+N7WvgB+3544+A/wAOf2ldZ+D/AMZdK/an+MHjz4jf8E+/iRotj8NvEs3i/wAA/A34q/sc/Db9 lDUvi9rPh3UtNs/svwo0T9qf4FW3x3s/HDWMHhW38FePZPHlrq2l+E9Z1JG+qPiB+xT8Y7HWf+Cl vh/4SfBLxvrPgv4Z/tWf8EjPjJ8JPAV5ozaFp37R3wh/Yq+FP7NWveOvhv8ADDX/ABhZ2fhLxnq8 mmfDLV/CGmxR6xDoj/ELTLHwv4h1nS/Mv1T+nmiu14qv9bWYQ9jTx6hlDVWFCMKFXFZFmWS57l2L xWFg4wr1Vn+X5pm2LpqdKji6/EWaKVOE6tStW5KFKhQhTw0ac5ZfRwWb5dQwUq9Wf1fAZ3XxEcdh 8PiJynXpc2U/2Tk9OopOpSo5JgsXGX12pia1X+Pv/gqxH8S/26P2hPB/xL/Z5/ZD/bIvvAPwq/ZP 1ez8SfE3xx+xx+0N8KtS8Va74X/bo/YQ+OOr/DTwx8P/AIh/DLw18a/EfiPwz8PPAXjDxJ4Z05Ph 9/ZfxB1C98RaN8I7zxprvhrx/aeH/wBmv2GPD3iO/wD2zv8Agqr8arj4c/Erwl4G+PPjT9jnxT8L fE3xG+FHxB+FV9468M6X+xt8PNMvPsOj/Enwv4U8TpdeFfEMuqeH/E3h7VNKs9a8F+K49Y8NeJNL 0fxDa6lp0X61UVxyoUv7LrZTT54UKuB4gwim5RlONTibPaOe5nXdoRU1CthMFh8FRtH2NGnXlXq4 uriIzoXzzeIrYiclOdeWBdS8UtMtyjKsnwvLbSMpUMtdXEys41Ktf9zDD06XJU/M/wD4I4eCPiB8 N/8AgmJ+xr4E+KfhHxj4C8f+FfhLDo/iTwb8QNA1vwt4w8OXVt4i14W2l634d8RWljrWjz2+nm0E Flf2dvJFZm2EcSwGKv0woortxVd4rFYnFSioSxOIrV5QTbUXWqSqOKb1ai5WTerSBu7bfV3+8KKK K5xBRRRQAUUUUAFFFFABRRRQAUUUUAFFFfBHxb/bB+IPwn/aA1X4aXfwa8F6x8K/Dtt+zRe6/wDE aH41apYfEJLX9p/4r+Jvgl4RGhfCO6+DbaDrt9oPxA8LX8mvaYPjDYXtz4RnstW8PRa14ilfwdF6 GWZVjs4xP1TL6VOtiOWDUKmJwuFUva4ihhKUIVMXWoU51auJxNCjSoxm6tSdRKEJJSampJUqGIxM 7qjhqcateSi5OEJ1qWHg1CClUm5Vq9Kmo04ym3NWjZNr73or4n+H/wC0p8bvizMnin4b/s4aHrXw V8Q+I/iF4Z8DfEfVvjlYaBr0v/Cvk8ZaN/wmPxC+H8vw7vZvC3gDxn498J2/h7wXqHgPxL8XPGc/ h7xDpnjLxL4B8Lww3+jW3C/sZftq+PP2wPBeteM9D+Hn7P0NrB8PdC8TaVb/AA1/ap1L4t/8I/4/ 8Raa2p2Hwh+NMi/s++CJvhf4xsYHgbxFDodp8Srrw6i3g1HS0uBpFtrffPhnOYYXMMZKhhvYZTDC TzNxzPK51MA8fLGU8LRxeHhjJYihi6tXL8VReDqUo4unXpwoVaMKtehCqpVIRlCLl/EqwoU5RTlT qVJ1XSioVYp0px92VaVSM3ThhITxs5RwcJV1+iVFfmZ8Ov26vix46t3s7v4E/Cbw74zv/wBn28+L HhrwTP8AtIeKbrU734m6Z8Tbn4T638CtfvJ/2atMsPD+veHPG1sPCviDXLWXX7i08V3djpFl4W1K wkutcs+i0L9u2+udT+H3iXxf4F+E/wAPfgN8V/idq/wm+HnxQ8ZftO+CPCPirxF4h8NXOtaJrWv2 fwx8e+GPBa6x4Q13xZ4c1LRfhra+DfG/i74qeLdP1Dwx4j8Q/CrwJp2p6uvhzepwfxDSq1KM8Hh+ enOrS93NMpqQqVqVavQlRw9WnjpU8VXnVwuJVChhp1auJhh69XDwq0qNScc5YmjGFWblJKhT9tVj 7Kq6kKawdHHyk6Sh7X3MLiKUpxUHKnVc8NNRxNKrRh+iNFfN/wAevi18Vfhr4h+Cnh/4Z/DP4ffE KT4ueOte8BXlz46+LviP4Wp4Z1HTPh54u+JOn3ltF4f+C/xcbxBZX+jeAvFNlemV9Bn03U/7Ajgh 1W11TUbvQvjL4Cft/wDx2/aQ+Ft18SvhR8A/2ZvGkdt4a8L+I9UsfCP7b+qeIrH4d3Gt6DqXiXV/ Bfxl1K3/AGVbfUvBXxF0HTrO0tZvB/hfw78RbuPWNQjtfEE/hjT1i1a55sLw3m+Ny6tm1ClhP7Ow 6oSxOJr5plWEjhoYrEY7C4aeJhi8bRq4enXxGW4ylRnWhCFSVKPJJqtQdTd39pSpJSlVr8nsacIy qTqyqTqU4U6UIKUp1pyo1XGjFOq4UqlRQ9nCUl+rtFfkTr//AAUR+P8A4OvPgXp3j39n79lb4cXH 7RPhHVvF3wsvPH37dPirQtI8W/YrX4OTaX4R8PS2/wCxpqWt6x8QPEV58ZdO0jSPCEHh+PULq/8A CPjG5t2uNCtNH1rWvrz9qD9pTxZ+zr8KfBPj6H4Z+Hde1/xV4h0zw3qug+LviXeeBfCnhfVr/wAH eJPEkOkXvj/Q/h18SFuNd8Q+ItBsvhh8OrJ/DFjpnjn4leLPCHhaPW9HvvEWmJc9WJ4O4gwlbLqF bCYb2ubYmvg8uVHNcoxMcVicLi6+AxNGFTDY6rTjLDY3DVcLX9pKEaNZRp1HGVWkp4UMTRxMYToS c4TwcsfGfs6kYfUo0nWeJlOcIxhSdKM6kJTceeFKu4cyoVuT66or5z0f4nfGy7+Mmh+DNc+DvgXw 78M/E3h3xB4h0jxTL8ZdX1H4sWcHhuz8Nx6h/wAJJ8JrP4Pf8IRpdsfEfiax0aGbSvjx4hvGtJ7X VZNNile/0rTPoyvCxWDr4P2HtvYNYmgsRSlQxWFxcXSdWrQfPPC1q0aVWNWhVhUoVXCvTlD95Tje N7p1YVU5QcnFOOrhOClzQhUi4OcY88XCcWpw5o3vG/NGSRRRRXKaBRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABXyrqH7H3wo1/wDajb9rPxlG/j74g6f4H8MeBvA+i+NvBvwf1/w9 8K7fwnq2s65pniL4Ya5cfDFfip4T8Uz6n4l8TXGq6nb/ABKnt9VXXGtr2wltdD8KQ+H/AKqoPIIy RkdRjI9xkEZHuCPUGuvCY/GZfOtVwVadCpWw1bC1J0+VTlQrpKrTjKSvTdRRUfaQcJpNpTjGUrqc VUpVKM1zUqypxrU3fkqRpV6WJhGaXxQjXoUqji7xk4JSTjdP5K8Kfsl2ngLWtfk8CfHr4/8AhD4f 6prPjXxXoPwZ0jWvhpL8OPAfjTx6+p3+ueJvCtzq3ws1P4j3drH4m13XfGGmfDvxp8QvF/wesfEO quF+HL6Lp2iaNpafs2fsmw/s1waHpmnfHr45fFHw54T+HGj/AAs8IeFviXH8ELLRvDvhXw//AGVF ou6T4R/BP4U6z4r1fSbHSINM0nWPiDq/i++0awvddj0eSwl8R6/NqXyx4A/ae+Nvwq0DxdpXjGe7 /aJnsfFXxw1jSvHHxG8ZeBvhx4jTwr8K/wBr0fs36r4Vt/Dfwi/Zw0HwvKfDvgy98K+OdO1a4N9q Hi/xfquv+HtYn8D6C3h/U4eg0L9rH4y+ALPRPDXiXw/4T+J83jTx7+1B8NvhV8QvHvxLh+Gus+Pv jJ8M/wBpLxt4A+G/wM1PQPAfwC1Pwno9z4g+G2mQazp/jqzmN1dW3gzxhc6j4KkOl3OtX33FbK+L J0K9GnissxtDH1v7PjVhLLoVMzqZRQzSFbERr47D4bFwr4SP9o4SpjcdLC5hjqleph6E8a5VFDnq yoxq4uFRSjUweMp08S4yko054hPFUp89OXI8LOnBY+tSi3DCU8RWxePoYV1MdOP1Ta/smfBay8YJ 43tNE1S31lPjbqvx/EcWu6imnt491rwkfDGpwyWSyBJfCt3qRHxDk8KyM2kD4nJF41WAalFGF4K2 /Yw0fQPFB1jwd8Z/jZoPgLT/AIg6/wDF3w3+z5DqHwnufg94e+JmvW2sXdxrWgan4h+DXij4veHd J/4TPXNS8f23g/TviVL8P9M8T3lxDaeCm8IyzeEJ6f7QXjP4pfD34leEPFPg34vQ3EFnoXiHVvFX 7Od9pPw6XwnqvgTSvB3ieCDxa3iHUNItPiqvj/WvjNqXw48CeEJtJ8b6b4Q1dNXtfDrfDW71Ea74 1sfAfD/xe+OP/Cro7iT49a/4w1XRvH37CvjN/iPYeE/g9bW/ibQf2lPGvgjTPH/wavNP074e3Phu LwZYaJ4ifWPDOp6LHp/xT0/w54n8INqHxA1a6tn8S+J+XL8LxDjMLRxNDPMPOjOGT5ZCOKli8R9U nj8weT4DkhXy+vRpYvL6uEpVYZhhXPEYSl7OeAxU8RCtSpOtVo0qsKVWj7V5jTzCvKLgv9oUaMcX mFLEc8qdanPFf217LEQq+ylif7VrSquWExdevL6x8V/s8+Nfib4e/Z7uPGP7QHxS8GfEP4KlPEmp +IvhjYfBCe28a/EO/wDh/qXgDWdf8QQ/ED4E+J9Nmii0nxL4yg06Dwr4b8AaTM/ia81C48N201l4 dtPDvF/CP9if/hT3ge8+H+jftPftH+IdBh+DcXwQ8G/8JHbfs2wXPw+8K2dnYado+q6MPCP7OfhS x8X+KvDun6dFY+HdW+L1j8S4NHtrvW47Owj/AOEj8QnVOk03xJ8SdE/bNuvA2seJfixqPw18b/Bv xb438N6T4i8M/BR/hJp+u+DfEfws0G5074d+JPBdnY/GvSta0u08WXF94usvjRLreieKbnxHaz/D fULC18Lazpcfz3+254y/aL0L45/Bjwf8EvH37RumaV41+Cvx/wDE2u+E/gBoH7Gep31jr/ww8Q/B i08OeOdduv2rvC07S+FbWH4n6rYeL9D8G+JrrxPqYg8MN4W8MpPB4gvbucGs1xtTBZPTzLh7B4PP 8vzDOOfE4XC08uweHy+lxFmGLw2KxU8srVsM8EqGeYanCnKrhcPHE1cLCvDDVqyjtQhONaMac8RK vl0sLSw9dSquriHB4fE0KlGVK0sTLnxCnKMoqrOvGvhnSeIXsJfQvhn9kLQvD/if4CeJL74u/Fnx hD+z/wDCDxL8FNF8NeLLH4JXXhvxx4T8Uz+FLnULz4gW+kfBnRdTudegm+H/AMPZLC78I6t4OsIH 8FaW76ZM+qeK28Rdn+0h+znoP7Svg7TvB+u+OPHvgGPTb7XbhNY8BL4Avrq+0/xX4F8W/DbxV4f1 nQPin4C+JvgLW9E8Q+DfG3iHSLyPVfB15qFmLsXWi6jpV4pnf4J8X/8ABTrxX4L8J+EtY8L/ALPv iX9pG1H7P3g34peNfHnwl0f4yeF/AkviDxL8KJfibFqei+JfG3wRHwr8MfC69srdEa9+Jfxm8IfF zSbjWNL0u3+DniK7LSy+laJ8ffj7onjjVfCvjPTrzVvEt3+1H4g8FaboWjeNvh8vw38IWkX7CNj+ 0Hp3wp8Q+PJvgdpPj7xP4LuvG1zqr6J4q0P4bab49sGsba78SeK9S0bST4L8f9eMyXjGlXlmOZTw uFqZVhM7zGhLF1Mvo+2w+Gzh1M55ct9n7Sca2OzqtXr08xwVKjiKWInh583tMPhanLl9ahy4WOBj OlP6ngq1ChBpSwuHWXutgpRqRnLDUKkKNCnCnUpV1UjieXEKpelXxNH7C8U/CzWLHwf4kt/hP4n1 fwz48Pwt0T4ceAte1LVdM1FfCw8Mtqkukaqt94u8G/Edbq/vp9RgPia91/w/4rOuQ6PpXm2cd5A1 8/tsSyLFGsriWVY0WSVU8tZJAoDuse5/LDtlgm9tgO3c2Mn5O/ZO/aP8W/tFeHNU1nxp8K9N+E+o w+H/AIYeMtI0TTviJ/wsZ7nwp8VvAun+NdAl1rUE8F+DLXSPEVolzdWOqaLpg8SaZFHDZ3lv4kuZ by5sNN+tK+UznD5lgMZXyzN4U1j8LWlPESVbDYuq6mIpUanLLG4WrXpVo2aq8sK01GtWryn++nUL wv1edChUwqtQVKNOjaM6adKnTo4eneM4xnUjToYWhRw8qikqdCCjh3GlUlzlFFFeQdIUUUUAFFFF ABRRRQAUUUUAFFFFABRX5h/8FKfD3xY8cy/skfDn4SWms65qvjf4/wDim01zwfpv7aH7Sn7Blh4t 0TQf2cfjh4rWx134+/speGvGHxYsbHS9W0PTPEFp4ZtvDmoaH4i1jSdNtdaextkF9b/l58P/AAp+ 078bP+Gbfhdpb+N/Gfirw74O/bR1v4r/ALPviv8A4LBf8FEf2adf/Zy8T6L8cvgNaaN8H/iJ+1F8 DfA/jv43/tS+OvhBonjabRNG174v6La+Hde8KeL4PGHw98Ua74DvPBOveJFhufFYyOChBRqTeIlT qVJctJ08Nl9bMKvMmvrF3DD1o/WaWHrZPhHCMc2zbLMTisBhcY63JRowryleDnSozinTjKNavVqU qSjKdSNBq8IuWHqV6WaVVN1cBluOw1DE4ij/AE/0V+Efjvx3+zf4J+OHxC8P/tLftkftKfBr9oz4 bfEX4c+GP2T/AIBeCf2qfjZpvjrx58JNJ8NfDs/Duf4S/syS+Ir/AET9v65+KHi+fxpp3xH+I/xX +Ef7Rvia/wDGdx498AeIvFGlQfDC0s/CXi37L/xs+NXhv9pL9rXVPhv8SNJ/4KDfGvVfDX7ZnjSL 9nn4c/Hf9q/w9c/sxeJvBX7Q2naZ8CvgB8a/Af7U37S9x+zZ8JvEXxK8Na0+keDNQs/2bv2R9f0r RPhJ4xn8Gy/G3wVrGv8AxCiISjU+qypxq1aeMynHZvR9jCNWt7PDZVh84pYKdCFRuOZQw1aVDNsP zOjlOPprCfWcZOtSc1yyvUpt06dali8twdSGInPDQisbicThauOdavTpxWWe0w6qZVi5qE86w9al Ww9Cim4n9ItFfy+QfH3/AIKOJ/wTM/aitdI+H/7ZWv8Axq039on9rfwn8UvjfqXjb9inSvjX8F/h 54a0rxF401rxV8NPDo/am1D4W+HdO0DXYo/hJ4S8P+CfHHifVvg9os954w8C6L8U7rwd4el8a974 n+PvibUPjV8ALnxb8a/2gPhT+0xq+h/8EwZ/2av2YtQ+L2p2MXxU+H3xP+IUGnftm63r3wZ8C/Ez V/hT+05qemfD6b4gT/GLxtrkPxVf9nzw94R8M/EPw3rnhK/nt9V1p4H/AG6rg6UJU19bfASi4VFW lKPH2VY3M8DXw9OneWKwuAjg5wxdanyupTpY2rhqdWpg/q9bPEVFQjUlKFSPJ/rdeVWKo0qL4Rzb CZVioY6tOXJgZ154qNZ+2vHCQnhvrE1HFKpT/pGorxfUvij42sviB4w8GQfs9fFu58NeG/h/d+Md I+NH9sfBJvhd408QW8Vs8fwy8P6PYfF/UfjxB4znNxNi9134H6R4IK6feiDxfc3Mml2up/DPgP8A aT+K/jPUvGOreFviv8DPHHiDVtK/ZT8N6efDOieLtV+Hfwv1v4p/Ezx9oPivQvFfga3+LN5f33xD 8IWNxaRa68PjPwTqHiFtO0Ky1nw/4PWzjQ92BwFfMI1JUOVKFbL8O1Pmi/bZnmc8pwkZx5XKlGeK p1JOrWVOn7BUq8ZSp4rCOv8AM8TcX5bwtWwNDH08RVq47C53jaUcN7CTeF4fyf8AtvMZU1Vr0niK 0cI6cKeHw3tajrzlTrexjh8TOj+p1Z2saPpHiHSNU0DxBpena5oWuade6RrWiaxY22p6RrGk6lbS 2eo6Xqmm3sU9nqGnX9nNNaXtldwzW11bSywTxSRSOh/Jm7/bE+LfxAm/ae+Gmj+JvhdZ33g74NfH TXPDni/wTZ2U9/4R1z4ZapZaAYNUtdG/aG1r4iWfiDXdOvr7UrS08b/Dv4G6r4J1/TpI9Ii+KGk6 XPrVz7p8GPH3xK8Ep8Y/h7rN5qfx81LwP488L+GRF4Kv7HT9b+F3hfUfgz4B1W28V+Prn40/tIa3 8RNQ8LazqUus3ljc6Vq3ivxreanpXi2+t21+8uUh0zpr5RXwuEr4urXoRlSy2ObUafNUj7XCRxuH y+rKdadONPCzpYnF0FbEOCnD2tSMlGNH2/g5V4nZVm+bZdgsuy/N6mGxWb4vI6mYxpUZTwubYXA4 7NKFGhgMNXr4/MaeJwOW4rERr5dSxEqDeHVanFLHSy/6E8U/sn/ss+OfDHgnwT42/Zq+AHjDwZ8N LO6074ceEfFPwb+HXiDwx8P9Pvls1vrHwToOreHLvSvClneLp2nrdW2hWlhDcLY2YmRxawBJfDP7 OXw38CeJfD+p/DnTbH4Z+DNA1HxD4o/4U98OfBvwx8FfDHW/iP4ktZ9Mvvip4gtNA8B2XjDUfHKa NeX2kLMPGUHhy7gul1HVvDmpa9pui6xpnwv8LP20Piz4q+Jnhj4StpHgDw7Hqvg/SLHS9O8R+IPA zeNoWn+DNh44svidaQeLv2pj8aviVoFxrTm3Hhi2+BrXeo6I15rl18Zb2/0bV1n6D9n/AOIXxd13 VvB/xOvfEeq/tH2Nj+yn8EZYPBnwevIfDst74s8Z6/470zxh4j1UfED9pbRPhBr3iDQ7/wAD3ej+ LL/W7CbxXBqMC2Xh0+HJLHxBpeu+1WwmfYaGIpYrNqiwsIxqqlXxVTEUalTPlmzhOdGpKphMNiMV Xy+dTFYmvUpyw9StHGOu6+FrOj5eW+LGQZ3/AGfQynKc0xkq1XMMHUSwnsI4OjkdXJI5tLCUZxjm mYUKeHzxrC0Mqy6vUzGNOpgqlGjSzPCvFfcmqfs+fAPW/idpvxs1r4IfCDV/jNoy2q6R8W9U+Gvg y/8AidpS2NrNY2S6b49u9Fl8VWK2dlcT2dqLXVohb2s01vFshkdGo3X7NP7OV94Iufhle/AD4J3n w3vPFM3jm8+H118KvAlx4IuvG1xdNfT+MLnwnLoL6DP4pnvWa8m8QS2D6tJdM1w920pLn41039sf 4nXSfE66sb34NeN9R8LeHvjjfyfDjwvoviux8YfB25+GnxGh8G+EdY+M2pjxt4mF54e8XaI954pm isPCfgu8ns9H1Cbwbd+LtJjutX07g/iL+3p8RvAtv4YGg+K/2efijo93c+L5F+MPh1vCfgH4QfEi 58PHwpJbeBPC3iH40/tU/Dnwx4b8QRHXdQ0/X/Evgr4g/tHw6W+ni9HgyXUbPxL4V8Pc2GwPEFar gcPQx+IjLlhPBL67ioU8NHCV681OFRL2eHjhcRh51MPOMoxxFVqeWSxUo1JQ6Mb4u8HYTBYjMsR9 fnQpRoxq+zw2GrYmosR7LB4SlTwscW8TiJVKOPqQxFKlSqSyWi61DiCOUVK9CjifvXxJ+y/8BfEG lfGCxtvhT8OfC+qfHrSn0j4t+LfDHw5+Htp4r8ewbJ0guPF+p6h4V1SHxdeWH2m4k06bxZZ64LCe Z7i2jjnIkFj4m/su/s0fGzUtK1r4z/s8/A/4wa1oelpoeja18VPhR4E+ImsaVoyTy3S6VYar4w0H Wb+10/7VPPdG0huEga6nnuGQzTSO3k3xi/aL8a+DH0Wzl0bQfgDoeo60tkfjd8f28G+J/hHqe3w5 qOtW+h+HbT4efGzSPEEeta9fWkWj6VeeObvwLDJKZW0PSfF2oSWukTeUL+03+0Hruj/D/wARaBD8 HdIsPEXhL9k59Z0vW/CHjzVL6Txf+0/r+peEZ7zTr6Lx54dbRvDvw/1FdO1+PRdR0XVdZ8XWkV94 Zn1XwbdTw+JbTPDQz+p9WrUMxrU6lHF4HAYWrDH1VUo4jNadPL8voU8XRlKFN11h6WXewVdSwMY0 1jaWDwlSFWfp4/xH4awGJxmGq08yqVcPl+Z5riILL5Ua0sFlmGjmec4p4LGzwuYOhhsvwlDMfrVT BxwucU6MKOR182x2Cr4TC/V/xA/Zb/Zk+LN7ouo/FT9nT4E/EvUPDegDwp4dv/iB8Ivh/wCMr3QP C6idV8N6LdeI/D2pT6VoCrc3KjR7F4NOAuJwLbEsm6qP2Tf2WFuby8X9mj9n8XeoXy6nqF0Pg18O hc32pJ4cv/ByaheTjw55tzfL4R1XVPCy3czPOvhzUr/QxINMvLi1k+QtJ/a/+LLeNtL8H694m+Al lr2na54V8OT+BI/CvjO28bfGu9vfjt8SfhF4vuvhLHc/EuRfDg8O6B4FtvHdzps2l/FNtDt9Qubb xRqWlaDbxeLpqnhT9q7xx4X+KvgD4Yap4j8K+ItJ8UeJfiDap4bt38GeNPjRrd/P8XPivo2kWAtN e/aW8BePPC+i2cGjaDY6bq2n/An4meDdH8P2t5qfiPxb4T8PaXqt34Z2jQ4hjTjQhmuL9k6+JwlK lTxmP9jOVJSzCrCjBJKoq9WNKtCFKE5TxdWCqxp4mFRU/Nh4rcLSdCqsPjYU1Qw0pVJ08BGpgo4i vg8ppwxEFjZfU4YeGLrQxP1ipQ9lgsLUq0IYnB4nB1MR93/DP4B/Av4LT61dfBz4LfCb4TXXiS00 Kw8RXPwz+HPg/wABz69Y+FrSaw8M2WtTeFtG0qTVLTw5Y3NxZaFbXzTw6RaXE1vp6W8Mro3rNfnp 4o/av+I1h8W9O8Gyaf4J+Fk7p8H5rL4H/FXT9P1r47fEkfEHx/4m8J+KLbwPrfwz+MniDwFbTeEv D2h23jQyaTafEf7Jpd5v8aW/gzT1k1WDzjxX+258S/D3h/x3rNpq3wU1vW9K1u603Uvh1pGi3x8Y /s32Fv8AFK38E2ur/HrVfFnxk8DfDy9i1TQLg6zHF4q8afs4QrqEZ/sK88WeGINX8T6Nx1ctzbH1 qVXEV3i8RiqkcLCtWxM8XKpUpQwtOlB4te2pSoU6FahbE+3eCw9OCw9XEUq3sqE+jEeKXCWAhmFS osfShl8cVWxcZYKOGxChg4YhYhvAYmth8x+uqrhJYellFTCRz3EpxxmGyyrldOvj6P6pUV+Vl9+2 98RZfAvw58Rr4p/Z28D33ibwH8X/ABNDe+Jp9O+IGifFLxL8NfGPh/wz4X8D/Dq5+EHx68U+FNG8 U/EyDVbqS38M6d8R/i94k8NazbS6Dp2l+PbnTdQkHqf7Tf7WHxP+EGk6HNpfwm1P4fWOqeJ7XRrj 4o/Fe6+Bd/8ADw28vhrVtbEWm2mr/tX/AAQjtLu5v7CHRo3+IfjX4b3Znlb+wtC8WXh/s+LGeR42 nKgpPDpV8Ri8PTk6yjFywWYVMtrTjKSiqzWIpVWsPh/bY2NKHtKmFgp0lUcfFXhaeDzPHRjm86WV YLKcbiadLLKuIxEVnOUYbOsHRq0MPKrUwF8JjcJB43Nll+U1MRW9nhsxxEaOJqUf0Aor86h+1d8S dc1X4baZpt/8GfDNj8Q/B/w/1nxD4jmlufiPovwj8V+LvD2t6jo3gXVvEfgbx7/wgvjbVvi/qNvp kXwl1XTvF3hvS7SziuTex+LtQ8SeAtP8TeKeB/24fijp2pfs2+CrnU/hf42s/F/w++Cb6r4n1DX/ AIW+E7r4p6340vpvDvjCXwfrvj79qXwzrya/8PL+0m0rxBo3hP4WfGzUfE3jrS9T0C5XwHe6zYWm n7UuHcwrTqU4vDqdPFUsJaVb3JVKqzNJ+2UXRhFVcqxEF7SpCc6VTD5hCDyqvSx8+XGeMHCeCeGd Snm06OJw08QqlHBRqVYKNXIlGEsCq6zCalhuIMJip16WFqYajWoY3I61aHE+Er5HT/YCivz2T9of 47aXYeMfEXiPU/gTBoV94I/aS8TeAIbrSNa8Gw+Ebj4G/E3R/AmkN8QPGfi74sW3hXxJaeJNP1iP Vb4Y+E2m6XqcK6XP4nt9NuJPEFl5Vpv7aPjDV/CfhTxpB4i+HFtdXlp4h8O+JfibruiahY/B7wTC vxY+E/hq48bahofw2/aU+MHwy8V+F/D2h+LmF/4n0v41z2trrsdzo2o+Pfh5HaeNdCt8MPkuLxM8 PTpSozliJulBRnK8aqlmNCcJ80IwhGjjMtq4WvWnONGLnTqUaleE4c/VjvFPhzLqNWti6WY4aFLC rH82Io4enGpgnUyaVKrScMTVnUqYvL86w+Y4TDQpuuqNOvTzCGXVKNZUv1eor827/wDaZ+PWreC7 TxL4H1P4H3dr4d+Gnx++Jeu+K7nwV4z1vwv8WNF+DHjPSfDugal8L7fSvirYHwr4d+JGkX1xrVjr +o+IfiTaaSBZtpi+MNLuYtUl9G8JftL6/q/7WviD4E6prvw9udDj0+8m0DQPCFr4Q8TeLtPls/DO jeIJLjx3rOkftDan478IBfP1OCSLxX+zH4S8LG8m0LSLH4h6hqWraIniEWS4uSbUqLthc2xji3Vj NUMnxcsFiXKnKlGdOpUrwq+xo1IwrRhSqSxNPDqNn0x8SuH5V8PQdHMYfW834ayTD1pU8G8NVx/F GW08zwMaWIhjp061ChQrYeniMVRlUw9aviKMcrqZlCbqL7eoooryD9BCiiigAooooAKKKKACiiig DN1rSbXXtH1bQ76XU4LLWtMv9JvJ9F1rWPDesQ2uo2stncS6T4i8O3+l+INB1OOKZ3sNa0PU9O1j S7oRX2mX9pewQXEfz7/wyj8L/wDoaf2lP/Ezf2wf/n6V9KUVvRxWKw6caGJr0Iyd5KjWqUlJpWTa hKKbtpd62PJzHIcjzedOpm2TZTmlSjFwo1Mxy7B42dKEpc0oU54mjVlCLklJxi0nJXaufNf/AAyj 8L/+hp/aU/8AEzf2wf8A5+lH/DKPwv8A+hp/aU/8TN/bB/8An6V9KUVt/aWY/wDQfjf/AAqr/wDy w87/AFK4N/6JLhj/AMMOVf8AzJ5L7j5r/wCGUfhf/wBDT+0p/wCJm/tg/wDz9KP+GUfhf/0NP7Sn /iZv7YP/AM/SvpSij+0sx/6D8b/4VV//AJYH+pXBv/RJcMf+GHKv/mTyX3Hy5pv7Hvwc0a0FhpGs ftC6VYi4vbsWem/thftdWNoLrUr241LUbkW9r8cIoRcX+o3d1f3swTzLq9ubi6naSeaSRr//AAyj 8L/+hp/aU/8AEzf2wf8A5+lfSlFN5nmTbbzDHNt3beLrttvdt+01bFDgfgqnGMIcIcLwhCMYwhDh /KYxhGKSjGMVhEoxiklFJJJJJKyR8rX/AOxp8FNVutPvdU1D4/6le6Q162k3d/8Ate/tbXl1pjal ZTabqLafcXHxvklsmv8ATrifT702zxG6sp5rWcyQSvG02lfsefBvQtM03RNE1f8AaF0fRtHsLPSt I0jSv2wv2udP0zStM0+3jtLDTdNsLT44Q2ljYWNpDFa2dnaxRW9tbxRwwxpGiqPqOij+1Mzs4/2j juV8l4/W8RZ8ntHC69pZ8jq1XC/w+1qWtzyvC4D4HVT2y4M4UVb317VcO5Qqlqqw8ai9p9T5v3kc JhYz199YbDqV1Rp8vy5D+x78HLfUb7V7fWP2hYNW1O3sbTUtUh/bC/a6i1HULXS2vG0y2vr1Pjgt zd2+nNqF+1jDPLJHaNfXht1jNzMXv/8ADKPwv/6Gn9pT/wATN/bB/wDn6V9KUUPM8yerzDHN2S1x dd6JJJfxNkkkl0SSWhceB+CoK0OD+F4JynNqPD+UxTnObnOVlhEuac25zlvKbcm222fLkP7Hvwct 9RvtXt9Y/aFg1bU7extNS1SH9sL9rqLUdQtdLa8bTLa+vU+OC3N3b6c2oX7WMM8skdo19eG3WM3M xe//AMMo/C//AKGn9pT/AMTN/bB/+fpX0pRQ8zzJ6vMMc3ZLXF13okkl/E2SSSXRJJaBHgfgqCtD g/heCcpzajw/lMU5zm5zlZYRLmnNuc5bym3Jtttny437HvwcfU4dbfWP2hX1m2sLnS7fV2/bC/a6 bU4NMvbi0u7zTob8/HA3UVhd3VhY3NzZpKtvPcWVpNLG8ltCyX/+GUfhf/0NP7Sn/iZv7YP/AM/S vpSij+08ytGP9oY60U1FfW69oqU5VJKK9pZKU5zm7bzlKT1k2xcD8FRlOUeD+F4yqSjOpJcP5SpV Jxp06UZTawl5SjSpUqcZSu1Tp04J8sIpfNf/AAyj8L/+hp/aU/8AEzf2wf8A5+lH/DKPwv8A+hp/ aU/8TN/bB/8An6V9KUUv7SzH/oPxv/hVX/8Alg/9SuDf+iS4Y/8ADDlX/wAyeS+4+a/+GUfhf/0N P7Sn/iZv7YP/AM/Sj/hlH4X/APQ0/tKf+Jm/tg//AD9K+lKKP7SzH/oPxv8A4VV//lgf6lcG/wDR JcMf+GHKv/mTyX3HzX/wyj8L/wDoaf2lP/Ezf2wf/n6V0vhD9nzwH4H8Rad4o0XX/jfe6npf2v7N beL/ANpr9pH4heHZfttjdadN/aPhDx98V/EvhLV9lvdyyWn9raJe/YL5LbVLD7NqdlZ3cHt9FTLM MfOMoTxuLnCcXGcJYmtKMoyTUoyi5tSjJNppppptNWNaHCHCeGrUcThuF+HcPiMPVp16FehkmW0q 1CtSnGpSrUatPDRnSq0pxjOnUhKM4TjGUWmk0UUUVyH0QUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9n62mjX162lX4gqKco80U5RW8o6xXv16e60/iYbEw/x4evH4qVRRbTSnJpp U+TnbWkPaOnGnzvaPtJVqMYXtzOrTUbucb95RRVaC9s7qS8htbu2uZtOuVstQignimksbxrS1v1t LyON2a1uWsb6yvVgnCSm0vLW4CGG4id11t1ScmuqinGLl6KUopvZOUVu1dFmiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAr8Tviz/AME8/wDgo34/+Knx l1vw1/wU7+Efhf8AZ9+Jnj+Txn4Z/Zk8Qf8ABPdPGOgeAYP+Et8P61cRn4t2H7Xngz40eJfEPi/w tomp+A/iFqj+MtF8KXWkePfHN58MvAPwlvF+H3/Cvf2xooilCtTxCjF1aVlBzjGcbRr4fFRUqc1K lU5MVhMLiaftIS9niMNQrQ5atKEo1zy5JU7vklJTce01Tq0eeL3jKWHxGJwtSUWnUwmKxeEqOWGx WIpVfw3+Ef8AwTQ/ba+BGl/FXS/hH+19+wr4AX4veEk8M+Ibvwn/AMExvip4butN1GfTdUt9e8fa Eugf8FL9MsoviH4x1zWL7xx4w8SavZ6z/b/jeQ65dWfzzW0v5qftR/8ABIPxHrHxD/Zq8AftCf8A BYH9h74W+PH+NWl/Ef8AZ7+E3iv9jq08Ia18U/FnhCfxX4b8CeCfBHgf4g/8FE7zXPGmkfDXSfip beBvB1j4FtV8X6ZHbeENQv8AxDqPjy4vvE+uf1518n/H79lU/HbXDqtn8f8A44/BnTtd8Gv8OPil 4U+Flr8B9U8NfGj4em61m4g8IeOofjX8DfjFq2h2VtF4o8YWC6v8JdX+GXiq7sfFWoR6n4gv5dM8 LTeH85OUJ0HCkqsI1cG6lNzVNSp5bWrZhl9N1ZRqqlSoZg41I/7NjIU1WrP6lXjUqQdwaca79r7C tKnWVOtGDbcsZQwWWYz2jpOFWqp5VhoQhR9tRjVr4PBRliMM4RxVH+eD4q/8G2/j74jfEz4deMrD 9rf9hj4Nal4F8a6B8SvDPgn4K/8ABKLSPh9oer3nw8XxbYeHLXWoU/bb1Dxd4l8PeCNM+IkXh/wv HeeJJ7j4f6Po3gfTvB+o+G10m2Nz93fsF/8ABITVP2RP29PHf7W3iv8AaF/Z48b6jq37NKfA3wt+ z78CP2PLf9mvwt8IPCF18S4/GHhzU/Awv/2kPjnrfh/wXG9j4v8ADA8JWlpY6PrROl3A1WOfwWLO +zfH3/Buf+wz8RPgufgzqfi/40eHobjxlaeNNR8ffDzQP2UPhv4vvbnS9T8GazoHhy00LwR+y1oX wj8KeBvDOqeDBf8AhzwV4E+F/hXw7pF54u+IF1a2CXPjTWpbj9Df2Uf+Cen7Pf7GPibxN4m+Bthq OgyeMvC+g+HvFWltonwy0/T9f1PRNP0K0ufHWp3XhX4d+GdfufHPiu+0a68S+ONVfW/sPi7xZ4j1 /wARa1pVzqT6VNpPTRk6FZxhWlCnTxmZwp1YOcvaUanDuHwdPFuE+WXJmFSrjspq4eopVMP7KGay jKtmOInhOKvBVqEb0I1Jyhgqvsak1CNCph8+p1I01yKUOfD4CMcxoyoyjT54LLXN0cPRjiPuaiii sjoCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKAP/9kAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA UEsDBBQABgAIAAAAIQB0sUijYAYAADIbAAAUAAAAcHB0L3RoZW1lL3RoZW1lMi54bWzsWU9vHDUU vyPxHay5t9k/TchG3VTJ7qaBNm2U3Rb16J31zrjrGY9sb9K9ofaIhIQoiAsSNw4IqNRKXMqnCRRB kfoVeLZndu3MLEnaCBB0I2Vn7J/f//f87L167UHC0CERkvK0HdQv1wJE0pCPaBq1gzuDnUvrAZIK pyPMeErawYzI4Nrmu+9cxRsqJglBsD6VG7gdxEplGysrMoRhLC/zjKQwN+YiwQpeRbQyEvgI6CZs pVGrra0kmKYBSnECZG+PxzQkaKBJBpsF8R6D11RJPRAy0dekSb7CoEaTup6TIhp2mECHmLWDmvkE K5tXV/BGDmCqjNsxnxyXA0aTxmn0DICpMm69pv/m9AwAhyHIX+a9vd2r9Zo51gHZxzLtJnxaLQ/v 0G+WZPZ0s0QNyD5eKeE9mzkg+7hawne3et3ejiePAVn8Wgnf6Da661se3oBiRtNJCV2rteCTo+eQ MWe7lfBWq9OpFYZfoMD785jRLMY8VV4E2ZgL9FyC73OxAwD9wrCiKVKzjIxxCLHZwYwOBdXy4A2C nRk7FMrSkOaFZChoptrBBxmGOF/Qe/X8u1fPn6JXz58cP3x2/PDH40ePjh/+YGl5C3dxGrkLX37z 6R9ffYR+f/r1y8efV+Oli//l+49//umzaqBygS++ePLrsycvvvzkt28fV8C3BB668AFNiES3yBE6 4AnoZgzjS06G4nwrBjGm7oqtNJI4xZpLBf2eij30rRlmuAK3TXwL3hUUKlkF8Pr0vidwPxZTlbvc 0+xGnHjAPc7ZNheVVriheTmOH0zTqJq5mLq4A4wPq3h3cOr5tzfNoCDSKpKdmHhi7jOcKhyRlCik 5/iEkAoz3KPUs+seDQWXfKzQPYq2Ma00yYAOvWhaLNqlCfhlViUg+Nuzzd5dtM1ZldZdcugjISsw qxB+QJhnxut4qnBSRXKAE+Ya/CZWcZWQ/ZkIXVxPKvB0RBhHvRGRsmrNbQH6Ok6/AdWj2u17bJb4 SKHopIrmTcy5i+zySSfGSVaF7dM0drHvywmEKEb7XFXB97ifIfod/IDTpe6+S4nn7tOrwR0aeSIt AkTPTIX2JVRrrwgnNH1bkc9ckbcErUyJ3RN1eBnuZPXtcDGi//7i28XTdJ9AvJd3oLe1923tDf7z tXdZPp+14i6KLNRf3efYBtm0y8nSbnlMGeurGSM3pWmYJWwYox0Y1OvM+Y/MT2NZDI95gfdwkcBm DRJcfUhV3I9xBs123fTjkcxJRxJlXMKhzgxX0tZMoWFX9vS3qo8yth5IrPb4yA433UPhnIzZdiJz vCwYNTWBszJrvvdmzOpWqqVm81WrG9FMqfNUm6sMPiyrBoNza0IngqB/ASuvwQlcyw6HFMzISNvd bsKFWzTr4vlCXCRjPCK5j7TeZR/VjZOKWDFnfYidCh+tG9H/0moOt5Ym+wbczuIkl92VJewK772J l4pTbuEZY5yT6chSNzlZio7aQWu1sRqgEGftYAznW3hMMvC61M0fZhFc/YRK2LA/NZmN4RfebBWK QfQ5GVevFeMlhb06kAmpuljGNjTMVB4CLNWcrPyNVTDrRSlgI/01pGiuQzD8Y1KAHX3XkvGYhMp1 tjOibWdf81LKp4qIfjw6QkM2FQcY3K9DFfQZUQnXFKYi6BfRDrS1zZRfnPPCWHHbprlhlsU4L7c6 RYtMtnATqnMZzJsjHuhWKbtR7vyqmJS/IFXcMP6fqaL3E7gyaI60B0K4qBUY6XxtB1yomEMVymIa 7ghoHEztgGhBUF30do3guth8C3Kov23OWRqaGoOTnzqgERIU9iMVC0L2oSyZ6DuFWD3fuyzJgpCJ KEdcmVmxh+SQsIGugWt6bw9QDKFuqkleBgzuZPz573kGDSPd5Lj55tWQ+d5rc+Dv7nxsMoNSfh02 DU1h/7mIxlp+52PXm+XF3usqoicWbdaVIiuAmbMVtPK0f00RzrnV2opV0rixWggHXixrDIPzhiiD ix+k/8H+R0XI7G8PekMd8AOorQh+T9DEIGwgqi/ZxgPpAmkHh9A42UEbTJqUNW3e3WqrFZv1hbRR CxfM+Z4wtpbsLP4+p7HnzZnPzsvFizR2bmHP1nZsqanBsydTFIbGxUHGOMb8aOX+rsSH98HRXbjr nzIlTTCRB3DNB61n3+QBJL/laJZu/gkAAP//AwBQSwMEFAAGAAgAAAAhAFibkMKqAAAAHwEAABEA AABwcHQvcHJlc1Byb3BzLnhtbIyPOw7CMAxAdyTuEGWnKQwIVf0siJkBDhClbhspcSI7/G5PxEeC raNlvefnurt7J65AbAM2cl2UUgCa0FscG3k+HVY7KThp7LULCI18AMuuXS7qWEUCBkw6ZfRIIouQ K93IKaVYKcVmAq+5CBEw74ZAXqc80qh60rd8wDu1Kcut8tqi/PA0hw/DYA3sg7n4HPCWELhXCU82 8tcW59h+//hLUu0TAAD//wMAUEsDBBQABgAIAAAAIQBBsvwqxAEAABIEAAARAAAAcHB0L3ZpZXdQ cm9wcy54bWyUU01v4yAQva+0/wFxT/3RbmJZcaJK1Z56qJTs3ikQhxUGxOA06a/vgNPGTVKpe2OG mTfvvYH5ct9pspMelDUNLW5ySqThVijTNvTP+vekogQCM4Jpa2RDDxLocvHzx9zVOyVfnjxBAAM1 a+g2BFdnGfCt7BjcWCcN3m2s71jA0LeZ8OwFgTudlXk+zTqmDD32++/0281Gcflged9JEwYQLzUL SB62ysE7mvsOmvMSECZ1f6akGYS/qK6hoMV623fPhikdM3SBwk2UlMInH2PECdZL8Sg3gcAr2vhr WqKRrA/2XvzrITQ0p9m4dG1dqpzNivL2SmV2OQW0EjJyGIbylRajaDiSHfMrzjQuqkhUIQaLOath T3C/U2Ql8C5PdDB7uMzi6GOXq61XrTJk39BJUUzvKDngaVZFLVjGT/PbHsk9Qoga05lgK5qLe7D+ lRJnoaFlgfOTDUPJkKyqlES8E0gEH+nD8Ey97YNWZmzHicuZ5lv091Lz52wcMDg11oxmod53dh9q sfhivLFBwlru07M5LuhLRtH+K5TO0v/L6QqF1iuxcozjnyMclzir8hLtxukchX1EwzZ3w9N6AwAA //8DAFBLAwQUAAYACAAAACEAkjno3dUCAACLFQAAEwAAAHBwdC90YWJsZVN0eWxlcy54bWzsWEuP 2jAQvlfqf7B8z4Y8YAERVryiVmp72NLeTeKAtY6NEnfZVbX/vc6QF2gXFQoqLZxwxHi+mfE8Prt3 9xRz9EiTlEnhYeumgREVgQyZmHv429Q32hilioiQcCmoh59piu/679/1SFfN+Ff1zOmnVCGtRaRd 4uGFUsuuaabBgsYkvZFLKvR/kUxiovRnMjfDhKy09pibdqPRMmPCBEYhjTz8szmy7abrDozbyaRl uI5rG8OG2zbazeF41PHH1sgZvOB+DVvbpi34GP725vWGLyTWvnymIfsRI3AC2chAgyCgQiELIFYL yel0xgEumD6BWPYRSaHuaYRY+OThmAmZgPwySdWIJ+iRcA/POAkesNnvmaV8thXCQkup8MHKZVQd QAUllgqGYZLt5DRS8CvQSp+TfdvQJxXES+15KuZgQCo5C33GweItJK4KpJqUto0LMLHQnrD54oQw pXoll6dzJlc+k0rJ+HQwlX4mUhbSD6eDqgGsl99PjaUBdHaU2RcVWbUjxQgUz7p2FNNlBIWga1xn 6roQypwE5ZuJuEYAzDz59bpegjPdgyyI8XZ5aOW6yA620P0TCyurspX9ln1bflWysB9O8+y8AqvA 0rfse80rkOVEt0K52TnRzMNSQKM6XgOt2trOBrp3huT5WmW7dvXVDK15GrFsAFyE13VXswjcy1VW g+UZ/M2zBkPq48VpW0edlTBeIPXz0bxP69krsfKwQrTPLcTV9OPASI4d5UL/yQNdRTeDyiktJFG+ rlFMvzkYWqNWx2hNxkPD9X3X6LQd37Daw7FtdSa+Y9svGV/WnHQ3xXSgEdbnW1k8MM2uFPNAJnul mH7BhLIrWHXXqEblJvHKbwD/EMVc1845U8xtC/8Pinl8ry6XYjrFleiiKOYeXl8p5mHMZ48Q15h7 RYLOiMUXFDB7pcoevc6LYu4R6Cq6GxSz9qGfUPu/AAAA//8DAFBLAwQUAAYACAAAACEAZRbrG+wA AABdAQAAEwAIAWRvY1Byb3BzL2N1c3RvbS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACckMFuwyAQRO+V8g9o7wRM6ja2MFFiJ+ce0twRxglSAMsQq1bVfy+W235Ab7ua1ZvZ 4bsPe0ejHoLxroJsTQFpp3xr3LWC9/MJbwGFKF0r797pCiYdYCdWT/xt8L0eotEBJYQLFdxi7EtC grppK8M6yS4pnR+sjGkdrsR3nVG68ephtYuEUfpC1CNEb3H/h4OFV47xv8jWqzlduJynPsUV/Ac+ oc5G01bw2eR10+Q0x+xY1Dij2QEXm+IV0y2l7MDqU7E/fgHq52MGyEmbXr8sLSXeGEvzLDJOloGT XwPByey89CK+AQAA//8DAFBLAwQUAAYACAAAACEAhGvdLV0CAAAfBQAAEAAIAWRvY1Byb3BzL2Fw cC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcVN9P2zAQfp+0/8HK0/ZQ 0kIFW+W6AgIrEpRqDVTam0kujTXHjnxugf31OydtaUWFtPnpfvl899195qOXSrMVOFTWDKPeUTdi YDKbK7MYRg/pdedbxNBLk0ttDQyjV8BoJD5/4lNna3BeATJKYXAYld7XgzjGrIRK4hG5DXkK6yrp SXWL2BaFyiCx2bIC4+Pjbvc0hhcPJoe8U28TRm3Gwcr/b9LcZqE+fExfaypY8BSqWksPgsdvYmq9 1KmqQHTJvFX43LocRe97j8etyM/rWqtMegJJ3KnMWbSFZ/dNO2xqn8FNrTKex7uBBBEg9dlcu25g EPemg5kDMGxW2mf2pT84+crjA4F8Kp1cOFmXKPpU3o7KZ1rlgOKUx2uJT6wnQ5/HrcDHKs/BrL10 e0/nd3eXWtUYut6IfJZJDZeEmSikRqDUWwMfgwz7MJXKoeArP1hB5q1jqP7QRvQj9iQRAtLDaCWd ksYT4iGsVRpZ1+idSGk1KDf5Wr0Rd8N2ZdUXNAGKJeHDwDZX0y1LldeA//AEoXjoiWBs26S39wFo n7gvaCT+AB5nu3g0pbVotFUmUMil9iwBVAuzW+cWlB9Xk6uf57c3v66SEbsg6j2r3JfsYOzF+SSZ 36Rjxual9Ewh8yUwotKThmp08EqL08kHPtqjbTFhjmt8rV4GAnQOX00UZksM30g8IU6zmYf6/Rya xQkkbMa0xfBWmd/4UKc2CRxdb+C+kc9K6SCnz2PjfzPwMS2f0yHJZSnNAvJNzHtH4PJj+9+J3vFR l05D240tsHHzs4m/AAAA//8DAFBLAwQUAAYACAAAACEAGNw9qJgBAAD/AgAAEQAIAWRvY1Byb3Bz L2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfJJda9swFIbvB/0P QlcdzJHs0Kwzjgrrx1UTDM1Y2Z2QThMxWzJHat38+8pK7Ha0K+jGPs95/J4jVxfPbUOeAL1xdknz GacErHLa2O2S/trcZOeU+CCtlo2zsKR78PRCnHypVFcqh1Cj6wCDAU+iyfpSdUu6C6ErGfNqB630 s0jYWHxw2MoQH3HLOqn+yi2wgvMFayFILYNkgzDrJiM9KrWalN0jNkmgFYMGWrDBs3yWs1c2ALb+ w4ZUeUO2Juy7ONMx7lu3VofiRD97M4F938/6eYoR8+fsfnV7l0bNjB12pYCKSqsymNCAqF0PWDtj A6kRfEwsQ1x2xSZiYBWCDA7FSuJWopHfyOUeTUNO13drkpGra7Z6tEbtvqa+kR5uoZE+rOKFPRjQ P/fi0DZqKvaeGJoQnsxw5aI4LxIzvRiVNcbEoEW+4HmWzobzMp0/k3WE4gRpuYcxQJO4rvKw3LHy e355tbmh//GNVBosfnUStsfJPjEWPJ9n/Hs255t8URY/yrMiJhyNo0Ck0P/+suIFAAD//wMAUEsD BBQABgAIAAAAIQDN62TC1wAAAFABAAARAAAAcHB0L3RhZ3MvdGFnMS54bWyMkEFLw0AQhe+C/2GZ u93oQSQkKaVGUIotJT2XIZkkC7uzy85a9d+7WHvw1uPw+D7em2r55aw6URTjuYb7RQGKuPeD4amG Q/dy9wRKEvKA1jPV8E0Cy+b2pgplwmkjSWUBS4k1zCmFUmvpZ3IoCx+Iczb66DDlM056iPiZxc7q h6J41A4Nwx8fr+H9OJqenn3/4YjTWRLJYsrlZTZBLrZwjS1Ekqz5pf9Vas7jFKPLi1f77nV92Ky6 9rjbb9/adXfc7tp3UCe0NRSgm0pfntH8AAAA//8DAFBLAQItABQABgAIAAAAIQCmVNfCegIAABQT AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAEe/ GtATAQAAdQMAAAsAAAAAAAAAAAAAAAAAswQAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhANq2 9V0ZAQAAngIAACAAAAAAAAAAAAAAAAAA9wcAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAFsIU0zZAAAAzgEAACAAAAAAAAAAAAAAAAAATgkAAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhADMOHgTBAAAANwEAACAAAAAA AAAAAAAAAAAAZQoAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhADMOHgTBAAAANwEAACAAAAAAAAAAAAAAAAAAZAsAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU0 LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXCJ4jZAAAAzgEAACAAAAAAAAAAAAAAAAAAYwwAAHBw dC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALy9+rjZAAAAzgEA ACAAAAAAAAAAAAAAAAAAeg0AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU2LnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhAAZgXlphAQAAhAcAAB8AAAAAAAAAAAAAAAAAkQ4AAHBwdC9fcmVscy9wcmVzZW50 YXRpb24ueG1sLnJlbHNQSwECLQAUAAYACAAAACEA9vIRbc4CAABcDgAAFAAAAAAAAAAAAAAAAAA3 EQAAcHB0L3ByZXNlbnRhdGlvbi54bWxQSwECLQAUAAYACAAAACEAAHtHQ8oFAABZGgAAFQAAAAAA AAAAAAAAAAA3FAAAcHB0L3NsaWRlcy9zbGlkZTUueG1sUEsBAi0AFAAGAAgAAAAhAGqic1V4BAAA oQ8AABUAAAAAAAAAAAAAAAAANBoAAHBwdC9zbGlkZXMvc2xpZGU2LnhtbFBLAQItABQABgAIAAAA IQCat6TRZAUAALIVAAAVAAAAAAAAAAAAAAAAAN8eAABwcHQvc2xpZGVzL3NsaWRlMy54bWxQSwEC LQAUAAYACAAAACEASQ9x1SsEAABsDwAAFQAAAAAAAAAAAAAAAAB2JAAAcHB0L3NsaWRlcy9zbGlk ZTIueG1sUEsBAi0AFAAGAAgAAAAhAK/fL/uNBQAAmxcAABUAAAAAAAAAAAAAAAAA1CgAAHBwdC9z bGlkZXMvc2xpZGU0LnhtbFBLAQItABQABgAIAAAAIQCmE9ue3QQAAGUSAAAVAAAAAAAAAAAAAAAA AJQuAABwcHQvc2xpZGVzL3NsaWRlMS54bWxQSwECLQAUAAYACAAAACEAsxOfipMEAAB6DgAAIQAA AAAAAAAAAAAAAACkMwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1sUEsBAi0AFAAG AAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAdjgAAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAA AAAAAAAAAAAAfjkAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAhjoAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAA NwEAACwAAAAAAAAAAAAAAAAAjjsAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQy LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAljwAAHBw dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh AGmiXyEeAQAAxwcAACwAAAAAAAAAAAAAAAAAnj0AAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMvc2xp ZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAA AAAABj8AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAADkAAAHBwdC9zbGlkZUxheW91dHMv X3JlbHMvc2xpZGVMYXlvdXQ3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwA AAAAAAAAAAAAAAAAFkEAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAJn2ma7VAAAAvwEAACoAAAAAAAAAAAAAAAAAHkIAAHBwdC9ub3Rl c1NsaWRlcy9fcmVscy9ub3Rlc1NsaWRlMi54bWwucmVsc1BLAQItABQABgAIAAAAIQBKr3U51AAA AL8BAAAqAAAAAAAAAAAAAAAAADtDAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTEu eG1sLnJlbHNQSwECLQAUAAYACAAAACEATyAyGFsIAAC0NwAAIQAAAAAAAAAAAAAAAABXRAAAcHB0 L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEA AC0AAAAAAAAAAAAAAAAA8UwAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54 bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAAAAAAAAAAAAAAPpNAABwcHQv c2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEA 1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAAADTwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlk ZUxheW91dDkueG1sLnJlbHNQSwECLQAUAAYACAAAACEAI9CoCdUAAAC/AQAAKgAAAAAAAAAAAAAA AAALUAAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGU0LnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhADYfPKDHAwAACgwAACEAAAAAAAAAAAAAAAAAKFEAAHBwdC9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQyLnhtbFBLAQItABQABgAIAAAAIQBtnZI3awQAAPgSAAAhAAAAAAAAAAAAAAAAAC5V AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWxQSwECLQAUAAYACAAAACEAejkUUuAD AABBDAAAIgAAAAAAAAAAAAAAAADYWQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEwLnht bFBLAQItABQABgAIAAAAIQC3dGwPFgUAANESAAAhAAAAAAAAAAAAAAAAAPhdAABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0OS54bWxQSwECLQAUAAYACAAAACEA8vWpLUYFAABPEwAAIQAAAAAA AAAAAAAAAABNYwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgueG1sUEsBAi0AFAAGAAgA AAAhAJcXM5bFAgAAqAcAACEAAAAAAAAAAAAAAAAA0mgAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQ3LnhtbFBLAQItABQABgAIAAAAIQBteFQAQQMAABcJAAAhAAAAAAAAAAAAAAAAANZrAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWxQSwECLQAUAAYACAAAACEAY+Xj4MUFAAD5 HAAAIQAAAAAAAAAAAAAAAABWbwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDUueG1sUEsB Ai0AFAAGAAgAAAAhAPCJRJ7VAAAAvwEAACoAAAAAAAAAAAAAAAAAWnUAAHBwdC9ub3Rlc1NsaWRl cy9fcmVscy9ub3Rlc1NsaWRlMy54bWwucmVsc1BLAQItABQABgAIAAAAIQDYKjOIDwQAACENAAAi AAAAAAAAAAAAAAAAAHd2AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1sUEsBAi0A FAAGAAgAAAAhAAj5PUCZAgAAXQYAAB8AAAAAAAAAAAAAAAAAxnoAAHBwdC9ub3Rlc1NsaWRlcy9u b3Rlc1NsaWRlMS54bWxQSwECLQAUAAYACAAAACEAMEeHL1QEAAAsDgAAIQAAAAAAAAAAAAAAAACc fQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0AFAAGAAgAAAAhAOorFKKa AgAAXQYAAB8AAAAAAAAAAAAAAAAAL4IAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlNC54bWxQ SwECLQAUAAYACAAAACEAdTB9pJYCAABdBgAAHwAAAAAAAAAAAAAAAAAGhQAAcHB0L25vdGVzU2xp ZGVzL25vdGVzU2xpZGUyLnhtbFBLAQItABQABgAIAAAAIQCkZHCemgIAAF0GAAAfAAAAAAAAAAAA AAAAANmHAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTMueG1sUEsBAi0AFAAGAAgAAAAhAKug 24orCwAAZkIAABQAAAAAAAAAAAAAAAAAsIoAAHBwdC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAG AAgAAAAhAE6hqkyBBgAA+CIAACEAAAAAAAAAAAAAAAAADZYAAHBwdC9ub3Rlc01hc3RlcnMvbm90 ZXNNYXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQC0z1gZuwAAACQBAAAsAAAAAAAAAAAAAAAAAM2c AABwcHQvbm90ZXNNYXN0ZXJzL19yZWxzL25vdGVzTWFzdGVyMS54bWwucmVsc1BLAQItAAoAAAAA AAAAIQBsozSoAFQAAABUAAAXAAAAAAAAAAAAAAAAANKdAABkb2NQcm9wcy90aHVtYm5haWwuanBl Z1BLAQItABQABgAIAAAAIQB0sUijYAYAADIbAAAUAAAAAAAAAAAAAAAAAAfyAABwcHQvdGhlbWUv dGhlbWUyLnhtbFBLAQItABQABgAIAAAAIQBYm5DCqgAAAB8BAAARAAAAAAAAAAAAAAAAAJn4AABw cHQvcHJlc1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQBBsvwqxAEAABIEAAARAAAAAAAAAAAAAAAA AHL5AABwcHQvdmlld1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQCSOejd1QIAAIsVAAATAAAAAAAA AAAAAAAAAGX7AABwcHQvdGFibGVTdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAGUW6xvsAAAAXQEA ABMAAAAAAAAAAAAAAAAAa/4AAGRvY1Byb3BzL2N1c3RvbS54bWxQSwECLQAUAAYACAAAACEAhGvd LV0CAAAfBQAAEAAAAAAAAAAAAAAAAACQAAEAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAA IQAY3D2omAEAAP8CAAARAAAAAAAAAAAAAAAAACMEAQBkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQA BgAIAAAAIQDN62TC1wAAAFABAAARAAAAAAAAAAAAAAAAAPIGAQBwcHQvdGFncy90YWcxLnhtbFBL BQYAAAAAPAA8ACESAAD4BwEAAAA= --_004_523C37072C291347B9730C9291CCA07D0D04AFDB3PRD0411MB427eu_-- From ramon.casellas@cttc.es Tue Jul 30 14:38:22 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12EE11E814B for ; Tue, 30 Jul 2013 14:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTbKEtBNmZSW for ; Tue, 30 Jul 2013 14:38:22 -0700 (PDT) Received: from torres.puc.rediris.es (torres.puc.rediris.es [IPv6:2001:720:418:ca00::9]) by ietfa.amsl.com (Postfix) with ESMTP id B5E7B11E8125 for ; Tue, 30 Jul 2013 14:38:08 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by torres.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1V4HcH-0003Nx-0p; Tue, 30 Jul 2013 23:38:01 +0200 Received: from [10.25.11.163] (unknown [46.189.28.57]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 7E3AF1FD41; Tue, 30 Jul 2013 23:37:58 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <51F81614.1020409@cttc.es> Date: Tue, 30 Jul 2013 21:37:56 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Margaria, Cyril (Coriant - DE/Munich)" References: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5@ENFICSMBX1.datcon.co.uk> <523C37072C291347B9730C9291CCA07D0CC675@DB3PRD0411MB427.eurprd04.prod.outlook.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863A@ENFICSMBX1.datcon.co.uk> <51F78824.4060907@cttc.es> <523C37072C291347B9730C9291CCA07D0D04AF@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: <523C37072C291347B9730C9291CCA07D0D04AF@DB3PRD0411MB427.eurprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------010302010807070906050008" X-Spamina-Bogosity: Ham Cc: "pce@ietf.org" Subject: Re: [Pce] =?utf-8?b?562U5aSNOiAgQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1wY2Ut?= =?utf-8?q?gmpls-pcep-extensions-08?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 21:38:23 -0000 This is a multi-part message in MIME format. --------------010302010807070906050008 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 30/07/2013 18:33, Margaria, Cyril (Coriant - DE/Munich) escribió: > > Hi PCE WG, > > 3)Treat this as an errata to RFC5440 ““The BANDWIDTH *of OT 1 and OT > 2* object body have a fixed length of 4 bytes.â€, and define new OT > for GMPLS > PCErs, all Rather than "Errata" :) consider it a liberal interpretation, but I guess this approach is a nice trade-off. Maybe a solution could be to define Ctypes 3 and 4 which are like 1 and 2 but allowing TLVs (generically), then define a TLV to encode GMPLS traffic parameters. The BW objects can have a 32 bit IEEE floating point encoding of the nominal rate. Current implementations support 1 and 2 with fixed size. New Ctypes can be addressed with "unknown object ctype", hopefully without strictly checking the object length. Just my view, of course R. --------------010302010807070906050008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
El 30/07/2013 18:33, Margaria, Cyril (Coriant - DE/Munich) escribió:

Hi PCE WG,

 

3)      Treat this as an errata to RFC5440 ““The BANDWIDTH of OT 1 and OT 2  object body have a fixed length of 4 bytes.â€, and define new OT for GMPLS

 

PCErs, all

Rather than "Errata" :) consider it a liberal interpretation, but I guess this approach is a nice trade-off.
Maybe a solution could be to define Ctypes 3 and 4 which are like 1 and 2 but allowing TLVs (generically), then define a TLV to encode GMPLS traffic parameters. The BW objects can have a 32 bit IEEE floating point encoding of the nominal rate. Current implementations support 1 and 2 with fixed size. New Ctypes can be addressed with "unknown object ctype", hopefully without strictly checking the object length.

Just my view, of course
R.

--------------010302010807070906050008-- From wang.qilei@zte.com.cn Tue Jul 30 19:56:53 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7467121F9C87 for ; Tue, 30 Jul 2013 19:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.753 X-Spam-Level: X-Spam-Status: No, score=-97.753 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnyVySzCZ8rC for ; Tue, 30 Jul 2013 19:56:49 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCFE21F9C83 for ; Tue, 30 Jul 2013 19:56:43 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id AA35C48319 for ; Wed, 31 Jul 2013 10:56:13 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id C4FA37442A5; Wed, 31 Jul 2013 10:56:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r6V2uCiK016366; Wed, 31 Jul 2013 10:56:12 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn) In-Reply-To: <51F81614.1020409@cttc.es> References: <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F61A5@ENFICSMBX1.datcon.co.uk> <523C37072C291347B9730C9291CCA07D0CC675@DB3PRD0411MB427.eurprd04.prod.outlook.com> <09CE6C3BE5E1EA40B987BF5F25D8DDBAE10F863A@ENFICSMBX1.datcon.co.uk> <51F78824.4060907@cttc.es> <523C37072C291347B9730C9291CCA07D0D04AF@DB3PRD0411MB427.eurprd04.prod.outlook.com> <51F81614.1020409@cttc.es> To: Ramon Casellas , "Margaria, Cyril (Coriant - DE/Munich)" MIME-Version: 1.0 X-KeepSent: 8F4853E1:A55F62DF-48257BB9:000DD3EC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.qilei@zte.com.cn Date: Wed, 31 Jul 2013 10:56:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-31 10:55:56, Serialize complete at 2013-07-31 10:55:56 Content-Type: multipart/alternative; boundary="=_alternative 0010262448257BB9_=" X-MAIL: mse01.zte.com.cn r6V2uCiK016366 Cc: "pce@ietf.org" Subject: Re: [Pce] =?gb2312?b?tPC4tDogIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGNlLWdt?= =?gb2312?b?cGxzLXBjZXAtZXh0ZW5zaW9ucy0wOA==?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 02:56:53 -0000 This is a multipart message in MIME format. --=_alternative 0010262448257BB9_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIFJhbW9uLCBDeXJpbCAmIGFsbCwNCg0KSSBzZWNvbmQgdGhpcyBzb2x1dGlvbi4NCg0KRGVm aW5pbmcgbmV3IEMtdHlwZSBjYW4gYWxzbyBrZWVwIHRoZSBjdXJyZW50IHByb3RvY29sIGFuZCBp bXBsZW1lbnRhdGlvbiANCnVudG91Y2hlZC4gQnV0IHdlIG5lZWQgdG8gbG9vc2UgdGhlIHJlc3Ry aWN0aW9uIG9mIGJhbmR3aWR0aCBvYmplY3QgaW4gDQpSRkM1NDQwIGZpcnN0Lg0KDQpCZXNpZGVz LCBJTUhPLCB0aGUgc29sdXRpb24gYWxsb3dpbmcgVExWcyBjYW4gYmV0dGVyIGhlbHAgdGhlIHBh dGggDQpjb21wdXRhdGlvbiBwcm9jZXNzLiBUaGVyZSBpcyBubyBuZWVkIHRvIHJldHJpZXZlIGhv bW9nZW5vdXMgcGFyYW1ldGVycyANCmZyb20gdHdvIGRpZmZlcmVudCBvYmplY3RzIGZvciBQQ0Ug d2hlbiBjb21wdXRpbmcgdGhlIHBhdGguDQoNCkp1c3QgbXkgdmlldyB0b28uDQoNClRoYW5rcw0K UWlsZWkgV2FuZw0KDQoNCg0KDQoNClJhbW9uIENhc2VsbGFzIDxyYW1vbi5jYXNlbGxhc0BjdHRj LmVzPiANCuWPkeS7tuS6ujogIHBjZS1ib3VuY2VzQGlldGYub3JnDQoyMDEzLTA3LTMxIDAzOjM3 DQoNCuaUtuS7tuS6ug0KIk1hcmdhcmlhLCBDeXJpbCAoQ29yaWFudCAtIERFL011bmljaCkiIDxj eXJpbC5tYXJnYXJpYUBjb3JpYW50LmNvbT4sIA0K5oqE6YCBDQoicGNlQGlldGYub3JnIiA8cGNl QGlldGYub3JnPg0K5Li76aKYDQpSZTogW1BjZV0g562U5aSNOiAgQ29tbWVudHMgb24gZHJhZnQt aWV0Zi1wY2UtZ21wbHMtcGNlcC1leHRlbnNpb25zLTA4DQoNCg0KDQoNCg0KDQpFbCAzMC8wNy8y MDEzIDE4OjMzLCBNYXJnYXJpYSwgQ3lyaWwgKENvcmlhbnQgLSBERS9NdW5pY2gpIGVzY3JpYmnD szoNCkhpIFBDRSBXRywgDQogIA0KMykgICAgICBUcmVhdCB0aGlzIGFzIGFuIGVycmF0YSB0byBS RkM1NDQwIOKAnOKAnFRoZSBCQU5EV0lEVEggb2YgT1QgMSBhbmQgDQpPVCAyICBvYmplY3QgYm9k eSBoYXZlIGEgZml4ZWQgbGVuZ3RoIG9mIDQgYnl0ZXMu4oCdLCBhbmQgZGVmaW5lIG5ldyBPVCBm b3IgDQpHTVBMUw0KIA0KUENFcnMsIGFsbA0KDQpSYXRoZXIgdGhhbiAiRXJyYXRhIiA6KSBjb25z aWRlciBpdCBhIGxpYmVyYWwgaW50ZXJwcmV0YXRpb24sIGJ1dCBJIGd1ZXNzIA0KdGhpcyBhcHBy b2FjaCBpcyBhIG5pY2UgdHJhZGUtb2ZmLiANCk1heWJlIGEgc29sdXRpb24gY291bGQgYmUgdG8g ZGVmaW5lIEN0eXBlcyAzIGFuZCA0IHdoaWNoIGFyZSBsaWtlIDEgYW5kIDIgDQpidXQgYWxsb3dp bmcgVExWcyAoZ2VuZXJpY2FsbHkpLCB0aGVuIGRlZmluZSBhIFRMViB0byBlbmNvZGUgR01QTFMg dHJhZmZpYyANCnBhcmFtZXRlcnMuIFRoZSBCVyBvYmplY3RzIGNhbiBoYXZlIGEgMzIgYml0IElF RUUgZmxvYXRpbmcgcG9pbnQgZW5jb2RpbmcgDQpvZiB0aGUgbm9taW5hbCByYXRlLiBDdXJyZW50 IGltcGxlbWVudGF0aW9ucyBzdXBwb3J0IDEgYW5kIDIgd2l0aCBmaXhlZCANCnNpemUuIE5ldyBD dHlwZXMgY2FuIGJlIGFkZHJlc3NlZCB3aXRoICJ1bmtub3duIG9iamVjdCBjdHlwZSIsIGhvcGVm dWxseSANCndpdGhvdXQgc3RyaWN0bHkgY2hlY2tpbmcgdGhlIG9iamVjdCBsZW5ndGguIA0KDQpK dXN0IG15IHZpZXcsIG9mIGNvdXJzZQ0KUi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCg0K --=_alternative 0010262448257BB9_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBSYW1vbiwgQ3lyaWwgJmFtcDsgYWxs LDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBzZWNv bmQgdGhpcyBzb2x1dGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkRlZmluaW5nIG5ldyBDLXR5cGUgY2FuIGFsc28ga2VlcCB0aGUNCmN1cnJlbnQg cHJvdG9jb2wgYW5kIGltcGxlbWVudGF0aW9uIHVudG91Y2hlZC4gQnV0IHdlIG5lZWQgdG8gbG9v c2UgdGhlDQpyZXN0cmljdGlvbiBvZiBiYW5kd2lkdGggb2JqZWN0IGluIFJGQzU0NDAgZmlyc3Qu PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CZXNpZGVz LCBJTUhPLCB0aGUgc29sdXRpb24gYWxsb3dpbmcNClRMVnMgY2FuIGJldHRlciBoZWxwIHRoZSBw YXRoIGNvbXB1dGF0aW9uIHByb2Nlc3MuIFRoZXJlIGlzIG5vIG5lZWQgdG8NCnJldHJpZXZlIGhv bW9nZW5vdXMgcGFyYW1ldGVycyBmcm9tIHR3byBkaWZmZXJlbnQgb2JqZWN0cyBmb3IgUENFIHdo ZW4NCmNvbXB1dGluZyB0aGUgcGF0aC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPkp1c3QgbXkgdmlldyB0b28uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPlFpbGVpIFdhbmc8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+UmFtb24gQ2FzZWxsYXMgJmx0 O3JhbW9uLmNhc2VsbGFzQGN0dGMuZXMmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7lj5Hku7bkuro6ICZuYnNwO3BjZS1ib3VuY2VzQGlldGYub3Jn PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTMtMDctMzEgMDM6 Mzc8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPuaUtuS7tuS6ujwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+JnF1b3Q7TWFyZ2FyaWEsIEN5cmlsIChDb3JpYW50IC0gREUvTXVuaWNoKSZxdW90Ow0K Jmx0O2N5cmlsLm1hcmdhcmlhQGNvcmlhbnQuY29tJmd0OywgPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7mioTpgIE8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PiZxdW90O3BjZUBpZXRmLm9yZyZxdW90OyAmbHQ7cGNlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+5Li76aKYPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5SZTogW1BjZV0g562U5aSNOiAmbmJzcDtDb21tZW50cyBvbg0KZHJhZnQtaWV0 Zi1wY2UtZ21wbHMtcGNlcC1leHRlbnNpb25zLTA4PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFi bGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkVsIDMwLzA3LzIwMTMgMTg6MzMsIE1hcmdhcmlh LCBDeXJpbCAoQ29yaWFudCAtIERFL011bmljaCkNCmVzY3JpYmnDszo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSM4MTNmNjIgZmFjZT0iQ2FsaWJyaSI+SGkgUENFIFdHLCA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MTNmNjIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7IDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgxM2Y2MiBmYWNlPSJDYWxpYnJpIj4zKSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KVHJlYXQgdGhpcyBhcyBhbiBlcnJhdGEgdG8g UkZDNTQ0MCDigJzigJxUaGUgQkFORFdJRFRIIDxiPm9mIE9UIDEgYW5kIE9UDQoyPC9iPiAmbmJz cDtvYmplY3QgYm9keSBoYXZlIGEgZml4ZWQgbGVuZ3RoIG9mIDQgYnl0ZXMu4oCdLCBhbmQgZGVm aW5lDQpuZXcgT1QgZm9yIEdNUExTPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jODEz ZjYyIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9Mz5QQ0Vycywg YWxsPGJyPg0KPGJyPg0KUmF0aGVyIHRoYW4gJnF1b3Q7RXJyYXRhJnF1b3Q7IDopIGNvbnNpZGVy IGl0IGEgbGliZXJhbCBpbnRlcnByZXRhdGlvbiwNCmJ1dCBJIGd1ZXNzIHRoaXMgYXBwcm9hY2gg aXMgYSBuaWNlIHRyYWRlLW9mZi4gPGJyPg0KTWF5YmUgYSBzb2x1dGlvbiBjb3VsZCBiZSB0byBk ZWZpbmUgQ3R5cGVzIDMgYW5kIDQgd2hpY2ggYXJlIGxpa2UgMSBhbmQNCjIgYnV0IGFsbG93aW5n IFRMVnMgKGdlbmVyaWNhbGx5KSwgdGhlbiBkZWZpbmUgYSBUTFYgdG8gZW5jb2RlIEdNUExTIHRy YWZmaWMNCnBhcmFtZXRlcnMuIFRoZSBCVyBvYmplY3RzIGNhbiBoYXZlIGEgMzIgYml0IElFRUUg ZmxvYXRpbmcgcG9pbnQgZW5jb2RpbmcNCm9mIHRoZSBub21pbmFsIHJhdGUuIEN1cnJlbnQgaW1w bGVtZW50YXRpb25zIHN1cHBvcnQgMSBhbmQgMiB3aXRoIGZpeGVkDQpzaXplLiBOZXcgQ3R5cGVz IGNhbiBiZSBhZGRyZXNzZWQgd2l0aCAmcXVvdDt1bmtub3duIG9iamVjdCBjdHlwZSZxdW90OywN CmhvcGVmdWxseSB3aXRob3V0IHN0cmljdGx5IGNoZWNraW5nIHRoZSBvYmplY3QgbGVuZ3RoLiA8 YnI+DQo8YnI+DQpKdXN0IG15IHZpZXcsIG9mIGNvdXJzZTxicj4NClIuPGJyPg0KPC9mb250Pjx0 dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpQY2UgbWFpbGluZyBsaXN0PGJyPg0KUGNlQGlldGYub3JnPGJyPg0KPC9mb250 PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZT48 dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNl PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8cD4N Cg== --=_alternative 0010262448257BB9_=-- From diego@tid.es Wed Jul 31 02:16:29 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C940121F9DB0 for ; Wed, 31 Jul 2013 02:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.997 X-Spam-Level: X-Spam-Status: No, score=-4.997 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPUnnaqFIBPS for ; Wed, 31 Jul 2013 02:16:23 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id A613321F9DAF for ; Wed, 31 Jul 2013 02:11:48 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MQS00A36MVMOS@tid.hi.inet> for pce@ietf.org; Wed, 31 Jul 2013 11:11:46 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 4F.F4.02911.2D4D8F15; Wed, 31 Jul 2013 11:11:46 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MQS00A33MVMOS@tid.hi.inet> for pce@ietf.org; Wed, 31 Jul 2013 11:11:46 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.81]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0123.003; Wed, 31 Jul 2013 11:11:45 +0200 Date: Wed, 31 Jul 2013 09:11:45 +0000 From: "Diego R. Lopez" X-Originating-IP: [10.95.64.115] To: "pce@ietf.org" Message-id: Content-id: <485E30A8B32A2846922981E12B23B283@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: Draft on securing PCEP (a.k.a. PCEPS) Thread-index: AQHOjc36C6T/1NLiZEGibZT6/euQGA== X-AuditID: 0a5f4e69-b7f118e000000b5f-b6-51f8d4d2c534 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsXCFe9nqHvpyo9Agzf7LC2a7t9gd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvSN35gLZvFXrJ57i6WB8QVfFyMnh4SAicSqVX1MELaYxIV7 69m6GLk4hAS2M0ps3PSRBcL5ziixa+ZTRghnA6NE/8W/LCAtLAKqEjsXz2EDsdmA7EfNv9lB bGEBPYk9zzYxQoxVkPhz7jFYvYiAosT3G6vB6nkFLCVO3f8NVsMsYCbxouUVK0RcUOLH5HtA 9RxAcXWJKVNyIUrEJZpbb7JA2IoS0xY1gLUyCshKvJs/nxVivLFEZ/sHRghbT2Lh1alQJwhI LNlznhnCFpV4+fgf6wRG0VlINs9CsnkWwuZZSDbPQrJ5ASPrKkax4qSizPSMktzEzJx0AyO9 jEy9zLzUkk2MkGjJ3MG4fKfKIUYBDkYlHl6HC98DhVgTy4orcw8xSnAwK4nwygf9CBTiTUms rEotyo8vKs1JLT7EyMTBKdXAaBBneU9zz7y692pLj181FDjDL71WbfdkmVULwq7ePOMyYdK9 5swD8WyvlIq3zVtplCPLFXJkz9sAlZI5CpUKdr9vHllr51us/u2EPavfN6eQpwYCph9N/W83 r445Zhs7s5TLZtOxkye3dcgxbJpo9+KXuZH4x/lXFPM3L8tmi05qP5U124GzQImlOCPRUIu5 qDgRAHgdjnh0AgAA Subject: [Pce] Draft on securing PCEP (a.k.a. PCEPS) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:16:29 -0000 SGksDQoNClRoaXMgaXMgYSBraW5kIHJlbWluZGVyIG9uIHRoZSBkcmFmdCB3ZSBoYXZlIHByZXNl bnRlZCBvbiBhcHBseWluZyBUTFMgYXMgc2VjdXJlIHRyYW5zcG9ydCBmb3IgUENFUCAoUENFUFMp DQoNCkJlY2F1c2Ugb2YgYSBtaXN0YWtlIEkgbWFkZSBpdCBpcyBjdXJyZW50bHkgbmFtZWQgZHJh ZnQtbG9wZXotcGNwLXBjZXBzLTAwIChub3RoaW5nIHRvIGRvIHdpdGggUENQLCBhcyB5b3UgY2Fu IGltYWdpbmUpDQpBZnRlciB0aGlzIG1lZXRpbmcgd2Ugd2lsbCB1cGRhdGUgYW5kIHJlbmFtZSBp dCBpbnRvIGRyYWZ0LWxvcGV6LXBjcC1wY2Vwcy0wMCwgYXMgaXQgc2hvdWxkIGJlLg0KDQpBbmQg YmVjYXVzZSBhIG1pc3VuZGVyc3RhbmRpbmcgY2F1c2VkIGJ5IHRoZSBwcmV2aW91cyBtaXN0YWtl IHdlIHdpbGwgbm90IGJlIGFibGUgdG8gcHJlc2VudCBpdCBhdCB0aGUgUENFIG1lZXRpbmcgdG9k YXkuIEkgYXNrZWQgdGhlIEtBUlAgY2hhaXJzIGFuZCB0aGV5IGhhdmUgYWxsb2NhdGVkIGEgc2xv dCBmb3IgcHJlc2VudGluZyBpdCBhdCB0aGVpciBtZWV0aW5nIChDaGFybG90dGVuYnVyZyAxLCBm cm9tIDEzOjAwIHRvIDE1OjAwKS4gVGhlIFBDRSBjaGFpcnMgaGFzIGluY2x1ZGVkIGEgbWVudGlv biB0byB0aGUgZHJhZnQgaW4gdGhlIGFnZW5kYSwgYnV0IGlmIHlvdSBhcmUgaW50ZXJlc3RlZCB0 byBoYXZlIGEgZmlyc3QgZGV0YWlsZWQgY29udGFjdCB3aXRoIHRoZSBpZGVhcyB1bmRlcnBpbm5p bmcgdGhlIGRyYWZ0IHBsZWFzZSBjb21lIHRvIHRoZSBLQVJQIHNlc3Npb24uDQoNCkJlIGdvb2Rl LA0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIg RGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVn by5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQx DQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3Rl IG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVk ZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBj b3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlz IG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9u bHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBv dXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From adrian@olddog.co.uk Wed Jul 31 06:46:27 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F087A21F9FF2 for ; Wed, 31 Jul 2013 06:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUeMUUB6QhrH for ; Wed, 31 Jul 2013 06:46:21 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 79EA521F9BB1 for ; Wed, 31 Jul 2013 06:46:07 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6VDjrxu021911; Wed, 31 Jul 2013 14:45:53 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6VDjorV021793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Jul 2013 14:45:51 +0100 From: "Adrian Farrel" To: "'Margaria, Cyril \(Coriant - DE/Munich\)'" , "'Fatai Zhang'" , "'Ramon Casellas'" , "'Jonathan Hardwick'" , Date: Wed, 31 Jul 2013 14:45:46 +0100 Message-ID: <04fc01ce8df4$449e3a40$cddaaec0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04FD_01CE8DFC.A669CE30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6N9DiVJiun0U6YRwaJrGQj4XjIeQ== Content-Language: en-gb Subject: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:46:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04FD_01CE8DFC.A669CE30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Cyril, =20 Thanks for raising the question. =20 Before getting on to discuss how to make the change, we need to dig more = into "why to make the change". =20 I went straight to this draft trying to find the reasoning. In 1.3 I found... [RFC5440] does not include the ability to convey a (Intserv) TSPEC object. I probably made the mistake of stopping when I reached this text. The text is completely true! However, 5440 was wilful in its choice to not support Intserv on the = understanding (which might not be true anymore, but probably is) that = no-one uses Intserv TSpec in their MPLS-TE or GMPLS implementations. =20 *If* Intserv is the only reason for the discussion of changing the = Bandwidth object, we should drop the discussion, IMHO. =20 I then went to draft-ietf-pce-gmpls-aps-req and searched for "bandwidth" = and the only discussion I found was with respect to the asymmetrical = requirements. =20 =20 At the mic, Cyril and Fatai helped me to understand that the requirement = is not specific to bandwidth, but is related to Traffic Parameters that = will be signaled. This breaks the problem out into three different use = cases: =20 1. The PCC wishes to request *bandwidth*. It does not mind it gets a fat = pipe or VCAT, a lambda or OTN. 2. The PCC wants bandwidth, but *does* care about how this supplied in = the network. This makes the request: i. layer-specific ii. sub-layer-specific iii. label-specific 3. The PCE wants to convey information to the PCC about what details it = needs to place in signaling. =20 My view is that the Bandwidth object is not called the "Sender-TSpec = object for use if the PCC just happens to be the ingress node of a GMPLS = LSP" object! My view is that the bandwidth object describes the = bandwidth that has been requested, and the bandwidth that the supplied = path will actually be able to supply (may be >, =3D, or < requested = b/w). =20 Thus, IMHO, if we want to constrain the request to return paths that use = a limited set of the available network resources, we need to add this = through other objects. =20 And if we want to give information to the PCC that it can map to = specific details in the signaling protocol, then we should provide that = detail in objects specifically intended to carry that information. This = information is clearly related to bandwidth, but it is not the same as = bandwidth. =20 Just my =E2=82=AC0.02 =20 Adrian =20 From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Margaria, Cyril (Coriant - DE/Munich) Sent: 30 July 2013 17:33 To: Fatai Zhang; Ramon Casellas; Jonathan Hardwick; pce@ietf.org Subject: Re: [Pce] =E7=AD=94=E5=A4=8D: Comments on = draft-ietf-pce-gmpls-pcep-extensions-08 =20 Hi PCE WG,=20 =20 The Problem we had with the BANDWIDTH (and LOAD-BALANCING BTW) object is = that RFC5440 section 7.7 defines=20 =E2=80=9CThe BANDWIDTH object body has a fixed length of 4 = bytes.=E2=80=9D =20 RFC5440 defines two OT : 1 and 2. The text can be interpreted as all OT = (current and future) should have length =3D 4, this is not future = friendly. =20 Now several options can be considered : =20 1) GMPLS-pcep extensions : new object, keep existing implementation = untouched, at the expense of the gmpls ones (more complex rules)=20 2) Allow TLV in the BANDWIDTH=20 3) Treat this as an errata to RFC5440 =E2=80=9C=E2=80=9CThe = BANDWIDTH of OT 1 and OT 2 object body have a fixed length of 4 = bytes.=E2=80=9D, and define new OT for GMPLS =20 The Cons of 1 is discussed below. The cons of the TLV would be to change existing object definition and = make the protocol definition rather awkward : different Object format = depending on OPEN (for example) negotiation and would not help for new = CTypes =20 With 3) the existing implementation for existing CType will see no = change, it may be a problem for new CTypes (anyhow not supported), but = an implementation may return an Unknow object, unknown object type OR = treated as invalid object. This can be solved by negotiating the use of = OT>2 for BANDWIDTH (and LOAD-BALANCING) =20 For the sake of discussion I attach a slideset if by any chance there is = some time left during the session, =20 =20 =20 =20 =20 =20 =20 =20 Mit freundlichen Gr=C3=BC=C3=9Fen / Best Regards=20 Cyril Margaria=20 From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Fatai Zhang Sent: Tuesday, July 30, 2013 2:41 PM To: Ramon Casellas; Jonathan Hardwick; pce@ietf.org Subject: [Pce] =E7=AD=94=E5=A4=8D: Comments on = draft-ietf-pce-gmpls-pcep-extensions-08 =20 Hi all, =20 I think a new object type could be better and simple. =20 Thanks =20 Fatai =20 =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: pce-bounces@ietf.org = [mailto:pce-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Ramon Casellas =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8830=E6=97=A5 = 17:32 =E6=94=B6=E4=BB=B6=E4=BA=BA: Jonathan Hardwick; pce@ietf.org =E4=B8=BB=E9=A2=98: Re: [Pce] Comments on = draft-ietf-pce-gmpls-pcep-extensions-08 =20 On 07/30/2013 11:08 AM, Jonathan Hardwick wrote: Cyril and I had an offline conversation about these comments. This = email is to document the discussion for the benefit of the mailing list. = See [JEH-MC] comments below. =20 We have one question for the WG, as follows. If anyone has an opinion = on this, please could you provide it to the mailing list? =20 --- [JEH-MC] Jon believes that this draft should relax the restriction of = RFC 5440 that the BANDWIDTH object is mandatory, in the case where a = GENERALIZED-BANDWIDTH is supplied instead. This would mean changing = existing procedures, the initial mechanism was not to change RFC5440 = object presence rule. Cyril is fine with the proposal from Jonathan, = but we would like to get WG and implementers feedback.=20 =20 Jon, Cyril, all In this case, I would go back to one of my initial suggestions: do not = add GENERALIZED_BANDWIDTH and add a TLV to the BW objects, which can be = ignored. In other words, the creation of GEN_BW was justified due to: a) do not = touch rfc5440 b) if RFC5440 does not state that BW object can have TLVs, = then they can't and it is fixed length. My personal preference always was to add a TLV or a new object type for = BW. If we allow ourselves a liberal interpretation of rfc5440 then = let's assume we can add a tlv... Just my opinion, of course, and not a particularly strong one Ramon --=20 Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division Optical Networks and Systems Department -- http://wikiona.cttc.es CTTC - Centre Tecnol=C3=B2gic de Telecomunicacions de Catalunya Parc Mediterrani de la Tecnologia (PMT) - Edifici B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01=20 ------=_NextPart_000_04FD_01CE8DFC.A669CE30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Cyril,

 

Thanks for raising the = question.

 

Before getting on to = discuss how to make the change, we need to dig more into "why to = make the change".

 

I went straight to = this draft trying to find the reasoning.

In 1.3 I = found...

=C2=A0=C2=A0=C2=A0=C2=A0 [RFC5440] = does not include the ability to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 convey = a (Intserv) TSPEC object.

I probably made the = mistake of stopping when I reached this text.

The text is completely = true!

However, 5440 was = wilful in its choice to not support Intserv on the understanding (which = might not be true anymore, but probably is) that no-one uses Intserv = TSpec in their MPLS-TE or GMPLS implementations.

 

*If* Intserv is the = only reason for the discussion of changing the Bandwidth object, we = should drop the discussion, IMHO.

 

I then went to = draft-ietf-pce-gmpls-aps-req and searched = for "bandwidth" and the only discussion I found was with = respect to the asymmetrical requirements.

 

 

At the mic, Cyril and Fatai = helped me to understand that the requirement is not specific to = bandwidth, but is related to Traffic Parameters that will be signaled. This breaks the problem out into three = different use cases:

 

1. The PCC wishes to = request *bandwidth*. It does not mind it gets a fat pipe or VCAT, a = lambda or OTN.

2. The PCC wants = bandwidth, but *does* care about how this supplied in the network. This = makes the request:

=C2=A0=C2=A0 i. = layer-specific

=C2=A0=C2=A0 ii. = sub-layer-specific

=C2=A0=C2=A0 iii. = label-specific

3. The PCE wants to = convey information to the PCC about what details it needs to place in = signaling.

 

My view is that the = Bandwidth object is not called the "Sender-TSpec object for use if the PCC just happens to be = the ingress node of a GMPLS LSP" object! My view is that the = bandwidth object describes the bandwidth that has been requested, and = the bandwidth that the supplied path will actually be able to supply = (may be >, =3D, or < requested b/w).

 

Thus, IMHO, if we want = to constrain the request to return paths that use a limited set of the = available network resources, we need to add this through other = objects.

 

And if we want to give = information to the PCC that it can map to specific details in the signaling protocol, then we should provide that = detail in objects specifically intended to carry that information.=C2=A0 This information is clearly = related to bandwidth, but it is not the same as = bandwidth.

 

Just my = =E2=82=AC0.02

 

Adrian

 

From: = pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Margaria, Cyril (Coriant - DE/Munich)
Sent: 30 July 2013 = 17:33
To: Fatai Zhang; Ramon Casellas; Jonathan Hardwick; = pce@ietf.org
Subject: Re: [Pce] =E7=AD=94=E5=A4=8D: = Comments on = draft-ietf-pce-gmpls-pcep-extensions-08

=

 

Hi PCE WG, =

 <= /p>

The Problem we had with = the BANDWIDTH (and LOAD-BALANCING BTW) object is that RFC5440 section = 7.7 defines

=E2=80=9CThe BANDWIDTH = object body has a fixed length of 4 = bytes.=E2=80=9D

 <= /p>

RFC5440 defines two OT : = 1 and 2. The text can be interpreted as all OT (current and future) = should have length =3D 4, this is not future = friendly.

 <= /p>

Now several options can = be considered : 

1)      = GMPLS-pcep extensions : = new object, keep existing implementation untouched, at the expense of = the gmpls ones (more complex rules)

2)      = Allow TLV in the = BANDWIDTH

3)      = Treat this as an errata = to RFC5440 =E2=80=9C=E2=80=9CThe BANDWIDTH of OT 1 and OT 2 =  object body have a fixed length of 4 bytes.=E2=80=9D, and define = new OT for GMPLS

 <= /p>

The Cons of 1 is = discussed below.

The cons of = the TLV would be to change existing object definition and make the = protocol definition rather awkward : different Object format depending = on OPEN (for example) negotiation and would not help for new = CTypes

 <= /p>

With 3) the existing = implementation for existing CType will see no change, it may be a = problem for new CTypes (anyhow not supported), but an implementation may = return an Unknow object, unknown object type OR treated as invalid = object. This can be solved by negotiating the use of OT>2 for = BANDWIDTH (and LOAD-BALANCING)

 <= /p>

For the sake of = discussion I attach a slideset if by any chance there is some time left = during the session,

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

Mit freundlichen Gr=C3=BC=C3=9Fen / Best = Regards
Cyril Margaria

From: pce-bounces@ietf.org = [mailto:pce-bounces@ietf.org] On Behalf Of Fatai = Zhang
Sent: Tuesday, July 30, 2013 2:41 PM
To: Ramon = Casellas; Jonathan Hardwick; pce@ietf.org
Subject: [Pce] = =E7=AD=94=E5= =A4=8D: Comments on = draft-ietf-pce-gmpls-pcep-extensions-08

=

 

Hi = all,

&nb= sp;

I think = a new object type could be better and simple.

&nb= sp;

Thanks

&nb= sp;

Fatai

&nb= sp;

&nb= sp;

=E5=8F=91=E4=BB=B6=E4=BA=BA: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Ramon Casellas
=E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4: 2013=E5=B9=B47=E6=9C=8830=E6=97=A5 17:32
=E6=94=B6=E4=BB=B6=E4=BA=BA: Jonathan Hardwick; pce@ietf.org
=E4=B8=BB=E9=A2=98: Re: [Pce] Comments on = draft-ietf-pce-gmpls-pcep-extensions-08

=

 

On 07/30/2013 11:08 AM, Jonathan = Hardwick wrote:

Cyril and I had an = offline conversation about these comments.  This email is to = document the discussion for the benefit of the mailing list.  See = [JEH-MC] comments below.

 

We have one question for = the WG, as follows.  If anyone has an opinion on this, please could = you provide it to the mailing list?

 

---

[JEH-MC] Jon = believes that this draft should relax the restriction of RFC 5440 that = the BANDWIDTH object is mandatory, in the case where a = GENERALIZED-BANDWIDTH is supplied instead.  This would mean = changing existing procedures, the initial mechanism was not to change = RFC5440 object presence rule.  Cyril is fine with the proposal from = Jonathan, but we would like to get WG and implementers feedback. =

 

Jon, Cyril, all

In this case, I would go back to one of my = initial suggestions: do not add GENERALIZED_BANDWIDTH and add a TLV to = the BW objects, which can be ignored.

In other words, the = creation of GEN_BW was justified due to:  a) do not touch rfc5440 = b) if RFC5440 does not state that BW object can have TLVs, then they = can't and it is fixed length.

My personal preference always was = to add a TLV or a new object type for BW.  If we allow ourselves a = liberal interpretation of rfc5440 then let's assume we can add a = tlv...

Just my opinion, of course, and not a particularly strong = one

Ramon

-- 
Ramon Casellas, Ph.D. -- Senior Research =
Associate -- Networks Division
Optical Networks and Systems Department -- =
http://wikiona.cttc.es
CTTC - Centre Tecnol=C3=B2gic de =
Telecomunicacions de Catalunya
Parc Mediterrani de la Tecnologia (PMT) - =
Edifici B4
Av. Carl Friedrich Gauss, 7 - 08860 =
Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 =
93 645 29 01
------=_NextPart_000_04FD_01CE8DFC.A669CE30-- From diego@tid.es Wed Jul 31 08:08:04 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F9A21E8055 for ; Wed, 31 Jul 2013 08:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z3FdZyXDbfF for ; Wed, 31 Jul 2013 08:07:53 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3A221F9F20 for ; Wed, 31 Jul 2013 08:07:52 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MQT008Z33D3PH@tid.hi.inet> for pce@ietf.org; Wed, 31 Jul 2013 17:07:51 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 42.01.02911.64829F15; Wed, 31 Jul 2013 17:07:51 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MQT008Z03D2PH@tid.hi.inet> for pce@ietf.org; Wed, 31 Jul 2013 17:07:50 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.81]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Wed, 31 Jul 2013 17:07:50 +0200 Date: Wed, 31 Jul 2013 15:07:50 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: "" Message-id: Content-id: <92EF9150A174AC4484032D577F06485C@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: Draft on securing PCEP (a.k.a. PCEPS) Thread-index: AQHOjc36C6T/1NLiZEGibZT6/euQGJl+wk2A X-AuditID: 0a5f4e69-b7f118e000000b5f-db-51f9284670c4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsXCFe9nqOuu8TPQ4OlSVoum+zfYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXrdG5aCY8IVa29MYm1gbBHuYuTkkBAwkWg5+4sNwhaTuHBv PZDNxSEksJ1RYv3JPYwQzndGiV3LprNDONMYJd586GABaWERUJXYcXMGI4jNBmQ/av4NVMTB ISxgJLG11RckzClgJTF3z01miA0KEn/OPWYBKRERUJa4fyYZJMwrYCnxcN4ZsBJmATOJrVeX MkHEBSV+TL4HVs4soC4xZUouRIm4RHPrTRYIW1Fi2qIGsAMYBWQl3s2fzwpiiwgYS3S2f2CE sI0kFr3vZ4G4QEBiyZ7zUNeISrx8/A+sXgjohD/bz7FNYBSfheSKWUiumIVwxSwkV8xCcsUC RtZVjGLFSUWZ6RkluYmZOekGRnoZmXqZeaklmxghkZW5g3H5TpVDjAIcjEo8vA4XvgcKsSaW FVfmHmKU4GBWEuHdw/ozUIg3JbGyKrUoP76oNCe1+BAjEwenVAPj3uL30264t1cs3DnpiNkv plPLpk9R5J98ZZrXtCtpOdpR8yYre/P+DZXtPt2dPcM/JUSn5cyiJ3oLvsuKc56Yy7BOWXXz r2xNfZ2WWtPXtl9WHFYxLnkVpbt2zsrEi/kRzs8/HLoQc+jP4YseImZcPlnqwZXPVzqmCu9l lls8S894+4TjvjGiSizFGYmGWsxFxYkAjXPcu4oCAAA= References: Subject: Re: [Pce] Draft on securing PCEP (a.k.a. PCEPS) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:08:04 -0000 SGkgYWdhaW4sDQoNCkFkcmlhbiBoYXMganVzdCBwb2ludGVkIHRvIG1lIHRoYXQgSSB1c2VkIGFn YWluICJkcmFmdC1sb3Blei1wY3AtcGNlcHMtMDAiIGFzIHRoZSBuZXcgbmFtZQ0KDQpJIGFtIHN0 YXJ0aW5nIHRvIHRoaW5rIHRoYXQgdGhpcyBhIGNsZWFyIGRlbW9uc3RyYXRpb24gb2Ygd2hhdCB0 d28gd2Vla3Mgb2YgbWVldGluZ3Mgb24gc3RhbmRhcmRzIGNhbiBtYWtlIHRvIGEgaHVtYW4gYnJh aW4uIEluZGVlZCwgdGhlIG5ldyBuYW1lIHNob3VsZCBiZSAiZHJhZnQtbG9wZXotcGNFLXBjZXBz LTAwIiAoWWF5ISBJIG1hZGUgaXQgdGhpcyB0aW1lISkNCg0KQmUgZ29vZGUsDQoNCk9uIDMxIEp1 bCAyMDEzLCBhdCAxMToxMSAsIERpZWdvIFIuIExvcGV6IHdyb3RlOg0KDQo+IEhpLA0KPg0KPiBU aGlzIGlzIGEga2luZCByZW1pbmRlciBvbiB0aGUgZHJhZnQgd2UgaGF2ZSBwcmVzZW50ZWQgb24g YXBwbHlpbmcgVExTIGFzIHNlY3VyZSB0cmFuc3BvcnQgZm9yIFBDRVAgKFBDRVBTKQ0KPg0KPiBC ZWNhdXNlIG9mIGEgbWlzdGFrZSBJIG1hZGUgaXQgaXMgY3VycmVudGx5IG5hbWVkIGRyYWZ0LWxv cGV6LXBjcC1wY2Vwcy0wMCAobm90aGluZyB0byBkbyB3aXRoIFBDUCwgYXMgeW91IGNhbiBpbWFn aW5lKQ0KPiBBZnRlciB0aGlzIG1lZXRpbmcgd2Ugd2lsbCB1cGRhdGUgYW5kIHJlbmFtZSBpdCBp bnRvIGRyYWZ0LWxvcGV6LXBjcC1wY2Vwcy0wMCwgYXMgaXQgc2hvdWxkIGJlLg0KPg0KPiBBbmQg YmVjYXVzZSBhIG1pc3VuZGVyc3RhbmRpbmcgY2F1c2VkIGJ5IHRoZSBwcmV2aW91cyBtaXN0YWtl IHdlIHdpbGwgbm90IGJlIGFibGUgdG8gcHJlc2VudCBpdCBhdCB0aGUgUENFIG1lZXRpbmcgdG9k YXkuIEkgYXNrZWQgdGhlIEtBUlAgY2hhaXJzIGFuZCB0aGV5IGhhdmUgYWxsb2NhdGVkIGEgc2xv dCBmb3IgcHJlc2VudGluZyBpdCBhdCB0aGVpciBtZWV0aW5nIChDaGFybG90dGVuYnVyZyAxLCBm cm9tIDEzOjAwIHRvIDE1OjAwKS4gVGhlIFBDRSBjaGFpcnMgaGFzIGluY2x1ZGVkIGEgbWVudGlv biB0byB0aGUgZHJhZnQgaW4gdGhlIGFnZW5kYSwgYnV0IGlmIHlvdSBhcmUgaW50ZXJlc3RlZCB0 byBoYXZlIGEgZmlyc3QgZGV0YWlsZWQgY29udGFjdCB3aXRoIHRoZSBpZGVhcyB1bmRlcnBpbm5p bmcgdGhlIGRyYWZ0IHBsZWFzZSBjb21lIHRvIHRoZSBLQVJQIHNlc3Npb24uDQo+DQo+IEJlIGdv b2RlLA0KPg0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyIN Cg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5l cy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAx MjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlv LiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOz biBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8u DQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUu IFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1z IHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNw eA0K From giomarti@cisco.com Wed Jul 31 10:50:54 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878F111E81A2 for ; Wed, 31 Jul 2013 10:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPuM+zehQZe3 for ; Wed, 31 Jul 2013 10:50:46 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B86BD21E80F9 for ; Wed, 31 Jul 2013 10:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=905; q=dns/txt; s=iport; t=1375293036; x=1376502636; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=euOKkErEdBhy01c6wuAqZSuALFB9TfLhXnTvxZLcdPc=; b=GGjkOqAskWuqxvIGnAHjSShVuAfDI3M3IqRgQGTWJDa4sjgvbMDIAOor EHKqEJZYs3U49rPRR8JWMEVeroYL8zGFOSfoXOm1n5hsqNRH6mS48UjIh hbdzYNGZcRFCXdWekH/7sT3dhrdD5S7k0d+vCmXuZeVM4kzlSnxVKzbyI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAN5N+VGtJXG+/2dsb2JhbABbgwaBBb4jgRkWdIImAQQ6UQEqFEInBAoRiAiYbKBRj1aDUHMDqSyDFIIq X-IronPort-AV: E=Sophos;i="4.89,788,1367971200"; d="scan'208";a="241950445" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2013 17:50:23 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6VHoNQE017663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Jul 2013 17:50:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 12:50:23 -0500 From: "Giovanni Martinelli (giomarti)" To: "pce@ietf.org" Thread-Topic: comment on draft-zhx-pce-stateful-lsp-sync-00 Thread-Index: AQHOjhZtsN4LXaxlykWXRM5qQ9+0SA== Date: Wed, 31 Jul 2013 17:50:22 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D0E156B22@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.169.238] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Pce] comment on draft-zhx-pce-stateful-lsp-sync-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:50:54 -0000 Dear Authors, here an engineer (not necessarily a network engineer) comment. It comes to = my mind during today presentation so ... tossing to the list hope help dis= cussion. Looks to me you are adding an optimisation that actually may add more probl= ems than the one you are trying to solve. I first wonder if the PCC state is so big that could not be transferred in = one shot (not necessarily one packet or one datagram). In case first reque= st fails wound't be better just retry instead of adding the complexity of i= ncremental updates? Second, you have to pay the price of partially synchronised DB. What you ca= n do with a partial state? My first feeling you have to just consider your = DB as not synchronised.=20 Third, You also imply there's more state to maintain at the PCC side as wel= l... e.g. "A PCC SHOULD remember the deleted LSP as well" . Cheers G From zhang.xian@huawei.com Wed Jul 31 14:16:36 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F63621F90C9 for ; Wed, 31 Jul 2013 14:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jeNLoPToPzu for ; Wed, 31 Jul 2013 14:16:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7BB21F909A for ; Wed, 31 Jul 2013 14:16:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATZ11796; Wed, 31 Jul 2013 21:16:28 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 22:14:51 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 22:15:02 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.4]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 05:14:56 +0800 From: "Zhangxian (Xian)" To: "Giovanni Martinelli (giomarti)" , "pce@ietf.org" Thread-Topic: comment on draft-zhx-pce-stateful-lsp-sync-00 Thread-Index: AQHOjhZtsN4LXaxlykWXRM5qQ9+0SJl/RrYG Date: Wed, 31 Jul 2013 21:14:55 +0000 Message-ID: References: <0D7F95913F470A4B83AB5F5833A4390D0E156B22@xmb-rcd-x14.cisco.com> In-Reply-To: <0D7F95913F470A4B83AB5F5833A4390D0E156B22@xmb-rcd-x14.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.216.75] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] comment on draft-zhx-pce-stateful-lsp-sync-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 21:16:36 -0000 SGksIA0KDQogICBUaGFuayB5b3UgZm9yIHF1ZXN0aW9ucy4gDQoNCiAgSSBkbyBub3QgdW5kZXJz dGFuZCB5b3VyIHN0YXRlbWVudCAiaWYgdGhlIFBDQyBzdGF0ZSBpcyBzbyBiaWcgdGhhdCBjb3Vs ZCBub3QgYmUgdHJhbnNmZXJyZWQgaW4gb25lIHNob3QgKG5vdCBuZWNlc3NhcmlseSBvbmUgcGFj a2V0IG9yIG9uZSBkYXRhZ3JhbSkuICIgV2hlbiB3ZSBhcmUgdGFsa2luZyBoZXJlIGlzIHRvIHN5 bmNocm9uaXplIHRoZSBMU1AtREIsIHdoaWNoIGNvbnNpc3RzIG9mIExTUHMgb2YgbWFuYWdlYWJs ZSBtZXNzYWdlIHNpemUuIEFjdHVhbGx5LCBpdCBpcyBwb3NzaWJsZSB0byBjb21iaW5lIG11bHRp cGxlIExTUCBzdGF0ZXMgdG9nZXRoZXIuIA0KDQogU2Vjb25kbHksIGZvciB3aGF0IHlvdSBtZW50 aW9uZWQgImZpcnN0IHJlcXVlc3QgZmFpbHMiLCB3aGF0IGRvIHlvdSBtZWFuIGJ5IHRoYXQ/IFNp bmNlIFBDRVAgaXMgYmFzZWQgb24gVENQLCBzbyB0aGVyZSBzaG91bGQgYmUgbWVjaGFuaXNtcyB0 byBzdXBwb3J0IHJlbGlhYmxlIGRlbGl2ZXJ5IChvdXRzaWRlIG9mIFBDRVApLiBTbywgTk8gTUFU VEVSIGlmIGl0IGlzIGZ1bGwgc3luYy4gb3IgcGFydGlhbCBzeW5jLiwgdGhlIERCIHdpbGwgYmUg aW5jb21wbGV0ZSBhbnl3YXkgZXZlbiBpZiB5b3VyIGFzc3VtcHRpb24gaG9sZHMuIFNvIGl0IGRv ZXMgbm90IGludmFsaWRhdGUgb3VyIHByb3Bvc2FsLiANCg0KIEFzIGZvciB0aGUgbGFzdCBjb21t ZW50LCBpZiB5b3UgcmVhZCAob3IgbWF5IGJlIGludGVyZXN0ZWQgdG8pIHRoZSBXRyBkcmFmdCBj YXJlZnVsbHksIHRoZSBmdW5jdGlvbiB5b3UgbWVudGlvbmVkIGJlbG93IGFzICJBIFBDQyBTSE9V TEQgcmVtZW1iZXIgdGhlIGRlbGV0ZWQgTFNQIGFzIHdlbGwiIGlzIGFscmVhZHkgc3VwcG9ydGVk IHRoZXJlLiBTbywgSSBkbyBub3Qgc2VlIGhvdyBpdCBpcyBhbiBpc3N1ZSBhdCBhbGwuIA0KDQpS ZWdhcmRzLA0KWGlhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQq3orz+yMs6IHBjZS1ib3VuY2VzQGlldGYub3JnIFtwY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSkgW2dpb21hcnRpQGNpc2NvLmNvbV0NCrei y83KsbzkOiAyMDEzxOo41MIxyNUgMTo1MA0Ktb06IHBjZUBpZXRmLm9yZw0K1vfM4jogW1BjZV0g Y29tbWVudCBvbiBkcmFmdC16aHgtcGNlLXN0YXRlZnVsLWxzcC1zeW5jLTAwDQoNCkRlYXIgQXV0 aG9ycywNCg0KaGVyZSBhbiBlbmdpbmVlciAobm90IG5lY2Vzc2FyaWx5IGEgbmV0d29yayBlbmdp bmVlcikgY29tbWVudC4gSXQgY29tZXMgdG8gbXkgbWluZCBkdXJpbmcgdG9kYXkgcHJlc2VudGF0 aW9uIHNvIC4uLiAgdG9zc2luZyB0byB0aGUgbGlzdCBob3BlIGhlbHAgZGlzY3Vzc2lvbi4NCg0K TG9va3MgdG8gbWUgeW91IGFyZSBhZGRpbmcgYW4gb3B0aW1pc2F0aW9uIHRoYXQgYWN0dWFsbHkg bWF5IGFkZCBtb3JlIHByb2JsZW1zIHRoYW4gdGhlIG9uZSB5b3UgYXJlIHRyeWluZyB0byBzb2x2 ZS4NCg0KSSBmaXJzdCB3b25kZXIgaWYgdGhlIFBDQyBzdGF0ZSBpcyBzbyBiaWcgdGhhdCBjb3Vs ZCBub3QgYmUgdHJhbnNmZXJyZWQgaW4gb25lIHNob3QgKG5vdCBuZWNlc3NhcmlseSBvbmUgcGFj a2V0IG9yIG9uZSBkYXRhZ3JhbSkuICBJbiBjYXNlIGZpcnN0IHJlcXVlc3QgZmFpbHMgd291bmQn dCBiZSBiZXR0ZXIganVzdCByZXRyeSBpbnN0ZWFkIG9mIGFkZGluZyB0aGUgY29tcGxleGl0eSBv ZiBpbmNyZW1lbnRhbCB1cGRhdGVzPw0KDQpTZWNvbmQsIHlvdSBoYXZlIHRvIHBheSB0aGUgcHJp Y2Ugb2YgcGFydGlhbGx5IHN5bmNocm9uaXNlZCBEQi4gV2hhdCB5b3UgY2FuIGRvIHdpdGggYSBw YXJ0aWFsIHN0YXRlPyBNeSBmaXJzdCBmZWVsaW5nIHlvdSBoYXZlIHRvIGp1c3QgY29uc2lkZXIg eW91ciAgREIgYXMgbm90IHN5bmNocm9uaXNlZC4NCg0KVGhpcmQsIFlvdSBhbHNvIGltcGx5IHRo ZXJlJ3MgbW9yZSBzdGF0ZSB0byBtYWludGFpbiBhdCB0aGUgUENDIHNpZGUgYXMgd2VsbC4uLiAg ZS5nLiAiQSBQQ0MgU0hPVUxEIHJlbWVtYmVyIHRoZSBkZWxldGVkIExTUCBhcyB3ZWxsIiAuDQoN CkNoZWVycw0KRw0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KUGNlIG1haWxpbmcgbGlzdA0KUGNlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ== From giomarti@cisco.com Wed Jul 31 15:30:59 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4819121F9A97 for ; Wed, 31 Jul 2013 15:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.498 X-Spam-Level: X-Spam-Status: No, score=-8.498 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzR4YYDsgyje for ; Wed, 31 Jul 2013 15:30:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1160E21F9A96 for ; Wed, 31 Jul 2013 15:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4044; q=dns/txt; s=iport; t=1375309854; x=1376519454; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Lw8dorBU2fAcWtopsPsvTE4jffUfqTKuA+ylnet38ZM=; b=ArLMUrGPPJ4d4QehcZJdNVvACFwoVTPPQbaWpLcbNi8gzEPy4wL566yU X4pOmmjmO1e+nYsp0h5tiJokPkynWkSBOLcAMXjelliwJDJqyPVwhT6cl nQApvTaQjJlnIcUqXfYnMRHArRYCKkDh9RjBk89YTJBdqx4H40gLSRR/T s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAMeO+VGtJV2Y/2dsb2JhbABbgwY1UIMQuyQXgQMWdIIkAQEBAwEBAQExOgsFCwIBBgIcBiICAiULJQIECgQFCIgCBgyLcZtACJFPBIEkjjIxB4JhN3MDqSyDFIIq X-IronPort-AV: E=Sophos;i="4.89,790,1367971200"; d="scan'208";a="241976696" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2013 22:30:53 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6VMUrQo011615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 22:30:53 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 17:30:53 -0500 From: "Giovanni Martinelli (giomarti)" To: "Zhangxian (Xian)" Thread-Topic: comment on draft-zhx-pce-stateful-lsp-sync-00 Thread-Index: AQHOjhZtsN4LXaxlykWXRM5qQ9+0SJl/RrYGgABr+QA= Date: Wed, 31 Jul 2013 22:30:52 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D0E1571DD@xmb-rcd-x14.cisco.com> References: <0D7F95913F470A4B83AB5F5833A4390D0E156B22@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.213.119] Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] comment on draft-zhx-pce-stateful-lsp-sync-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 22:30:59 -0000 SGkgWGlhbiwNCg0KT24gSnVsIDMxLCAyMDEzLCBhdCAyMzoxNCAsICJaaGFuZ3hpYW4gKFhpYW4p IiA8emhhbmcueGlhbkBodWF3ZWkuY29tPg0KIHdyb3RlOg0KDQo+IEhpLCANCj4gDQo+ICAgVGhh bmsgeW91IGZvciBxdWVzdGlvbnMuIA0KPiANCj4gIEkgZG8gbm90IHVuZGVyc3RhbmQgeW91ciBz dGF0ZW1lbnQgImlmIHRoZSBQQ0Mgc3RhdGUgaXMgc28gYmlnIHRoYXQgY291bGQgbm90IGJlIHRy YW5zZmVycmVkIGluIG9uZSBzaG90IChub3QgbmVjZXNzYXJpbHkgb25lIHBhY2tldCBvciBvbmUg ZGF0YWdyYW0pLiAiIFdoZW4gd2UgYXJlIHRhbGtpbmcgaGVyZSBpcyB0byBzeW5jaHJvbml6ZSB0 aGUgTFNQLURCLCB3aGljaCBjb25zaXN0cyBvZiBMU1BzIG9mIG1hbmFnZWFibGUgbWVzc2FnZSBz aXplLiBBY3R1YWxseSwgaXQgaXMgcG9zc2libGUgdG8gY29tYmluZSBtdWx0aXBsZSBMU1Agc3Rh dGVzIHRvZ2V0aGVyLiANCj4gDQoNCkdNPiBJbiAgc2VjdGlvbiAxLjEgIk1vdGl2YXRpb24iIHlv dSBwcm92aWRlIHNvbWUgbnVtYmVycy4gQ291bGQgeW91IGVzdGltYXRlIHRoZSB0aGUgTFNQLURC IHNpemUgJiBiYW5kd2lkdGggYXZhaWxhYmxlPyBEbyB5b3UgYWdyZWUgdGhhdCBvcHRpbWlzYXRp b24gc3VnZ2VzdGVkIGhlcmUgaGFzIHNvbWUgY29zdHM/ICAgDQoNCg0KPiBTZWNvbmRseSwgZm9y IHdoYXQgeW91IG1lbnRpb25lZCAiZmlyc3QgcmVxdWVzdCBmYWlscyIsIHdoYXQgZG8geW91IG1l YW4gYnkgdGhhdD8gU2luY2UgUENFUCBpcyBiYXNlZCBvbiBUQ1AsIHNvIHRoZXJlIHNob3VsZCBi ZSBtZWNoYW5pc21zIHRvIHN1cHBvcnQgcmVsaWFibGUgZGVsaXZlcnkgKG91dHNpZGUgb2YgUENF UCkuIFNvLCBOTyBNQVRURVIgaWYgaXQgaXMgZnVsbCBzeW5jLiBvciBwYXJ0aWFsIHN5bmMuLCB0 aGUgREIgd2lsbCBiZSBpbmNvbXBsZXRlIGFueXdheSBldmVuIGlmIHlvdXIgYXNzdW1wdGlvbiBo b2xkcy4gU28gaXQgZG9lcyBub3QgaW52YWxpZGF0ZSBvdXIgcHJvcG9zYWwuDQoNCkdNPiBJIGd1 ZXNzIEkgbWVhbnQgYSBzdGF0ZSBzeW5jcm9uaXphdGlvbiBvcGVyYXRpb24gKG9yIHNlcXVlbmNl ICkgYXMgcGVyIHNlY3Rpb24gNS40ICJTdGF0ZSBTeW5jaHJvbmlzYXRpb24iICBvZiB0aGUgYmli bGUuICBJbiBnZW5lcmFsIG9wZXJhdGlvbnMgbWF5IGZhaWxzIGZvciBkaWZmZXJlbnQgcmVhc29u cyAuLi4gYW55d2F5IFRDUCBzaG91bGQgaGVscCB5b3UgaW4gYXZvaWRpbmcgZnVydGhlciBtZWNo YW5pc20gDQoNCg0KPiANCj4gDQo+IEFzIGZvciB0aGUgbGFzdCBjb21tZW50LCBpZiB5b3UgcmVh ZCAob3IgbWF5IGJlIGludGVyZXN0ZWQgdG8pIHRoZSBXRyBkcmFmdCBjYXJlZnVsbHksIHRoZSBm dW5jdGlvbiB5b3UgbWVudGlvbmVkIGJlbG93IGFzICJBIFBDQyBTSE9VTEQgcmVtZW1iZXIgdGhl IGRlbGV0ZWQgTFNQIGFzIHdlbGwiIGlzIGFscmVhZHkgc3VwcG9ydGVkIHRoZXJlLiBTbywgSSBk byBub3Qgc2VlIGhvdyBpdCBpcyBhbiBpc3N1ZSBhdCBhbGwuIA0KDQpHTT4gIGNvdWxkIHlvdSBw cm92aWRlIGEgcG9pbnRlciB3aGVyZSBpcyBhbHJlYWR5IHN1cHBvcnRlZD8NCg0KQ2hlZXJzDQpH DQoNCg0KPiANCj4gUmVnYXJkcywNCj4gWGlhbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiC3orz+yMs6IHBjZS1ib3VuY2VzQGlldGYub3JnIFtwY2Ut Ym91bmNlc0BpZXRmLm9yZ10gtPqx7SBHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSkgW2dp b21hcnRpQGNpc2NvLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTPE6jjUwjHI1SAxOjUwDQo+ILW9OiBw Y2VAaWV0Zi5vcmcNCj4g1vfM4jogW1BjZV0gY29tbWVudCBvbiBkcmFmdC16aHgtcGNlLXN0YXRl ZnVsLWxzcC1zeW5jLTAwDQo+IA0KPiBEZWFyIEF1dGhvcnMsDQo+IA0KPiBoZXJlIGFuIGVuZ2lu ZWVyIChub3QgbmVjZXNzYXJpbHkgYSBuZXR3b3JrIGVuZ2luZWVyKSBjb21tZW50LiBJdCBjb21l cyB0byBteSBtaW5kIGR1cmluZyB0b2RheSBwcmVzZW50YXRpb24gc28gLi4uICB0b3NzaW5nIHRv IHRoZSBsaXN0IGhvcGUgaGVscCBkaXNjdXNzaW9uLg0KPiANCj4gTG9va3MgdG8gbWUgeW91IGFy ZSBhZGRpbmcgYW4gb3B0aW1pc2F0aW9uIHRoYXQgYWN0dWFsbHkgbWF5IGFkZCBtb3JlIHByb2Js ZW1zIHRoYW4gdGhlIG9uZSB5b3UgYXJlIHRyeWluZyB0byBzb2x2ZS4NCj4gDQo+IEkgZmlyc3Qg d29uZGVyIGlmIHRoZSBQQ0Mgc3RhdGUgaXMgc28gYmlnIHRoYXQgY291bGQgbm90IGJlIHRyYW5z ZmVycmVkIGluIG9uZSBzaG90IChub3QgbmVjZXNzYXJpbHkgb25lIHBhY2tldCBvciBvbmUgZGF0 YWdyYW0pLiAgSW4gY2FzZSBmaXJzdCByZXF1ZXN0IGZhaWxzIHdvdW5kJ3QgYmUgYmV0dGVyIGp1 c3QgcmV0cnkgaW5zdGVhZCBvZiBhZGRpbmcgdGhlIGNvbXBsZXhpdHkgb2YgaW5jcmVtZW50YWwg dXBkYXRlcz8NCj4gDQo+IFNlY29uZCwgeW91IGhhdmUgdG8gcGF5IHRoZSBwcmljZSBvZiBwYXJ0 aWFsbHkgc3luY2hyb25pc2VkIERCLiBXaGF0IHlvdSBjYW4gZG8gd2l0aCBhIHBhcnRpYWwgc3Rh dGU/IE15IGZpcnN0IGZlZWxpbmcgeW91IGhhdmUgdG8ganVzdCBjb25zaWRlciB5b3VyICBEQiBh cyBub3Qgc3luY2hyb25pc2VkLg0KPiANCj4gVGhpcmQsIFlvdSBhbHNvIGltcGx5IHRoZXJlJ3Mg bW9yZSBzdGF0ZSB0byBtYWludGFpbiBhdCB0aGUgUENDIHNpZGUgYXMgd2VsbC4uLiAgZS5nLiAi QSBQQ0MgU0hPVUxEIHJlbWVtYmVyIHRoZSBkZWxldGVkIExTUCBhcyB3ZWxsIiAuDQo+IA0KPiBD aGVlcnMNCj4gRw0KPiANCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gUGNlIG1haWxpbmcgbGlzdA0KPiBQY2VAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg0K From ramon.casellas@cttc.es Wed Jul 31 21:51:29 2013 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639C421F880F for ; Wed, 31 Jul 2013 21:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mloAnGolQ3tT for ; Wed, 31 Jul 2013 21:51:28 -0700 (PDT) Received: from torres.puc.rediris.es (torres.puc.rediris.es [IPv6:2001:720:418:ca00::9]) by ietfa.amsl.com (Postfix) with ESMTP id A7E6B21F86B2 for ; Wed, 31 Jul 2013 21:51:26 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by torres.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1V4kr8-0001U8-CQ; Thu, 01 Aug 2013 06:51:18 +0200 Received: from [10.25.11.163] (unknown [46.189.28.57]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 10B5F1FD41; Thu, 1 Aug 2013 06:51:15 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <51F9CD23.4040401@cttc.es> Date: Thu, 01 Aug 2013 04:51:15 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <04fc01ce8df4$449e3a40$cddaaec0$@olddog.co.uk> In-Reply-To: <04fc01ce8df4$449e3a40$cddaaec0$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------060301060507090307030003" X-Spamina-Bogosity: Ham Cc: pce@ietf.org, "'Margaria, Cyril \(Coriant - DE/Munich\)'" Subject: Re: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 04:51:29 -0000 This is a multi-part message in MIME format. --------------060301060507090307030003 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Adrian, all Please see inline. > However, 5440 was wilful in its choice to not support Intserv on the > understanding (which might not be true anymore, but probably is) that > no-one uses Intserv TSpec in their MPLS-TE or GMPLS implementations. [Ramon] that is good to know, thanks; I have wondered about the rationale for that choice, which I humbly thought to be unfortunate; I would have guessed that algorithms could use at least some token bucket or peak/mean rate parameters to compute paths in view of statistical multiplexing. Now, with contributions and standards work regarding metrics such as delay and packet loss rates imho it would make sense to characterize flows / requests not only as a single floating point value /CBR. However, also related to parts of your mail, the RFC5440 text in the bandwidth object description still puzzles me: "The notion of bandwidth is similar to the one used for RSVP signaling in [RFC2205], [RFC3209], and [RFC3473]" in which the term requested bandwidth is indeed used. I would think that the choice of bandwdith is clearly related to RSVP and "the sender-speec object for use if the PCC happens to be the ingress node" > > 2. The PCC wants bandwidth, but *does* care about how this supplied in > the network. This makes the request: > > i. layer-specific > > ii. sub-layer-specific > > iii. label-specific > > My view is that the Bandwidth object is not called the "Sender-TSpec > object for use if the PCC just happens to be the ingress node of a > GMPLS LSP" object! My view is that the bandwidth object describes the > bandwidth that has been requested, and the bandwidth that the supplied > path will actually be able to supply (may be >, =, or < requested b/w). > [Ramon] Imho, 2 would be the use case I am most interested in, quite biased since most of the time in my scenarios pcc is part of an LSR (not necessarily ingress, but also in expansions). Much like I like that a PCC can pass the bits around regarding the ERO in a response, I would like to pass the tspec transparently, saying "expand the path I am establishing, this is the tspec I have in my sender descriptor". Otherwise, I am not sure what magic I have to implement to deduce a floating point bandwidth to convey in the object. Another use case (very particular to mu interests) is when I want to ask the PCE to perform routing and spectrum assignment. I want the PCE to compute a path of a given spectrum width, to pre-establish it. the width is given by the corresponding OTS / slot, and the actual client signal mapping is unknown, and will depend on the modulation format and FEC. I don't know what bandwdith I would convey in the message. So in my case we are not always requesting bytes per second. > Thus, IMHO, if we want to constrain the request to return paths that > use a limited set of the available network resources, we need to add > this through other objects. > [Ramon] In short, I would be ok if we agree that "this is not full related to bandwidth, leave the object as it is", but I would think that not being able to request/reply traffic parameters is a limitation of the PCEP extensions for GMPLS > > And if we want to give information to the PCC that it can map to > specific details in the signaling protocol, then we should provide > that detail in objects specifically intended to carry that > information.This information is clearly related to bandwidth, but it > is not the same as bandwidth. > [Ramon] I think it should be possible Thanks Ramon --------------060301060507090307030003 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Adrian, all

Please see inline.

However, 5440 was wilful in its choice to not support Intserv on the understanding (which might not be true anymore, but probably is) that no-one uses Intserv TSpec in their MPLS-TE or GMPLS implementations.
[Ramon] that is good to know, thanks; I have wondered about the rationale for that choice, which I humbly thought to be unfortunate; I would have guessed that algorithms  could use at least some token bucket or peak/mean rate parameters to compute paths in view of statistical multiplexing. Now, with contributions and standards work regarding metrics such as delay and packet loss rates imho it would make sense to characterize flows  / requests not only as a single floating point value /CBR.
However, also related to parts of your mail, the RFC5440 text in the bandwidth object description still puzzles me: "The notion of bandwidth is similar to the one used for RSVP signaling in [RFC2205], [RFC3209], and [RFC3473]" in which the term requested bandwidth is indeed used. I would think that the choice of bandwdith is clearly related to RSVP and "the sender-speec object for use if the PCC happens to be the ingress node"
 

2. The PCC wants bandwidth, but *does* care about how this supplied in the network. This makes the request:

   i. layer-specific

   ii. sub-layer-specific

   iii. label-specific


 

My view is that the Bandwidth object is not called the "Sender-TSpec object for use if the PCC just happens to be the ingress node of a GMPLS LSP" object! My view is that the bandwidth object describes the bandwidth that has been requested, and the bandwidth that the supplied path will actually be able to supply (may be >, =, or < requested b/w).


[Ramon] Imho, 2 would be the use case I am most interested in, quite biased since most of the time in my scenarios pcc is part of an LSR (not necessarily ingress, but also in expansions). Much like I like that a PCC can pass the bits around regarding the ERO in a response, I would like to pass the tspec transparently, saying "expand the path I am establishing, this is the tspec I have in my sender descriptor". Otherwise, I am not sure what magic I have to implement to deduce a floating point bandwidth to convey in the object. Another use case (very particular to mu interests) is when I want to ask the PCE to perform routing and spectrum assignment. I want the PCE to compute a path of a given spectrum width, to pre-establish it. the width is given by the corresponding OTS / slot, and the actual client signal mapping is unknown, and will depend on the modulation format and FEC. I don't know what bandwdith I would convey in the message.
So in my case we are not always requesting bytes per second.

 

Thus, IMHO, if we want to constrain the request to return paths that use a limited set of the available network resources, we need to add this through other objects.

[Ramon] In short, I would be ok if we agree that "this is not full related to bandwidth, leave the object as it is", but I would think that not being able to request/reply traffic parameters is a limitation of the PCEP extensions for GMPLS

 

And if we want to give information to the PCC that it can map to specific details in the signaling protocol, then we should provide that detail in objects specifically intended to carry that information.  This information is clearly related to bandwidth, but it is not the same as bandwidth.

 

[Ramon] I think it should be possible


Thanks

Ramon

--------------060301060507090307030003--