From julien.meuric@orange.com Tue Oct 4 01:31:41 2011 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 EA0EB21F8CCD for ; Tue, 4 Oct 2011 01:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 b-HVxzdLAOD7 for ; Tue, 4 Oct 2011 01:31:41 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5052B21F8CCC for ; Tue, 4 Oct 2011 01:31:41 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4A1198B8004 for ; Tue, 4 Oct 2011 10:35:43 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 43AED8B8003 for ; Tue, 4 Oct 2011 10:35:43 +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, 4 Oct 2011 10:34:45 +0200 Received: from [10.193.71.78] ([10.193.71.78]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 10:34:44 +0200 Message-ID: <4E8AC524.2070307@orange.com> Date: Tue, 04 Oct 2011 10:34:44 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: pce@ietf.org References: <4E78AC63.1020704@orange.com> In-Reply-To: <4E78AC63.1020704@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Oct 2011 08:34:44.0689 (UTC) FILETIME=[77ED4C10:01CC8270] Subject: Re: [Pce] Adoption of draft-king-pce-hierarchy-fwk-06 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, 04 Oct 2011 08:31:42 -0000 Hi all. The consensus is loud and clear: the I-D is adopted as WG document. Some side comments have came up: as their scope is beyond the I-D itself, please use the parallel threads to express your views. Author, you may publish the I-D as draft-ietf-pce-hierarchy-fwk-00. Cheers, Julien Le 20/09/2011 17:08, Julien Meuric a écrit : > Hi PCE WG. > > The framework for hierarchical PCE has been there for long, discussed > several times and was pending the charter update. This is a poll for > adopting draft-king-pce-hierarchy-fwk-06 as WG document. Please reply > to this message to express either your support, i.e. you consider the > I-D is a good foundation to address the issue, or your objection, > which you are expected to clarify. > > Thank you, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From internet-drafts@ietf.org Tue Oct 4 05:43:13 2011 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 190E921F87E2; Tue, 4 Oct 2011 05:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 oM47hOiyl-eA; Tue, 4 Oct 2011 05:43:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9C021F87C2; Tue, 4 Oct 2011 05:43:12 -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: 3.60 Message-ID: <20111004124312.25477.48807.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2011 05:43:12 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-hierarchy-fwk-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, 04 Oct 2011 12:43:13 -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 Grou= p of the IETF. Title : The Application of the Path Computation Element Architec= ture to the Determination of a Sequence of Domains in MPLS and GMPLS Author(s) : Daniel King Adrian Farrel Filename : draft-ietf-pce-hierarchy-fwk-00.txt Pages : 28 Date : 2011-10-04 Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture. Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply-connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward Recursive Path Computation Procedure (BRPC) can be used to derive an optimal path. This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-hierarchy-fwk-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-hierarchy-fwk-00.txt From ramon.casellas@cttc.es Fri Oct 14 01:11:32 2011 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 7199921F8A67 for ; Fri, 14 Oct 2011 01:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 kDjioeAkqdHA for ; Fri, 14 Oct 2011 01:11:31 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id EE48C21F886A for ; Fri, 14 Oct 2011 01:11:29 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9E8BG6N000917 for ; Fri, 14 Oct 2011 10:11:22 +0200 Received: from [84.88.61.50] (unknown [84.88.61.50]) by castor (Postfix) with ESMTP id 79BAF2FC267 for ; Fri, 14 Oct 2011 10:11:16 +0200 (CEST) Message-ID: <4E97EEEF.6070700@cttc.es> Date: Fri, 14 Oct 2011 10:12:31 +0200 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Fri, 14 Oct 2011 10:11:16 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: [Pce] ANN: New Version Notification for draft-zhang-pce-hierarchy-extensions-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, 14 Oct 2011 08:11:32 -0000 Dear PCErs, FYI, a new version of draft-zhang-pce-hierarchy-extensions has been uploaded. This document defines PCEP extensions for H-PCE (see below). It is a minor update, and, most importantly, a lot of open issues remain. In this sense, your comments / suggestions are welcome. The current draft already proposes some protocol extensions / encodings to the high-level procedures detailed in the companion framework document. Recent exchanges seem to imply that there is room to revisit requirements and procedures,including * (Parent) TED management: it can be argued that the framework document relies on basic domain connectivity, precluding TE aggregation mechanisms. This seems to be a topic of debate. It has been mentioned in private conversations that it should be a decision of the network operator (based on policies or whatever criterion) to decide the level of information exchange allowed. It clearly seems to depend on the actual scenario (e.g. multi-area WSON vs Inter-AS/carriers) * In any case, decoupling TED management from path computation has been a design criterion within the PCE architecture and this should be applied also to the solutions document. Several mails have hinted the idea of (separate?) approaches to (hierarchical) TED management (cfr. Olivier/Oscar mails) and leaving TED management out of scope (including wrapping TED-related messages out of PCEP / PCNtf). It may be difficult if both functions (path computation and TED management) are slightly coupled (border node identification, endpoint localization and topology aggregation for domain sequence selection, to name a few in which an IGP-based TED may not be sufficient) * Domain representation: the role of domains and domain identifiers is clearly important. We should align with e.g. draft-dhruv on domain sequence, avoid new encodings for domains which could re-use Route sub-objects, etc. * Alternative approaches (Dhruv) suggest to keep the Parent-PCE’s topology graph free of BNs (Boundary Nodes) and inter-AS TE link; it being composed only of neighbor domain adjacency. * OF codes: new requirements arise regarding OF codes, including the consideration of actual OF codes (e.g. minimize domain crossing) and policies affecting them (e.g. do not allow domain re-enter). Additionally, there seems to be a need to be able to specify the OF codes to apply at both levels, not only at the parent level but also the child's (i.e. intra-domain level) * Reachability: the current fwk/pcep drafts rely on polling to locate endpoints. This does not preclude some form of caching, but alternative solutions based on notifications/announcements of endpoint (prefixes) have been mentioned. * Exclusions: exclusions need to take into account domains. * Other?... Dan mentioned that discussion and agreement of the above, will help create requirements that will allow us define the Protocol extensions, including PCEP extensions, encoding, error handling and manageability. For this, Dan plans to leave the Framework document open in case new requirements arise. Best regards, Ramon, on behalf of the draft co-authors ------------------------------------------------------------------------- New Version Notification for draft-zhang-pce-hierarchy-extensions-01.txt A new version of I-D, draft-zhang-pce-hierarchy-extensions-01.txt has been successfully submitted by Fatai Zhang and posted to the IETF repository. Filename: draft-zhang-pce-hierarchy-extensions Revision: 01 Title: Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE) Creation date: 2011-10-13 WG ID: Individual Submission Number of pages: 19 Abstract: The hierarchical Path Computation Element (PCE) architecture, defined in the companion framework document [I-D.ietf-pce-hierarchy-fwk], allows the selection of an optimum domain sequence and the optimum end-to-end path, to be derived through the use of a hierarchical relationship between domains. This document defines the Path Computation Element Protocol (PCEP) extensions for the purpose of implementing hierarchical PCE procedures which are described the aforementioned document. -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 From daniel@olddog.co.uk Fri Oct 14 03:46:39 2011 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 A5A1821F87C5 for ; Fri, 14 Oct 2011 03:46:39 -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 x+WcbewE0ek8 for ; Fri, 14 Oct 2011 03:46:38 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 78D7C21F86AA for ; Fri, 14 Oct 2011 03:46:38 -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 p9EAkaSk020791 for ; Fri, 14 Oct 2011 11:46:37 +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 p9EAkZkZ020779 for ; Fri, 14 Oct 2011 11:46:36 +0100 From: "Daniel King" To: References: <4E97EEEF.6070700@cttc.es> In-Reply-To: <4E97EEEF.6070700@cttc.es> Date: Fri, 14 Oct 2011 11:46:33 +0100 Message-ID: <00d301cc8a5e$8a5ea880$9f1bf980$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQEYhWDrSLDuvkYKSZ1/dsxapLVqK5bjsEvA Subject: Re: [Pce] ANN: New Version Notification for draft-zhang-pce-hierarchy-extensions-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, 14 Oct 2011 10:46:39 -0000 Great summary, thanks Ramon.=20 As ever WG contributions are always actively sought, however with H-PCE = we would love to hear more operator/provider feedback regarding the applications, procedures and extensions being discussed!=20 We plan to summarise a number of open H-PCE issues and discuss them during our WG at IETF 82 (Taipei) next month. We will also organise a separate discussion at IETF 82 to give us time to go into more detail = for specific areas. Please unicast me if you are interested in = participating, and mentioning your H-PCE topic of interest.=20 Br, Dan.=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Ramon Casellas Sent: 14 October 2011 09:13 To: pce@ietf.org Subject: [Pce] ANN: New Version Notification for draft-zhang-pce-hierarchy-extensions-01.txt Dear PCErs, FYI, a new version of draft-zhang-pce-hierarchy-extensions has been uploaded. This document defines PCEP extensions for H-PCE (see below). It is a minor update, and, most importantly, a lot of open issues = remain. In this sense, your comments / suggestions are welcome. The current draft already proposes some protocol extensions / encodings = to the high-level procedures detailed in the companion framework document. Recent exchanges seem to imply that there is room to revisit = requirements and procedures,including * (Parent) TED management: it can be argued that the framework document relies on basic domain connectivity, precluding TE aggregation mechanisms. = This seems to be a topic of debate. It has been mentioned in private conversations that it should be a decision of the network operator (based on = policies or whatever criterion) to decide the level of information exchange = allowed. It clearly seems to depend on the actual scenario (e.g. multi-area WSON = vs Inter-AS/carriers) * In any case, decoupling TED management from path computation has been = a design criterion within the PCE architecture and this should be = applied also to the solutions document. Several mails have hinted the idea of (separate?) approaches to (hierarchical) TED management (cfr. Olivier/Oscar = mails) and leaving TED management out of scope (including wrapping TED-related messages out of PCEP / PCNtf). It may be difficult if both functions (path computation and TED management) are slightly coupled (border node identification, endpoint localization and topology aggregation for domain sequence selection, to name a few in which an IGP-based TED may not be sufficient) * Domain representation: the role of domains and domain identifiers is clearly important. We should align with e.g. draft-dhruv on domain sequence, avoid new encodings for domains which could re-use Route sub-objects, etc. * Alternative approaches (Dhruv) suggest to keep the Parent-PCE=92s = topology graph free of BNs (Boundary Nodes) and inter-AS TE link; it being composed only of neighbor domain adjacency. * OF codes: new requirements arise regarding OF codes, including the consideration of actual OF codes (e.g. minimize domain crossing) and policies affecting them (e.g. do not allow domain re-enter). Additionally, there seems to be a need to be able to specify the OF codes to apply = at both levels, not only at the parent level but also the child's (i.e. intra-domain level) * Reachability: the current fwk/pcep drafts rely on polling to locate endpoints. This does not preclude some form of caching, but = alternative solutions based on notifications/announcements of endpoint (prefixes) have been mentioned. * Exclusions: exclusions need to take into account domains. * Other?... Dan mentioned that discussion and agreement of the above, will help = create requirements that will allow us define the Protocol extensions, = including PCEP extensions, encoding, error handling and manageability. For this, = Dan plans to leave the Framework document open in case new requirements = arise. Best regards, Ramon, on behalf of the draft co-authors -------------------------------------------------------------------------= New Version Notification for draft-zhang-pce-hierarchy-extensions-01.txt A new version of I-D, draft-zhang-pce-hierarchy-extensions-01.txt has = been successfully submitted by Fatai Zhang and posted to the IETF repository. Filename: draft-zhang-pce-hierarchy-extensions Revision: 01 Title: Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE) Creation date: 2011-10-13 WG ID: Individual Submission Number of pages: 19 Abstract: The hierarchical Path Computation Element (PCE) architecture, = defined in the companion framework document [I-D.ietf-pce-hierarchy-fwk], allows the selection of an optimum domain sequence and the optimum end-to-end path, to be derived through the use of a hierarchical relationship between domains. This document defines the Path Computation Element Protocol (PCEP) extensions for the purpose of implementing hierarchical PCE procedures which are described the aforementioned document. -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es = CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 Av. = Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From prvs=32686a909c=lyong@ciena.com Fri Oct 14 13:21:21 2011 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 3AE1321F8CCE for ; Fri, 14 Oct 2011 13:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.844 X-Spam-Level: X-Spam-Status: No, score=-100.844 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, 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 tMPq9opQ5u+0 for ; Fri, 14 Oct 2011 13:21:20 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 835CD21F87F0 for ; Fri, 14 Oct 2011 13:21:20 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p9EKKQnF026315 for ; Fri, 14 Oct 2011 16:21:17 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 10et5k0j10-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 14 Oct 2011 16:21:17 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Fri, 14 Oct 2011 16:21:14 -0400 From: "Ong, Lyndon" To: "pce@ietf.org" Content-Class: urn:content-classes:message Date: Fri, 14 Oct 2011 16:21:05 -0400 Thread-Topic: question on gmpls extensions Thread-Index: AcyKrszfB9PxYNIhRBiT/JY2fzCgDg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18450.001 x-tm-as-result: No--39.504100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_004_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E07MDWEXGMB02ciena_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-14_06:2011-10-14, 2011-10-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1110140251 Subject: [Pce] question on gmpls extensions 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, 14 Oct 2011 20:21:21 -0000 --_004_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E07MDWEXGMB02ciena_ Content-Type: multipart/alternative; boundary="_000_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E07MDWEXGMB02ciena_" --_000_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E07MDWEXGMB02ciena_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, I had a couple of questions on the gmpls extensions draft: 1) How are the label set and suggested label objects used, given that = labels are usually local significance? Are these specifically only for the= egress interface? 2) Switching Type and LSP Encoding Type look like they could be in two= spots, in the SWITCH-LAYER object and in the ENDPOINTS object Label_Reques= t TLV - did I misread this? Or if this is correct, when would you use one = vs. the other? I did not find this on the archives, my apologies if this has been asked an= d answered before. Cheers, Lyndon [cid:imagebe061c.gif@044e8261.6db34a49] --_000_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E07MDWEXGMB02ciena_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= meta content=3D"Microsoft Word 12 (filtered medium)" name=3DGenerator>
Hi Folks,

 =

I had a couple of questions on the gmpls ext= ensions draft:

 

1)      How are the label set and suggested label objects used, given that l= abels are usually local significance?  Are these specifically only for= the egress interface?

 = ;

2)      Switching Type and LSP Encoding Type look like they c= ould be in two spots, in the SWITCH-LAYER object and in the ENDPOINTS objec= t Label_Request TLV – did I misread this?  Or if this is correct= , when would you use one vs. the other?

=  

I did not find this on the archiv= es, my apologies if this has been asked and answered before.

=

 

Cheers,=

 

Ly= ndon

 

 

 

 


=3D"ciena

= --_000_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E07MDWEXGMB02ciena_-- --_004_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E07MDWEXGMB02ciena_ Content-Type: image/gif; name="imagebe061c.gif@044e8261.6db34a49" Content-Description: imagebe061c.gif@044e8261.6db34a49 Content-Disposition: inline; filename="imagebe061c.gif@044e8261.6db34a49"; size=3410; creation-date="Fri, 14 Oct 2011 16:21:14 GMT"; modification-date="Fri, 14 Oct 2011 16:21:14 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= --_004_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E07MDWEXGMB02ciena_-- From prvs=32686a909c=lyong@ciena.com Fri Oct 14 14:38:39 2011 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 C9DBD21F8CE5 for ; Fri, 14 Oct 2011 14:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.844 X-Spam-Level: X-Spam-Status: No, score=-100.844 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, 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 lDI2GzWQn-tn for ; Fri, 14 Oct 2011 14:38:39 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id ED2C521F8CE1 for ; Fri, 14 Oct 2011 14:38:38 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p9ELYj51012892 for ; Fri, 14 Oct 2011 17:38:38 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 10ermbgwm5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 14 Oct 2011 17:38:38 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Fri, 14 Oct 2011 17:38:38 -0400 From: "Ong, Lyndon" To: "pce@ietf.org" Content-Class: urn:content-classes:message Date: Fri, 14 Oct 2011 17:38:35 -0400 Thread-Topic: questions on gmpls extensions Thread-Index: AcyKuaCxyi9VKgjER9uZ541OEzaaNg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18450.002 x-tm-as-result: No--35.754200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_004_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E39MDWEXGMB02ciena_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-14_06:2011-10-14, 2011-10-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1110140277 Subject: [Pce] questions on gmpls extensions 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, 14 Oct 2011 21:38:39 -0000 --_004_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E39MDWEXGMB02ciena_ Content-Type: multipart/alternative; boundary="_000_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E39MDWEXGMB02ciena_" --_000_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E39MDWEXGMB02ciena_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, I support completion of the GMPLS PCE extensions, but I did have a couple o= f questions on the draft: 1) How are the label set and suggested label objects used, given that = labels are local significance? Are these used only for the egress interfac= e? 2) Switching Type and LSP Encoding Type look like they could be in two= spots, in the SWITCH-LAYER object and in the ENDPOINTS object Label_Reques= t TLV - did I misread this? Or if this is correct, when would you use one = vs. the other? I did not find this on the archives, my apologies if this has been asked an= d answered before. Cheers, Lyndon [cid:image93cb61.gif@09f25551.180c4608] --_000_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E39MDWEXGMB02ciena_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Folks,

 =

I support completion of the GMPLS PCE extens= ions, but I did have a couple of questions on the draft:

 

1) =      How are the label set and = suggested label objects used, given that labels are local significance?&nbs= p; Are these used only for the egress interface?

 

2) &= nbsp;    Switching Type and LSP Enco= ding Type look like they could be in two spots, in the SWITCH-LAYER object = and in the ENDPOINTS object Label_Request TLV – did I misread this? &= nbsp;Or if this is correct, when would you use one vs. the other?

 

I did n= ot find this on the archives, my apologies if this has been asked and answe= red before.

 

Cheers,

 <= /p>

Lyndon

&nbs= p;

 


3D"ciena

= --_000_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E39MDWEXGMB02ciena_-- --_004_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E39MDWEXGMB02ciena_ Content-Type: image/gif; name="image93cb61.gif@09f25551.180c4608" Content-Description: image93cb61.gif@09f25551.180c4608 Content-Disposition: inline; filename="image93cb61.gif@09f25551.180c4608"; size=3410; creation-date="Fri, 14 Oct 2011 17:38:38 GMT"; modification-date="Fri, 14 Oct 2011 17:38:38 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= --_004_A0B4FC0A5EFBD44585414760DB4FD2742A8C4E39MDWEXGMB02ciena_-- From edc@google.com Sun Oct 16 22:33:42 2011 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 4D20C21F8AFF for ; Sun, 16 Oct 2011 22:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 4w25IRzBxamJ for ; Sun, 16 Oct 2011 22:33:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6F45921F8ABB for ; Sun, 16 Oct 2011 22:33:41 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p9H5XeBW006513 for ; Sun, 16 Oct 2011 22:33:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318829620; bh=4yJqlJTHgPB83XxPwiOKKw6ZgiU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WkeN8qyldpZ46o+7E5i0FYPD+K46hYAw4rFlZM98Gnir9JXnwufVwJgxnsZAl6o2A NLjswTC7JcHtKqR6NBHIA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=SrOUPrqNXVLYaFHDA2JduqZz/YcbVKazVTVXvzeim9d5HWWJvkf7q3d2zBXy5DrM7 RFb5CZNuAhX95vVRGFc5A== Received: from yxs7 (yxs7.prod.google.com [10.190.5.135]) by hpaq6.eem.corp.google.com with ESMTP id p9H5TBTG021499 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 16 Oct 2011 22:33:39 -0700 Received: by yxs7 with SMTP id 7so4009128yxs.10 for ; Sun, 16 Oct 2011 22:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Lxp9SRvTUjfT4bhmxM0UGylgMo12mpqq4eNn6JG9xaU=; b=xCBuZEYm8sWSPxNBEQBgwTDC+eFKCU++fwRdVgFfhXfPC3wElY6y8HwxUB3HbWsiad rHqT6+NzPCh4euBWODnA== Received: by 10.150.73.39 with SMTP id v39mr16511604yba.96.1318829619384; Sun, 16 Oct 2011 22:33:39 -0700 (PDT) Received: by 10.150.73.39 with SMTP id v39mr16511587yba.96.1318829619125; Sun, 16 Oct 2011 22:33:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.137.5 with HTTP; Sun, 16 Oct 2011 22:33:19 -0700 (PDT) In-Reply-To: <20111017025125.12274.29902.idtracker@ietfa.amsl.com> References: <20111017025125.12274.29902.idtracker@ietfa.amsl.com> From: Edward Crabbe Date: Sun, 16 Oct 2011 22:33:19 -0700 Message-ID: To: pce@ietf.org Content-Type: multipart/alternative; boundary=000e0cd58e6cf79e9d04af77f231 X-System-Of-Record: true Cc: JP Vasseur Subject: [Pce] Fwd: New Version Notification for draft-crabbe-pce-stateful-pce-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, 17 Oct 2011 05:33:42 -0000 --000e0cd58e6cf79e9d04af77f231 Content-Type: text/plain; charset=ISO-8859-1 Hello; We've submitted a draft for the group's consideration. We know that stateful PCE has been discussed by the working group in the past. We believe that we have addressed some of the issues that have been raised in previous discussions and have specific use cases that make stateful PCE valuable. We hope you'll find the time to look through the draft and comment on the list before the WG meeting in Taipei, and hope that we'll be able to have a fruitful and lively discussion there. best, -Edward ---------- Forwarded message ---------- From: Date: Sun, Oct 16, 2011 at 7:51 PM Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt To: edc@google.com Cc: jmedved@juniper.net, edc@google.com, rvarga@juniper.net A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been successfully submitted by Edward Crabbe and posted to the IETF repository. Filename: draft-crabbe-pce-stateful-pce Revision: 00 Title: PCEP Extensions for Stateful PCE Creation date: 2011-10-16 WG ID: Individual Submission Number of pages: 39 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 this functionality, providing stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP. The IETF Secretariat --000e0cd58e6cf79e9d04af77f231 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello;

We've submitted a draft for the group's c= onsideration. =A0We know that stateful PCE has been d= iscussed=A0by the working group in the past. We believe that we have addres= sed some of=A0the issues that have been raised in previous discussions and = have specific=A0use cases that make stateful PCE valuable. We hope you'= ll find the time to=A0look through the draft and comment on the list before= the WG meeting in Taipei, and hope that we'll be able to have a fruitf= ul and lively discussion there. =A0

best,
<= br>
=A0 =A0-Edward

---------- Forwarded message ----------
From: <internet-drafts@ietf.org<= /a>>
Date: Sun, Oct 16, 2011 at 7:51 PM
Subject: New Version Notification for= draft-crabbe-pce-stateful-pce-00.txt
To: edc@google.com
Cc: jmedved@juniper.net, edc@google.com, rvarga@juniper.net


A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been= successfully submitted by Edward Crabbe and posted to the IETF repository.=

Filename: =A0 =A0 =A0 =A0draft-crabbe-pce-stateful-pce
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 PCEP Extensions for Stateful PCE
Creation date: =A0 2011-10-16
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 39

Abstract:
=A0 The Path Computation Element Communication Protocol (PCEP) provides =A0 mechanisms for Path Computation Elements (PCEs) to perform path
=A0 computations in response to Path Computation Clients (PCCs) requests.<= br>
=A0 Although PCEP explicitly makes no assumptions regarding the
=A0 information available to the PCE, it also makes no provisions for
=A0 synchronization or PCE control of timing and sequence of path
=A0 computations within and across PCEP sessions. =A0This document
=A0 describes a set of extensions to PCEP to enable this functionality, =A0 providing stateful control of Multiprotocol Label Switching (MPLS)
=A0 Traffic Engineering Label Switched Paths (TE LSP) via PCEP.





The IETF Secretariat

--000e0cd58e6cf79e9d04af77f231-- From jpv@cisco.com Mon Oct 17 01:52:00 2011 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 473B221F854D for ; Mon, 17 Oct 2011 01:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 DNt+csAN9i0t for ; Mon, 17 Oct 2011 01:51:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6051921F853A for ; Mon, 17 Oct 2011 01:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=146; q=dns/txt; s=iport; t=1318841519; x=1320051119; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=f77uMhaP6ucGVpT68z4Ja2Pvf+seDqqnDE4g4/V70+A=; b=Rw3mb2qnlTO2M0ipK1dCm4ECxffxv1nq3l+Htq1ZuKgDk2P716cepdrh +Svm/LF85PvuWetYsMPl1Lo6c0dFybuB9YoVqXD/QFioI7WaxvlUQFMge BHMcy1FxucOaJV4FqIEMmfNRSb8+yRAc0gQhIM+p7isM0+7XJHSuZRMW6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQIAHbrm05Io8UR/2dsb2JhbABDmgOOX4EFggcBJ4IynUiBJgGQMI1AhydhBJN6hSkJjCY X-IronPort-AV: E=Sophos;i="4.69,358,1315180800"; d="scan'208";a="119260160" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 17 Oct 2011 08:51:57 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9H8puLj006154 for ; Mon, 17 Oct 2011 08:51:57 GMT Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 14:21:56 +0530 Received: from [10.60.114.232] ([10.60.114.232]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 14:21:55 +0530 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 17 Oct 2011 10:51:54 +0200 Message-Id: <8C75947D-0626-4784-B8E6-C60CACEE6F86@cisco.com> To: pce@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 17 Oct 2011 08:51:55.0987 (UTC) FILETIME=[05FFA230:01CC8CAA] Subject: [Pce] Provisional PCE Meeting for IETF-82 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, 17 Oct 2011 08:52:00 -0000 pce Session 1 (2 hours) Thursday, Afternoon Session I 1300-1500 Room Name: 3F Banquet --------------------------------------------- From julien.meuric@orange.com Mon Oct 17 05:55:55 2011 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 BCB9121F8AFB for ; Mon, 17 Oct 2011 05:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 KfKz4GQMyrwN for ; Mon, 17 Oct 2011 05:55:55 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3603321F8AEE for ; Mon, 17 Oct 2011 05:55:55 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5660AB58007 for ; Mon, 17 Oct 2011 15:05:38 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 51CD3B58004 for ; Mon, 17 Oct 2011 15:05:38 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 14:55:53 +0200 Received: from [10.193.71.78] ([10.193.71.78]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 14:55:53 +0200 Message-ID: <4E9C25D9.3070609@orange.com> Date: Mon, 17 Oct 2011 14:55:53 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2011 12:55:53.0532 (UTC) FILETIME=[1AA7BFC0:01CC8CCC] Subject: [Pce] Building the PCE Agenda 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, 17 Oct 2011 12:55:55 -0000 Hi PCE WG. If you intend to present during our meeting in Taipei, please send a message to _both_ chairs and secretary not later than Monday 31st October. Include the I-D/presentation title, the estimated duration and the (forecast) presenter's name. Like last time, please keep in mind that individual I-Ds which have not been publicly discussed _on list_ since their previous presentation will be disregarded for the agenda. Thank you, JP & Julien From greg.jones@itu.int Mon Oct 17 16:44:22 2011 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 1423D11E8096 for ; Mon, 17 Oct 2011 16:44:22 -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 g1Qdw73BCoXu for ; Mon, 17 Oct 2011 16:44:21 -0700 (PDT) Received: from kapur.svc.unicc.org (kapur.svc.unicc.org [193.194.138.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5F54F11E8095 for ; Mon, 17 Oct 2011 16:44:20 -0700 (PDT) Received: from gombe.svc.unicc.org (gombe.svc.unicc.org [192.168.202.227]) by kapur.svc.unicc.org (Switch-3.1.7/Switch-3.1.7) with ESMTP id p9HNhfrP005965; Tue, 18 Oct 2011 01:43:41 +0200 Received: from lati.svc.unicc.org (localhost.localdomain [127.0.0.1]) by gombe.svc.unicc.org (Switch-3.1.7/Switch-3.1.7) with ESMTP id p9HNiIJs014042; Tue, 18 Oct 2011 01:44:19 +0200 Received: from mailweb.itu.int ([10.81.6.61]) by lati.svc.unicc.org (Switch-3.1.7/Switch-3.1.7) with ESMTP id p9HNiIac032246; Tue, 18 Oct 2011 01:44:18 +0200 Received: from TUCHM04.TUECSP.UNICC.ORG ([10.81.38.61]) by TUCHM02 ([10.81.6.61]) with mapi id 14.01.0289.001; Mon, 17 Oct 2011 23:43:59 +0000 From: "Jones, Greg" To: Julien Meuric , "pce@ietf.org" Thread-Topic: [Pce] Building the PCE Agenda Thread-Index: AQHMjMwUavlhow3xMk+ZlLW99yalopWBM6/Q Date: Mon, 17 Oct 2011 23:43:59 +0000 Message-ID: References: <4E9C25D9.3070609@orange.com> In-Reply-To: <4E9C25D9.3070609@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] Building the PCE Agenda 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, 17 Oct 2011 23:44:22 -0000 Tom, I have forwarded to Toby for action. I do not have the file. Regards, Greg Julien Meuric wrote: Hi PCE WG. If you intend to present during our meeting in Taipei, please send a message to _both_ chairs and secretary not later than Monday 31st October. Include the I-D/presentation title, the estimated duration and the (forecast) presenter's name. Like last time, please keep in mind that individual I-Ds which have not been publicly discussed _on list_ since their previous presentation will be disregarded for the agenda. Thank you, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From adrian@olddog.co.uk Tue Oct 18 05:40:04 2011 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 A868821F8A69 for ; Tue, 18 Oct 2011 05:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 1IU3XsNViyS0 for ; Tue, 18 Oct 2011 05:40:02 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 2B19F21F8A55 for ; Tue, 18 Oct 2011 05:40:00 -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 p9ICdtSX014964; Tue, 18 Oct 2011 13:39:55 +0100 Received: from 950129200 ([149.254.187.112]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9ICdpGL014957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Oct 2011 13:39:53 +0100 From: "Adrian Farrel" To: "'Edward Crabbe'" References: <20111017025125.12274.29902.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 18 Oct 2011 13:39:49 +0100 Message-ID: <047901cc8d93$0904a4f0$1b0deed0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_047A_01CC8D9B.6ACC1A30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH2opK3lyhUEe8DM/jXtMwyzJq0+AIwSccYlRxWxDA= Content-language: en-gb Cc: pce@ietf.org, 'JP Vasseur' Subject: Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-00.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: Tue, 18 Oct 2011 12:40:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_047A_01CC8D9B.6ACC1A30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Ed, Interesting work, thanks. As you know, the concept of stateful PCE was in our minds all through the architecture phase of PCE and is included as a concept in RFC 4655. I think stateful PCE was left on one side over the last few years because it added complexity and the use cases were far more sophisticated than applied to initial use cases. But now that PCE is established as an idea, it is interesting to look at the more advanced uses that you describe and see how stateful PCE could be a benefit. It is good that you have a section on policy, because it is likely that operators will want to tweak this function in different ways according to how they run their networks. It might be interesting to make a reference to RFC 5394 and show how that description of policy fits in. Maybe the authors of 5394 could comment? You don't mention RFC 5557. Is this because you think GCO is too complex to be valuable or because it is not one of your primary use cases? Thanks, Adrian From: Edward Crabbe [mailto:edc@google.com] Sent: 17 October 2011 06:33 To: pce@ietf.org Cc: JP Vasseur; Julien Meuric Subject: Fwd: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt Hello; We've submitted a draft for the group's consideration. We know that stateful PCE has been discussed by the working group in the past. We believe that we have addressed some of the issues that have been raised in previous discussions and have specific use cases that make stateful PCE valuable. We hope you'll find the time to look through the draft and comment on the list before the WG meeting in Taipei, and hope that we'll be able to have a fruitful and lively discussion there. best, -Edward ---------- Forwarded message ---------- From: Date: Sun, Oct 16, 2011 at 7:51 PM Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt To: edc@google.com Cc: jmedved@juniper.net, edc@google.com, rvarga@juniper.net A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been successfully submitted by Edward Crabbe and posted to the IETF repository. Filename: draft-crabbe-pce-stateful-pce Revision: 00 Title: PCEP Extensions for Stateful PCE Creation date: 2011-10-16 WG ID: Individual Submission Number of pages: 39 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 this functionality, providing stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP. The IETF Secretariat ------=_NextPart_000_047A_01CC8D9B.6ACC1A30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Ed,

 

Interesting work, thanks. As = you know, the concept of stateful PCE was in our minds all through the = architecture phase of PCE and is included as a concept in RFC = 4655.

 

I think stateful PCE was left = on one side over the last few years because it added complexity and the = use cases were far more sophisticated than applied to initial use cases. = But now that PCE is established as an idea, it is interesting to look at = the more advanced uses that you describe and see how stateful PCE could = be a benefit.

 

It is good that you have a = section on policy, because it is likely that operators will want to = tweak this function in different ways according to how they run their = networks. It might be interesting to make a reference to RFC 5394 and = show how that description of policy fits in. Maybe the authors of 5394 = could comment?

 

You don't mention RFC 5557. Is = this because you think GCO is too complex to be valuable or because it = is not one of your primary use cases?

 

Thanks,

Adrian

 

From: Edward Crabbe = [mailto:edc@google.com]
Sent: 17 October 2011 = 06:33
To: pce@ietf.org
Cc: JP Vasseur; Julien = Meuric
Subject: Fwd: New Version Notification for = draft-crabbe-pce-stateful-pce-00.txt

 

Hello;

 

We've submitted a draft for the group's consideration. =  We know that stateful PCE has been discussed by the working = group in the past. We believe that we have addressed some of the = issues that have been raised in previous discussions and have = specific use cases that make stateful PCE valuable. We hope you'll = find the time to look through the draft and comment on the list = before the WG meeting in Taipei, and hope that we'll be able to have a = fruitful and lively discussion there. =  

 

best,

 

  =  -Edward

 

---------- Forwarded message ----------
From: = <internet-drafts@ietf.org>
Date: Sun, Oct 16, = 2011 at 7:51 PM
Subject: New Version Notification for = draft-crabbe-pce-stateful-pce-00.txt
To: edc@google.com
Cc: jmedved@juniper.net, edc@google.com, rvarga@juniper.net


A new version of = I-D, draft-crabbe-pce-stateful-pce-00.txt has been successfully = submitted by Edward Crabbe and posted to the IETF = repository.

Filename:       =  draft-crabbe-pce-stateful-pce
Revision:       =  00
Title:           PCEP Extensions = for Stateful PCE
Creation date:   2011-10-16
WG ID:   =         Individual Submission
Number of pages: = 39

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 this = functionality,
  providing stateful control of Multiprotocol = Label Switching (MPLS)
  Traffic Engineering Label Switched = Paths (TE LSP) via PCEP.





The IETF = Secretariat

 

------=_NextPart_000_047A_01CC8D9B.6ACC1A30-- From edc@google.com Tue Oct 18 18:32:34 2011 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 9C9A41F0C42 for ; Tue, 18 Oct 2011 18:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 ICKjBDbc8X+j for ; Tue, 18 Oct 2011 18:32:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 561D91F0C40 for ; Tue, 18 Oct 2011 18:32:33 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p9J1WViv018320 for ; Tue, 18 Oct 2011 18:32:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318987952; bh=WLzPdmbygaUpb8E/c5jJERNoqEw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ABGPvLdZ0JX73kzxr3+SMvzEm0hnqGWWFYkRwHDKclKB9/68D/OXD3F2MLeUoHpur dSe6JYgOvRIsdz3QuSMew== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=e6UukhZofDWikeYFfcq3s+qLU0FW0Yf8+yNbrg4QFyEdHIdm2UmK+2/FbJ2Q7A71f hr1EfjK3oIR/viePRR/DQ== Received: from vcbfo14 (vcbfo14.prod.google.com [10.220.205.14]) by wpaz37.hot.corp.google.com with ESMTP id p9J1TZRC011621 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 18 Oct 2011 18:32:30 -0700 Received: by vcbfo14 with SMTP id fo14so1869197vcb.4 for ; Tue, 18 Oct 2011 18:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=JQGWl4UlOrE5OEDjkapuPWf5V757XY5hkbhUzyAwSNc=; b=IQdWABbWKoFuXY80dOBU+koMs+GSy+RFOVtSnjDszAQYcmeyZw+EUuZ292uF2GVlWv zgTaWVcOD+z0PTzGjyRA== Received: by 10.150.63.2 with SMTP id l2mr4384079yba.111.1318987950415; Tue, 18 Oct 2011 18:32:30 -0700 (PDT) Received: by 10.150.63.2 with SMTP id l2mr4384063yba.111.1318987950143; Tue, 18 Oct 2011 18:32:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.137.5 with HTTP; Tue, 18 Oct 2011 18:32:10 -0700 (PDT) In-Reply-To: <047901cc8d93$0904a4f0$1b0deed0$@olddog.co.uk> References: <20111017025125.12274.29902.idtracker@ietfa.amsl.com> <047901cc8d93$0904a4f0$1b0deed0$@olddog.co.uk> From: Edward Crabbe Date: Tue, 18 Oct 2011 18:32:10 -0700 Message-ID: To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=000e0cd3b27c3b391704af9cd016 X-System-Of-Record: true Cc: pce@ietf.org, JP Vasseur Subject: Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-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: Wed, 19 Oct 2011 01:32:34 -0000 --000e0cd3b27c3b391704af9cd016 Content-Type: text/plain; charset=ISO-8859-1 Adrian; I think not mentioning 5557 is clearly an oversight on our part. We will remedy this in the next version of the draft. Optimization of resource usage is certainly an interesting use case for stateful PCE (although by no means the only one), and the draft would benefit from a comparison with what is achievable via stateful extensions relative to 5557. Global control of LSP operation sequence in 5557 is predicated on the use of what is effectively a stateful (or semi-stateful) NMS, which is either not local to the switch (in which case we are required to use another northbound interface for LSP attribute changes) or local/collocated, in which case we have some significant issues with efficiency in resource usage. Stateful adds a few features here in that: 1) the requirements for the NMS and additional northbound interface are effectively removed 2) it allows the system with the greatest visibility of the system to determine which LSPs should reoptimized and on what time interval 3) the pce controls the sequence of events across pcc's, allowing for bulk (if not global) optimization, lsp shuffling etc Thanks much for pointing out the oversight. :-/ best, -ed On Tue, Oct 18, 2011 at 5:39 AM, Adrian Farrel wrote: > Hi Ed,**** > > ** ** > > Interesting work, thanks. As you know, the concept of stateful PCE was in > our minds all through the architecture phase of PCE and is included as a > concept in RFC 4655.**** > > ** ** > > I think stateful PCE was left on one side over the last few years because > it added complexity and the use cases were far more sophisticated than > applied to initial use cases. But now that PCE is established as an idea, it > is interesting to look at the more advanced uses that you describe and see > how stateful PCE could be a benefit.**** > > ** ** > > It is good that you have a section on policy, because it is likely that > operators will want to tweak this function in different ways according to > how they run their networks. It might be interesting to make a reference to > RFC 5394 and show how that description of policy fits in. Maybe the authors > of 5394 could comment?**** > > ** ** > > You don't mention RFC 5557. Is this because you think GCO is too complex to > be valuable or because it is not one of your primary use cases?**** > > ** ** > > Thanks,**** > > Adrian**** > > ** ** > > *From:* Edward Crabbe [mailto:edc@google.com] > *Sent:* 17 October 2011 06:33 > *To:* pce@ietf.org > *Cc:* JP Vasseur; Julien Meuric > *Subject:* Fwd: New Version Notification for > draft-crabbe-pce-stateful-pce-00.txt**** > > ** ** > > Hello;**** > > ** ** > > We've submitted a draft for the group's consideration. We know that > stateful PCE has been discussed by the working group in the past. We believe > that we have addressed some of the issues that have been raised in previous > discussions and have specific use cases that make stateful PCE valuable. We > hope you'll find the time to look through the draft and comment on the list > before the WG meeting in Taipei, and hope that we'll be able to have a > fruitful and lively discussion there. **** > > ** ** > > best,**** > > ** ** > > -Edward**** > > ** ** > > ---------- Forwarded message ---------- > From: > Date: Sun, Oct 16, 2011 at 7:51 PM > Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt > To: edc@google.com > Cc: jmedved@juniper.net, edc@google.com, rvarga@juniper.net > > > A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been > successfully submitted by Edward Crabbe and posted to the IETF repository. > > Filename: draft-crabbe-pce-stateful-pce > Revision: 00 > Title: PCEP Extensions for Stateful PCE > Creation date: 2011-10-16 > WG ID: Individual Submission > Number of pages: 39 > > 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 this functionality, > providing stateful control of Multiprotocol Label Switching (MPLS) > Traffic Engineering Label Switched Paths (TE LSP) via PCEP. > > > > > > The IETF Secretariat**** > > ** ** > --000e0cd3b27c3b391704af9cd016 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adrian;

I think not mentioning 5557 is clearl= y an oversight on our part. =A0We will remedy this in the next version of t= he draft.=A0

Optimization of resource usage is cer= tainly an interesting use case=A0for stateful PCE (although by no means the= only one), and the draft would benefit from a comparison with what is achi= evable via stateful=A0extensions relative to 5557. =A0 =A0

Global control of LSP operation sequence in 5557 is pre= dicated on the use=A0of what is effectively a stateful (or semi-stateful) N= MS, which is either=A0not local to the switch (in which case we are require= d to use another=A0northbound interface for LSP attribute changes) or local= /collocated, in=A0which case we have some significant issues with efficienc= y in resource=A0usage. =A0

Stateful adds a few features here in that:
1) the requirements for the NMS and additional northbound inte= rface are=A0
effectively removed=A0
2) it allows the sy= stem with the greatest visibility of the system to determine=A0
which LSPs should reoptimized and on what time interval=A0
3= ) the pce controls the sequence of events across pcc's, allowing for bu= lk
(if not global) optimization, lsp shuffling etc

Thanks much for pointing out the oversight. =A0:-/
best,

=A0 -ed

On Tue, Oct 18, 2011 at 5:39 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi Ed,

=A0

Interesting work, thanks. As you know, the concept of sta= teful PCE was in our minds all through the architecture phase of PCE and is= included as a concept in RFC 4655.

=A0

I think stateful PCE was left on one side over the last f= ew years because it added complexity and the use cases were far more sophis= ticated than applied to initial use cases. But now that PCE is established = as an idea, it is interesting to look at the more advanced uses that you de= scribe and see how stateful PCE could be a benefit.

=A0

It is good that you have a section on policy, because it = is likely that operators will want to tweak this function in different ways= according to how they run their networks. It might be interesting to make = a reference to RFC 5394 and show how that description of policy fits in. Ma= ybe the authors of 5394 could comment?

=A0

You don't mention RFC 5557. Is this because you think= GCO is too complex to be valuable or because it is not one of your primary= use cases?

=A0

Thanks,

Adrian

=A0

F= rom: Edward Crab= be [mailto:edc@google.c= om]
Sent: 17 October 2011 06:33
To: pce@ietf.org
Cc: JP Vasseur; Julien M= euric
Subject: Fwd: New Version Notification for draft-crabbe-pce= -stateful-pce-00.txt

=A0

Hello;

=A0

We= 9;ve submitted a draft for the group's consideration. =A0We know that stateful PCE has been disc= ussed=A0by the working group in the past. We believe that we have addressed= some of=A0the issues that have been raised in previous discussions and hav= e specific=A0use cases that make stateful PCE valuable. We hope you'll = find the time to=A0look through the draft and comment on the list before th= e WG meeting in Taipei, and hope that we'll be able to have a fruitful = and lively discussion there. =A0

=A0

best,

=A0

=A0 = =A0-Edward

=A0

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, Oct 16, 2011 at 7:51 PM
Subject: New Version Notification for= draft-crabbe-pce-stateful-pce-00.txt
To: edc@google.com
Cc: jmedved@juniper.net, edc@google.com, rvarga@juniper.net


A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been= successfully submitted by Edward Crabbe and posted to the IETF repository.=

Filename: =A0 =A0 =A0 =A0draft-crabbe-pce-stateful-pce
Revision:= =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 PCEP Extensions for Stateful PCE
Creation dat= e: =A0 2011-10-16
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Nu= mber of pages: 39

Abstract:
=A0 The Path Computation Element Comm= unication Protocol (PCEP) provides
=A0 mechanisms for Path Computation Elements (PCEs) to perform path
=A0 = computations in response to Path Computation Clients (PCCs) requests.
=A0 Although PCEP explicitly makes no assumptions regarding the
=A0 in= formation available to the PCE, it also makes no provisions for
=A0 synchronization or PCE control of timing and sequence of path
=A0 co= mputations within and across PCEP sessions. =A0This document
=A0 describ= es a set of extensions to PCEP to enable this functionality,
=A0 providi= ng stateful control of Multiprotocol Label Switching (MPLS)
=A0 Traffic Engineering Label Switched Paths (TE LSP) via PCEP.


=


The IETF Secretariat

=A0

<= /div>
--000e0cd3b27c3b391704af9cd016-- From jmedved@juniper.net Wed Oct 19 23:58:21 2011 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 7856D21F8509 for ; Wed, 19 Oct 2011 23:58:21 -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 OtbCWLLnkk8T for ; Wed, 19 Oct 2011 23:58:20 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEF921F8479 for ; Wed, 19 Oct 2011 23:58:17 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Oct 2011 23:58:20 PDT Received: from P-EMHUB11-HQ.jnpr.net (172.24.192.58) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Oct 2011 23:55:20 -0700 Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB11-HQ.jnpr.net ([::1]) with mapi; Wed, 19 Oct 2011 23:55:20 -0700 From: Jan Medved To: "adrian@olddog.co.uk" , 'Edward Crabbe' Date: Wed, 19 Oct 2011 23:55:13 -0700 Thread-Topic: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-00.txt Thread-Index: AcyO9TrEN6P46ehnQrKVQUzhQrtTzw== Message-ID: In-Reply-To: <047901cc8d93$0904a4f0$1b0deed0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pce@ietf.org" , 'JP Vasseur' Subject: Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-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, 20 Oct 2011 06:58:21 -0000 Hi Adrian Good point about policy. The current revision of draft-crabbe-pce-stateful-= pce only covers only basic policy settings for the PCC. We also need to cov= er PCE-side policies, inter-component communication (e.g. what information = must be carried in State Reports form a PCE for use of a policy implemented= on a PCE), etc. IMO the PCE/PCC policy framework defined in RFC5394 by and large applies to= stateful PCEs as well. There will be stateful PCEP=96specific use cases an= d examples, policy attributes, and inter-component communication. They wou= ld need to be identified and documented.But the overall framework should b= e directly applicable. Thanks, Jan On 10/18/11 5:39 AM, "Adrian Farrel" > wrote: Hi Ed, Interesting work, thanks. As you know, the concept of stateful PCE was in o= ur minds all through the architecture phase of PCE and is included as a con= cept in RFC 4655. I think stateful PCE was left on one side over the last few years because i= t added complexity and the use cases were far more sophisticated than appli= ed to initial use cases. But now that PCE is established as an idea, it is = interesting to look at the more advanced uses that you describe and see how= stateful PCE could be a benefit. It is good that you have a section on policy, because it is likely that ope= rators will want to tweak this function in different ways according to how = they run their networks. It might be interesting to make a reference to RFC= 5394 and show how that description of policy fits in. Maybe the authors of= 5394 could comment? You don't mention RFC 5557. Is this because you think GCO is too complex to= be valuable or because it is not one of your primary use cases? Thanks, Adrian From: Edward Crabbe [mailto:edc@google.com] Sent: 17 October 2011 06:33 To: pce@ietf.org Cc: JP Vasseur; Julien Meuric Subject: Fwd: New Version Notification for draft-crabbe-pce-stateful-pce-00= .txt Hello; We've submitted a draft for the group's consideration. We know that statef= ul PCE has been discussed by the working group in the past. We believe that= we have addressed some of the issues that have been raised in previous dis= cussions and have specific use cases that make stateful PCE valuable. We ho= pe you'll find the time to look through the draft and comment on the list b= efore the WG meeting in Taipei, and hope that we'll be able to have a fruit= ful and lively discussion there. best, -Edward ---------- Forwarded message ---------- From: > Date: Sun, Oct 16, 2011 at 7:51 PM Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt To: edc@google.com Cc: jmedved@juniper.net, edc@google.com, rvarga@juniper.net A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been success= fully submitted by Edward Crabbe and posted to the IETF repository. Filename: draft-crabbe-pce-stateful-pce Revision: 00 Title: PCEP Extensions for Stateful PCE Creation date: 2011-10-16 WG ID: Individual Submission Number of pages: 39 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 this functionality, providing stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP. The IETF Secretariat From dhruv.dhody@huawei.com Thu Oct 20 01:06:07 2011 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 1301921F84AB for ; Thu, 20 Oct 2011 01:06:07 -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 xwNWqZkquJmG for ; Thu, 20 Oct 2011 01:06:05 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4862821F849B for ; Thu, 20 Oct 2011 01:06:05 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTC00EJ6UGW0J@szxga03-in.huawei.com> for pce@ietf.org; Thu, 20 Oct 2011 16:05:20 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTC00A9QUGW2S@szxga03-in.huawei.com> for pce@ietf.org; Thu, 20 Oct 2011 16:05:20 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI32721; Thu, 20 Oct 2011 16:05:19 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 16:05:13 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.196]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Thu, 20 Oct 2011 16:05:10 +0800 Date: Thu, 20 Oct 2011 08:05:10 +0000 From: Dhruv Dhody X-Originating-IP: [10.18.24.179] To: Peng JIANG , "ke-kumaki@kddi.com" , "murai@fnsc.co.jp" , "to-yamagata@kddi.com" , "ch-sasaki@kddilabs.jp" Message-id: <23CE718903A838468A8B325B80962F9B2639001D@SZXEML520-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_w1f2HsZlvEz4/GydmTsSxw)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: Query on draft-kumaki-murai-pce-pcep-extension-l3vpn-07 Thread-index: AcyO/vwamsCYaW4QSTmlvWTgt4O/GQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: [Pce] Query on draft-kumaki-murai-pce-pcep-extension-l3vpn-07 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, 20 Oct 2011 08:06:07 -0000 --Boundary_(ID_w1f2HsZlvEz4/GydmTsSxw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Authors, I understand that in this document you want to focus only on - "Dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites" and not the complete PCE-VPN-EXT. I agree completely with the need for address translation and use of VPN-IPv4/v6 ENDPOINTS. Though you mention that the model will work when PCE function is not the PE router, it's not immediately understood how. Especially when identification of VPN is based on incoming interface? If all PE routers must act as PCE, isn't it a drawback. Do you think this rule is acceptable? We need to figure out how PCE can learn the VPN information or do PCE and VPN must always co-locate. Also I find customer sites acting as a PCC, and connecting directly to Service Provider PCE not compatible with the PCE architecture. PCE-VPN-REQ documents talk about customer PCE cooperating with Service Provide PCE which fits better in the inter-domain path computation paradigm. Kindly provide your thoughts on this. Regards, Dhruv *************************************************************************************** Dhruv Dhody, Senior Technical Leader, 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! --Boundary_(ID_w1f2HsZlvEz4/GydmTsSxw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear Authors,

 

I understand that in this document you want to focus only on – “Dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites” and not the complete PCE-VPN-EXT.

 

I agree completely with the need for address translation and use of VPN-IPv4/v6 ENDPOINTS.

 

Though you mention that the model will work when PCE function is not the PE router, it’s not immediately understood how. Especially when identification of VPN is based on incoming interface?

If all PE routers must act as PCE, isn’t it a drawback. Do you think this rule is acceptable?

We need to figure out how PCE can learn the VPN information or do PCE and VPN must always co-locate.

 

Also I find customer sites acting as a PCC, and connecting directly to Service Provider PCE not compatible with the PCE architecture.

PCE-VPN-REQ documents talk about customer PCE cooperating with Service Provide PCE which fits better in the inter-domain path computation paradigm.

 

Kindly provide your thoughts on this.

 

Regards,

Dhruv

***************************************************************************************
Dhruv Dhody, Senior Technical Leader, 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!

 

--Boundary_(ID_w1f2HsZlvEz4/GydmTsSxw)-- From zhangfatai@huawei.com Thu Oct 20 20:55:37 2011 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 17C1921F8A35 for ; Thu, 20 Oct 2011 20:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.094 X-Spam-Level: X-Spam-Status: No, score=-4.094 tagged_above=-999 required=5 tests=[AWL=-1.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 htAdu1bctqtc for ; Thu, 20 Oct 2011 20:55:36 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8E65221F891D for ; Thu, 20 Oct 2011 20:55:35 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00E15DK10A@szxga04-in.huawei.com> for pce@ietf.org; Fri, 21 Oct 2011 11:55:13 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00JX0DK1WV@szxga04-in.huawei.com> for pce@ietf.org; Fri, 21 Oct 2011 11:55:13 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEP24640; Fri, 21 Oct 2011 11:55:08 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 11:55:03 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.196]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Fri, 21 Oct 2011 11:55:01 +0800 Date: Fri, 21 Oct 2011 03:55:00 +0000 From: Zhangfatai In-reply-to: <23CE718903A838468A8B325B80962F9BB65844@SZXEML520-MBX.china.huawei.com> X-Originating-IP: [10.70.76.157] To: Dhruv Dhody , "pce@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vVJWJ7MXcQKM03qn7XBf+A)" Content-language: en-US Accept-Language: zh-CN, en-US Thread-topic: Update in ID: draft-dhody-pce-pcep-domain-sequence Thread-index: AcxxOKGkuTRlAQXDT8SZMz6PceJEHAeaMZWA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <23CE718903A838468A8B325B80962F9BB65844@SZXEML520-MBX.china.huawei.com> Subject: Re: [Pce] Update in ID: draft-dhody-pce-pcep-domain-sequence 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, 21 Oct 2011 03:55:37 -0000 --Boundary_(ID_vVJWJ7MXcQKM03qn7XBf+A) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgRGhydXYgYW5kIGFsbCwNCg0KWW91IG1heSBub3RpY2UgdGhlIG1haWwgZnJvbSBSYW1vbiBh Ym91dCBbSFBDRS0gUENFUC1FWFRdLCB3aGljaCByYWlzZWQgYSBwb2ludCBhYm91dCB0aGUgZm9y bWF0IG9mIHRoZSBEb21haW4tSUQgVExWLiBXZSBhbHNvIHB1dCBhIGVkaXRvcnOhryBub3RlIGlu IHNlY3Rpb24gMy4xLjMgdG8gY2FwdHVyZSB0aGlzIGlzc3VlLg0KDQpJbiBbSFBDRS0gUENFUC1F WFRdIGRyYWZ0LCB3ZSBkZWZpbmVkIHRoZSBEb21haW4tSUQgVExWIHdoaWNoIGhhcyB0aGUgc2Ft ZSBmb3JtYXQgYXMgUENFLURPTUFJTiBzdWItVExWIGZvcm1hdCBkZWZpbmVkIGluIFJGQzUwODgs IGJ1dCB3ZSBkaWQgbm90IG5vdGljZSB0aGF0IHRoZSBsZW5ndGggb2YgIElTSVMgYXJlYSBJRCBz aG91bGQgYmUgdmFyaWFibGUuIFNvLCB3ZSBuZWVkIHRvIHJlZmluZSB0aGUgZm9ybWF0IGFzIGZv bGxvd3MgYXQgbGVhc3QgKGp1c3QgbXkgc3VnZ2VzdGlvbnMpOg0KDQoNCg0KICAgIDAgICAgICAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCg0K ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMQ0KDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICB8ICAgICAgICAgICBEb21haW4gVHlwZSAg ICAgICAgIHwgICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgfA0KDQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K DQogICAvLyAgICAgICAgICAgICAgICAgICAgICAgRG9tYWluIElEICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLy8NCg0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KDQoNCiAgVHlwZT0xOiBhbiBBUyBudW1i ZXIgKDQgYnl0ZXMpDQoNCiAgVHlwZT0yOiBPU1BGIGFyZWEgSUQgKDQgYnl0ZXMpDQoNCiAgVHlw ZT0zOiBJU0lTIGFyZWEgSUQsIHRoZSBsZW5ndGggaXMgdmFyaWFibGUNCg0KTm90ZSB0aGF0IHRo aXMgRG9tYWluLUlEIFRMViBjYW4gYmUgaW5jbHVkZWQgaW4gbWFueSBQQ0VQIG9iamVjdHMgbGlr ZSBPUEVOLCBOT1RJRklDQVRJT04sIFJQIG9iamVjdHMuDQoNCkFzIGZvciBbZHJhZnQtZGhvZHld LCB0aGUgc3ViLW9iamVjdHMgZXh0ZW5kZWQgaW4gdGhpcyBkcmFmdCBpcyBmb3IgSVJPLCB3aGlj aCBoYXMgdGhlIHNhbWUgZm9ybWF0IG9mIEVSTy4gIFNvIEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRv IGhhdmUgdGhpcyBkcmFmdCB0byBmb2xsb3cgdGhlIFJTVlAgc3ViLW9iamVjdHMgZm9ybWF0Lg0K DQpJbiBzdW1tYXJ5LCBJIHRoaW5rIHRoZSBEb21haW4gSUQgVExWIGNhbiBiZSBkZWZpbmVkIGFz IGRlZmluZWQgaW4gW0hQQ0UtIFBDRVAtRVhUXSAod2l0aCBzb21lIHJlZmluZW1lbnQpLCBJUk8g c3ViamVjdCBleHRlbnNpb24gY2FuIGJlIGRlZmluZWQgYXMgZGVmaW5lZCBpbiBbZHJhZnQtZGhv ZHldLg0KDQpXaGF0IGFyZSB5b3VyIG9waW5pb25zPw0KDQoNCg0KDQoNCg0KDQpUaGFua3MNCg0K RmF0YWkNCg0KRnJvbTogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIERocnV2IERob2R5DQpTZW50OiAyMDExxOo51MIxMsjVIDE4 OjUwDQpUbzogcGNlQGlldGYub3JnDQpTdWJqZWN0OiBbUGNlXSBVcGRhdGUgaW4gSUQ6IGRyYWZ0 LWRob2R5LXBjZS1wY2VwLWRvbWFpbi1zZXF1ZW5jZQ0KDQoNCkRlYXIgQWxsLA0KDQoNCg0KV2Ug aGF2ZSByb2xsZWQgb3V0IGEgbmV3IHZlcnNpb24gZm9yIERPTUFJTi1TRVEgZHJhZnQuDQoNCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRob2R5LXBjZS1wY2VwLWRvbWFpbi1zZXF1 ZW5jZS0wMQ0KDQoNCg0KTWFpbiBDaGFuZ2VzIGRvbmU6DQoNCiogQWxpZ25tZW50IGZvciB0aGUg bmV3IHN1Yi1vYmplY3RzDQoNCiogU3VwcG9ydCBmb3IgNCBieXRlIEFTIG51bWJlcg0KDQoNCg0K V2UgYXJlIHN0aWxsIGF3YWl0aW5nIGNvbW1lbnRzL3N1Z2dlc3Rpb25zIGluIFdHIHJlZ2FyZGlu Zw0KDQoqIE5ldyBJUk8gQ2xhc3MgVHlwZSBmb3IgZG9tYWluIFNlcXVlbmNlDQoNCiogVXNlIG9m IFJCTkYgdG8gZXhwbGFpbiBTdWJvYmplY3RzIG9yZGVyaW5nIHdpdGhpbiBkb21haW4tc2VxdWVu Y2UoSVJPIE9iamVjdCkNCg0KDQoNCkZvciBtb3JlIGluZm9ybWF0aW9uIHJlZmVyIE1lc3NhZ2Ug VGhyZWFkOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcGNlL2N1cnJl bnQvbXNnMDI1ODAuaHRtbA0KDQoNCg0KV2UgcGxhbiB0byByZXNvbHZlIHRoaXMgYmVmb3JlL2R1 cmluZyB0aGUgbmV4dCBJRVRGIG1lZXRpbmcuDQoNCg0KDQpSZWdhcmRzLA0KDQpEaHJ1dg0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCkRocnV2IERob2R5DQoNClNlbmlvciBUZWNobmljYWwgTGVhZGVyLCBI dWF3ZWkgVGVjaG5vbG9naWVzIEluZGlhIFB2dC4gTHRkLiwgQmFuZ2Fsb3JlLCBJbmRpYS4gUGgg KzkxLTk4NDUwNjI0MjINCg0KDQpUaGlzIGUtbWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFpbiBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlzIGludGVuZGVkIG9u bHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3Zl LiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkg KGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1 cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFu IHRoZSBpbnRlbmRlZCByZWNpcGllbnQncykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUg dGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9uZSBv ciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --Boundary_(ID_vVJWJ7MXcQKM03qn7XBf+A) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Dhruv and all,

 

You may notice the mail from Ramon about = [HPCE- PCEP-EXT], which raised a point about the format of the Domain-ID TL= V. We also put a editors=A1=AF note in section 3.1.3 to capture this issue.

 

In [HPCE- PCEP-EXT] draft, we defined the= Domain-ID TLV which has the same format as PCE-DOMAIN sub-TLV format defined in RFC5088,= but we did not notice that the length of  ISIS area ID should be vari= able. So, we need to refine the format as follows at least (just my suggestions):

 
    0       &nb=
sp;           1 &nbs=
p;             =
    2        &n=
bsp;          3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 =
3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+=

   |        &nb=
sp;  Domain Type         |&nbs=
p;           Reserved&nbs=
p;          |
   +-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+=

   //        &n=
bsp;            =
;  Domain ID         &nbs=
p;            &=
nbsp;       //
   +-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+=

 
  Type=3D1: an AS numb=
er (4 bytes)
  Type=3D2: OSPF area =
ID (4 bytes)
  Type=3D3: ISIS area =
ID, the length is variable

 

Note that this Domain-ID TLV can= be included in many PCEP objects like OPEN, NOTIFICATION, RP objects.

 

As for [draft-dhody], the sub-objects ext= ended in this draft is for IRO, which has the same format of ERO.  So = I think it is better to have this draft to follow the RSVP sub-objects format.

 

In summary, I think the Domain ID TLV can= be defined as defined in [HPCE- PCEP-EXT] (with some refinement), IRO subj= ect extension can be defined as defined in [draft-dhody].=

 

What are your opinions?=

 

 

 

 

 

 

 

Thanks
 
Fatai

 

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: 2011=C4=EA9=D4=C212=C8= =D5 18:50
To: pce@ietf.org
Subject: [Pce] Update in ID: draft-dhody-pce-pcep-domain-sequence

 

Dear All,

 

We have rolled out a new versi= on for DOMAIN-SEQ draft.

http://tools.ietf.org/html= /draft-dhody-pce-pcep-domain-sequence-01

 

Main Changes done:

* Alignment for the new sub-ob= jects

* Support for 4 byte AS number=

 

We are still awaiting comments= /suggestions in WG regarding

* New IRO Class Type for domai= n Sequence

* Use of RBNF to explain Subob= jects ordering within domain-sequence(IRO Object) 

 

For more information refer Mes= sage Thread:

http://www.ietf.org/mail-archi= ve/web/pce/current/msg02580.html

 

We plan to resolve this before= /during the next IETF meeting.

 

Regards,

Dhruv

 

------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------=

Dhruv Dhody

Senior Technical Leader, Huawe= i Technologies India Pvt. Ltd., Bangalore, India. Ph +91-9845062422&nbs= p;

 

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 th= e information contained herein in any way (including, but not limited to, t= otal or partial disclosure, reproduction, or dissemination) by persons othe= r 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!

------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------=

--Boundary_(ID_vVJWJ7MXcQKM03qn7XBf+A)-- From dhruv.dhody@huawei.com Fri Oct 21 01:51:27 2011 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 BFE8721F8A6F for ; Fri, 21 Oct 2011 01:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.546 X-Spam-Level: X-Spam-Status: No, score=-5.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 4a78bEGMaX80 for ; Fri, 21 Oct 2011 01:51:26 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0CB21F8A6C for ; Fri, 21 Oct 2011 01:51:26 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE002JJR4NWR@szxga03-in.huawei.com> for pce@ietf.org; Fri, 21 Oct 2011 16:48:23 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE0048AR45SG@szxga03-in.huawei.com> for pce@ietf.org; Fri, 21 Oct 2011 16:48:23 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI89299; Fri, 21 Oct 2011 16:48:23 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 16:48:14 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.196]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Fri, 21 Oct 2011 16:48:16 +0800 Date: Fri, 21 Oct 2011 08:48:14 +0000 From: Dhruv Dhody In-reply-to: X-Originating-IP: [10.18.24.179] To: Zhangfatai , "pce@ietf.org" Message-id: <23CE718903A838468A8B325B80962F9B26390141@SZXEML520-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_s5hxW3iVvza+M8P3PEm/Hw)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: Update in ID: draft-dhody-pce-pcep-domain-sequence Thread-index: AcxxOKGkuTRlAQXDT8SZMz6PceJEHAeaMZWAAAr6KnA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <23CE718903A838468A8B325B80962F9BB65844@SZXEML520-MBX.china.huawei.com> Subject: Re: [Pce] Update in ID: draft-dhody-pce-pcep-domain-sequence 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, 21 Oct 2011 08:51:27 -0000 --Boundary_(ID_s5hxW3iVvza+M8P3PEm/Hw) Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT Dear Fatai and all, I do agree with you in this regard, that we need SUB-Objects in case of IRO and ERO where we need a sequence of domains. But when domain information needs to be carried in OPEN, NOTIFICATION it may be similar to definition defined in PCE Discovery via OSPF, ISIS RFCs. [RFC 5088, 5089]. >>the Domain ID TLV can be defined as defined in [HPCE- PCEP-EXT] (with some refinement), IRO subject extension can be defined as defined in [draft-dhody]. So yes! This is the right way forward IMHO! :D Regards, Dhruv *************************************************************************************** Dhruv Dhody, Senior Technical Leader, 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! From: Zhangfatai Sent: Friday, October 21, 2011 9:25 AM To: Dhruv Dhody; pce@ietf.org Subject: RE: Update in ID: draft-dhody-pce-pcep-domain-sequence Hi Dhruv and all, You may notice the mail from Ramon about [HPCE- PCEP-EXT], which raised a point about the format of the Domain-ID TLV. We also put a editors$B!G(B note in section 3.1.3 to capture this issue. In [HPCE- PCEP-EXT] draft, we defined the Domain-ID TLV which has the same format as PCE-DOMAIN sub-TLV format defined in RFC5088, but we did not notice that the length of ISIS area ID should be variable. So, we need to refine the format as follows at least (just my suggestions): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Domain ID // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type=1: an AS number (4 bytes) Type=2: OSPF area ID (4 bytes) Type=3: ISIS area ID, the length is variable Note that this Domain-ID TLV can be included in many PCEP objects like OPEN, NOTIFICATION, RP objects. As for [draft-dhody], the sub-objects extended in this draft is for IRO, which has the same format of ERO. So I think it is better to have this draft to follow the RSVP sub-objects format. In summary, I think the Domain ID TLV can be defined as defined in [HPCE- PCEP-EXT] (with some refinement), IRO subject extension can be defined as defined in [draft-dhody]. What are your opinions? Thanks Fatai From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: 2011$BG/(B9$B7n(B12$BF|(B 18:50 To: pce@ietf.org Subject: [Pce] Update in ID: draft-dhody-pce-pcep-domain-sequence Dear All, We have rolled out a new version for DOMAIN-SEQ draft. http://tools.ietf.org/html/draft-dhody-pce-pcep-domain-sequence-01 Main Changes done: * Alignment for the new sub-objects * Support for 4 byte AS number We are still awaiting comments/suggestions in WG regarding * New IRO Class Type for domain Sequence * Use of RBNF to explain Subobjects ordering within domain-sequence(IRO Object) For more information refer Message Thread: http://www.ietf.org/mail-archive/web/pce/current/msg02580.html We plan to resolve this before/during the next IETF meeting. Regards, Dhruv ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Dhruv Dhody Senior Technical Leader, Huawei Technologies India Pvt. Ltd., 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! ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ --Boundary_(ID_s5hxW3iVvza+M8P3PEm/Hw) Content-type: text/html; charset=iso-2022-jp Content-transfer-encoding: 7BIT

Dear Fatai and all,

 

I do agree with you in this regard, that we need SUB-Objects in case of IRO and ERO where we need a sequence of domains.

But when domain information needs to be carried in OPEN, NOTIFICATION it may be similar to definition defined in PCE Discovery via OSPF, ISIS RFCs. [RFC 5088, 5089].

 

>>the Domain ID TLV can be defined as defined in [HPCE- PCEP-EXT] (with some refinement), IRO subject extension can be defined as defined in [draft-dhody].

 

So yes! This is the right way forward IMHO! :D

 

Regards,

Dhruv

 

***************************************************************************************
Dhruv Dhody, Senior Technical Leader, 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!

 

From: Zhangfatai
Sent: Friday, October 21, 2011 9:25 AM
To: Dhruv Dhody; pce@ietf.org
Subject: RE: Update in ID: draft-dhody-pce-pcep-domain-sequence

 

Hi Dhruv and all,

 

You may notice the mail from Ramon about [HPCE- PCEP-EXT], which raised a point about the format of the Domain-ID TLV. We also put a editors$B!G(B note in section 3.1.3 to capture this issue.

 

In [HPCE- PCEP-EXT] draft, we defined the Domain-ID TLV which has the same format as PCE-DOMAIN sub-TLV format defined in RFC5088, but we did not notice that the length of  ISIS area ID should be variable. So, we need to refine the format as follows at least (just my suggestions):

 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Domain Type         |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                       Domain ID                              //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
  Type=1: an AS number (4 bytes)
  Type=2: OSPF area ID (4 bytes)
  Type=3: ISIS area ID, the length is variable

 

Note that this Domain-ID TLV can be included in many PCEP objects like OPEN, NOTIFICATION, RP objects.

 

As for [draft-dhody], the sub-objects extended in this draft is for IRO, which has the same format of ERO.  So I think it is better to have this draft to follow the RSVP sub-objects format.

 

In summary, I think the Domain ID TLV can be defined as defined in [HPCE- PCEP-EXT] (with some refinement), IRO subject extension can be defined as defined in [draft-dhody].

 

What are your opinions?

 

 

 

 

 

 

 

Thanks
 
Fatai

 

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: 2011$BG/(B9$B7n(B12$BF|(B 18:50
To: pce@ietf.org
Subject: [Pce] Update in ID: draft-dhody-pce-pcep-domain-sequence

 

Dear All,

 

We have rolled out a new version for DOMAIN-SEQ draft.

http://tools.ietf.org/html/draft-dhody-pce-pcep-domain-sequence-01

 

Main Changes done:

* Alignment for the new sub-objects

* Support for 4 byte AS number

 

We are still awaiting comments/suggestions in WG regarding

* New IRO Class Type for domain Sequence

* Use of RBNF to explain Subobjects ordering within domain-sequence(IRO Object) 

 

For more information refer Message Thread:

http://www.ietf.org/mail-archive/web/pce/current/msg02580.html

 

We plan to resolve this before/during the next IETF meeting.

 

Regards,

Dhruv

 

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

Dhruv Dhody

Senior Technical Leader, Huawei Technologies India Pvt. Ltd., 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!

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

--Boundary_(ID_s5hxW3iVvza+M8P3PEm/Hw)-- From he.wenjuan1@zte.com.cn Mon Oct 24 02:37:01 2011 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 0F87821F8B79 for ; Mon, 24 Oct 2011 02:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.996 X-Spam-Level: X-Spam-Status: No, score=-97.996 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, 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 5jUpOVrW8ASh for ; Mon, 24 Oct 2011 02:37:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9C73021F8B87 for ; Mon, 24 Oct 2011 02:36:59 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417131441414862; Mon, 24 Oct 2011 17:33:19 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.1441414862; Mon, 24 Oct 2011 17:36:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9O9aJVj050457 for ; Mon, 24 Oct 2011 17:36:19 +0800 (GMT-8) (envelope-from he.wenjuan1@zte.com.cn) To: pce@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: he.wenjuan1@zte.com.cn Date: Mon, 24 Oct 2011 17:36:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-24 17:36:22, Serialize complete at 2011-10-24 17:36:22 Content-Type: multipart/alternative; boundary="=_alternative 003503CC48257933_=" X-MAIL: mse02.zte.com.cn p9O9aJVj050457 Subject: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-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, 24 Oct 2011 09:37:01 -0000 This is a multipart message in MIME format. --=_alternative 003503CC48257933_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KV2UndmUgc3VibWl0dGVkIGEgZHJhZnQgZm9yIHRoZSBleHRlbnNpb25zIG9mIFBD RVAgdG8gc3VwcG9ydCBhc3NvY2lhdGVkIA0KYmlkaXJlY3Rpb25hbCBsc3AsIGJlbG93IGlzIHRo ZSBsaW5rOiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhlLXBjZS1wY2VwLWFz c29jaWF0ZWQtbHNwLWV4dGVuc2lvbnMtMDAuIA0KDQoNClRoZSBNUExTLVRQIHJlcXVpcmVtZW50 cyBbUkZDNTY1NF0gYW5kIGNvbnRyb2wgcGxhbmUgZnJhbWV3b3JrIA0KZG9jdW1lbnRzW1JGQzYz NzNdZGVzY3JpYmUgdGhhdCBNUExTLVRQIE1VU1QNCnN1cHBvcnQgYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIHBvaW50LXRvLXBvaW50IExTUHMuICBQYXRoIENvbXB1dGF0aW9uIA0KRWxlbWVudCAo UENFKSwgc2VlIFtSRkM0NjU1XSwgbWF5IGJlIHVzZWQgZm9yIHBhdGgNCmNvbXB1dGF0aW9uIG9m IGEgR01QTFMgTFNQLGFuZCBjb25zZXF1ZW50bHkgYW4gYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IA0KTFNQLCBhY3Jvc3MgZG9tYWlucyBhbmQgaW4gYSBzaW5nbGUgZG9tYWluLg0KDQpBcyBkZXNj cmliZWQgaW4gDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLW1w bHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMg0KLA0KdGhlIGFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbCBMU1AgY2FuIGJlIGRlcGxveWVkIGJ5IFNpbmdsZSBTaWRlZCANClByb3Zpc2lv bmluZyBtb2RlbCBvciBEb3VibGUgU2lkZWQgUHJvdmlzaW9uaW5nDQptb2RlbC5Gb3IgdGhlIGRv dWJsZSBzaWRlZCBwcm92aXNpb25pbmcsIHRoZSBwYXRoIGNvbXB1dGF0aW9uIG9mIHRoZSANCmZv cndhcmQgYW5kIHRoZSBiYWNrd2FyZCBMU1ANCmFyZSBzdWJtaXR0ZWQgYnkgdGhlIGhlYWQtZW5k IGFuZCB0aGUgdGFpbC1lbmQgc2VwYXJhdGVseS5Gb3IgdGhlIHNpbmdsZSANCnNpZGVkIHByb3Zp c2lvbmluZywgdGhlIHBhdGggY29tcHV0YXRpb24gY2FuIGJlDQpyZWFsaXplZCBieSB0aGUgY29u Y3VycmVudCBvciBzdWNjZXNzaXZlIGNvbXB1dGF0aW9uLiAgVGhlIGNvbmN1cnJlbnQgDQpjb21w dXRhdGlvbiBtZWFucyB0aGF0IHRoZSBoZWFkLWVuZCBzdWJtaXRzIHRoZSBjb21wdXRhdGlvbiBy ZXF1ZXN0DQpmb3IgYm90aCB0d28gZGlyZWN0aW9uYWwgTFNQcyBjb25jdXJyZW50bHkuICBBcyB0 byB0aGUgc3VjY2Vzc2l2ZSANCmNvbXB1dGF0aW9uLCB0aGUgaGVhZC1lbmQgYW5kIHRoZSB0YWls LWVuZCBzZW5kIHRoZSBmb3J3YXJkIExTUCBhbmQNCmJhY2t3YXJkIExTUCBjb21wdXRhdGlvbiBy ZXF1ZXN0cyBzZXBhcmF0ZWx5Lg0KDQpXZSBoYXZlIGV4dGVuZGVkIFBDRVAgcHJvdG9jb2wgdG8g c3VwcG9ydCB0aGUgQ29uY3VycmVudCBjb21wdXRhdGlvbiBmb3IgDQpTaW5nbGUgU2lkZWQgUHJv dmlzaW9uaW5nIG1vZGVsLg0KQ29uY3VycmVudCBjb21wdXRhdGlvbiBjYW4gZW5zdXJlIHRoYXQg dGhlIHBhdGhzIGZvciB0aGUgYXNzb2NpYXRlZCANCmJpZGlyZWN0aW9uYWwgTFNQIGlzIG9wdGlt YWwsIGFzIGRlc2NyaWJlZCBpbiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU1NTcu DQpJbiB0aGlzIGRyYWZ0o6wgYW4gQS1iaXQgaXMgYWRkZWQgdG8gdGhlIGZsYWcgYml0cyBvZiB0 aGUgUlAgb2JqZWN0IHRvIA0KaW5kaWNhdGUgdGhlIHJlcXVlc3QgaXMgYWJvdXQgYW4gYXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsIExTUCBvciBub3QuDQpmdXRoZXJtb3Jlo6xSRVZFUlNFX0xTUCBv YmplY3QgaXMgYWRkZWQgaW4gYSBQQ1JlcSBtZXNzYWdlIHRvIHNwZWNpZnkgdGhlIA0KaW5mb3Jt YXRpb24gb2YgdGhlIHJldmVyc2UgTFNQoaMNCg0KDQpQbGVhc2UgcHJvdmlkZSBjb21tZW50cyBh bmQgZmVlZGJhY2suIA0KDQpUaGFua3MNCldlbmp1YW4NCg0K --=_alternative 003503CC48257933_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlJ3ZlIHN1Ym1pdHRlZCBhIGRyYWZ0IGZv ciB0aGUgZXh0ZW5zaW9ucw0Kb2YgUENFUCB0byBzdXBwb3J0IGFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCBsc3AsIGJlbG93IGlzIHRoZSBsaW5rOiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhlLXBjZS1w Y2VwLWFzc29jaWF0ZWQtbHNwLWV4dGVuc2lvbnMtMDAuDQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBNUExTLVRQIHJlcXVpcmVtZW50cyBbUkZD NTY1NF0gYW5kDQpjb250cm9sIHBsYW5lIGZyYW1ld29yayBkb2N1bWVudHNbUkZDNjM3M11kZXNj cmliZSB0aGF0IE1QTFMtVFAgTVVTVDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+c3VwcG9ydCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcG9pbnQtdG8tcG9pbnQN CkxTUHMuICZuYnNwO1BhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENFKSwgc2VlIFtSRkM0NjU1 XSwgbWF5IGJlIHVzZWQNCmZvciBwYXRoPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5jb21wdXRhdGlvbiBvZiBhIEdNUExTIExTUCxhbmQgY29uc2VxdWVudGx5DQph biBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLCBhY3Jvc3MgZG9tYWlucyBhbmQgaW4gYSBz aW5nbGUgZG9tYWluLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+QXMgZGVzY3JpYmVkIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTAyLDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCBMU1AgY2FuDQpiZSBkZXBsb3llZCBieSBTaW5nbGUgU2lkZWQgUHJvdmlzaW9uaW5nIG1v ZGVsIG9yIERvdWJsZSBTaWRlZCBQcm92aXNpb25pbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPm1vZGVsLkZvciB0aGUgZG91YmxlIHNpZGVkIHByb3Zpc2lvbmlu ZywNCnRoZSBwYXRoIGNvbXB1dGF0aW9uIG9mIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQg TFNQPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hcmUgc3VibWl0 dGVkIGJ5IHRoZSBoZWFkLWVuZCBhbmQgdGhlDQp0YWlsLWVuZCBzZXBhcmF0ZWx5LkZvciB0aGUg c2luZ2xlIHNpZGVkIHByb3Zpc2lvbmluZywgdGhlIHBhdGggY29tcHV0YXRpb24NCmNhbiBiZTwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cmVhbGl6ZWQgYnkgdGhl IGNvbmN1cnJlbnQgb3Igc3VjY2Vzc2l2ZQ0KY29tcHV0YXRpb24uICZuYnNwO1RoZSBjb25jdXJy ZW50IGNvbXB1dGF0aW9uIG1lYW5zIHRoYXQgdGhlIGhlYWQtZW5kIHN1Ym1pdHMNCnRoZSBjb21w dXRhdGlvbiByZXF1ZXN0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5mb3IgYm90aCB0d28gZGlyZWN0aW9uYWwgTFNQcyBjb25jdXJyZW50bHkuDQombmJzcDtBcyB0 byB0aGUgc3VjY2Vzc2l2ZSBjb21wdXRhdGlvbiwgdGhlIGhlYWQtZW5kIGFuZCB0aGUgdGFpbC1l bmQgc2VuZA0KdGhlIGZvcndhcmQgTFNQIGFuZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+YmFja3dhcmQgTFNQIGNvbXB1dGF0aW9uIHJlcXVlc3RzIHNlcGFyYXRl bHkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSBo YXZlIGV4dGVuZGVkIFBDRVAgcHJvdG9jb2wgdG8gc3VwcG9ydA0KdGhlIENvbmN1cnJlbnQgY29t cHV0YXRpb24gZm9yIFNpbmdsZSBTaWRlZCBQcm92aXNpb25pbmcgbW9kZWwuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Db25jdXJyZW50IGNvbXB1dGF0aW9uIGNh biBlbnN1cmUgdGhhdA0KdGhlIHBhdGhzIGZvciB0aGUgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IExTUCBpcyBvcHRpbWFsLCBhcyBkZXNjcmliZWQNCmluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzU1NTcuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5J biB0aGlzIGRyYWZ0o6wgYW4gQS1iaXQgaXMgYWRkZWQgdG8NCnRoZSBmbGFnIGJpdHMgb2YgdGhl IFJQIG9iamVjdCB0byBpbmRpY2F0ZSB0aGUgcmVxdWVzdCBpcyBhYm91dCBhbiBhc3NvY2lhdGVk DQpiaWRpcmVjdGlvbmFsIExTUCBvciBub3QuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5mdXRoZXJtb3Jlo6xSRVZFUlNFX0xTUCBvYmplY3QgaXMgYWRkZWQNCmlu IGEgUENSZXEgbWVzc2FnZSB0byBzcGVjaWZ5IHRoZSBpbmZvcm1hdGlvbiBvZiB0aGUgcmV2ZXJz ZSBMU1ChozwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+UGxlYXNlIHByb3ZpZGUgY29tbWVudHMgYW5kIGZlZWRiYWNrLg0KPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3M8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlbmp1YW48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 003503CC48257933_=-- From cyril.margaria@nsn.com Mon Oct 24 05:45:39 2011 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 D29F721F8D54 for ; Mon, 24 Oct 2011 05:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=0.766, 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 0XTCv+UffNpw for ; Mon, 24 Oct 2011 05:45:39 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id F28C821F8D50 for ; Mon, 24 Oct 2011 05:45:38 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9OCjY0B010580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Oct 2011 14:45:34 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9OCjNoV009670; Mon, 24 Oct 2011 14:45:33 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 14:45:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2011 14:45:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] questions on gmpls extensions Thread-Index: AcySSAGZ6Vq3dshcQVu+IDbatCJI3A== From: "Margaria, Cyril (NSN - DE/Munich)" To: X-OriginalArrivalTime: 24 Oct 2011 12:45:22.0159 (UTC) FILETIME=[CB381FF0:01CC924A] Cc: pce@ietf.org Subject: Re: [Pce] questions on gmpls extensions 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, 24 Oct 2011 12:45:39 -0000 > > Hi Folks, > Hi, =20 > I support completion of the GMPLS PCE extensions, but I did have a = couple of questions on the draft: >=20 > 1) How are the label set and suggested label objects used, given = that labels are local > significance? Are these used only for the egress interface? The label set and suggested label are used to restrict the label for a = given layer with end-to-end scope, the switching type and encoding are = provided to interpret correctly the labels and scope the layer (for = instance when combined with the inter-layer document where the path can = use several layers).=20 The switching type and encoding should in my opinion provide enough = information to decode the label. If you think this is not enough, = examples would be greatly appreciated. > > 2) Switching Type and LSP Encoding Type look like they could be = in two spots, in the SWITCH-LAYER=20 > object and in the ENDPOINTS object Label_Request TLV =96 did I = misread this? =20 > Or if this is correct, when would you use one vs. the other? In fact they could be in more than two spot, considering the inter-layer = extensions :-) In case of mono-layer request they should be consistent, but in case of = inter-layer requests the TE-LSP endpoint and layers considered might not = have the same switching capabilities. Having separate switching type and encoding for the endpoint is = explained in the document:=20 "The REQ-ADAP-CAP object from [I-D.ietf-pce-inter-layer-ext] can be used in case of mono-layer request, however in case of multilayer it is possible to have in the future more than one object, so it is better to have a dedicated TLV for the label and label request (the scope is then more clear).=20 " >=20 > I did not find this on the archives, my apologies if this has been = asked and answered before. I do not recall those to be asked. I hope the document and my answers = address fully your questions. Any other clarification/questions is appreciated.=20 Best regards,=20 Cyril > > Cheers, > >Lyndon From cyril.margaria@nsn.com Mon Oct 24 06:11:28 2011 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 461E121F8BEE for ; Mon, 24 Oct 2011 06:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.788 X-Spam-Level: X-Spam-Status: No, score=-5.788 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, J_CHICKENPOX_33=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 JTFTnk9AbsrY for ; Mon, 24 Oct 2011 06:11:27 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 435B621F8BEB for ; Mon, 24 Oct 2011 06:11:27 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9ODAhIY015985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Oct 2011 15:10:44 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9ODAgku005481; Mon, 24 Oct 2011 15:10:43 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 15:10:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2011 15:10:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-00 Thread-Index: AcySTJHfGMDDLCBaSZabd1OYwiS5Fg== From: "Margaria, Cyril (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 24 Oct 2011 13:10:33.0749 (UTC) FILETIME=[50327450:01CC924E] Subject: Re: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-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, 24 Oct 2011 13:11:28 -0000 > Hi all, Hi,=20 > We've submitted a draft for the extensions of PCEP to support=20 > associated bidirectional lsp, below is the link:=20 > = http://tools.ietf.org/html/draft-he-pce-pcep-associated-lsp-extensions-00= . > The MPLS-TP requirements [RFC5654] and control plane framework = documents=20 > [RFC6373]describe that MPLS-TP MUST support associated bidirectional=20 > point-to-point LSPs. Path Computation Element (PCE), see [RFC4655],=20 > may be used for path computation of a GMPLS LSP,and consequently an=20 > associated bidirectional LSP, across domains and in a single domain. > As described in http://tools.ietf.org/html/ > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02, the associated > bidirectional LSP can be deployed by Single Sided Provisioning model = or > Double Sided Provisioning model.For the double sided provisioning, the > path computation of the forward and the backward LSP are submitted by=20 > the head-end and the tail-end separately.For the single sided=20 > provisioning, the path computation can be realized by the concurrent = or=20 > successive computation. The concurrent computation means that the=20 > head-end submits the computation request for both two directional LSPs = > concurrently. As to the successive computation, the head-end and the=20 > tail-end send the forward LSP and backward LSP computation requests=20 > separately. > > We have extended PCEP protocol to support the Concurrent computation > for Single Sided Provisioning model. Concurrent computation can ensure > that the paths for the associated bidirectional LSP is optimal, as=20 > described in > http://tools.ietf.org/html/rfc5557. > In this draft, an A-bit is added to the flag bits of the RP object to > indicate the request is about an associated bidirectional LSP or not. > futhermore,REVERSE_LSP object is added in a PCReq message to specify = the > information of the reverse LSP. > > Please provide comments and feedback. Hi,=20 According to [RFC5654],=20 "Associated bidirectional path: A path that supports traffic flow in both directions but that is constructed from a pair of unidirectional paths (one for each direction) that are associated with one another at the path's ingress/egress points. The forward and backward directions are setup, monitored, and protected independently. As a consequence, they may or may not follow the same route (links and nodes) across the network." >From PCEP protocol point the Concurrent computation for Single Sided Provisioning model can be achieved with the following options:=20 - SVEC request containing one request for the forward direction and=20 one request for the reverse direction (forward and reverse path MAY be different)=20 - One bidirectional request using GENERALIZED-BANDWIDTH with forward=20 and reverse bandwidth if both direction must follow the same path=20 and have same other properties =20 This cover the requirements you are describing, I do not see the need = for PCEP extensions. One thing that could be considered (As far as I remember it was also = raised=20 for backup ingress and egress draft) is that the SVEC only allows to = compute diverse route but there is no indication that one desire sharing of = links, node (SRLGS?) for synchronized requests. BR=20 > > Thanks > Wenjuan=20 From jmedved@juniper.net Mon Oct 24 11:23:40 2011 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 DBA4511E80A6 for ; Mon, 24 Oct 2011 11:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 SUhjQPItmTa1 for ; Mon, 24 Oct 2011 11:23:39 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8675111E809D for ; Mon, 24 Oct 2011 11:23:39 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP; Mon, 24 Oct 2011 11:23:39 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 24 Oct 2011 11:21:26 -0700 From: Jan Medved To: "he.wenjuan1@zte.com.cn" , "pce@ietf.org" Date: Mon, 24 Oct 2011 11:21:23 -0700 Thread-Topic: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-00 Thread-Index: AcySeb2dapCntUVUQSG08epJvxdEDw== 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.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-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, 24 Oct 2011 18:23:41 -0000 Hi Wenjuan, Double Sided Provisioning (Section 3.2) will require LSP setup coordination= between the head-end and the tail-end, which will need to be provided eith= er by a management system or a stateful PCE proposed in draft-crabbe-pce-st= ateful-pce-00 (http://datatracker.ietf.org/doc/draft-crabbe-pce-stateful-pc= e/). Thanks, Jan On 10/24/11 2:36 AM, "he.wenjuan1@zte.com.cn= " > wrote: Hi all, We've submitted a draft for the extensions of PCEP to support associated bi= directional lsp, below is the link: http://tools.ietf.org/html/draft-he-pce-pcep-associated-lsp-extensions-00. The MPLS-TP requirements [RFC5654] and control plane framework documents[RF= C6373]describe that MPLS-TP MUST support associated bidirectional point-to-point LSPs. Path Computation Ele= ment (PCE), see [RFC4655], may be used for path computation of a GMPLS LSP,and consequently an associated bidirectional LSP= , across domains and in a single domain. As described in http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-= ext-associated-lsp-02, the associated bidirectional LSP can be deployed by Single Sided Provisioni= ng model or Double Sided Provisioning model.For the double sided provisioning, the path computation of the forwar= d and the backward LSP are submitted by the head-end and the tail-end separately.For the single si= ded provisioning, the path computationcan be realized by the concurrent or successive computation. The concurrent compu= tation means that the head-end submits the computation request for both two directional LSPs concurrently. As to the successive computati= on, the head-end and the tail-end send the forward LSP and backward LSP computation requests separately. We have extended PCEP protocol to support the Concurrent computation for Si= ngle Sided Provisioning model. Concurrent computation can ensure that the paths for the associated bidirec= tional LSP is optimal, as described in http://tools.ietf.org/html/rfc5557. In this draft=1B$B!$=1B(B an A-bit is added to the flag bits of the RP obje= ct to indicate the request is about an associated bidirectional LSP or not. futhermore=1B$B!$=1B(BREVERSE_LSP object is added in a PCReq message to spe= cify the information of the reverse LSP=1B$B!#=1B(B Please provide comments and feedback. Thanks Wenjuan From murai@fnsc.co.jp Mon Oct 24 22:24:57 2011 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 181F521F8C61 for ; Mon, 24 Oct 2011 22:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 aPUtRW7JM6K7 for ; Mon, 24 Oct 2011 22:24:56 -0700 (PDT) Received: from fnsc.co.jp (ms.fnsc.co.jp [211.127.153.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBC121F8C60 for ; Mon, 24 Oct 2011 22:24:55 -0700 (PDT) Received: from ([158.202.234.12]) by ms.fnsc.co.jp with ESMTP id 4D8TFN1.569211; Tue, 25 Oct 2011 14:24:32 +0900 Date: Tue, 25 Oct 2011 14:24:32 +0900 (JST) Message-Id: <20111025.142432.179479209.murai@fnsc.co.jp> To: dhruv.dhody@huawei.com In-Reply-To: <23CE718903A838468A8B325B80962F9B2639001D@SZXEML520-MBX.china.huawei.com> References: <23CE718903A838468A8B325B80962F9B2639001D@SZXEML520-MBX.china.huawei.com> From: Tomoki Murai X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: Re: [Pce] Query on draft-kumaki-murai-pce-pcep-extension-l3vpn-07 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, 25 Oct 2011 05:24:57 -0000 Hi Dhruv, Thank you for your comments. Please see inline. From: Dhruv Dhody Subject: Query on draft-kumaki-murai-pce-pcep-extension-l3vpn-07 Date: Thu, 20 Oct 2011 08:05:10 +0000 : > Dear Authors, > > > > I understand that in this document you want to focus only on - "Dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites" and not the complete PCE-VPN-EXT. > > > > I agree completely with the need for address translation and use of VPN-IPv4/v6 ENDPOINTS. > > > > Though you mention that the model will work when PCE function is not the PE router, it's not immediately understood how. Especially when identification of VPN is based on incoming interface? Yes, the identification of VPN at the edge PE is based on incoming interface. > If all PE routers must act as PCE, isn't it a drawback. Do you think this rule is acceptable? It is assumed in the draft that the BGP/MPLS IP-VPN ingress and egress PE routers have PCE capabilities. However we think it's possible to adapt the external PCE architectures. It will require further study. > We need to figure out how PCE can learn the VPN information or do PCE and VPN must always co-locate. Yes, we need to consider it. Regards, Tomoki > Also I find customer sites acting as a PCC, and connecting directly to Service Provider PCE not compatible with the PCE architecture. > > PCE-VPN-REQ documents talk about customer PCE cooperating with Service Provide PCE which fits better in the inter-domain path computation paradigm. > > > > Kindly provide your thoughts on this. > > > > Regards, > > Dhruv From he.wenjuan1@zte.com.cn Tue Oct 25 04:18:49 2011 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 30AFA21F8B02 for ; Tue, 25 Oct 2011 04:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.814 X-Spam-Level: X-Spam-Status: No, score=-95.814 tagged_above=-999 required=5 tests=[AWL=3.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, 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 tZw7BIGj6MSp for ; Tue, 25 Oct 2011 04:18:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id BCAD521F84F9 for ; Tue, 25 Oct 2011 04:18:47 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466211441414862; Tue, 25 Oct 2011 18:59:27 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 42838.3059275569; Tue, 25 Oct 2011 19:18:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9PBBa4U071064; Tue, 25 Oct 2011 19:11:36 +0800 (GMT-8) (envelope-from he.wenjuan1@zte.com.cn) In-Reply-To: To: cyril.margaria@nsn.com, pce@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: he.wenjuan1@zte.com.cn Date: Tue, 25 Oct 2011 19:11:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-25 19:11:38, Serialize complete at 2011-10-25 19:11:38 Content-Type: multipart/alternative; boundary="=_alternative 003DBD2948257934_=" X-MAIL: mse01.zte.com.cn p9PBBa4U071064 Subject: Re: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-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: Tue, 25 Oct 2011 11:18:49 -0000 This is a multipart message in MIME format. --=_alternative 003DBD2948257934_= Content-Type: text/plain; charset="US-ASCII" Hi cyril, Thanks for your comments, you catch the essence immediately. :-) For the first comment,-Yeah, the SVEC object can be used to synchronize the request about the forward and backward LSPs, and it is a more general method. As to the second comment, I also agree that GENERALIZED-BANDWIDTH with forward and reverse bandwidth and the "B" bit set in the RP object can be used since associated or co-routed is the same in the data plane. But consider the usecase that only the forward and backward's bandwidths is specified, and there is no need to limit them to be co-routed. I think another bit "A" defined in the RP ojbect will be useful, for the encoding efficiency will be higher than using the method based on the "SVEC" object. What do you think? The third comment, -If we want to support the sharing of links,node, SRLG for synchronized requests, this can be realized by two methods: a)the IRO object can be used to carry the same link or node, but the SRLG is not supported; b)extend one tlv to specify the sharing link,node or SRLG in the SVEC object. Just my two comments, do you think there are requirements or usecases about supporting the sharing SRLG? Your comments on this are most welcome. Thanks Wenjuan > Hi all, Hi, > We've submitted a draft for the extensions of PCEP to support > associated bidirectional lsp, below is the link: > http://tools.ietf.org/html/draft-he-pce-pcep-associated-lsp-extensions-00. > The MPLS-TP requirements [RFC5654] and control plane framework documents > [RFC6373]describe that MPLS-TP MUST support associated bidirectional > point-to-point LSPs. Path Computation Element (PCE), see [RFC4655], > may be used for path computation of a GMPLS LSP,and consequently an > associated bidirectional LSP, across domains and in a single domain. > As described in http://tools.ietf.org/html/ > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02, the associated > bidirectional LSP can be deployed by Single Sided Provisioning model or > Double Sided Provisioning model.For the double sided provisioning, the > path computation of the forward and the backward LSP are submitted by > the head-end and the tail-end separately.For the single sided > provisioning, the path computation can be realized by the concurrent or > successive computation. The concurrent computation means that the > head-end submits the computation request for both two directional LSPs > concurrently. As to the successive computation, the head-end and the > tail-end send the forward LSP and backward LSP computation requests > separately. > > We have extended PCEP protocol to support the Concurrent computation > for Single Sided Provisioning model. Concurrent computation can ensure > that the paths for the associated bidirectional LSP is optimal, as > described in > http://tools.ietf.org/html/rfc5557. > In this draft, an A-bit is added to the flag bits of the RP object to > indicate the request is about an associated bidirectional LSP or not. > futhermore,REVERSE_LSP object is added in a PCReq message to specify the > information of the reverse LSP. > > Please provide comments and feedback. Hi, According to [RFC5654], "Associated bidirectional path: A path that supports traffic flow in both directions but that is constructed from a pair of unidirectional paths (one for each direction) that are associated with one another at the path's ingress/egress points. The forward and backward directions are setup, monitored, and protected independently. As a consequence, they may or may not follow the same route (links and nodes) across the network." >From PCEP protocol point the Concurrent computation for Single Sided Provisioning model can be achieved with the following options: - SVEC request containing one request for the forward direction and one request for the reverse direction (forward and reverse path MAY be different) - One bidirectional request using GENERALIZED-BANDWIDTH with forward and reverse bandwidth if both direction must follow the same path and have same other properties This cover the requirements you are describing, I do not see the need for PCEP extensions. One thing that could be considered (As far as I remember it was also raised for backup ingress and egress draft) is that the SVEC only allows to compute diverse route but there is no indication that one desire sharing of links, node (SRLGS?) for synchronized requests. BR > > Thanks > Wenjuan --=_alternative 003DBD2948257934_= Content-Type: text/html; charset="US-ASCII"
Hi cyril,

Thanks for your comments, you catch the essence immediately. :-)

For the first comment,-Yeah, the SVEC object can be used to synchronize the request about the forward and backward LSPs, and it is a more general method.

As to the second comment, I also agree that GENERALIZED-BANDWIDTH with forward and reverse bandwidth and the "B" bit set in the RP object can be used since associated or co-routed is the same in the data plane.

But consider the usecase that only the forward and backward's bandwidths is specified, and there is no need to limit them to be co-routed. I think another bit "A" defined in the RP ojbect will be useful, for the encoding efficiency will be higher than using the method based on the "SVEC" object. What do you think?

The third comment,
-If we want to support the sharing of links,node, SRLG for synchronized requests, this can be realized by two methods:
  a)the IRO object can be used to carry the same link or node, but the SRLG is not supported;
  b)extend one tlv to specify the sharing link,node or SRLG in the SVEC object.
Just my two comments, do you think there are requirements or usecases about supporting the sharing SRLG?


Your comments on this are most welcome.

Thanks

Wenjuan





> Hi all,

Hi,

> We've submitted a draft for the extensions of PCEP to support
> associated bidirectional lsp, below is the link:
> http://tools.ietf.org/html/draft-he-pce-pcep-associated-lsp-extensions-00.
> The MPLS-TP requirements [RFC5654] and control plane framework documents
> [RFC6373]describe that MPLS-TP MUST support associated bidirectional
> point-to-point LSPs.  Path Computation Element (PCE), see [RFC4655],
> may be used for path computation of a GMPLS LSP,and consequently an
> associated bidirectional LSP, across domains and in a single domain.

> As described in http://tools.ietf.org/html/
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02, the associated
> bidirectional LSP can be deployed by Single Sided Provisioning model or
> Double Sided Provisioning model.For the double sided provisioning, the
> path computation of the forward and the backward LSP are submitted by
> the head-end and the tail-end separately.For the single sided
> provisioning, the path computation can be realized by the concurrent or
> successive computation. The concurrent computation means that the
> head-end submits the computation request for both two directional LSPs
> concurrently.  As to the successive computation, the head-end and the
> tail-end send the forward LSP and backward LSP computation requests
> separately.
>
> We have extended PCEP protocol to support the Concurrent computation
> for Single Sided Provisioning model. Concurrent computation can ensure
> that the paths for the associated bidirectional LSP is optimal, as
> described in > http://tools.ietf.org/html/rfc5557.
> In this draft, an A-bit is added to the flag bits of the RP object to
> indicate the request is about an associated bidirectional LSP or not.
> futhermore,REVERSE_LSP object is added in a PCReq message to specify the
> information of the reverse LSP.
>
> Please provide comments and feedback.
Hi,

According to [RFC5654],
"Associated bidirectional path: A path that supports traffic flow in
both directions but that is constructed from a pair of unidirectional
paths (one for each direction) that are associated with one another
at the path's ingress/egress points.  The forward and backward
directions are setup, monitored, and protected independently.  As a
consequence, they may or may not follow the same route (links and
nodes) across the network."

>From PCEP protocol point the Concurrent computation for Single Sided
Provisioning model can be achieved with the following options:
 - SVEC request containing one request for the forward direction and
   one request for the reverse direction (forward and reverse path MAY
   be different)
 - One bidirectional request using GENERALIZED-BANDWIDTH with forward
   and reverse bandwidth if both direction must follow the same path
   and have same other properties
   
This cover the requirements you are describing, I do not see the need for
PCEP extensions.

One thing that could be considered (As far as I remember it was also raised
for backup ingress and egress draft) is that the SVEC only allows to compute
diverse route but there is no indication that one desire sharing of links,
node (SRLGS?) for synchronized requests.

BR

>
> Thanks
> Wenjuan


--=_alternative 003DBD2948257934_=-- From igor@yahoo-inc.com Tue Oct 25 11:59:00 2011 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 E57A81F0C3F for ; Tue, 25 Oct 2011 11:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 BHn+mSbibmpa for ; Tue, 25 Oct 2011 11:59:00 -0700 (PDT) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id 06CE81F0C3B for ; Tue, 25 Oct 2011 11:58:59 -0700 (PDT) Received: from netops1.corp.bf1.yahoo.com (netops1.corp.bf1.yahoo.com [98.139.254.110]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p9PIwiDb062294; Tue, 25 Oct 2011 11:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1319569125; bh=wk3CNONPs1PGuuqL8U0rDnaW8eK0xJm1Mo1hz+50Qwc=; h=Date:From:To:cc:Subject:Message-ID:MIME-Version:Content-Type; b=c3urz1LTpUA+fSf+SjjzzhBnfbi14LYlJlQQ13xZf63jbFxuou3wmc1aPv4S1k8qz 3K4+l9RwBaLRjbF2Q8J3BIlxTxhEe5bUqEfeYkGFPx27PGMTZAX5nN2N3/3+lW3udJ 7sclFBSObWEJ1ZiWJngK0vZMzRF6WmZwKuo16cYQ= Date: Tue, 25 Oct 2011 11:58:44 -0700 (PDT) From: Igor Gashinsky X-X-Sender: igor@netops1.corp.bf1.yahoo.com To: pce@ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-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, 25 Oct 2011 18:59:01 -0000 On Sun, 14 Oct 2011, Edward Crabbe wrote: :: Hello; :: :: We've submitted a draft for the group's consideration. We know that :: stateful PCE has been discussed by the working group in the past. We :: believe that we have addressed some of the issues that have been raised :: in previous discussions and have specific use cases that make stateful :: PCE valuable. We hope you'll find the time to look through the draft :: and comment on the list before the WG meeting in Taipei, and hope that :: we'll be able to have a fruitful and lively discussion there. I didn't see much discussion on the list about benefits of what this draft woudl allow, so just wanted to drop a quick note to say that I think this is really great work, and we should absolutely pursue it. Thanks! -igor From robert@raszuk.net Tue Oct 25 14:28:46 2011 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 E6D7611E807F for ; Tue, 25 Oct 2011 14:28: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 5He-fAjz8p+n for ; Tue, 25 Oct 2011 14:28:45 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 3957411E8081 for ; Tue, 25 Oct 2011 14:28:45 -0700 (PDT) Received: (qmail 20128 invoked by uid 399); 25 Oct 2011 21:28:44 -0000 Received: from unknown (HELO ?10.58.3.65?) (65.91.55.103) by mail37.opentransfer.com with SMTP; 25 Oct 2011 21:28:44 -0000 Message-ID: <4EA72A0C.2000700@raszuk.net> Date: Tue, 25 Oct 2011 23:28:44 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: pce@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Pce] Comments on draft-crabbe-pce-stateful-pce-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 21:28:46 -0000 Dear Authors, I went through yr draft and have few comments ... * In introduction you say that PCE to PCE is out of scope while at the bottom of section 2 you say that PCE to PCE should be done as if requesting PCE is PCC. A bit confusing. * Also stating that PCE to PCE is out of scope you sort of cross PCE to PCE synchronization for redundancy. I understand that in the spirit of the draft it would have to go via PCC attached to 2 or more PCEs. * 3.1.2 typo .. double "which" * 3.1.2.3 .. I am not sure what are you showing in table 6. Demand 20 seems not achievable no matter what. Please clarify. * In some TE scenarios it is useful to bind the incoming port on the headend to the TE-LSP from such headend. Maybe extending PCRpt message with such field could be not a bad idea ? * Why do you enforce to signal the RRO ? Maybe things changed but I was under assumption that RRO is optional. At least most of the original TE deployments never used RRO. For explicitly configured LSPs ERO is sufficient. Is this that this document mandates the RRO to be enabled on each LSP which you delegate control to PCE ? Otherwise you would not know about the path cspf have chosen ? If so I think this RRO mandate needs to be a bit more explicitly discussed. * Section 6.2 talks about PCE to PCC overload case (PCUpd rate exceeded). Cool. How about the reverse ? Best regards, R. From edc@google.com Tue Oct 25 18:03:40 2011 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 958C121F86EE for ; Tue, 25 Oct 2011 18:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 cfu2xA7WGUWn for ; Tue, 25 Oct 2011 18:03:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id BC2AE21F86EC for ; Tue, 25 Oct 2011 18:03:39 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p9Q13cxf015328 for ; Tue, 25 Oct 2011 18:03:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319591019; bh=zGDBrCSkLQis3ncgGXTKeu+iFO8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=E12kTsuGNgXK1RHnKWkEyCBVI6GBNgFvlAM8HD991+UGpFmpQ4XSWvD0Upbx/PpBt rRXCZ7JZzUvxLKyRLKELA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=JHBxcf9dm9d6LlEsmC85OnHuEw9qeM3jWu2eNbAaiy/37HYNA3qQfzhVdmm1h4Lyw gHj7p4rSqH2FH5mloYkrQ== Received: from qabg14 (qabg14.prod.google.com [10.224.20.206]) by hpaq1.eem.corp.google.com with ESMTP id p9Q13aJk014489 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 25 Oct 2011 18:03:37 -0700 Received: by qabg14 with SMTP id g14so2306500qab.3 for ; Tue, 25 Oct 2011 18:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wjVQuTOFJjhLHD4ahv8gaO/KiR9BWSInc8kSi9h8jDc=; b=jq+x+GRD4m9juaxxO8XIFYxMn9/7VXRYff/1ZQt8OnmkF2t5AjHSiSqTLvBhBhM6U3 kqJm7BLsRKEJmUO55DVw== Received: by 10.151.158.1 with SMTP id k1mr20634732ybo.66.1319591016379; Tue, 25 Oct 2011 18:03:36 -0700 (PDT) Received: by 10.151.158.1 with SMTP id k1mr20634716ybo.66.1319591016099; Tue, 25 Oct 2011 18:03:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.14.17 with HTTP; Tue, 25 Oct 2011 18:03:16 -0700 (PDT) In-Reply-To: <4EA72A0C.2000700@raszuk.net> References: <4EA72A0C.2000700@raszuk.net> From: Edward Crabbe Date: Tue, 25 Oct 2011 18:03:16 -0700 Message-ID: To: robert@raszuk.net Content-Type: multipart/alternative; boundary=0015174ff5f4c3706204b0293920 X-System-Of-Record: true Cc: pce@ietf.org Subject: Re: [Pce] Comments on draft-crabbe-pce-stateful-pce-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: Wed, 26 Oct 2011 01:03:40 -0000 --0015174ff5f4c3706204b0293920 Content-Type: text/plain; charset=ISO-8859-1 > > Robert; > Hey there. :) Comments in-line. * In introduction you say that PCE to PCE is out of scope while at the > bottom of section 2 you say that PCE to PCE should be done as if requesting > PCE is PCC. A bit confusing. > > Yes this is a typo. The text in section 2 is correct: PCE to PCE communication is in scope. > * Also stating that PCE to PCE is out of scope you sort of cross PCE to PCE > synchronization for redundancy. I understand that in the spirit of the draft > it would have to go via PCC attached to 2 or more PCEs. > > PCE-PCE is in scope. I'm actually not sure it *can* be out of scope given the comments in > * 3.1.2 typo .. double "which" > yep :P > > * 3.1.2.3 .. I am not sure what are you showing in table 6. Demand 20 seems > not achievable no matter what. Please clarify. > hrm. Current text is: Lack of ingress admission control coupled with the behavior in [RFC3209] effectively results in mis-signaled LSPs during periods of contention for network capacity between LSPs in a given LSP priority. This in turn causes information loss in the TED with regard to actual network state, resulting in LSPs sharing common network interfaces with mis-signaled LSPs operating in a degraded state for significant periods of time, even when unused network capacity may potentially be available. The intent here is simply to point out that , due to RSVP-TE protocol behavior and decoupling of data and control planes in resource reservation, in periods of contention for network resources well behaved flows may be harmed by poorly behaved flows for extended periods even if there is sufficient capacity to route the well behaved flows elsewhere in the network. I guess the text here isn't clear enough. I'll work on it :P > > * In some TE scenarios it is useful to bind the incoming port on the > headend to the TE-LSP from such headend. Maybe extending PCRpt message with > such field could be not a bad idea ? > This is essentially the beginnings of a FEC advertisement discussion. Out of scope for the current draft, but certainly an interesting use case for discussion. > > * Why do you enforce to signal the RRO ? Maybe things changed but I was > under assumption that RRO is optional. At least most of the original TE > deployments never used RRO. For explicitly configured LSPs ERO is > sufficient. Is this that this document mandates the RRO to be enabled on > each LSP which you delegate control to PCE ? Otherwise you would not know > about the path cspf have chosen ? If so I think this RRO mandate needs to be > a bit more explicitly discussed. > > This is primarily a naming artifact from 5440 section 7.10 > * Section 6.2 talks about PCE to PCC overload case (PCUpd rate exceeded). > Cool. How about the reverse ? > > Good point - we'll add it. regards, -ed --0015174ff5f4c3706204b0293920 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Robert;

Hey there. :) =A0Comments in-line. =A0
=A0

* In introduction you say that PCE to PCE is out of scope while at the bott= om of section 2 you say that PCE to PCE should be done as if requesting PCE= is PCC. A bit confusing.


Yes this is a typo. =A0The text in sec= tion 2 is correct: =A0PCE to PCE communication is in scope. =A0
= =A0
* Also stating that PCE to PCE is out of scope you sort of cross PCE to PCE= synchronization for redundancy. I understand that in the spirit of the dra= ft it would have to go via PCC attached to 2 or more PCEs.


PCE-PCE is in scope. =A0I'm actual= ly not sure it *can* be out of scope given the comments in=A0
=A0=
* 3.1.2 typo .. double "which"

yep :P
=A0

* 3.1.2.3 .. I am not sure what are you showing in table 6. Demand 20 seems= not achievable no matter what. Please clarify.

hrm. =A0Current text is:


 Lack of ingress admission control coupled with the behavior in
   [RFC3209] effectively results in mis-signaled LSPs during periods of
   contention for network capacity between LSPs in a given LSP priority.
   This in turn causes information loss in the TED with regard to actual
   network state, resulting in LSPs sharing common network interfaces
   with mis-signaled LSPs operating in a degraded state for significant
   periods of time, even when unused network capacity may potentially be
   available.

The intent here is simp= ly to point out that , due to RSVP-TE protocol behavior and decoupling of d= ata and control planes in resource reservation,=A0in periods of contention = for network resources=A0well behaved flows may be harmed by poorly behaved = flows for extended periods even if there is sufficient capacity to route th= e well behaved flows elsewhere in the network. =A0I guess the text here isn= 't clear enough. =A0I'll work on it :P
=A0

* In some TE scenarios it is useful to bind the incoming port on the headen= d to the TE-LSP from such headend. Maybe extending PCRpt message with such = field could be not a bad idea ?

This is= essentially the beginnings of a FEC advertisement discussion. =A0Out of sc= ope for the current draft, but certainly an interesting use case for discus= sion. =A0
=A0

* Why do you enforce to signal the RRO ? Maybe things changed but I was und= er assumption that RRO is optional. At least most of the original TE deploy= ments never used RRO. For explicitly configured LSPs ERO is sufficient. Is = this that this document mandates the RRO to be enabled on each LSP which yo= u delegate control to PCE ? Otherwise you would not know about the path csp= f have chosen ? If so I think this RRO mandate needs to be a bit more expli= citly discussed.


This is primarily a naming artifact fr= om 5440 section 7.10
=A0
* Section 6.2 talks about PCE to PCC overload case (PCUpd rate exceeded). C= ool. How about the reverse ?

Good point - we'l= l add it. =A0
=A0


regards= ,

=A0 -ed=A0
--0015174ff5f4c3706204b0293920-- From he.wenjuan1@zte.com.cn Tue Oct 25 18:56:55 2011 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 BAD7221F8A57 for ; Tue, 25 Oct 2011 18:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.424 X-Spam-Level: X-Spam-Status: No, score=-96.424 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 wAdbKb6TI3Te for ; Tue, 25 Oct 2011 18:56:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 623ED21F8A56 for ; Tue, 25 Oct 2011 18:56:54 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 466211441414862; Wed, 26 Oct 2011 09:49:06 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 20387.2005898773; Wed, 26 Oct 2011 09:56:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9Q1uSoZ063454; Wed, 26 Oct 2011 09:56:29 +0800 (GMT-8) (envelope-from he.wenjuan1@zte.com.cn) In-Reply-To: To: Jan Medved , "pce@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: he.wenjuan1@zte.com.cn Date: Wed, 26 Oct 2011 09:56:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-26 09:56:30, Serialize complete at 2011-10-26 09:56:30 Content-Type: multipart/alternative; boundary="=_alternative 000AEA8C48257935_=" X-MAIL: mse01.zte.com.cn p9Q1uSoZ063454 Subject: Re: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-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, 26 Oct 2011 01:56:55 -0000 This is a multipart message in MIME format. --=_alternative 000AEA8C48257935_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSmFuLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cywgSSB0aGluayBpdCBpcyByZWFsbHkg dmFsdWFibGUuDQoNCkZvciB0aGUgRG91YmxlIFNpZGVkIFByb3Zpc2lvbmluZyBtb2RlbCwgYWx0 aG91Z2ggdGhlIGhlYWQtZW5kIGFuZCB0aGUgDQp0YWlsLWVuZCBvciBOTVMgc3VibWl0IHRoZSBQ Q1JlcSBtZXNzYWdlIHNlcGFyYXRlbHksIHRoZSB0d28gcmV2ZXJzZSBsc3BzIA0KY2FuIGJlIGFz c29jaWF0ZWQgDQp0byBiZSBvcHRpbWFsIGlmIHN0YXRlZnVsIFBDRSBpcyB1c2VkLiANCg0KVGhl IGRyYWZ0ICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNyYWJiZS1wY2Ut c3RhdGVmdWwtcGNlLyANCmp1c3Qgc2F5IHRoYXQgYWxsIG90aGVyIExTUCdzIGNvbmRpdGlvbiBj YW4gYmUgY29uc2lkZXJlZCBpZiBhIG5ldyByZXF1ZXN0IA0KaXMgc3VibWl0dGVkLCBob3dldmVy LCB3ZSB3YW50IHRvIGNvbnNpZGVyIHRoZSB0d28gcmVsYXRlZCBMU1BzIHRvZ2V0aGVyIA0KKGVz cGVjaWFsbHkgdGhlIFRFIHBhcmFtZXRlcnMpLCBhdCB0aGUgc2FtZSB0aW1lIGFsbCB0aGUgb3Ro ZXIgTFNQJ3MgDQpjb25kaXRpb24gc2hvdWxkIGJlIHRha2VuIGludG8gY29uc2lkZXJhdGlvbi4N Cg0KSG93IGFib3V0IGludHJvZHVjaW5nIHRoZSBBc3NvY2lhdGlvbiBPYmplY3QgaW4gdGhpcyBz Y2VuYXJpbz8gV2hlbiB0aGUgDQpQQ0Mgc3VibWl0cyB0aGUgcGF0aCBjb21wdXRhdGlvbiByZXF1 ZXN0IGZvciB0aGUgZm9yd2FyZCBsc3Agb3IgdGhlIA0KYmFja3dhcmQgbHNwLCB0aGUgUENSZXEg bWVzc2FnZSBtYXkgY2FycnkgYXNzb2NpYXRpb24gb2JqZWN0IHRvIGluZGljYXRlIA0KdGhhdCBh IHJldmVyc2UgbHNwIGlzIG5lZWRlZCB0byBiZSBwcm92aWRlZCBsYXRlci4gV2hlbiB0aGUgc2Vj b25kIHJlcXVlc3QgDQp3aXRoIHRoZSBzYW1lIEFzc29pY2F0aW9uIE9iamVjdCBhcnJpdmVzLA0K dGhlIHN0YXRlZnVsIFBDRSBjYW4gY29tcHV0ZSB0aGUgdHdvIHJldmVyc2UgbHNwcyBhZ2Fpbiwg YW5kIGdldCB0aGUgDQpvcHRpbWFsIHBhdGggZm9yIHRoZSBhc3NvY2lhdGVkIGJpLWRpcmVjdGlv bmFsIGxzcC4gQWZ0ZXIgdGhlIHN1Y2Nlc3NmdWwgDQpjb21wdXRhdGlvbiwgdGhlIFBDRSByZXNw b25zZXMgdGhlIFBDQyB3aXRoIHRoZSBQQ1JlcCBtZXNzYWdlIGFuZCB1cGRhdGVzIA0KdGhlIHJl dmVyc2UgbHNwIHdpdGggUENVcGQgTWVzc2FnZS4gDQoNCllvdXIgY29tbWVudHMgb24gdGhpcyBh cmUgbW9zdCB3ZWxjb21lLg0KDQpUaGFua3MNCg0KV2VuanVhbg0KDQoNCg0KDQoNCkphbiBNZWR2 ZWQgPGptZWR2ZWRAanVuaXBlci5uZXQ+IA0KMjAxMS0xMC0yNSAwMjoyMQ0KDQrK1bz+yMsNCiJo ZS53ZW5qdWFuMUB6dGUuY29tLmNuIiA8aGUud2VuanVhbjFAenRlLmNvbS5jbj4sICJwY2VAaWV0 Zi5vcmciIA0KPHBjZUBpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KUmU6IFtQY2VdIFtQQ0VdIFJl cXVlc3QgY29tbWVudHMgb24gDQpkcmFmdC1oZS1wY2UtcGNlcC1hc3NvY2lhdGVkLWxzcC1leHRl bnNpb25zLTAwDQoNCg0KDQoNCg0KDQpIaSBXZW5qdWFuLA0KDQpEb3VibGUgU2lkZWQgUHJvdmlz aW9uaW5nIChTZWN0aW9uIDMuMikgd2lsbCByZXF1aXJlIExTUCBzZXR1cCANCmNvb3JkaW5hdGlv biBiZXR3ZWVuIHRoZSBoZWFkLWVuZCBhbmQgdGhlIHRhaWwtZW5kLCB3aGljaCB3aWxsIG5lZWQg dG8gYmUgDQpwcm92aWRlZCBlaXRoZXIgYnkgYSBtYW5hZ2VtZW50IHN5c3RlbSBvciBhIHN0YXRl ZnVsIFBDRSBwcm9wb3NlZCBpbiANCmRyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLTAwICgN Cmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY3JhYmJlLXBjZS1zdGF0ZWZ1 bC1wY2UvKS4NCg0KDQoNClRoYW5rcywNCkphbg0KDQoNCk9uIDEwLzI0LzExIDI6MzYgQU0sICJo ZS53ZW5qdWFuMUB6dGUuY29tLmNuPG1haWx0bzpoZS53ZW5qdWFuMUB6dGUuY29tLmNuDQo+IiA8 aGUud2VuanVhbjFAenRlLmNvbS5jbjxtYWlsdG86aGUud2VuanVhbjFAenRlLmNvbS5jbj4+IHdy b3RlOg0KDQoNCkhpIGFsbCwNCldlJ3ZlIHN1Ym1pdHRlZCBhIGRyYWZ0IGZvciB0aGUgZXh0ZW5z aW9ucyBvZiBQQ0VQIHRvIHN1cHBvcnQgYXNzb2NpYXRlZCANCmJpZGlyZWN0aW9uYWwgbHNwLCBi ZWxvdyBpcyB0aGUgbGluazoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhlLXBj ZS1wY2VwLWFzc29jaWF0ZWQtbHNwLWV4dGVuc2lvbnMtMDAuDQoNClRoZSBNUExTLVRQIHJlcXVp cmVtZW50cyBbUkZDNTY1NF0gYW5kIGNvbnRyb2wgcGxhbmUgZnJhbWV3b3JrIA0KZG9jdW1lbnRz W1JGQzYzNzNdZGVzY3JpYmUgdGhhdCBNUExTLVRQIE1VU1QNCnN1cHBvcnQgYXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsIHBvaW50LXRvLXBvaW50IExTUHMuICBQYXRoIENvbXB1dGF0aW9uIA0KRWxl bWVudCAoUENFKSwgc2VlIFtSRkM0NjU1XSwgbWF5IGJlIHVzZWQgZm9yIHBhdGgNCmNvbXB1dGF0 aW9uIG9mIGEgR01QTFMgTFNQLGFuZCBjb25zZXF1ZW50bHkgYW4gYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIA0KTFNQLCBhY3Jvc3MgZG9tYWlucyBhbmQgaW4gYSBzaW5nbGUgZG9tYWluLg0KDQpB cyBkZXNjcmliZWQgaW4gDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNj YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMg0KLA0KdGhlIGFzc29jaWF0 ZWQgYmlkaXJlY3Rpb25hbCBMU1AgY2FuIGJlIGRlcGxveWVkIGJ5IFNpbmdsZSBTaWRlZCANClBy b3Zpc2lvbmluZyBtb2RlbCBvciBEb3VibGUgU2lkZWQgUHJvdmlzaW9uaW5nDQptb2RlbC5Gb3Ig dGhlIGRvdWJsZSBzaWRlZCBwcm92aXNpb25pbmcsIHRoZSBwYXRoIGNvbXB1dGF0aW9uIG9mIHRo ZSANCmZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZCBMU1ANCmFyZSBzdWJtaXR0ZWQgYnkgdGhlIGhl YWQtZW5kIGFuZCB0aGUgdGFpbC1lbmQgc2VwYXJhdGVseS5Gb3IgdGhlIHNpbmdsZSANCnNpZGVk IHByb3Zpc2lvbmluZywgdGhlIHBhdGggY29tcHV0YXRpb25jYW4gYmUNCnJlYWxpemVkIGJ5IHRo ZSBjb25jdXJyZW50IG9yIHN1Y2Nlc3NpdmUgY29tcHV0YXRpb24uICBUaGUgY29uY3VycmVudCAN CmNvbXB1dGF0aW9uIG1lYW5zIHRoYXQgdGhlIGhlYWQtZW5kIHN1Ym1pdHMgdGhlIGNvbXB1dGF0 aW9uIHJlcXVlc3QNCmZvciBib3RoIHR3byBkaXJlY3Rpb25hbCBMU1BzIGNvbmN1cnJlbnRseS4g IEFzIHRvIHRoZSBzdWNjZXNzaXZlIA0KY29tcHV0YXRpb24sIHRoZSBoZWFkLWVuZCBhbmQgdGhl IHRhaWwtZW5kIHNlbmQgdGhlIGZvcndhcmQgTFNQIGFuZA0KYmFja3dhcmQgTFNQIGNvbXB1dGF0 aW9uIHJlcXVlc3RzIHNlcGFyYXRlbHkuDQoNCldlIGhhdmUgZXh0ZW5kZWQgUENFUCBwcm90b2Nv bCB0byBzdXBwb3J0IHRoZSBDb25jdXJyZW50IGNvbXB1dGF0aW9uIGZvciANClNpbmdsZSBTaWRl ZCBQcm92aXNpb25pbmcgbW9kZWwuDQpDb25jdXJyZW50IGNvbXB1dGF0aW9uIGNhbiBlbnN1cmUg dGhhdCB0aGUgcGF0aHMgZm9yIHRoZSBhc3NvY2lhdGVkIA0KYmlkaXJlY3Rpb25hbCBMU1AgaXMg b3B0aW1hbCwgYXMgZGVzY3JpYmVkIGluIA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTU1Ny4NCkluIHRoaXMgZHJhZnSjrCBhbiBBLWJpdCBpcyBhZGRlZCB0byB0aGUgZmxhZyBiaXRz IG9mIHRoZSBSUCBvYmplY3QgdG8gDQppbmRpY2F0ZSB0aGUgcmVxdWVzdCBpcyBhYm91dCBhbiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIG9yIG5vdC4NCmZ1dGhlcm1vcmWjrFJFVkVSU0Vf TFNQIG9iamVjdCBpcyBhZGRlZCBpbiBhIFBDUmVxIG1lc3NhZ2UgdG8gc3BlY2lmeSB0aGUgDQpp bmZvcm1hdGlvbiBvZiB0aGUgcmV2ZXJzZSBMU1Chow0KDQoNClBsZWFzZSBwcm92aWRlIGNvbW1l bnRzIGFuZCBmZWVkYmFjay4NCg0KVGhhbmtzDQpXZW5qdWFuDQoNCg0KDQo= --=_alternative 000AEA8C48257935_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEphbiw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgdGhlIGNvbW1l bnRzLCBJIHRoaW5rIGl0DQppcyByZWFsbHkgdmFsdWFibGUuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Gb3IgdGhlIERvdWJsZSBTaWRlZCBQcm92aXNp b25pbmcgbW9kZWwsDQphbHRob3VnaCB0aGUgaGVhZC1lbmQgYW5kIHRoZSB0YWlsLWVuZCBvciBO TVMgc3VibWl0IHRoZSBQQ1JlcSBtZXNzYWdlDQpzZXBhcmF0ZWx5LCB0aGUgdHdvIHJldmVyc2Ug bHNwcyBjYW4gYmUgYXNzb2NpYXRlZCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPnRvIGJlIG9wdGltYWwgaWYgc3RhdGVmdWwgUENFIGlzIHVzZWQuDQo8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBkcmFmdCAmbmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLzwvdHQ+PC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4NCmp1c3Qgc2F5IHRoYXQgYWxsIG90aGVyIExTUCdzIGNvbmRpdGlv biBjYW4gYmUgY29uc2lkZXJlZCBpZiBhIG5ldyByZXF1ZXN0DQppcyBzdWJtaXR0ZWQsIGhvd2V2 ZXIsIHdlIHdhbnQgdG8gY29uc2lkZXIgdGhlIHR3byByZWxhdGVkIExTUHMgdG9nZXRoZXINCihl c3BlY2lhbGx5IHRoZSBURSBwYXJhbWV0ZXJzKSwgYXQgdGhlIHNhbWUgdGltZSBhbGwgdGhlIG90 aGVyIExTUCdzIGNvbmRpdGlvbg0Kc2hvdWxkIGJlIHRha2VuIGludG8gY29uc2lkZXJhdGlvbi48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhvdyBhYm91 dCBpbnRyb2R1Y2luZyB0aGUgQXNzb2NpYXRpb24NCk9iamVjdCBpbiB0aGlzIHNjZW5hcmlvPyBX aGVuIHRoZSBQQ0Mgc3VibWl0cyB0aGUgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0DQpmb3IgdGhl IGZvcndhcmQgbHNwIG9yIHRoZSBiYWNrd2FyZCBsc3AsIHRoZSBQQ1JlcSBtZXNzYWdlIG1heSBj YXJyeSBhc3NvY2lhdGlvbg0Kb2JqZWN0IHRvIGluZGljYXRlIHRoYXQgYSByZXZlcnNlIGxzcCBp cyBuZWVkZWQgdG8gYmUgcHJvdmlkZWQgbGF0ZXIuIFdoZW4NCnRoZSBzZWNvbmQgcmVxdWVzdCB3 aXRoIHRoZSBzYW1lIEFzc29pY2F0aW9uIE9iamVjdCBhcnJpdmVzLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIHN0YXRlZnVsIFBDRSBjYW4gY29tcHV0ZSB0 aGUgdHdvDQpyZXZlcnNlIGxzcHMgYWdhaW4sIGFuZCBnZXQgdGhlIG9wdGltYWwgcGF0aCBmb3Ig dGhlIGFzc29jaWF0ZWQgYmktZGlyZWN0aW9uYWwNCmxzcC4gQWZ0ZXIgdGhlIHN1Y2Nlc3NmdWwg Y29tcHV0YXRpb24sIHRoZSBQQ0UgcmVzcG9uc2VzIHRoZSBQQ0Mgd2l0aCB0aGUNClBDUmVwIG1l c3NhZ2UgYW5kIHVwZGF0ZXMgdGhlIHJldmVyc2UgbHNwIHdpdGggUENVcGQgTWVzc2FnZS4gPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Zb3VyIGNvbW1l bnRzIG9uIHRoaXMgYXJlIG1vc3Qgd2VsY29tZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+V2VuanVhbjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MjclPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5KYW4gTWVkdmVkICZsdDtqbWVk dmVkQGp1bmlwZXIubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4yMDExLTEwLTI1IDAyOjIxPC9mb250Pg0KPHRkIHdpZHRoPTcyJT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O2hlLndlbmp1YW4xQHp0ZS5jb20uY24m cXVvdDsgJmx0O2hlLndlbmp1YW4xQHp0ZS5jb20uY24mZ3Q7LA0KJnF1b3Q7cGNlQGlldGYub3Jn JnF1b3Q7ICZsdDtwY2VAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW1BjZV0gW1BDRV0gUmVxdWVzdCBjb21t ZW50cyBvbg0KZHJhZnQtaGUtcGNlLXBjZXAtYXNzb2NpYXRlZC1sc3AtZXh0ZW5zaW9ucy0wMDwv Zm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+ SGkgV2VuanVhbiw8YnI+DQo8YnI+DQpEb3VibGUgU2lkZWQgUHJvdmlzaW9uaW5nIChTZWN0aW9u IDMuMikgd2lsbCByZXF1aXJlIExTUCBzZXR1cCBjb29yZGluYXRpb24NCmJldHdlZW4gdGhlIGhl YWQtZW5kIGFuZCB0aGUgdGFpbC1lbmQsIHdoaWNoIHdpbGwgbmVlZCB0byBiZSBwcm92aWRlZCBl aXRoZXINCmJ5IGEgbWFuYWdlbWVudCBzeXN0ZW0gb3IgYSBzdGF0ZWZ1bCBQQ0UgcHJvcG9zZWQg aW4gZHJhZnQtY3JhYmJlLXBjZS1zdGF0ZWZ1bC1wY2UtMDANCihodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLykuPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkphbjxicj4NCjxicj4NCjxicj4NCk9uIDEwLzI0LzEx IDI6MzYgQU0sICZxdW90O2hlLndlbmp1YW4xQHp0ZS5jb20uY24mbHQ7bWFpbHRvOmhlLndlbmp1 YW4xQHp0ZS5jb20uY24mZ3Q7JnF1b3Q7DQombHQ7aGUud2VuanVhbjFAenRlLmNvbS5jbiZsdDtt YWlsdG86aGUud2VuanVhbjFAenRlLmNvbS5jbiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjxi cj4NCkhpIGFsbCw8YnI+DQpXZSd2ZSBzdWJtaXR0ZWQgYSBkcmFmdCBmb3IgdGhlIGV4dGVuc2lv bnMgb2YgUENFUCB0byBzdXBwb3J0IGFzc29jaWF0ZWQNCmJpZGlyZWN0aW9uYWwgbHNwLCBiZWxv dyBpcyB0aGUgbGluazo8YnI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oZS1w Y2UtcGNlcC1hc3NvY2lhdGVkLWxzcC1leHRlbnNpb25zLTAwLjxicj4NCjxicj4NClRoZSBNUExT LVRQIHJlcXVpcmVtZW50cyBbUkZDNTY1NF0gYW5kIGNvbnRyb2wgcGxhbmUgZnJhbWV3b3JrIGRv Y3VtZW50c1tSRkM2MzczXWRlc2NyaWJlDQp0aGF0IE1QTFMtVFAgTVVTVDxicj4NCnN1cHBvcnQg YXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBvaW50LXRvLXBvaW50IExTUHMuICZuYnNwO1BhdGgg Q29tcHV0YXRpb24NCkVsZW1lbnQgKFBDRSksIHNlZSBbUkZDNDY1NV0sIG1heSBiZSB1c2VkIGZv ciBwYXRoPGJyPg0KY29tcHV0YXRpb24gb2YgYSBHTVBMUyBMU1AsYW5kIGNvbnNlcXVlbnRseSBh biBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCkxTUCwgYWNyb3NzIGRvbWFpbnMgYW5kIGluIGEg c2luZ2xlIGRvbWFpbi48YnI+DQo8YnI+DQpBcyBkZXNjcmliZWQgaW4gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRl ZC1sc3AtMDIsPGJyPg0KdGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgY2FuIGJlIGRl cGxveWVkIGJ5IFNpbmdsZSBTaWRlZCBQcm92aXNpb25pbmcNCm1vZGVsIG9yIERvdWJsZSBTaWRl ZCBQcm92aXNpb25pbmc8YnI+DQptb2RlbC5Gb3IgdGhlIGRvdWJsZSBzaWRlZCBwcm92aXNpb25p bmcsIHRoZSBwYXRoIGNvbXB1dGF0aW9uIG9mIHRoZSBmb3J3YXJkDQphbmQgdGhlIGJhY2t3YXJk IExTUDxicj4NCmFyZSBzdWJtaXR0ZWQgYnkgdGhlIGhlYWQtZW5kIGFuZCB0aGUgdGFpbC1lbmQg c2VwYXJhdGVseS5Gb3IgdGhlIHNpbmdsZQ0Kc2lkZWQgcHJvdmlzaW9uaW5nLCB0aGUgcGF0aCBj b21wdXRhdGlvbmNhbiBiZTxicj4NCnJlYWxpemVkIGJ5IHRoZSBjb25jdXJyZW50IG9yIHN1Y2Nl c3NpdmUgY29tcHV0YXRpb24uICZuYnNwO1RoZSBjb25jdXJyZW50DQpjb21wdXRhdGlvbiBtZWFu cyB0aGF0IHRoZSBoZWFkLWVuZCBzdWJtaXRzIHRoZSBjb21wdXRhdGlvbiByZXF1ZXN0PGJyPg0K Zm9yIGJvdGggdHdvIGRpcmVjdGlvbmFsIExTUHMgY29uY3VycmVudGx5LiAmbmJzcDtBcyB0byB0 aGUgc3VjY2Vzc2l2ZQ0KY29tcHV0YXRpb24sIHRoZSBoZWFkLWVuZCBhbmQgdGhlIHRhaWwtZW5k IHNlbmQgdGhlIGZvcndhcmQgTFNQIGFuZDxicj4NCmJhY2t3YXJkIExTUCBjb21wdXRhdGlvbiBy ZXF1ZXN0cyBzZXBhcmF0ZWx5Ljxicj4NCjxicj4NCldlIGhhdmUgZXh0ZW5kZWQgUENFUCBwcm90 b2NvbCB0byBzdXBwb3J0IHRoZSBDb25jdXJyZW50IGNvbXB1dGF0aW9uIGZvcg0KU2luZ2xlIFNp ZGVkIFByb3Zpc2lvbmluZyBtb2RlbC48YnI+DQpDb25jdXJyZW50IGNvbXB1dGF0aW9uIGNhbiBl bnN1cmUgdGhhdCB0aGUgcGF0aHMgZm9yIHRoZSBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCkxT UCBpcyBvcHRpbWFsLCBhcyBkZXNjcmliZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTU1Ny48YnI+DQpJbiB0aGlzIGRyYWZ0o6wgYW4gQS1iaXQgaXMgYWRkZWQgdG8gdGhlIGZs YWcgYml0cyBvZiB0aGUgUlAgb2JqZWN0IHRvDQppbmRpY2F0ZSB0aGUgcmVxdWVzdCBpcyBhYm91 dCBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIG9yIG5vdC48YnI+DQpmdXRoZXJtb3Jl o6xSRVZFUlNFX0xTUCBvYmplY3QgaXMgYWRkZWQgaW4gYSBQQ1JlcSBtZXNzYWdlIHRvIHNwZWNp ZnkNCnRoZSBpbmZvcm1hdGlvbiBvZiB0aGUgcmV2ZXJzZSBMU1Chozxicj4NCjxicj4NCjxicj4N ClBsZWFzZSBwcm92aWRlIGNvbW1lbnRzIGFuZCBmZWVkYmFjay48YnI+DQo8YnI+DQpUaGFua3M8 YnI+DQpXZW5qdWFuPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 000AEA8C48257935_=-- From vishwas.ietf@gmail.com Tue Oct 25 22:57:40 2011 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 4F42011E8082 for ; Tue, 25 Oct 2011 22:57:40 -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 nsjNRcVaIC3r for ; Tue, 25 Oct 2011 22:57:39 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 27D1511E807F for ; Tue, 25 Oct 2011 22:57:39 -0700 (PDT) Received: by ggnv1 with SMTP id v1so1448852ggn.31 for ; Tue, 25 Oct 2011 22:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EVF1LR2fLUs6ldno7yswcIuPnNvUBIrOHqtuUFze/KE=; b=Uj9rojtUAhf5RBfR2BLfzpjgWYOLjesc+Cjhq3p8bA5vnXh6XV5lx3E5yAj87Hf4Wi mm4TD1kPWRiwFIZAarf8YPVhefplHjn/5GbjytwusTy+64pLi2HwcYkpijJhpp78YHK+ Q+gbJWRr/D4V14e60Ic5MB/Rnb1fVmaMCcziM= MIME-Version: 1.0 Received: by 10.182.73.33 with SMTP id i1mr4978892obv.67.1319608658504; Tue, 25 Oct 2011 22:57:38 -0700 (PDT) Received: by 10.182.34.163 with HTTP; Tue, 25 Oct 2011 22:57:38 -0700 (PDT) In-Reply-To: References: <20111017025125.12274.29902.idtracker@ietfa.amsl.com> <047901cc8d93$0904a4f0$1b0deed0$@olddog.co.uk> Date: Tue, 25 Oct 2011 22:57:38 -0700 Message-ID: From: Vishwas Manral To: Edward Crabbe Content-Type: multipart/alternative; boundary=f46d04446bc7552c9e04b02d551a Cc: pce@ietf.org, JP Vasseur Subject: Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-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: Wed, 26 Oct 2011 05:57:40 -0000 --f46d04446bc7552c9e04b02d551a Content-Type: text/plain; charset=ISO-8859-1 Hi Ed, I agree these are important usecases to consider in defining a new architecture for PCE. Thanks, Vishwas On Tue, Oct 18, 2011 at 6:32 PM, Edward Crabbe wrote: > Adrian; > > I think not mentioning 5557 is clearly an oversight on our part. We will > remedy this in the next version of the draft. > > Optimization of resource usage is certainly an interesting use case for > stateful PCE (although by no means the only one), and the draft would > benefit from a comparison with what is achievable via stateful extensions > relative to 5557. > > Global control of LSP operation sequence in 5557 is predicated on the > use of what is effectively a stateful (or semi-stateful) NMS, which is > either not local to the switch (in which case we are required to use > another northbound interface for LSP attribute changes) or local/collocated, > in which case we have some significant issues with efficiency in > resource usage. > > Stateful adds a few features here in that: > > 1) the requirements for the NMS and additional northbound interface are > effectively removed > 2) it allows the system with the greatest visibility of the system to > determine > which LSPs should reoptimized and on what time interval > 3) the pce controls the sequence of events across pcc's, allowing for bulk > (if not global) optimization, lsp shuffling etc > > Thanks much for pointing out the oversight. :-/ > > best, > > -ed > > On Tue, Oct 18, 2011 at 5:39 AM, Adrian Farrel wrote: > >> Hi Ed,**** >> >> ** ** >> >> Interesting work, thanks. As you know, the concept of stateful PCE was in >> our minds all through the architecture phase of PCE and is included as a >> concept in RFC 4655.**** >> >> ** ** >> >> I think stateful PCE was left on one side over the last few years because >> it added complexity and the use cases were far more sophisticated than >> applied to initial use cases. But now that PCE is established as an idea, it >> is interesting to look at the more advanced uses that you describe and see >> how stateful PCE could be a benefit.**** >> >> ** ** >> >> It is good that you have a section on policy, because it is likely that >> operators will want to tweak this function in different ways according to >> how they run their networks. It might be interesting to make a reference to >> RFC 5394 and show how that description of policy fits in. Maybe the authors >> of 5394 could comment?**** >> >> ** ** >> >> You don't mention RFC 5557. Is this because you think GCO is too complex >> to be valuable or because it is not one of your primary use cases?**** >> >> ** ** >> >> Thanks,**** >> >> Adrian**** >> >> ** ** >> >> *From:* Edward Crabbe [mailto:edc@google.com] >> *Sent:* 17 October 2011 06:33 >> *To:* pce@ietf.org >> *Cc:* JP Vasseur; Julien Meuric >> *Subject:* Fwd: New Version Notification for >> draft-crabbe-pce-stateful-pce-00.txt**** >> >> ** ** >> >> Hello;**** >> >> ** ** >> >> We've submitted a draft for the group's consideration. We know that >> stateful PCE has been discussed by the working group in the past. We believe >> that we have addressed some of the issues that have been raised in previous >> discussions and have specific use cases that make stateful PCE valuable. We >> hope you'll find the time to look through the draft and comment on the list >> before the WG meeting in Taipei, and hope that we'll be able to have a >> fruitful and lively discussion there. **** >> >> ** ** >> >> best,**** >> >> ** ** >> >> -Edward**** >> >> ** ** >> >> ---------- Forwarded message ---------- >> From: >> Date: Sun, Oct 16, 2011 at 7:51 PM >> Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt >> To: edc@google.com >> Cc: jmedved@juniper.net, edc@google.com, rvarga@juniper.net >> >> >> A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been >> successfully submitted by Edward Crabbe and posted to the IETF repository. >> >> Filename: draft-crabbe-pce-stateful-pce >> Revision: 00 >> Title: PCEP Extensions for Stateful PCE >> Creation date: 2011-10-16 >> WG ID: Individual Submission >> Number of pages: 39 >> >> 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 this functionality, >> providing stateful control of Multiprotocol Label Switching (MPLS) >> Traffic Engineering Label Switched Paths (TE LSP) via PCEP. >> >> >> >> >> >> The IETF Secretariat**** >> >> ** ** >> > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --f46d04446bc7552c9e04b02d551a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ed,
=A0
I agree these are important usecases to consider in defining a new arc= hitecture=A0for PCE.
=A0
Thanks,
Vishwas
On Tue, Oct 18, 2011 at 6:32 PM, Edward Crabbe <= span dir=3D"ltr"><edc@google.com&g= t; wrote:
Adrian;

I think not mentioning 5557 is clearly an oversight on our part. =A0We= will remedy this in the next version of the draft.=A0

Optimization of resource usage is certainly an interesting use case=A0= for stateful PCE (although by no means the only one), and the draft would b= enefit from a comparison with what is achievable via stateful=A0extensions = relative to 5557. =A0 =A0

Global control of LSP operation sequence in 5557 is predicated on the = use=A0of what is effectively a stateful (or semi-stateful) NMS, which is ei= ther=A0not local to the switch (in which case we are required to use anothe= r=A0northbound interface for LSP attribute changes) or local/collocated, in= =A0which case we have some significant issues with efficiency in resource= =A0usage. =A0

Stateful adds a few features here in that:

1) the requirements for the NMS and additional northbound interface ar= e=A0
effectively removed=A0
2) it allows the system with the greatest visibility of the system to = determine=A0
which LSPs should reoptimized and on what time interval=A0
3) the pce controls the sequence of events across pcc's, allowing = for bulk
(if not global) optimization, lsp shuffling etc

Thanks much for pointing out the oversight. =A0:-/

best,

=A0 -ed

On Tue, Oct 18, 2011 at 5:39 AM, Adrian Farrel <= span dir=3D"ltr"><adrian@olddog.co.uk> wrote:

Hi E= d,

<= /u>=A0

Inte= resting work, thanks. As you know, the concept of stateful PCE was in our m= inds all through the architecture phase of PCE and is included as a concept= in RFC 4655.

<= /u>=A0

I th= ink stateful PCE was left on one side over the last few years because it ad= ded complexity and the use cases were far more sophisticated than applied t= o initial use cases. But now that PCE is established as an idea, it is inte= resting to look at the more advanced uses that you describe and see how sta= teful PCE could be a benefit.

<= /u>=A0

It i= s good that you have a section on policy, because it is likely that operato= rs will want to tweak this function in different ways according to how they= run their networks. It might be interesting to make a reference to RFC 539= 4 and show how that description of policy fits in. Maybe the authors of 539= 4 could comment?

<= /u>=A0

You = don't mention RFC 5557. Is this because you think GCO is too complex to= be valuable or because it is not one of your primary use cases?<= /u>

<= /u>=A0

Than= ks,

Adri= an

<= /u>=A0

Fr= om: Edward Crabbe= [mailto:edc@google.com= ]
Sent: 17 October 2011 06:33
To: pce@ietf.org
Cc: JP Vasseur; Julien M= euric
Subject: Fwd: New Version Notification for draft-crabbe-pce= -stateful-pce-00.txt

=A0

Hello;

=A0

We've submitted a draft for the group's cons= ideration. =A0We know th= at stateful PCE has been discussed=A0by the working group in the past. We b= elieve that we have addressed some of=A0the issues that have been raised in= previous discussions and have specific=A0use cases that make stateful PCE = valuable. We hope you'll find the time to=A0look through the draft and = comment on the list before the WG meeting in Taipei, and hope that we'l= l be able to have a fruitful and lively discussion there. =A0=

=A0

best,

=A0

=A0 =A0-Edward

=A0

---------- Forwarded message ----------
From: <= ;internet-dra= fts@ietf.org>
Date: Sun, Oct 16, 2011 at 7:51 PM
Subject: New = Version Notification for draft-crabbe-pce-stateful-pce-00.txt
To: edc@google.com<= br>Cc: jmedved@jun= iper.net, edc@googl= e.com, rvarga@j= uniper.net


A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been= successfully submitted by Edward Crabbe and posted to the IETF repository.=

Filename: =A0 =A0 =A0 =A0draft-crabbe-pce-stateful-pce
Revision:= =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 PCEP Extensions for Stateful PCE
Creation dat= e: =A0 2011-10-16
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Nu= mber of pages: 39

Abstract:
=A0 The Path Computation Element Comm= unication Protocol (PCEP) provides
=A0 mechanisms for Path Computation Elements (PCEs) to perform path
=A0 = computations in response to Path Computation Clients (PCCs) requests.
=A0 Although PCEP explicitly makes no assumptions regarding the
=A0 in= formation available to the PCE, it also makes no provisions for
=A0 synchronization or PCE control of timing and sequence of path
=A0 co= mputations within and across PCEP sessions. =A0This document
=A0 describ= es a set of extensions to PCEP to enable this functionality,
=A0 providi= ng stateful control of Multiprotocol Label Switching (MPLS)
=A0 Traffic Engineering Label Switched Paths (TE LSP) via PCEP.


=


The IETF Secretariat

=A0

<= /div>


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


--f46d04446bc7552c9e04b02d551a-- From jmedved@juniper.net Wed Oct 26 22:43:38 2011 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 D778F21F8B0F for ; Wed, 26 Oct 2011 22:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_33=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 Ty+xlZpwkV4v for ; Wed, 26 Oct 2011 22:43:38 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id B169E21F8B04 for ; Wed, 26 Oct 2011 22:43:37 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 26 Oct 2011 22:43:37 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 26 Oct 2011 22:40:01 -0700 From: Jan Medved To: "he.wenjuan1@zte.com.cn" , "pce@ietf.org" Date: Wed, 26 Oct 2011 22:39:57 -0700 Thread-Topic: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-00 Thread-Index: AcyUat4zyP1UP64pRHaMT0JQlbcNtg== 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.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Pce] [PCE] Request comments on draft-he-pce-pcep-associated-lsp-extensions-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, 27 Oct 2011 05:43:39 -0000 SGkgV2VuanVhbiwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCg0KVGhhbmtzLA0KSmFuDQoNCk9u IDEwLzI1LzExIDY6NTYgUE0sICJoZS53ZW5qdWFuMUB6dGUuY29tLmNuIiA8aGUud2VuanVhbjFA enRlLmNvbS5jbj4NCndyb3RlOg0KDQoNCj4NCj5IaSBKYW4sDQo+DQo+VGhhbmtzIGZvciB0aGUg Y29tbWVudHMsIEkgdGhpbmsgaXQNCj5pcyByZWFsbHkgdmFsdWFibGUuDQo+DQo+Rm9yIHRoZSBE b3VibGUgU2lkZWQgUHJvdmlzaW9uaW5nIG1vZGVsLA0KPmFsdGhvdWdoIHRoZSBoZWFkLWVuZCBh bmQgdGhlIHRhaWwtZW5kIG9yIE5NUyBzdWJtaXQgdGhlIFBDUmVxIG1lc3NhZ2UNCj5zZXBhcmF0 ZWx5LCB0aGUgdHdvIHJldmVyc2UgbHNwcyBjYW4gYmUgYXNzb2NpYXRlZA0KPnRvIGJlIG9wdGlt YWwgaWYgc3RhdGVmdWwgUENFIGlzIHVzZWQuDQo+DQo+DQo+VGhlIGRyYWZ0ICBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLw0KPmp1 c3Qgc2F5IHRoYXQgYWxsIG90aGVyIExTUCdzIGNvbmRpdGlvbiBjYW4gYmUgY29uc2lkZXJlZCBp ZiBhIG5ldyByZXF1ZXN0DQo+aXMgc3VibWl0dGVkLCBob3dldmVyLCB3ZSB3YW50IHRvIGNvbnNp ZGVyIHRoZSB0d28gcmVsYXRlZCBMU1BzIHRvZ2V0aGVyDQo+KGVzcGVjaWFsbHkgdGhlIFRFIHBh cmFtZXRlcnMpLCBhdCB0aGUgc2FtZSB0aW1lIGFsbCB0aGUgb3RoZXIgTFNQJ3MNCj5jb25kaXRp b24NCj5zaG91bGQgYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uLg0KDQpUaGUgImFsbCBMU1Bz IiBzZXQgYWxzbyBjb3ZlcnMgdGhlICJ0d28gcmVsYXRlZCBMU1BzIiBzZXQuIElmIGEgUENFIGtu b3dzDQphYm91dCAgYWxsIExTUHMgaW4gdGhlIG5ldHdvcmssIGl0IG11c3QgYWJvdXQgdGhlIGZv cndhcmQgYW5kIGJhY2t3YXJkDQpMU1BzIGFzIHdlbGwsIGFuZCBjYW4gY29uc2lkZXIgdGhlbSB0 b2dldGhlci4NCg0KPg0KPkhvdyBhYm91dCBpbnRyb2R1Y2luZyB0aGUgQXNzb2NpYXRpb24gT2Jq ZWN0IGluIHRoaXMgc2NlbmFyaW8/IFdoZW4gdGhlDQo+UENDIHN1Ym1pdHMgdGhlIHBhdGggY29t cHV0YXRpb24gcmVxdWVzdCBmb3IgdGhlIGZvcndhcmQgbHNwIG9yIHRoZQ0KPmJhY2t3YXJkIGxz cCwgdGhlIFBDUmVxIG1lc3NhZ2UgbWF5IGNhcnJ5IGFzc29jaWF0aW9uIG9iamVjdCB0byBpbmRp Y2F0ZQ0KPnRoYXQgYSByZXZlcnNlIGxzcCBpcyBuZWVkZWQgdG8gYmUgcHJvdmlkZWQgbGF0ZXIu IFdoZW4NCj50aGUgc2Vjb25kIHJlcXVlc3Qgd2l0aCB0aGUgc2FtZSBBc3NvaWNhdGlvbiBPYmpl Y3QgYXJyaXZlcywgdGhlIHN0YXRlZnVsDQo+UENFIGNhbiBjb21wdXRlIHRoZSB0d28gcmV2ZXJz ZSBsc3BzIGFnYWluLCBhbmQgZ2V0IHRoZSBvcHRpbWFsIHBhdGggZm9yDQo+dGhlIGFzc29jaWF0 ZWQgYmktZGlyZWN0aW9uYWwNCj5sc3AuIEFmdGVyIHRoZSBzdWNjZXNzZnVsIGNvbXB1dGF0aW9u LCB0aGUgUENFIHJlc3BvbnNlcyB0aGUgUENDIHdpdGggdGhlDQo+UENSZXAgbWVzc2FnZSBhbmQg dXBkYXRlcyB0aGUgcmV2ZXJzZSBsc3Agd2l0aCBQQ1VwZCBNZXNzYWdlLg0KDQpUaGUgQXNzb2Np YXRpb24gT2JqZWN0IG9uIGEgUENSZXEgbWVzc2FnZSB3b3VsZCBpbnRyb2R1Y2UgaW1wbGljaXQg c3RhdGUNCmludG8gdGhlIFBDRS4gRXJyb3IgY29uZGl0aW9ucyB3b3VsZCBiZSBkaWZmaWN1bHQg dG8gaGFuZGxlLiBGb3IgZXhhbXBsZSwNCndoYXQgd291bGQgdGhlIFBDRSBkbyB3aXRoIHRoZSBB c3NvY2lhdGlvbiBPYmplY3QgaWYgdGhlIHNlY29uZCByZXF1ZXN0DQooZnJvbSB0aGUgdGFpbC1l bmQpIG5ldmVyIGNvbWVzPyBUaGUgb2JqZWN0IHdvdWxkIGhhdmUgdG8gYmUgZmx1c2hlZCwgYnV0 DQp3aGVuPyBPciwgY2FuIHRoZSBQQ0UgZmx1c2ggdGhlIEFzc29jaWF0aW9uIE9iamVjdCBhZnRl ciB0aGUgY29tcHV0YXRpb24NCm9mIHRoZSBiYWNrd2FyZCBwYXRoIGlzIGRvbmU/IEl0IHByb2Jh Ymx5IGNhbid0IC0gdGhlIGJhY2t3YXJkIHBhdGggc2V0IHVwDQptYXkgZmFpbCwgYW5kIHRoZSB0 YWlsLWVuZCBQQ0MgbWF5IGNvbWUgYmFjayB0byB0aGUgUENFIHRvIGFzayBmb3IgYSBuZXcNCmJh Y2t3YXJkIHBhdGguDQoNCkFub3RoZXIgaXNzdWUgaXMgdGhhdCB0aGUgY29tcHV0YXRpb24gb2Yg Zm9yd2FyZCBhbmQgYmFja3dhcmQgTFNQcyBjYW4gbm90DQpiZSBzeW5jaHJvbml6ZWQgLSBhcyB5 b3UgcG9pbnRlZCBvdXQsIHRoZXkgc2hvdWxkIGJlIGNvbXB1dGVkIHRvZ2V0aGVyLg0KDQpUaGF0 IHNhaWQsIEkgdGhpbmsgd2Ugd2lsbCBuZWVkIHRoZSBBc3NvY2lhdGlvbiBPYmplY3QsIGJ1dCB3 ZSB3aWxsIG5lZWQNCml0IHdpdGggdGhlIHN0YXRlZnVsIFBDRSBtZWNoYW5pc21zIGRlc2NyaWJl ZCBpbg0KZHJhZnQtY3JhYmJlLXBjZS1zdGF0ZWZ1bC1wY2UuIEJvdGggdGhlIGhlYWQtZW5kIGFu ZCB0aGUgdGFpbC1lbmQgIFBDQ3MNCnN5bmMgdXAgYW5kIGRlbGVnYXRlIHRoZWlyIHJlc3BlY3Rp dmUgTFNQcyAoZm9yd2FyZCBhbmQgYmFja3dhcmQpIHRvIHRoZQ0KUENFIHVzaW5nIFBDUnB0IG1l c3NhZ2VzLiBUaGUgUENFIHdpbGwgY29tcHV0ZSB0aGUgZm9yd2FyZCBhbmQgYmFja3dhcmQNCnBh dGhzIGFuZCB0aGVuLCB1c2luZyBQQ1VwZCBtZXNzYWdlcywgd2lsbCB0cmlnZ2VyIHRoZSBoZWFk LWVuZCB0byBzZXR1cA0KdGhlIGZvcndhcmQgTFNQIGFuZCB0aGUgYmFja2VuZCB0byB0cmlnZ2Vy IHRoZSBzZXR1cCBvZiB0aGUgYmFja3dhcmQgTFNQLg0KVGhlIFBDRSB3aWxsIGNvb3JkaW5hdGUg TFNQIHNldHVwIGluIHRoZSBoZWFkLWVuZCBhbmQgdGhlIHRhaWwtZW5kLiBXZQ0Kd2lsbCBuZWVk IHRoZSBBc3NvY2lhdGlvbiBPYmplY3QgZHVyaW5nIHN5bmNocm9uaXphdGlvbiB0byB0ZWxsIHRo ZSBQQ0UNCnRoYXQgdGhlIGZvcndhcmQgTFNQIGFuZCB0aGUgYmFja3dhcmQgTFNQIGFyZSBhIHBh cnQgb2YgdGhlIHNhbWUNCmJpLWRpcmVjdGlvbmFsIExTUC4NCg0KPg0KPllvdXIgY29tbWVudHMg b24gdGhpcyBhcmUgbW9zdCB3ZWxjb21lLg0KPg0KPlRoYW5rcw0KPg0KPldlbmp1YW4NCj4NCj4N Cj4NCj4NCj5KYW4gTWVkdmVkIDxqbWVkdmVkQGp1bmlwZXIubmV0PjIwMTEtMTAtMjUgMDI6MjEN Cj7mlLbku7bkuroNCj4iaGUud2VuanVhbjFAenRlLmNvbS5jbiIgPGhlLndlbmp1YW4xQHp0ZS5j b20uY24+LA0KPiJwY2VAaWV0Zi5vcmciIDxwY2VAaWV0Zi5vcmc+5oqE6YCBDQo+5Li76aKYDQo+ UmU6IFtQY2VdIFtQQ0VdIFJlcXVlc3QgY29tbWVudHMgb24NCj5kcmFmdC1oZS1wY2UtcGNlcC1h c3NvY2lhdGVkLWxzcC1leHRlbnNpb25zLTAwDQo+DQo+DQo+DQo+DQo+SGkgV2VuanVhbiwNCj4N Cj5Eb3VibGUgU2lkZWQgUHJvdmlzaW9uaW5nIChTZWN0aW9uIDMuMikgd2lsbCByZXF1aXJlIExT UCBzZXR1cA0KPmNvb3JkaW5hdGlvbg0KPmJldHdlZW4gdGhlIGhlYWQtZW5kIGFuZCB0aGUgdGFp bC1lbmQsIHdoaWNoIHdpbGwgbmVlZCB0byBiZSBwcm92aWRlZA0KPmVpdGhlcg0KPmJ5IGEgbWFu YWdlbWVudCBzeXN0ZW0gb3IgYSBzdGF0ZWZ1bCBQQ0UgcHJvcG9zZWQgaW4NCj5kcmFmdC1jcmFi YmUtcGNlLXN0YXRlZnVsLXBjZS0wMA0KPihodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLykuDQo+DQo+DQo+DQo+VGhhbmtzLA0KPkph bg0KPg0KPg0KPk9uIDEwLzI0LzExIDI6MzYgQU0sDQo+ImhlLndlbmp1YW4xQHp0ZS5jb20uY248 bWFpbHRvOmhlLndlbmp1YW4xQHp0ZS5jb20uY24+Ig0KPjxoZS53ZW5qdWFuMUB6dGUuY29tLmNu PG1haWx0bzpoZS53ZW5qdWFuMUB6dGUuY29tLmNuPj4gd3JvdGU6DQo+DQo+DQo+SGkgYWxsLA0K PldlJ3ZlIHN1Ym1pdHRlZCBhIGRyYWZ0IGZvciB0aGUgZXh0ZW5zaW9ucyBvZiBQQ0VQIHRvIHN1 cHBvcnQgYXNzb2NpYXRlZA0KPmJpZGlyZWN0aW9uYWwgbHNwLCBiZWxvdyBpcyB0aGUgbGluazoN Cj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oZS1wY2UtcGNlcC1hc3NvY2lhdGVk LWxzcC1leHRlbnNpb25zLTAwLg0KPg0KPlRoZSBNUExTLVRQIHJlcXVpcmVtZW50cyBbUkZDNTY1 NF0gYW5kIGNvbnRyb2wgcGxhbmUgZnJhbWV3b3JrDQo+ZG9jdW1lbnRzW1JGQzYzNzNdZGVzY3Jp YmUNCj50aGF0IE1QTFMtVFAgTVVTVA0KPnN1cHBvcnQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IHBvaW50LXRvLXBvaW50IExTUHMuICBQYXRoIENvbXB1dGF0aW9uDQo+RWxlbWVudCAoUENFKSwg c2VlIFtSRkM0NjU1XSwgbWF5IGJlIHVzZWQgZm9yIHBhdGgNCj5jb21wdXRhdGlvbiBvZiBhIEdN UExTIExTUCxhbmQgY29uc2VxdWVudGx5IGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbA0KPkxT UCwgYWNyb3NzIGRvbWFpbnMgYW5kIGluIGEgc2luZ2xlIGRvbWFpbi4NCj4NCj5BcyBkZXNjcmli ZWQgaW4gDQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1tcGxz LXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC0NCj5sc3AtMDIsDQo+dGhlIGFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbCBMU1AgY2FuIGJlIGRlcGxveWVkIGJ5IFNpbmdsZSBTaWRlZA0KPlByb3Zpc2lv bmluZw0KPm1vZGVsIG9yIERvdWJsZSBTaWRlZCBQcm92aXNpb25pbmcNCj5tb2RlbC5Gb3IgdGhl IGRvdWJsZSBzaWRlZCBwcm92aXNpb25pbmcsIHRoZSBwYXRoIGNvbXB1dGF0aW9uIG9mIHRoZQ0K PmZvcndhcmQNCj5hbmQgdGhlIGJhY2t3YXJkIExTUA0KPmFyZSBzdWJtaXR0ZWQgYnkgdGhlIGhl YWQtZW5kIGFuZCB0aGUgdGFpbC1lbmQgc2VwYXJhdGVseS5Gb3IgdGhlIHNpbmdsZQ0KPnNpZGVk IHByb3Zpc2lvbmluZywgdGhlIHBhdGggY29tcHV0YXRpb25jYW4gYmUNCj5yZWFsaXplZCBieSB0 aGUgY29uY3VycmVudCBvciBzdWNjZXNzaXZlIGNvbXB1dGF0aW9uLiAgVGhlIGNvbmN1cnJlbnQN Cj5jb21wdXRhdGlvbiBtZWFucyB0aGF0IHRoZSBoZWFkLWVuZCBzdWJtaXRzIHRoZSBjb21wdXRh dGlvbiByZXF1ZXN0DQo+Zm9yIGJvdGggdHdvIGRpcmVjdGlvbmFsIExTUHMgY29uY3VycmVudGx5 LiAgQXMgdG8gdGhlIHN1Y2Nlc3NpdmUNCj5jb21wdXRhdGlvbiwgdGhlIGhlYWQtZW5kIGFuZCB0 aGUgdGFpbC1lbmQgc2VuZCB0aGUgZm9yd2FyZCBMU1AgYW5kDQo+YmFja3dhcmQgTFNQIGNvbXB1 dGF0aW9uIHJlcXVlc3RzIHNlcGFyYXRlbHkuDQo+DQo+V2UgaGF2ZSBleHRlbmRlZCBQQ0VQIHBy b3RvY29sIHRvIHN1cHBvcnQgdGhlIENvbmN1cnJlbnQgY29tcHV0YXRpb24gZm9yDQo+U2luZ2xl IFNpZGVkIFByb3Zpc2lvbmluZyBtb2RlbC4NCj5Db25jdXJyZW50IGNvbXB1dGF0aW9uIGNhbiBl bnN1cmUgdGhhdCB0aGUgcGF0aHMgZm9yIHRoZSBhc3NvY2lhdGVkDQo+YmlkaXJlY3Rpb25hbA0K PkxTUCBpcyBvcHRpbWFsLCBhcyBkZXNjcmliZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTU1Ny4NCj5JbiB0aGlzIGRyYWZ077yMIGFuIEEtYml0IGlzIGFkZGVkIHRvIHRoZSBm bGFnIGJpdHMgb2YgdGhlIFJQIG9iamVjdCB0bw0KPmluZGljYXRlIHRoZSByZXF1ZXN0IGlzIGFi b3V0IGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1Agb3Igbm90Lg0KPmZ1dGhlcm1vcmXv vIxSRVZFUlNFX0xTUCBvYmplY3QgaXMgYWRkZWQgaW4gYSBQQ1JlcSBtZXNzYWdlIHRvIHNwZWNp ZnkNCj50aGUgaW5mb3JtYXRpb24gb2YgdGhlIHJldmVyc2UgTFNQ44CCDQo+DQo+DQo+UGxlYXNl IHByb3ZpZGUgY29tbWVudHMgYW5kIGZlZWRiYWNrLg0KPg0KPlRoYW5rcw0KPldlbmp1YW4NCj4N Cg0K From he.wenjuan1@zte.com.cn Sat Oct 29 00:26:33 2011 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 5DD8F21F84D6 for ; Sat, 29 Oct 2011 00:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.906 X-Spam-Level: X-Spam-Status: No, score=-93.906 tagged_above=-999 required=5 tests=[AWL=-2.316, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 LMJFSXgFYo97 for ; Sat, 29 Oct 2011 00:26:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6653B21F84A9 for ; Sat, 29 Oct 2011 00:26:31 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466211441414862; Sat, 29 Oct 2011 15:18:10 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 60802.2005898773; Sat, 29 Oct 2011 15:26:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9T7QH3e021745; Sat, 29 Oct 2011 15:26:17 +0800 (GMT-8) (envelope-from he.wenjuan1@zte.com.cn) In-Reply-To: To: Jan Medved MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: he.wenjuan1@zte.com.cn Date: Sat, 29 Oct 2011 15:26:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-29 15:26:19, Serialize complete at 2011-10-29 15:26:19 Content-Type: multipart/alternative; boundary="=_alternative 00291E6648257938_=" X-MAIL: mse02.zte.com.cn p9T7QH3e021745 Cc: "pce@ietf.org" Subject: [Pce] =?gb2312?b?tPC4tDogUmU6ICBbUENFXSBSZXF1ZXN0IGNvbW1lbnRzIG9u?= =?gb2312?b?IGRyYWZ0LWhlLXBjZS1wY2VwLWFzc29jaWF0ZWQtbHNwLWV4dGVuc2lvbnMt?= =?gb2312?b?MDA=?= 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, 29 Oct 2011 07:26:33 -0000 This is a multipart message in MIME format. --=_alternative 00291E6648257938_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSmFuLA0KDQpUaGFua3MgZm9yIHlvdXIgdmFsdWFibGUgY29tbWVudHMuDQoNCkkgYW0gZ2xh ZCB3ZSBoYXZlIHJlYWNoZWQgdGhlIGFncmVlbWVudCwgdGhlIEFzc29jaWF0aW9uIG9iamVjdCB3 aWxsIGJlIA0KaW50cm9kdWNlZCB0byBQQ0VQLCB3aGljaCBjYW4gYmUgdXNlZCB0byBvcHRpbWl6 aW5nIHRoZSBhc3NvY2lhdGVkIA0KYmlkaXJlY3Rpb25hbCBsc3AuDQoNCkZvciB0aGUgRG91Ymxl IFNpZGVkIFByb3Zpc2lvbmluZyBtb2RlbCwgdGhlIFBDQyBzdWJtaXRzIHRoZSBQQ1JlcSBtZXNz YWdlIA0Kd2l0aCBBc3NvY2lhdGlvbiBvYmplY3QsIHRoZSBzdGF0ZWZ1bCBQQ0Ugd2lsbCBsb29r IHVwIHRoZSByZXZlcnNlIGxzcCANCmluZGljYXRlZCBieSB0aGUgQXNzb2NpYXRpb24gb2JqZWN0 Lg0KSWYgdGhlIHJlcXVlc3Qgb2YgdGhlIHJldmVyc2UgbHNwIGRvZXMgbm90IGFycml2ZSx0aGUg UENFIHdpbGwgY29tcHV0ZSB0aGUgDQpwYXRoIGNvbnNpZGVyaW5nIHRoZSBwcmVzZW50IG5ldHdv cmsuIFdoZW4gdGhlIHNlY29uZCByZXF1ZXN0IHdpdGggdGhlIA0Kc2FtZSBBc3NvaWNhdGlvbiBP YmplY3QgYXJyaXZlcywgdGhlIHN0YXRlZnVsIFBDRSB3aWxsIGtub3cgdGhlIHR3byANCnJldmVy c2UgbHNwcyBmb3JtIHRoZSBiaWRpcmVjdGlvbmFsIExTUCBhbmQgY29tcHV0ZSB0aGUgdHdvIHJl dmVyc2UgbHNwcyANCmFnYWluIHRvIGdldCB0aGUgb3B0aW1hbCBwYXRoIGZvciB0aGUgYXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsIGxzcC4gQWZ0ZXIgDQp0aGUgc3VjY2Vzc2Z1bCBjb21wdXRhdGlv biwgdGhlIFBDRSByZXNwb25zZXMgdGhlIFBDQyB3aXRoIHRoZSBQQ1JlcCANCm1lc3NhZ2UgYW5k IHVwZGF0ZXMgdGhlIHJldmVyc2UgbHNwIHdpdGggUENVcGQgTWVzc2FnZS4NCg0KSWYgdGhlIGJh Y2t3YXJkIHBhdGggc2V0dXAgZmFpbCwgdGhlIHRhaWwtZW5kIG1heSBzZW5kIHRoZSBQQ1JlcSBt ZXNzYWdlIA0KdG8gdGhlIFBDRSB0byBhc2sgZm9yIGEgbmV3IGJhY2t3YXJkIHBhdGguIFRoZSB0 d28gcmV2ZXJzZSBsc3BzIHdpbGwgYmUgDQpjb21wdXRlZCBhZ2FpbiBhbmQgY3JlYXRlZCB1c2lu ZyBtYWtlLWJlZm9yZS1icmVhayBpbiB0aGUgcmUtc2lnbmFsaW5nIA0Kb3BlcmF0aW9uLCBzZWUg c2VjdGlvbiA2LjIsIA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY3JhYmJlLXBj ZS1zdGF0ZWZ1bC1wY2UtMDAuDQoNClRoZSBFeHRlbmRlZCBBc3NvY2lhdGlvbiBvYmplY3QgaXMg ZGVmaW5lZCBpbiB0aGUgZHJhZnQgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWNjYW1wLWFzc29jLWV4dC0wMC4gDQpBIG5ldyBBc3NvY2lhdGlvbiBUeXBlICJhc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgTFNQIiBpcyBpbnRyb2R1Y2VkIGluIA0KYW5vdGhlciBkcmFmdCwg DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2 cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMg0KLiANCg0KSSB0aGluayBpdCBpcyBtb3JlIGFwcGxp Y2FibGUgdGhhdCB0aGUgQXNzb2NpYXRpb24gb2JqZWN0IGlzIGludHJvZHVjZWQgaW4gDQp0aGlz IGRyYWZ0LiBCZWNhdXNlIHRoZSBBc3NvY2lhdGlvbiBvYmplY3QgaXMgdXNlZCB0byBiaW5kIHRo ZSBmb3J3YXJkIGFuZCANCnRoZSBiYWNrd2FyZCBsc3BzLCBhbmQgSSBkb24ndCBzZWUgdGhlIG90 aGVyIHNjZW5hcmlvIGFza2luZyBmb3IgdGhlIA0KQXNzb2NpYXRpb24gb2JqZWN0LiBXaGF0IGRv IHlvdSB0aGluaz8NCg0KWW91ciBjb21tZW50cyBvbiB0aGlzIGFyZSBtb3N0IHdlbGNvbWUuDQoN ClRoYW5rcw0KDQpXZW5qdWFuDQoNCg0KDQoNCkphbiBNZWR2ZWQgPGptZWR2ZWRAanVuaXBlci5u ZXQ+IA0KMjAxMS0xMC0yNyAxMzozOQ0KDQrK1bz+yMsNCiJoZS53ZW5qdWFuMUB6dGUuY29tLmNu IiA8aGUud2VuanVhbjFAenRlLmNvbS5jbj4sICJwY2VAaWV0Zi5vcmciIA0KPHBjZUBpZXRmLm9y Zz4NCrOty80NCg0K1vfM4g0KUmU6IFtQY2VdIFtQQ0VdIFJlcXVlc3QgY29tbWVudHMgb24gDQpk cmFmdC1oZS1wY2UtcGNlcC1hc3NvY2lhdGVkLWxzcC1leHRlbnNpb25zLTAwDQoNCg0KDQoNCg0K DQpIaSBXZW5qdWFuLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KDQpUaGFua3MsDQpKYW4NCg0K T24gMTAvMjUvMTEgNjo1NiBQTSwgImhlLndlbmp1YW4xQHp0ZS5jb20uY24iIDxoZS53ZW5qdWFu MUB6dGUuY29tLmNuPg0Kd3JvdGU6DQoNCg0KPg0KPkhpIEphbiwNCj4NCj5UaGFua3MgZm9yIHRo ZSBjb21tZW50cywgSSB0aGluayBpdA0KPmlzIHJlYWxseSB2YWx1YWJsZS4NCj4NCj5Gb3IgdGhl IERvdWJsZSBTaWRlZCBQcm92aXNpb25pbmcgbW9kZWwsDQo+YWx0aG91Z2ggdGhlIGhlYWQtZW5k IGFuZCB0aGUgdGFpbC1lbmQgb3IgTk1TIHN1Ym1pdCB0aGUgUENSZXEgbWVzc2FnZQ0KPnNlcGFy YXRlbHksIHRoZSB0d28gcmV2ZXJzZSBsc3BzIGNhbiBiZSBhc3NvY2lhdGVkDQo+dG8gYmUgb3B0 aW1hbCBpZiBzdGF0ZWZ1bCBQQ0UgaXMgdXNlZC4NCj4NCj4NCj5UaGUgZHJhZnQgIGh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY3JhYmJlLXBjZS1zdGF0ZWZ1bC1wY2UvDQo+ anVzdCBzYXkgdGhhdCBhbGwgb3RoZXIgTFNQJ3MgY29uZGl0aW9uIGNhbiBiZSBjb25zaWRlcmVk IGlmIGEgbmV3IA0KcmVxdWVzdA0KPmlzIHN1Ym1pdHRlZCwgaG93ZXZlciwgd2Ugd2FudCB0byBj b25zaWRlciB0aGUgdHdvIHJlbGF0ZWQgTFNQcyB0b2dldGhlcg0KPihlc3BlY2lhbGx5IHRoZSBU RSBwYXJhbWV0ZXJzKSwgYXQgdGhlIHNhbWUgdGltZSBhbGwgdGhlIG90aGVyIExTUCdzDQo+Y29u ZGl0aW9uDQo+c2hvdWxkIGJlIHRha2VuIGludG8gY29uc2lkZXJhdGlvbi4NCg0KVGhlICJhbGwg TFNQcyIgc2V0IGFsc28gY292ZXJzIHRoZSAidHdvIHJlbGF0ZWQgTFNQcyIgc2V0LiBJZiBhIFBD RSBrbm93cw0KYWJvdXQgIGFsbCBMU1BzIGluIHRoZSBuZXR3b3JrLCBpdCBtdXN0IGFib3V0IHRo ZSBmb3J3YXJkIGFuZCBiYWNrd2FyZA0KTFNQcyBhcyB3ZWxsLCBhbmQgY2FuIGNvbnNpZGVyIHRo ZW0gdG9nZXRoZXIuDQoNCj4NCj5Ib3cgYWJvdXQgaW50cm9kdWNpbmcgdGhlIEFzc29jaWF0aW9u IE9iamVjdCBpbiB0aGlzIHNjZW5hcmlvPyBXaGVuIHRoZQ0KPlBDQyBzdWJtaXRzIHRoZSBwYXRo IGNvbXB1dGF0aW9uIHJlcXVlc3QgZm9yIHRoZSBmb3J3YXJkIGxzcCBvciB0aGUNCj5iYWNrd2Fy ZCBsc3AsIHRoZSBQQ1JlcSBtZXNzYWdlIG1heSBjYXJyeSBhc3NvY2lhdGlvbiBvYmplY3QgdG8g aW5kaWNhdGUNCj50aGF0IGEgcmV2ZXJzZSBsc3AgaXMgbmVlZGVkIHRvIGJlIHByb3ZpZGVkIGxh dGVyLiBXaGVuDQo+dGhlIHNlY29uZCByZXF1ZXN0IHdpdGggdGhlIHNhbWUgQXNzb2ljYXRpb24g T2JqZWN0IGFycml2ZXMsIHRoZSBzdGF0ZWZ1bA0KPlBDRSBjYW4gY29tcHV0ZSB0aGUgdHdvIHJl dmVyc2UgbHNwcyBhZ2FpbiwgYW5kIGdldCB0aGUgb3B0aW1hbCBwYXRoIGZvcg0KPnRoZSBhc3Nv Y2lhdGVkIGJpLWRpcmVjdGlvbmFsDQo+bHNwLiBBZnRlciB0aGUgc3VjY2Vzc2Z1bCBjb21wdXRh dGlvbiwgdGhlIFBDRSByZXNwb25zZXMgdGhlIFBDQyB3aXRoIHRoZQ0KPlBDUmVwIG1lc3NhZ2Ug YW5kIHVwZGF0ZXMgdGhlIHJldmVyc2UgbHNwIHdpdGggUENVcGQgTWVzc2FnZS4NCg0KVGhlIEFz c29jaWF0aW9uIE9iamVjdCBvbiBhIFBDUmVxIG1lc3NhZ2Ugd291bGQgaW50cm9kdWNlIGltcGxp Y2l0IHN0YXRlDQppbnRvIHRoZSBQQ0UuIEVycm9yIGNvbmRpdGlvbnMgd291bGQgYmUgZGlmZmlj dWx0IHRvIGhhbmRsZS4gRm9yIGV4YW1wbGUsDQp3aGF0IHdvdWxkIHRoZSBQQ0UgZG8gd2l0aCB0 aGUgQXNzb2NpYXRpb24gT2JqZWN0IGlmIHRoZSBzZWNvbmQgcmVxdWVzdA0KKGZyb20gdGhlIHRh aWwtZW5kKSBuZXZlciBjb21lcz8gVGhlIG9iamVjdCB3b3VsZCBoYXZlIHRvIGJlIGZsdXNoZWQs IGJ1dA0Kd2hlbj8gT3IsIGNhbiB0aGUgUENFIGZsdXNoIHRoZSBBc3NvY2lhdGlvbiBPYmplY3Qg YWZ0ZXIgdGhlIGNvbXB1dGF0aW9uDQpvZiB0aGUgYmFja3dhcmQgcGF0aCBpcyBkb25lPyBJdCBw cm9iYWJseSBjYW4ndCAtIHRoZSBiYWNrd2FyZCBwYXRoIHNldCB1cA0KbWF5IGZhaWwsIGFuZCB0 aGUgdGFpbC1lbmQgUENDIG1heSBjb21lIGJhY2sgdG8gdGhlIFBDRSB0byBhc2sgZm9yIGEgbmV3 DQpiYWNrd2FyZCBwYXRoLg0KDQpBbm90aGVyIGlzc3VlIGlzIHRoYXQgdGhlIGNvbXB1dGF0aW9u IG9mIGZvcndhcmQgYW5kIGJhY2t3YXJkIExTUHMgY2FuIG5vdA0KYmUgc3luY2hyb25pemVkIC0g YXMgeW91IHBvaW50ZWQgb3V0LCB0aGV5IHNob3VsZCBiZSBjb21wdXRlZCB0b2dldGhlci4NCg0K VGhhdCBzYWlkLCBJIHRoaW5rIHdlIHdpbGwgbmVlZCB0aGUgQXNzb2NpYXRpb24gT2JqZWN0LCBi dXQgd2Ugd2lsbCBuZWVkDQppdCB3aXRoIHRoZSBzdGF0ZWZ1bCBQQ0UgbWVjaGFuaXNtcyBkZXNj cmliZWQgaW4NCmRyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLiBCb3RoIHRoZSBoZWFkLWVu ZCBhbmQgdGhlIHRhaWwtZW5kICBQQ0NzDQpzeW5jIHVwIGFuZCBkZWxlZ2F0ZSB0aGVpciByZXNw ZWN0aXZlIExTUHMgKGZvcndhcmQgYW5kIGJhY2t3YXJkKSB0byB0aGUNClBDRSB1c2luZyBQQ1Jw dCBtZXNzYWdlcy4gVGhlIFBDRSB3aWxsIGNvbXB1dGUgdGhlIGZvcndhcmQgYW5kIGJhY2t3YXJk DQpwYXRocyBhbmQgdGhlbiwgdXNpbmcgUENVcGQgbWVzc2FnZXMsIHdpbGwgdHJpZ2dlciB0aGUg aGVhZC1lbmQgdG8gc2V0dXANCnRoZSBmb3J3YXJkIExTUCBhbmQgdGhlIGJhY2tlbmQgdG8gdHJp Z2dlciB0aGUgc2V0dXAgb2YgdGhlIGJhY2t3YXJkIExTUC4NClRoZSBQQ0Ugd2lsbCBjb29yZGlu YXRlIExTUCBzZXR1cCBpbiB0aGUgaGVhZC1lbmQgYW5kIHRoZSB0YWlsLWVuZC4gV2UNCndpbGwg bmVlZCB0aGUgQXNzb2NpYXRpb24gT2JqZWN0IGR1cmluZyBzeW5jaHJvbml6YXRpb24gdG8gdGVs bCB0aGUgUENFDQp0aGF0IHRoZSBmb3J3YXJkIExTUCBhbmQgdGhlIGJhY2t3YXJkIExTUCBhcmUg YSBwYXJ0IG9mIHRoZSBzYW1lDQpiaS1kaXJlY3Rpb25hbCBMU1AuDQoNCj4NCj5Zb3VyIGNvbW1l bnRzIG9uIHRoaXMgYXJlIG1vc3Qgd2VsY29tZS4NCj4NCj5UaGFua3MNCj4NCj5XZW5qdWFuDQo+ DQo+DQo+DQo+DQo+SmFuIE1lZHZlZCA8am1lZHZlZEBqdW5pcGVyLm5ldD4yMDExLTEwLTI1IDAy OjIxDQo+ytW8/sjLDQo+ImhlLndlbmp1YW4xQHp0ZS5jb20uY24iIDxoZS53ZW5qdWFuMUB6dGUu Y29tLmNuPiwNCj4icGNlQGlldGYub3JnIiA8cGNlQGlldGYub3JnPrOty80NCj7W98ziDQo+UmU6 IFtQY2VdIFtQQ0VdIFJlcXVlc3QgY29tbWVudHMgb24NCj5kcmFmdC1oZS1wY2UtcGNlcC1hc3Nv Y2lhdGVkLWxzcC1leHRlbnNpb25zLTAwDQo+DQo+DQo+DQo+DQo+SGkgV2VuanVhbiwNCj4NCj5E b3VibGUgU2lkZWQgUHJvdmlzaW9uaW5nIChTZWN0aW9uIDMuMikgd2lsbCByZXF1aXJlIExTUCBz ZXR1cA0KPmNvb3JkaW5hdGlvbg0KPmJldHdlZW4gdGhlIGhlYWQtZW5kIGFuZCB0aGUgdGFpbC1l bmQsIHdoaWNoIHdpbGwgbmVlZCB0byBiZSBwcm92aWRlZA0KPmVpdGhlcg0KPmJ5IGEgbWFuYWdl bWVudCBzeXN0ZW0gb3IgYSBzdGF0ZWZ1bCBQQ0UgcHJvcG9zZWQgaW4NCj5kcmFmdC1jcmFiYmUt cGNlLXN0YXRlZnVsLXBjZS0wMA0KPihodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLykuDQo+DQo+DQo+DQo+VGhhbmtzLA0KPkphbg0K Pg0KPg0KPk9uIDEwLzI0LzExIDI6MzYgQU0sDQo+ImhlLndlbmp1YW4xQHp0ZS5jb20uY248bWFp bHRvOmhlLndlbmp1YW4xQHp0ZS5jb20uY24+Ig0KPjxoZS53ZW5qdWFuMUB6dGUuY29tLmNuPG1h aWx0bzpoZS53ZW5qdWFuMUB6dGUuY29tLmNuPj4gd3JvdGU6DQo+DQo+DQo+SGkgYWxsLA0KPldl J3ZlIHN1Ym1pdHRlZCBhIGRyYWZ0IGZvciB0aGUgZXh0ZW5zaW9ucyBvZiBQQ0VQIHRvIHN1cHBv cnQgYXNzb2NpYXRlZA0KPmJpZGlyZWN0aW9uYWwgbHNwLCBiZWxvdyBpcyB0aGUgbGluazoNCj5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oZS1wY2UtcGNlcC1hc3NvY2lhdGVkLWxz cC1leHRlbnNpb25zLTAwLg0KPg0KPlRoZSBNUExTLVRQIHJlcXVpcmVtZW50cyBbUkZDNTY1NF0g YW5kIGNvbnRyb2wgcGxhbmUgZnJhbWV3b3JrDQo+ZG9jdW1lbnRzW1JGQzYzNzNdZGVzY3JpYmUN Cj50aGF0IE1QTFMtVFAgTVVTVA0KPnN1cHBvcnQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIHBv aW50LXRvLXBvaW50IExTUHMuICBQYXRoIENvbXB1dGF0aW9uDQo+RWxlbWVudCAoUENFKSwgc2Vl IFtSRkM0NjU1XSwgbWF5IGJlIHVzZWQgZm9yIHBhdGgNCj5jb21wdXRhdGlvbiBvZiBhIEdNUExT IExTUCxhbmQgY29uc2VxdWVudGx5IGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbA0KPkxTUCwg YWNyb3NzIGRvbWFpbnMgYW5kIGluIGEgc2luZ2xlIGRvbWFpbi4NCj4NCj5BcyBkZXNjcmliZWQg aW4gDQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRw LXJzdnB0ZS1leHQtYXNzb2NpYXRlZC0NCj5sc3AtMDIsDQo+dGhlIGFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCBMU1AgY2FuIGJlIGRlcGxveWVkIGJ5IFNpbmdsZSBTaWRlZA0KPlByb3Zpc2lvbmlu Zw0KPm1vZGVsIG9yIERvdWJsZSBTaWRlZCBQcm92aXNpb25pbmcNCj5tb2RlbC5Gb3IgdGhlIGRv dWJsZSBzaWRlZCBwcm92aXNpb25pbmcsIHRoZSBwYXRoIGNvbXB1dGF0aW9uIG9mIHRoZQ0KPmZv cndhcmQNCj5hbmQgdGhlIGJhY2t3YXJkIExTUA0KPmFyZSBzdWJtaXR0ZWQgYnkgdGhlIGhlYWQt ZW5kIGFuZCB0aGUgdGFpbC1lbmQgc2VwYXJhdGVseS5Gb3IgdGhlIHNpbmdsZQ0KPnNpZGVkIHBy b3Zpc2lvbmluZywgdGhlIHBhdGggY29tcHV0YXRpb25jYW4gYmUNCj5yZWFsaXplZCBieSB0aGUg Y29uY3VycmVudCBvciBzdWNjZXNzaXZlIGNvbXB1dGF0aW9uLiAgVGhlIGNvbmN1cnJlbnQNCj5j b21wdXRhdGlvbiBtZWFucyB0aGF0IHRoZSBoZWFkLWVuZCBzdWJtaXRzIHRoZSBjb21wdXRhdGlv biByZXF1ZXN0DQo+Zm9yIGJvdGggdHdvIGRpcmVjdGlvbmFsIExTUHMgY29uY3VycmVudGx5LiAg QXMgdG8gdGhlIHN1Y2Nlc3NpdmUNCj5jb21wdXRhdGlvbiwgdGhlIGhlYWQtZW5kIGFuZCB0aGUg dGFpbC1lbmQgc2VuZCB0aGUgZm9yd2FyZCBMU1AgYW5kDQo+YmFja3dhcmQgTFNQIGNvbXB1dGF0 aW9uIHJlcXVlc3RzIHNlcGFyYXRlbHkuDQo+DQo+V2UgaGF2ZSBleHRlbmRlZCBQQ0VQIHByb3Rv Y29sIHRvIHN1cHBvcnQgdGhlIENvbmN1cnJlbnQgY29tcHV0YXRpb24gZm9yDQo+U2luZ2xlIFNp ZGVkIFByb3Zpc2lvbmluZyBtb2RlbC4NCj5Db25jdXJyZW50IGNvbXB1dGF0aW9uIGNhbiBlbnN1 cmUgdGhhdCB0aGUgcGF0aHMgZm9yIHRoZSBhc3NvY2lhdGVkDQo+YmlkaXJlY3Rpb25hbA0KPkxT UCBpcyBvcHRpbWFsLCBhcyBkZXNjcmliZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTU1Ny4NCj5JbiB0aGlzIGRyYWZ0o6wgYW4gQS1iaXQgaXMgYWRkZWQgdG8gdGhlIGZsYWcg Yml0cyBvZiB0aGUgUlAgb2JqZWN0IHRvDQo+aW5kaWNhdGUgdGhlIHJlcXVlc3QgaXMgYWJvdXQg YW4gYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCBvciBub3QuDQo+ZnV0aGVybW9yZaOsUkVW RVJTRV9MU1Agb2JqZWN0IGlzIGFkZGVkIGluIGEgUENSZXEgbWVzc2FnZSB0byBzcGVjaWZ5DQo+ dGhlIGluZm9ybWF0aW9uIG9mIHRoZSByZXZlcnNlIExTUKGjDQo+DQo+DQo+UGxlYXNlIHByb3Zp ZGUgY29tbWVudHMgYW5kIGZlZWRiYWNrLg0KPg0KPlRoYW5rcw0KPldlbmp1YW4NCj4NCg0KDQoN Cg== --=_alternative 00291E6648257938_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5IaSBKYW4sPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciB2YWx1YWJsZSBjb21t ZW50cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkg YW0gZ2xhZCB3ZSBoYXZlIHJlYWNoZWQgdGhlIGFncmVlbWVudCwNCnRoZSBBc3NvY2lhdGlvbiBv YmplY3Qgd2lsbCBiZSBpbnRyb2R1Y2VkIHRvIFBDRVAsIHdoaWNoIGNhbiBiZSB1c2VkIHRvDQpv cHRpbWl6aW5nIDwvZm9udD48Zm9udCBzaXplPTI+PHR0PnRoZSBhc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgbHNwPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5Gb3IgdGhlIERvdWJsZSBTaWRlZCBQcm92 aXNpb25pbmcgbW9kZWw8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ LA0KdGhlIFBDQyBzdWJtaXRzIHRoZSBQQ1JlcSBtZXNzYWdlIHdpdGggQXNzb2NpYXRpb24gb2Jq ZWN0LCB0aGUgc3RhdGVmdWwNClBDRSB3aWxsIGxvb2sgdXAgdGhlIHJldmVyc2UgbHNwIGluZGlj YXRlZCBieSB0aGUgQXNzb2NpYXRpb24gb2JqZWN0LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+SWYgdGhlIHJlcXVlc3Qgb2YgdGhlIHJldmVyc2UgbHNwIGRvZXMN Cm5vdCBhcnJpdmUsdGhlIFBDRSB3aWxsIGNvbXB1dGUgdGhlIHBhdGggY29uc2lkZXJpbmcgdGhl IHByZXNlbnQgbmV0d29yay4NCjwvZm9udD48Zm9udCBzaXplPTI+PHR0PldoZW4gdGhlIHNlY29u ZCByZXF1ZXN0IHdpdGggdGhlIHNhbWUgQXNzb2ljYXRpb24NCk9iamVjdCBhcnJpdmVzLCB0aGUg c3RhdGVmdWwgUENFIHdpbGwga25vdyB0aGUgdHdvIHJldmVyc2UgbHNwcyBmb3JtIHRoZQ0KYmlk aXJlY3Rpb25hbCBMU1AgYW5kIGNvbXB1dGUgdGhlIHR3byByZXZlcnNlIGxzcHMgYWdhaW4gdG8g Z2V0IHRoZSBvcHRpbWFsDQpwYXRoIGZvciB0aGUgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIGxz cC4gQWZ0ZXIgdGhlIHN1Y2Nlc3NmdWwgY29tcHV0YXRpb24sDQp0aGUgUENFIHJlc3BvbnNlcyB0 aGUgUENDIHdpdGggdGhlIFBDUmVwIG1lc3NhZ2UgYW5kIHVwZGF0ZXMgdGhlIHJldmVyc2UNCmxz cCB3aXRoIFBDVXBkIE1lc3NhZ2UuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD5JZiB0aGUgYmFja3dhcmQgcGF0aCBzZXR1cCBmYWlsLCB0aGUgdGFpbC1lbmQgbWF5DQpz ZW5kIHRoZSBQQ1JlcSBtZXNzYWdlIHRvIHRoZSBQQ0UgdG8gYXNrIGZvciBhIG5ldyBiYWNrd2Fy ZCBwYXRoLiBUaGUgdHdvDQpyZXZlcnNlIGxzcHMgd2lsbCBiZSBjb21wdXRlZCBhZ2FpbiBhbmQg Y3JlYXRlZCB1c2luZyBtYWtlLWJlZm9yZS1icmVhaw0KaW4gdGhlIHJlLXNpZ25hbGluZyBvcGVy YXRpb24sIHNlZSBzZWN0aW9uIDYuMiwgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Y3JhYmJlLXBjZS1zdGF0ZWZ1bC1wY2UtMDAuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBFeHRlbmRlZCBBc3NvY2lhdGlvbiBvYmplY3Qg aXMgZGVmaW5lZA0KaW4gdGhlIGRyYWZ0PC9mb250Pjxmb250IHNpemU9Mj4gPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wMC48L2ZvbnQ+PGZvbnQgc2l6ZT0yPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpBIG5ldyBBc3NvY2lhdGlvbiBUeXBl ICZxdW90O2Fzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AmcXVvdDsgaXMgaW50cm9kdWNlZA0K aW4gYW5vdGhlciBkcmFmdCwgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j Y2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDIuPC9mb250Pjxmb250IHNp emU9Mj4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ SSB0aGluayBpdCBpcyBtb3JlIGFwcGxpY2FibGUgdGhhdCB0aGUNCkFzc29jaWF0aW9uIG9iamVj dCBpcyBpbnRyb2R1Y2VkIGluIHRoaXMgZHJhZnQuIEJlY2F1c2UgdGhlIEFzc29jaWF0aW9uDQpv YmplY3QgaXMgdXNlZCB0byBiaW5kIHRoZSBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQgbHNwcywg YW5kIEkgZG9uJ3Qgc2VlDQp0aGUgb3RoZXIgc2NlbmFyaW8gYXNraW5nIGZvciB0aGUgQXNzb2Np YXRpb24gb2JqZWN0LiBXaGF0IGRvIHlvdSB0aGluaz88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yPjx0dD5Zb3VyIGNvbW1lbnRzIG9uIHRoaXMgYXJlIG1vc3Qgd2VsY29tZS48YnI+DQo8 YnI+DQpUaGFua3M8YnI+DQo8YnI+DQpXZW5qdWFuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SmFuIE1lZHZlZCAmbHQ7am1l ZHZlZEBqdW5pcGVyLm5ldCZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MjAxMS0xMC0yNyAxMzozOTwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtoZS53ZW5qdWFuMUB6dGUuY29tLmNu JnF1b3Q7ICZsdDtoZS53ZW5qdWFuMUB6dGUuY29tLmNuJmd0OywNCiZxdW90O3BjZUBpZXRmLm9y ZyZxdW90OyAmbHQ7cGNlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtQY2VdIFtQQ0VdIFJlcXVlc3QgY29t bWVudHMgb24NCmRyYWZ0LWhlLXBjZS1wY2VwLWFzc29jaWF0ZWQtbHNwLWV4dGVuc2lvbnMtMDA8 L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRk PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0 PkhpIFdlbmp1YW4sPGJyPg0KPGJyPg0KUGxlYXNlIHNlZSBpbmxpbmUuPGJyPg0KPGJyPg0KPGJy Pg0KVGhhbmtzLDxicj4NCkphbjxicj4NCjxicj4NCk9uIDEwLzI1LzExIDY6NTYgUE0sICZxdW90 O2hlLndlbmp1YW4xQHp0ZS5jb20uY24mcXVvdDsgJmx0O2hlLndlbmp1YW4xQHp0ZS5jb20uY24m Z3Q7PGJyPg0Kd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDtIaSBKYW4sPGJy Pg0KJmd0Ozxicj4NCiZndDtUaGFua3MgZm9yIHRoZSBjb21tZW50cywgSSB0aGluayBpdDxicj4N CiZndDtpcyByZWFsbHkgdmFsdWFibGUuPGJyPg0KJmd0Ozxicj4NCiZndDtGb3IgdGhlIERvdWJs ZSBTaWRlZCBQcm92aXNpb25pbmcgbW9kZWwsPGJyPg0KJmd0O2FsdGhvdWdoIHRoZSBoZWFkLWVu ZCBhbmQgdGhlIHRhaWwtZW5kIG9yIE5NUyBzdWJtaXQgdGhlIFBDUmVxIG1lc3NhZ2U8YnI+DQom Z3Q7c2VwYXJhdGVseSwgdGhlIHR3byByZXZlcnNlIGxzcHMgY2FuIGJlIGFzc29jaWF0ZWQ8YnI+ DQomZ3Q7dG8gYmUgb3B0aW1hbCBpZiBzdGF0ZWZ1bCBQQ0UgaXMgdXNlZC48YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDtUaGUgZHJhZnQgJm5ic3A7aHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1jcmFiYmUtcGNlLXN0YXRlZnVsLXBjZS88YnI+DQomZ3Q7anVzdCBzYXkg dGhhdCBhbGwgb3RoZXIgTFNQJ3MgY29uZGl0aW9uIGNhbiBiZSBjb25zaWRlcmVkIGlmIGEgbmV3 DQpyZXF1ZXN0PGJyPg0KJmd0O2lzIHN1Ym1pdHRlZCwgaG93ZXZlciwgd2Ugd2FudCB0byBjb25z aWRlciB0aGUgdHdvIHJlbGF0ZWQgTFNQcyB0b2dldGhlcjxicj4NCiZndDsoZXNwZWNpYWxseSB0 aGUgVEUgcGFyYW1ldGVycyksIGF0IHRoZSBzYW1lIHRpbWUgYWxsIHRoZSBvdGhlciBMU1Anczxi cj4NCiZndDtjb25kaXRpb248YnI+DQomZ3Q7c2hvdWxkIGJlIHRha2VuIGludG8gY29uc2lkZXJh dGlvbi48YnI+DQo8YnI+DQpUaGUgJnF1b3Q7YWxsIExTUHMmcXVvdDsgc2V0IGFsc28gY292ZXJz IHRoZSAmcXVvdDt0d28gcmVsYXRlZCBMU1BzJnF1b3Q7DQpzZXQuIElmIGEgUENFIGtub3dzPGJy Pg0KYWJvdXQgJm5ic3A7YWxsIExTUHMgaW4gdGhlIG5ldHdvcmssIGl0IG11c3QgYWJvdXQgdGhl IGZvcndhcmQgYW5kIGJhY2t3YXJkPGJyPg0KTFNQcyBhcyB3ZWxsLCBhbmQgY2FuIGNvbnNpZGVy IHRoZW0gdG9nZXRoZXIuPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDtIb3cgYWJvdXQgaW50cm9k dWNpbmcgdGhlIEFzc29jaWF0aW9uIE9iamVjdCBpbiB0aGlzIHNjZW5hcmlvPyBXaGVuDQp0aGU8 YnI+DQomZ3Q7UENDIHN1Ym1pdHMgdGhlIHBhdGggY29tcHV0YXRpb24gcmVxdWVzdCBmb3IgdGhl IGZvcndhcmQgbHNwIG9yIHRoZTxicj4NCiZndDtiYWNrd2FyZCBsc3AsIHRoZSBQQ1JlcSBtZXNz YWdlIG1heSBjYXJyeSBhc3NvY2lhdGlvbiBvYmplY3QgdG8gaW5kaWNhdGU8YnI+DQomZ3Q7dGhh dCBhIHJldmVyc2UgbHNwIGlzIG5lZWRlZCB0byBiZSBwcm92aWRlZCBsYXRlci4gV2hlbjxicj4N CiZndDt0aGUgc2Vjb25kIHJlcXVlc3Qgd2l0aCB0aGUgc2FtZSBBc3NvaWNhdGlvbiBPYmplY3Qg YXJyaXZlcywgdGhlIHN0YXRlZnVsPGJyPg0KJmd0O1BDRSBjYW4gY29tcHV0ZSB0aGUgdHdvIHJl dmVyc2UgbHNwcyBhZ2FpbiwgYW5kIGdldCB0aGUgb3B0aW1hbCBwYXRoDQpmb3I8YnI+DQomZ3Q7 dGhlIGFzc29jaWF0ZWQgYmktZGlyZWN0aW9uYWw8YnI+DQomZ3Q7bHNwLiBBZnRlciB0aGUgc3Vj Y2Vzc2Z1bCBjb21wdXRhdGlvbiwgdGhlIFBDRSByZXNwb25zZXMgdGhlIFBDQyB3aXRoDQp0aGU8 YnI+DQomZ3Q7UENSZXAgbWVzc2FnZSBhbmQgdXBkYXRlcyB0aGUgcmV2ZXJzZSBsc3Agd2l0aCBQ Q1VwZCBNZXNzYWdlLjxicj4NCjxicj4NClRoZSBBc3NvY2lhdGlvbiBPYmplY3Qgb24gYSBQQ1Jl cSBtZXNzYWdlIHdvdWxkIGludHJvZHVjZSBpbXBsaWNpdCBzdGF0ZTxicj4NCmludG8gdGhlIFBD RS4gRXJyb3IgY29uZGl0aW9ucyB3b3VsZCBiZSBkaWZmaWN1bHQgdG8gaGFuZGxlLiBGb3IgZXhh bXBsZSw8YnI+DQp3aGF0IHdvdWxkIHRoZSBQQ0UgZG8gd2l0aCB0aGUgQXNzb2NpYXRpb24gT2Jq ZWN0IGlmIHRoZSBzZWNvbmQgcmVxdWVzdDxicj4NCihmcm9tIHRoZSB0YWlsLWVuZCkgbmV2ZXIg Y29tZXM/IFRoZSBvYmplY3Qgd291bGQgaGF2ZSB0byBiZSBmbHVzaGVkLCBidXQ8YnI+DQp3aGVu PyBPciwgY2FuIHRoZSBQQ0UgZmx1c2ggdGhlIEFzc29jaWF0aW9uIE9iamVjdCBhZnRlciB0aGUg Y29tcHV0YXRpb248YnI+DQpvZiB0aGUgYmFja3dhcmQgcGF0aCBpcyBkb25lPyBJdCBwcm9iYWJs eSBjYW4ndCAtIHRoZSBiYWNrd2FyZCBwYXRoIHNldA0KdXA8YnI+DQptYXkgZmFpbCwgYW5kIHRo ZSB0YWlsLWVuZCBQQ0MgbWF5IGNvbWUgYmFjayB0byB0aGUgUENFIHRvIGFzayBmb3IgYSBuZXc8 YnI+DQpiYWNrd2FyZCBwYXRoLjxicj4NCjxicj4NCkFub3RoZXIgaXNzdWUgaXMgdGhhdCB0aGUg Y29tcHV0YXRpb24gb2YgZm9yd2FyZCBhbmQgYmFja3dhcmQgTFNQcyBjYW4NCm5vdDxicj4NCmJl IHN5bmNocm9uaXplZCAtIGFzIHlvdSBwb2ludGVkIG91dCwgdGhleSBzaG91bGQgYmUgY29tcHV0 ZWQgdG9nZXRoZXIuPGJyPg0KPGJyPg0KVGhhdCBzYWlkLCBJIHRoaW5rIHdlIHdpbGwgbmVlZCB0 aGUgQXNzb2NpYXRpb24gT2JqZWN0LCBidXQgd2Ugd2lsbCBuZWVkPGJyPg0KaXQgd2l0aCB0aGUg c3RhdGVmdWwgUENFIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluPGJyPg0KZHJhZnQtY3JhYmJlLXBj ZS1zdGF0ZWZ1bC1wY2UuIEJvdGggdGhlIGhlYWQtZW5kIGFuZCB0aGUgdGFpbC1lbmQgJm5ic3A7 UENDczxicj4NCnN5bmMgdXAgYW5kIGRlbGVnYXRlIHRoZWlyIHJlc3BlY3RpdmUgTFNQcyAoZm9y d2FyZCBhbmQgYmFja3dhcmQpIHRvIHRoZTxicj4NClBDRSB1c2luZyBQQ1JwdCBtZXNzYWdlcy4g VGhlIFBDRSB3aWxsIGNvbXB1dGUgdGhlIGZvcndhcmQgYW5kIGJhY2t3YXJkPGJyPg0KcGF0aHMg YW5kIHRoZW4sIHVzaW5nIFBDVXBkIG1lc3NhZ2VzLCB3aWxsIHRyaWdnZXIgdGhlIGhlYWQtZW5k IHRvIHNldHVwPGJyPg0KdGhlIGZvcndhcmQgTFNQIGFuZCB0aGUgYmFja2VuZCB0byB0cmlnZ2Vy IHRoZSBzZXR1cCBvZiB0aGUgYmFja3dhcmQgTFNQLjxicj4NClRoZSBQQ0Ugd2lsbCBjb29yZGlu YXRlIExTUCBzZXR1cCBpbiB0aGUgaGVhZC1lbmQgYW5kIHRoZSB0YWlsLWVuZC4gV2U8YnI+DQp3 aWxsIG5lZWQgdGhlIEFzc29jaWF0aW9uIE9iamVjdCBkdXJpbmcgc3luY2hyb25pemF0aW9uIHRv IHRlbGwgdGhlIFBDRTxicj4NCnRoYXQgdGhlIGZvcndhcmQgTFNQIGFuZCB0aGUgYmFja3dhcmQg TFNQIGFyZSBhIHBhcnQgb2YgdGhlIHNhbWU8YnI+DQpiaS1kaXJlY3Rpb25hbCBMU1AuPGJyPg0K PGJyPg0KJmd0Ozxicj4NCiZndDtZb3VyIGNvbW1lbnRzIG9uIHRoaXMgYXJlIG1vc3Qgd2VsY29t ZS48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoYW5rczxicj4NCiZndDs8YnI+DQomZ3Q7V2VuanVhbjxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7SmFuIE1lZHZl ZCAmbHQ7am1lZHZlZEBqdW5pcGVyLm5ldCZndDsyMDExLTEwLTI1IDAyOjIxPGJyPg0KJmd0O8rV vP7Iyzxicj4NCiZndDsmcXVvdDtoZS53ZW5qdWFuMUB6dGUuY29tLmNuJnF1b3Q7ICZsdDtoZS53 ZW5qdWFuMUB6dGUuY29tLmNuJmd0Oyw8YnI+DQomZ3Q7JnF1b3Q7cGNlQGlldGYub3JnJnF1b3Q7 ICZsdDtwY2VAaWV0Zi5vcmcmZ3Q7s63LzTxicj4NCiZndDvW98ziPGJyPg0KJmd0O1JlOiBbUGNl XSBbUENFXSBSZXF1ZXN0IGNvbW1lbnRzIG9uPGJyPg0KJmd0O2RyYWZ0LWhlLXBjZS1wY2VwLWFz c29jaWF0ZWQtbHNwLWV4dGVuc2lvbnMtMDA8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0O0hpIFdlbmp1YW4sPGJyPg0KJmd0Ozxicj4NCiZndDtEb3VibGUg U2lkZWQgUHJvdmlzaW9uaW5nIChTZWN0aW9uIDMuMikgd2lsbCByZXF1aXJlIExTUCBzZXR1cDxi cj4NCiZndDtjb29yZGluYXRpb248YnI+DQomZ3Q7YmV0d2VlbiB0aGUgaGVhZC1lbmQgYW5kIHRo ZSB0YWlsLWVuZCwgd2hpY2ggd2lsbCBuZWVkIHRvIGJlIHByb3ZpZGVkPGJyPg0KJmd0O2VpdGhl cjxicj4NCiZndDtieSBhIG1hbmFnZW1lbnQgc3lzdGVtIG9yIGEgc3RhdGVmdWwgUENFIHByb3Bv c2VkIGluPGJyPg0KJmd0O2RyYWZ0LWNyYWJiZS1wY2Utc3RhdGVmdWwtcGNlLTAwPGJyPg0KJmd0 OyhodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNyYWJiZS1wY2Utc3RhdGVm dWwtcGNlLykuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O1RoYW5rcyw8 YnI+DQomZ3Q7SmFuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7T24gMTAvMjQvMTEgMjoz NiBBTSw8YnI+DQomZ3Q7JnF1b3Q7aGUud2VuanVhbjFAenRlLmNvbS5jbiZsdDttYWlsdG86aGUu d2VuanVhbjFAenRlLmNvbS5jbiZndDsmcXVvdDs8YnI+DQomZ3Q7Jmx0O2hlLndlbmp1YW4xQHp0 ZS5jb20uY24mbHQ7bWFpbHRvOmhlLndlbmp1YW4xQHp0ZS5jb20uY24mZ3Q7Jmd0Ow0Kd3JvdGU6 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7SGkgYWxsLDxicj4NCiZndDtXZSd2ZSBzdWJt aXR0ZWQgYSBkcmFmdCBmb3IgdGhlIGV4dGVuc2lvbnMgb2YgUENFUCB0byBzdXBwb3J0IGFzc29j aWF0ZWQ8YnI+DQomZ3Q7YmlkaXJlY3Rpb25hbCBsc3AsIGJlbG93IGlzIHRoZSBsaW5rOjxicj4N CiZndDtodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oZS1wY2UtcGNlcC1hc3NvY2lh dGVkLWxzcC1leHRlbnNpb25zLTAwLjxicj4NCiZndDs8YnI+DQomZ3Q7VGhlIE1QTFMtVFAgcmVx dWlyZW1lbnRzIFtSRkM1NjU0XSBhbmQgY29udHJvbCBwbGFuZSBmcmFtZXdvcms8YnI+DQomZ3Q7 ZG9jdW1lbnRzW1JGQzYzNzNdZGVzY3JpYmU8YnI+DQomZ3Q7dGhhdCBNUExTLVRQIE1VU1Q8YnI+ DQomZ3Q7c3VwcG9ydCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcG9pbnQtdG8tcG9pbnQgTFNQ cy4gJm5ic3A7UGF0aCBDb21wdXRhdGlvbjxicj4NCiZndDtFbGVtZW50IChQQ0UpLCBzZWUgW1JG QzQ2NTVdLCBtYXkgYmUgdXNlZCBmb3IgcGF0aDxicj4NCiZndDtjb21wdXRhdGlvbiBvZiBhIEdN UExTIExTUCxhbmQgY29uc2VxdWVudGx5IGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbDxicj4N CiZndDtMU1AsIGFjcm9zcyBkb21haW5zIGFuZCBpbiBhIHNpbmdsZSBkb21haW4uPGJyPg0KJmd0 Ozxicj4NCiZndDtBcyBkZXNjcmliZWQgaW4gPGJyPg0KJmd0O2h0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtPGJy Pg0KJmd0O2xzcC0wMiw8YnI+DQomZ3Q7dGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1Ag Y2FuIGJlIGRlcGxveWVkIGJ5IFNpbmdsZSBTaWRlZDxicj4NCiZndDtQcm92aXNpb25pbmc8YnI+ DQomZ3Q7bW9kZWwgb3IgRG91YmxlIFNpZGVkIFByb3Zpc2lvbmluZzxicj4NCiZndDttb2RlbC5G b3IgdGhlIGRvdWJsZSBzaWRlZCBwcm92aXNpb25pbmcsIHRoZSBwYXRoIGNvbXB1dGF0aW9uIG9m IHRoZTxicj4NCiZndDtmb3J3YXJkPGJyPg0KJmd0O2FuZCB0aGUgYmFja3dhcmQgTFNQPGJyPg0K Jmd0O2FyZSBzdWJtaXR0ZWQgYnkgdGhlIGhlYWQtZW5kIGFuZCB0aGUgdGFpbC1lbmQgc2VwYXJh dGVseS5Gb3IgdGhlIHNpbmdsZTxicj4NCiZndDtzaWRlZCBwcm92aXNpb25pbmcsIHRoZSBwYXRo IGNvbXB1dGF0aW9uY2FuIGJlPGJyPg0KJmd0O3JlYWxpemVkIGJ5IHRoZSBjb25jdXJyZW50IG9y IHN1Y2Nlc3NpdmUgY29tcHV0YXRpb24uICZuYnNwO1RoZSBjb25jdXJyZW50PGJyPg0KJmd0O2Nv bXB1dGF0aW9uIG1lYW5zIHRoYXQgdGhlIGhlYWQtZW5kIHN1Ym1pdHMgdGhlIGNvbXB1dGF0aW9u IHJlcXVlc3Q8YnI+DQomZ3Q7Zm9yIGJvdGggdHdvIGRpcmVjdGlvbmFsIExTUHMgY29uY3VycmVu dGx5LiAmbmJzcDtBcyB0byB0aGUgc3VjY2Vzc2l2ZTxicj4NCiZndDtjb21wdXRhdGlvbiwgdGhl IGhlYWQtZW5kIGFuZCB0aGUgdGFpbC1lbmQgc2VuZCB0aGUgZm9yd2FyZCBMU1AgYW5kPGJyPg0K Jmd0O2JhY2t3YXJkIExTUCBjb21wdXRhdGlvbiByZXF1ZXN0cyBzZXBhcmF0ZWx5Ljxicj4NCiZn dDs8YnI+DQomZ3Q7V2UgaGF2ZSBleHRlbmRlZCBQQ0VQIHByb3RvY29sIHRvIHN1cHBvcnQgdGhl IENvbmN1cnJlbnQgY29tcHV0YXRpb24NCmZvcjxicj4NCiZndDtTaW5nbGUgU2lkZWQgUHJvdmlz aW9uaW5nIG1vZGVsLjxicj4NCiZndDtDb25jdXJyZW50IGNvbXB1dGF0aW9uIGNhbiBlbnN1cmUg dGhhdCB0aGUgcGF0aHMgZm9yIHRoZSBhc3NvY2lhdGVkPGJyPg0KJmd0O2JpZGlyZWN0aW9uYWw8 YnI+DQomZ3Q7TFNQIGlzIG9wdGltYWwsIGFzIGRlc2NyaWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1NTU3Ljxicj4NCiZndDtJbiB0aGlzIGRyYWZ0o6wgYW4gQS1iaXQgaXMg YWRkZWQgdG8gdGhlIGZsYWcgYml0cyBvZiB0aGUgUlAgb2JqZWN0DQp0bzxicj4NCiZndDtpbmRp Y2F0ZSB0aGUgcmVxdWVzdCBpcyBhYm91dCBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQ IG9yIG5vdC48YnI+DQomZ3Q7ZnV0aGVybW9yZaOsUkVWRVJTRV9MU1Agb2JqZWN0IGlzIGFkZGVk IGluIGEgUENSZXEgbWVzc2FnZSB0byBzcGVjaWZ5PGJyPg0KJmd0O3RoZSBpbmZvcm1hdGlvbiBv ZiB0aGUgcmV2ZXJzZSBMU1Chozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O1BsZWFzZSBw cm92aWRlIGNvbW1lbnRzIGFuZCBmZWVkYmFjay48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoYW5rczxi cj4NCiZndDtXZW5qdWFuPGJyPg0KJmd0Ozxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K --=_alternative 00291E6648257938_=-- From leeyoung@huawei.com Sun Oct 30 13:42:02 2011 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 E3E0F21F8B81 for ; Sun, 30 Oct 2011 13:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Rkl2vN6FwgKN for ; Sun, 30 Oct 2011 13:42:02 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1681721F8B9A for ; Sun, 30 Oct 2011 13:42:02 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTW009HSC5V8F@usaga04-in.huawei.com> for pce@ietf.org; Sun, 30 Oct 2011 15:41:56 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTW00FXRC5UH0@usaga04-in.huawei.com> for pce@ietf.org; Sun, 30 Oct 2011 15:41:55 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 30 Oct 2011 13:41:54 -0700 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Sun, 30 Oct 2011 13:41:44 -0700 Date: Sun, 30 Oct 2011 20:41:44 +0000 From: Leeyoung In-reply-to: X-Originating-IP: [10.47.136.17] To: "Margaria, Cyril (NSN - DE/Munich)" , =?iso-8859-1?Q?ext_Oscar_Gonz=E1lez_de_Dios?= , ext Ramon Casellas Message-id: <7AEB3D6833318045B4AE71C2C87E8E171818364E@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: New requirements for draft-lee-pce-wson-rwa-ext Thread-index: AcyUvlcHb06PqYOVR2epEBdcPB3tpwAu5YKgAHJls3A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "pce@ietf.org" , "draft-lee-pce-wson-rwa-ext@tools.ietf.org" Subject: Re: [Pce] New requirements for draft-lee-pce-wson-rwa-ext 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, 30 Oct 2011 20:42:03 -0000 Hi Oscar and Cyril, I think what Oscar brought up are legitimate requirements for RWA. I tend t= o agree with Cyril's suggestion on how to encode for the requirements.=20 Unless there is objection on these new requirements, I will update the PCE = Requirement for WSON RWA at the minimum and the PCEP Extension for RWA as w= ell if I meet the deadline tomorrow. Thanks. Young -----Original Message----- From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com]=20 Sent: Friday, October 28, 2011 9:12 AM To: ext Oscar Gonz=E1lez de Dios; ext Ramon Casellas; Leeyoung Cc: draft-lee-pce-wson-rwa-ext@tools.ietf.org Subject: RE: New requirements for draft-lee-pce-wson-rwa-ext Hi Oscar, editors. I thinks there is two aspects :=20 - force continuous wavelength : this can be done in the WA object:=20 * C (Continuity - 1 bits): C bit is used to indicate that the wavelength assignment MUST return a continuous lambda in the ERO. This is useful in case of 3R were wavelength conversion MAY happen. This Flag forbid wavelength conversion. The same lambda on working and protecting max be considered as a SVEC exten= sion: SVEC now has the Link, Node, SRLG diverse flags.=20 It could be extended to Link, Node, Label sharing flags :=20 When set this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST have at least one Link, Node or Label in common.= =20 The PCE MUST try to maximize the number of common link, node and labels Would those two mechanism fulfill your req.? Best regards / Mit freundlichen Gr=FC=DFen Cyril Margaria > -----Original Message----- > From: ext Oscar Gonz=E1lez de Dios [mailto:ogondio@tid.es] > Sent: Thursday, October 27, 2011 5:45 PM > To: Margaria, Cyril (NSN - DE/Munich); ext Ramon Casellas; Leeyoung > Cc: draft-lee-pce-wson-rwa-ext@tools.ietf.org > Subject: New requirements for draft-lee-pce-wson-rwa-ext >=20 > Hi all, >=20 > I have some new requirements for the draft, that I would like > them to be included if possible: >=20 > - When requesting a 1+1 connection (e.g. link disjoint paths), > you should be able to request that both paths use the same wavelength. > This is extremely useful in the case of protection with single > transponder. Now, there is no way to specify such constraint. >=20 > - When performing 3R, you may change or not wavelength. You > should be able to specify such policy per request. >=20 > Best Regards, >=20 > =D3Scar >=20 >=20 >=20 > Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3= nico > en el enlace situado m=E1s 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 From leeyoung@huawei.com Sun Oct 30 13:51:08 2011 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 EC3BE21F8BA6 for ; Sun, 30 Oct 2011 13:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 TvSzSapcio8f for ; Sun, 30 Oct 2011 13:51:07 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id E0BCB21F8B86 for ; Sun, 30 Oct 2011 13:51:06 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTW009PKCL28F@usaga04-in.huawei.com> for pce@ietf.org; Sun, 30 Oct 2011 15:51:02 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTW00F92CL2H0@usaga04-in.huawei.com> for pce@ietf.org; Sun, 30 Oct 2011 15:51:02 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 30 Oct 2011 13:51:01 -0700 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Sun, 30 Oct 2011 13:50:54 -0700 Date: Sun, 30 Oct 2011 20:50:52 +0000 From: Leeyoung In-reply-to: <4EA91FBD.9020001@cttc.es> X-Originating-IP: [10.47.136.17] To: Ramon Casellas , "Margaria, Cyril (NSN - DE/Munich)" Message-id: <7AEB3D6833318045B4AE71C2C87E8E1718183685@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: Some proposal for the next revision of draft-lee-pce-wson-rwa-ext Thread-index: AcyULHddQ2l1gBE9S0SmCLWryZlL3wAlk+iAAKCb9VA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4EA91FBD.9020001@cttc.es> Cc: "pce@ietf.org" , "draft-lee-pce-wson-rwa-ext@tools.ietf.org" Subject: Re: [Pce] Some proposal for the next revision of draft-lee-pce-wson-rwa-ext 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, 30 Oct 2011 20:51:08 -0000 Hi Ramon, Thanks for your suggestion. I concur with your clarifying texts to keep the= consistency between this PCEP extension and the encoding draft.=20 Regards, Young -----Original Message----- From: Ramon Casellas [mailto:ramon.casellas@cttc.es]=20 Sent: Thursday, October 27, 2011 4:09 AM To: Margaria, Cyril (NSN - DE/Munich) Cc: draft-lee-pce-wson-rwa-ext@tools.ietf.org Subject: Re: Some proposal for the next revision of draft-lee-pce-wson-rwa-= ext Dear co-authors, While reviewing the current draft, I noticed the following: currently,=20 FEC / modulation restrictions are proposed as one TLV per modulation /=20 FEC as endpoint restrictions However, in draft-ietf-ccamp-rwa-wson-encode-12 the actual TLV is a "fec=20 list" or a "modulation list" I believe that having cases where we have a TLV as one element and cases=20 where we have TLV as a list is error prone, and in order to unify I=20 would like to align draft-lee-pce-wson-rwa-ext to=20 draft-ietf-ccamp-rwa-wson-encode-12 especially since the restriction TLVs can appear more than once --> add=20 them as a list. A first proposed new wording would be as follows: ::=3D =20 [...] Where signal-compatibility-restriction ::=3D=20 | with e.g. Value :=3D A list of FEC type Fields One issue remains. since draft-lee...rwa-02 only used one FEC element=20 field / MODULATION element filed per TLV, it could use the element=20 length field as a reserved field and add a flag X to exclude or include A way to solve this is to allow to=20 appear twice. One for inclusion and one for exclusion., or to define 2 TLVs ::=3D =20 [...] Where signal-compatibility-restriction ::=3D=20 =20 My main argument for this is to align fully with=20 draft-ietf-ccamp-rwa-wson-encode-12 Finally, I would like to consider the use case where the LSC LSP crosses=20 an O/E/O. Do we need control on the modulation/FEC at that point? Comments? R. --=20 Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 From leeyoung@huawei.com Sun Oct 30 13:58:32 2011 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 6AEC721F8B90 for ; Sun, 30 Oct 2011 13:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 gKx-dJCTeysa for ; Sun, 30 Oct 2011 13:58:31 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id E306B21F84DA for ; Sun, 30 Oct 2011 13:58:31 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTW009UICXJ8F@usaga04-in.huawei.com> for pce@ietf.org; Sun, 30 Oct 2011 15:58:31 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTW00FHRCXIH0@usaga04-in.huawei.com> for pce@ietf.org; Sun, 30 Oct 2011 15:58:31 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 30 Oct 2011 13:58:30 -0700 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Sun, 30 Oct 2011 13:58:24 -0700 Date: Sun, 30 Oct 2011 20:58:22 +0000 From: Leeyoung In-reply-to: X-Originating-IP: [10.47.139.243] To: "Margaria, Cyril (NSN - DE/Munich)" , "draft-lee-pce-wson-rwa-ext@tools.ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E17181836BA@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: Some proposal for the next revision of draft-lee-pce-wson-rwa-ext Thread-index: AcyULHddQ2l1gBE9S0SmCLWryZlL3wDGaqUA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "pce@ietf.org" Subject: Re: [Pce] Some proposal for the next revision of draft-lee-pce-wson-rwa-ext 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, 30 Oct 2011 20:58:32 -0000 Hi Cyril, Objective functions for GCO contexts and others are definitely an optional = requirement for PCEP extension for RWA. In the past, the PCE WG had one obj= ective function draft separate from PCEP draft. So my inclination is to ask= the PCE WG if this requirement should be a part of this draft or to separa= te this work into a new item. I will include this OF requirement in the rev= ision, which will shortly be published.=20 Thanks, Young -----Original Message----- From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com]=20 Sent: Wednesday, October 26, 2011 5:13 PM To: draft-lee-pce-wson-rwa-ext@tools.ietf.org Subject: Some proposal for the next revision of draft-lee-pce-wson-rwa-ext Hi,=20 Please find attached a proposal on the outline and text regarding a RWA asp= ect we did not consider up to now : Spectrum optimization=20 Flexigrid discussion brought this in the light but this is a fundamental DW= DM RWA aspect, which can be best addressed IMHO by Objective functions, Wh= ich will fit also nicely into the GCO context. I thinks it a better solutio= n to draft-zhaoyl-pce-flexi-grid-pcep-ex. I think that at least we should have some indication that standard DWDM has= already two spectrum and the assignment should already be considered, Simp= ly by taking the case of a 100Ghz grid : the spectrum can already overlap w= ith 50Gh (and smaller grids) . =20 Your comments/refinement are welcomed. <> Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria Nokia Siemens Networks GmbH & Co. KG NWS DWDM RD St.Martin-Str. 76 D-81541 M=FCnchen Germany mailto:cyril.margaria@nsn.com Phone: +49-89-5159-16934 Fax: +49-89-5159-44-16934 ---------------------------------------------------------------- Nokia Siemens Networks GmbH & Co. KG Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 WEEE-Reg.-Nr.: DE 52984304 Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens Net= works Management GmbH Gesch=E4ftsleitung / Board of Directors: Dr. Hermann = Rodler, Lydia Sommer, Olaf Horsthemke Vorsitzender des Aufsichtsrats / Chai= rman of supervisory board: Herbert Merz Sitz der Gesellschaft: M=FCnchen / = Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416=20 From internet-drafts@ietf.org Sun Oct 30 15:32:26 2011 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 AEB1521F8BDE; Sun, 30 Oct 2011 15:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Fq-rKhFAK3wy; Sun, 30 Oct 2011 15:32:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5209421F8BD5; Sun, 30 Oct 2011 15:32:26 -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: 3.62 Message-ID: <20111030223226.22527.13748.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 15:32:26 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-06.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, 30 Oct 2011 22:32:26 -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 Grou= p of the IETF. Title : PCEP Requirements for WSON Routing and Wavelength Assign= ment Author(s) : Young Lee Greg Bernstein Jonas Martensson Tomonori Takeda Takehiro Tsuritani Oscar Gonzalez de Dios Filename : draft-ietf-pce-wson-routing-wavelength-06.txt Pages : 13 Date : 2011-10-30 This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of 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. Requirements for Optical impairments will be addressed in a separate document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-wson-routing-wavelength-= 06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-wson-routing-wavelength-0= 6.txt From leeyoung@huawei.com Sun Oct 30 15:37:32 2011 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 2BDA721F8BEC for ; Sun, 30 Oct 2011 15:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 8Hi4PS7ozY57 for ; Sun, 30 Oct 2011 15:37:31 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9584421F8BC5 for ; Sun, 30 Oct 2011 15:37:31 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTW00JWCHIBMG@usaga02-in.huawei.com> for pce@ietf.org; Sun, 30 Oct 2011 17:37:24 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LTW00D8BHIBAM@usaga02-in.huawei.com> for pce@ietf.org; Sun, 30 Oct 2011 17:37:23 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 30 Oct 2011 15:37:23 -0700 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Sun, 30 Oct 2011 15:37:17 -0700 Date: Sun, 30 Oct 2011 22:37:16 +0000 From: Leeyoung In-reply-to: <20111030223226.22527.13748.idtracker@ietfa.amsl.com> X-Originating-IP: [10.47.139.31] To: "pce@ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E171818372C@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-06.txt Thread-index: AQHMl1PTSBQuGYEjfEK+/zG8K+gJqZWVeSmw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20111030223226.22527.13748.idtracker@ietfa.amsl.com> Subject: Re: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-06.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, 30 Oct 2011 22:37:32 -0000 Hi, The revision added a couple of new requirements on Wavelength Policy area, both of which was raised by Oscar. In Section 2.1.5. we have added these new requirements: - The PCReq Message SHOULD be able to request, when requesting a 1+1 connection (e.g. link disjoint paths), that both paths use the same wavelength. Note that this is extremely useful in the case of protection with single transponder. Now, there is no way to specify such constraint. - The PCReq Message SHOULD be able to request, when performing 3R, that wavelength may change or not. Oscar was also added to a new contributor of this draft. Please send your comment if any to the mailing list on these changes. Best Regards, Young -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Sunday, October 30, 2011 5:32 PM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-06.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 : PCEP Requirements for WSON Routing and Wavelength Assignment Author(s) : Young Lee Greg Bernstein Jonas Martensson Tomonori Takeda Takehiro Tsuritani Oscar Gonzalez de Dios Filename : draft-ietf-pce-wson-routing-wavelength-06.txt Pages : 13 Date : 2011-10-30 This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of 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. Requirements for Optical impairments will be addressed in a separate document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-wson-routing-wavelength-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-wson-routing-wavelength-06.txt _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From internet-drafts@ietf.org Sun Oct 30 22:57:39 2011 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 7254321F8C9A; Sun, 30 Oct 2011 22:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 c8n6e8StvP2h; Sun, 30 Oct 2011 22:57:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D6321F87D3; Sun, 30 Oct 2011 22:57:38 -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: 3.62 Message-ID: <20111031055738.13646.35966.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 22:57:38 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-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, 31 Oct 2011 05:57:39 -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 Grou= p 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 Tarek Saad Siva Sivabalan Daniel King Ramon Casellas Filename : draft-ietf-pce-pcep-inter-domain-p2mp-procedures-01.txt Pages : 26 Date : 2011-10-30 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 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 the procedures and extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of inter-domain paths for P2MP TE LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-inter-domain-p2mp-p= rocedures-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-pcep-inter-domain-p2mp-pr= ocedures-01.txt From jmedved@juniper.net Mon Oct 31 00:02:52 2011 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 5A01A11E80B4 for ; Mon, 31 Oct 2011 00:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 nuxvuCTad6jj for ; Mon, 31 Oct 2011 00:02:51 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9A27D11E808C for ; Mon, 31 Oct 2011 00:02:51 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Mon, 31 Oct 2011 00:02:51 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 31 Oct 2011 00:01:41 -0700 From: Jan Medved To: "pce@ietf.org" Date: Mon, 31 Oct 2011 00:01:40 -0700 Thread-Topic: New Version Notification for draft-crabbe-pce-stateful-pce-01.txt Thread-Index: AcyXmvDG1wYF5mSSRkmPcXuE0CJKSA== Message-ID: In-Reply-To: <20111031065020.28833.69830.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-stateful-pce-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, 31 Oct 2011 07:02:52 -0000 Hello, We submitted a new version of the Stateful PCE draft, where we addressed comments / suggestions from reviewers on the mailing list - many thanks to all who reviewed & commented. We to hope to have a good discussion of the draft in Taipei. Thanks, Ed+Jan+Robert On 10/30/11 11:50 PM, "internet-drafts@ietf.org" wrote: >A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been >successfully submitted by Jan Medved and posted to the IETF repository. > >Filename: draft-crabbe-pce-stateful-pce >Revision: 01 >Title: PCEP Extensions for Stateful PCE >Creation date: 2011-10-30 >WG ID: Individual Submission >Number of pages: 41 > >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 this functionality, > providing stateful control of Multiprotocol Label Switching (MPLS) > Traffic Engineering Label Switched Paths (TE LSP) via PCEP. > > > =20 > =20 > > >The IETF Secretariat From internet-drafts@ietf.org Mon Oct 31 06:33:34 2011 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 19F5E21F8C8E; Mon, 31 Oct 2011 06:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 tVTenEvmotQK; Mon, 31 Oct 2011 06:33:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73F921F8C7E; Mon, 31 Oct 2011 06:33:33 -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: 3.62 Message-ID: <20111031133333.22515.82590.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 06:33:33 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-gmpls-pcep-extensions-04.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, 31 Oct 2011 13:33:34 -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 Grou= p 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-04.txt Pages : 41 Date : 2011-10-31 This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-gmpls-pcep-extensions-04= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-gmpls-pcep-extensions-04.= txt From cyril.margaria@nsn.com Mon Oct 31 06:58:35 2011 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 77C6E21F8CF7 for ; Mon, 31 Oct 2011 06:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.458, 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 xupyW+fp8uOy for ; Mon, 31 Oct 2011 06:58:34 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 97C8921F8CF2 for ; Mon, 31 Oct 2011 06:58:34 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9VDwTDF017059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2011 14:58:29 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9VDwSJN026626; Mon, 31 Oct 2011 14:58:29 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 14:58:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2011 14:58:15 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] questions on gmpls extensions Thread-Index: AcySSAGZ6Vq3dshcQVu+IDbatCJI3AFiqnXw References: From: "Margaria, Cyril (NSN - DE/Munich)" To: "Margaria, Cyril (NSN - DE/Munich)" , X-OriginalArrivalTime: 31 Oct 2011 13:58:16.0029 (UTC) FILETIME=[2323F8D0:01CC97D5] Cc: pce@ietf.org Subject: Re: [Pce] questions on gmpls extensions 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, 31 Oct 2011 13:58:35 -0000 Hi Lyndon,=20 I gave some extra thoughts about this, the switching type and encoding = are not enough to understand the label, I found a counter example :=20 - in SDH a VC4-4c label address the "starting" timeslot --> without knowledge of the signal type its not possible to = distinguish between a VC4 and a VC4-4c, except if you mandate that for this switching layer the Associated Traffic spec = (GENERALIZED-BANDWIDTH) is present. - For ODU the label is relative to the HO-ODU, so this can change = along the path, so its also not possible to interpret it. In that regard we cannot restrict the label chosen end-to-end, so the = LABEL_SET is not applicable but=20 but label inclusion/exclusion in the IRO/XRO would make sense. The following text is considered: The IRO as defined in [RFC5440] is used to include specific objects in the path. RSVP allows to include label definition, in order to fullfill requierement 13 the IRO should support the new TLV Type as defined in [RFC3473]: The L bit of such sub-object has no meaning within an IRO. The XRO can follow the same semantic and encoding as in RFC5521 WG feedback is welcomed. Best regards / Mit freundlichen Gr=FC=DFen Cyril Margaria > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Margaria, Cyril (NSN - DE/Munich) > Sent: Monday, October 24, 2011 2:45 PM > To: Lyong@ciena.com > Cc: pce@ietf.org > Subject: Re: [Pce] questions on gmpls extensions >=20 > > > > Hi Folks, > > > Hi, >=20 > > I support completion of the GMPLS PCE extensions, but I did have a > couple of questions on the draft: > > > > 1) How are the label set and suggested label objects used, = given > that labels are local > > significance? Are these used only for the egress interface? >=20 > The label set and suggested label are used to restrict the label for a > given layer with end-to-end scope, the switching type and encoding are > provided to interpret correctly the labels and scope the layer (for > instance when combined with the inter-layer document where the path = can > use several layers). > The switching type and encoding should in my opinion provide enough > information to decode the label. If you think this is not enough, > examples would be greatly appreciated. >=20 >=20 > > > > 2) Switching Type and LSP Encoding Type look like they could be > in two spots, in the SWITCH-LAYER > > object and in the ENDPOINTS object Label_Request TLV - did I > misread this? > > Or if this is correct, when would you use one vs. the other? >=20 > In fact they could be in more than two spot, considering the inter- > layer extensions :-) In case of mono-layer request they should be > consistent, but in case of inter-layer requests the TE-LSP endpoint = and > layers considered might not have the same switching capabilities. >=20 > Having separate switching type and encoding for the endpoint is > explained in the document: > "The REQ-ADAP-CAP object from [I-D.ietf-pce-inter-layer-ext] can be > used in case of mono-layer request, however in case of multilayer it = is > possible to have in the future more than one object, so it is better = to > have a dedicated TLV for the label and label request (the scope is = then > more clear). > " >=20 >=20 > > > > I did not find this on the archives, my apologies if this has been > asked and answered before. >=20 > I do not recall those to be asked. I hope the document and my answers > address fully your questions. > Any other clarification/questions is appreciated. >=20 > Best regards, > Cyril > > > > Cheers, > > > >Lyndon >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From iesg-secretary@ietf.org Mon Oct 31 10:06:35 2011 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 93C9411E8170; Mon, 31 Oct 2011 10:06:35 -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.061, 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 oY-xLBtKz4MD; Mon, 31 Oct 2011 10:06:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA70611E8172; Mon, 31 Oct 2011 10:06:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031170634.18192.74088.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 10:06:34 -0700 Cc: pce mailing list , pce chair , RFC Editor Subject: [Pce] Document Action: 'PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering' to Informational RFC (draft-ietf-pce-inter-layer-req-15.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, 31 Oct 2011 17:06:35 -0000 The IESG has approved the following document: - 'PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering' (draft-ietf-pce-inter-layer-req-15.txt) as an Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-req/ Technical Summary MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. Working Group Summary No controversy on the I-D. Document Quality Comments sent by reviewers during last call have been addressed. A solution I-D is currently PCE WG document. Personnel Julien Meuricis the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. RFC Editor Note > Section 1 Final sentence > > ADD > and the framework provided in [RFC5623]. > END > > --- > > Section 3.1.2 > > OLD > Note that a PCE may not be able to distinguish virtual TE links from > regular TE links. In such cases, even if a request from a PCC to a > PCE indicates that triggered signaling is not acceptable, a PCE may > choose virtual TE links in path computation. Therefore, when a > network uses virtual TE links and a PCE is not able to distinguish > virtual TE links from regular TE links, it MUST be understood that a > PCE may choose virtual TE links even if a request from a PCC to a PCE > indicates triggered signaling is not acceptable. > NEW > Note that a PCE may not be able to distinguish virtual TE links from > regular TE links. In such cases, even if a request from a PCC to a > PCE indicates that triggered signaling is not acceptable, a PCE may > choose virtual TE links in path computation. Therefore, when a > network uses virtual TE links and a PCE is not able to distinguish > virtual TE links from regular TE links, a PCE MAY choose virtual TE > links even if a request from a PCC to a PCE indicates triggered > signaling is not acceptable. > END > > OLD > Also note that an ingress LSR may be present in multiple layers. > Thus, when a mono-layer path is requested or supplied, PCEP MUST be > able to indicate the required/provided path layer. > NEW > Also note that an ingress LSR of a higher-layer or lower-layer LSP > may be present in multiple layers. > Thus, even when a mono-layer path is requested or supplied, PCEP MUST > be able to indicate the required/provided path layer. > END > > --- > > Section 3.1.3 > > OLD > Furthermore, it may be desirable to constrain the number of layer > boundaries crossed (i.e., the number of adaptations performed on the > end-to-end path), so PCEP SHOULD include a constraint or objective > function to minimize or cap the number of adaptations on a path, and > a mechanism to report that number when a path is supplied. > NEW > Furthermore, it may be desirable to constrain the number of layer > boundaries crossed (i.e., the number of adaptations in the sense used > in [RFC5212] performed on the end-to-end path), so PCEP SHOULD > include a constraint or objective function to minimize or cap the > number of adaptations on a path, and a mechanism to report that > number when a path is supplied. > END > > --- > > 3.1.4 New first paragraph > > NEW > The concept of adaptation is used here as introduced in [RFC5212]. > END > > --- > > Section 4.1 New final paragraph > > NEW > A further discussion of policy-enabled path computation can be found > in [RFC5394]. > END > > --- > > Section 4.6 New first paragraph > > NEW > This section examines the impact on network operations of the > use of a PCE for inter-layer traffic engineering. It does not present > any further requirements on the PCE or PCC, for the PCEP, or for > deployment. > END > > --- > > Section 8.2 > > ADD > [RFC5394] I. Bryskin, D. Papadimitriou, L. Berger, and J. Ash, > "Policy-Enabled Path Computation Framework", RFC 5394, > December 2008 > END > > --- > > From ina@juniper.net Mon Oct 31 16:27:53 2011 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 E1EDF1F0D70 for ; Mon, 31 Oct 2011 16:27:53 -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 yQLtQ1wJtJ2t for ; Mon, 31 Oct 2011 16:27:53 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 24C591F0D52 for ; Mon, 31 Oct 2011 16:27:52 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP; Mon, 31 Oct 2011 16:27:52 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 31 Oct 2011 16:27:27 -0700 From: Ina Minei To: Jan Medved , "pce@ietf.org" , Edward Crabbe , Robert Varga Date: Mon, 31 Oct 2011 16:27:47 -0700 Thread-Topic: Comments on the capability negotiation in draft-crabbe-pce-stateful-pce-01.txt Thread-Index: AcyXmvDG1wYF5mSSRkmPcXuE0CJKSAAiKwuQ Message-ID: <189716C74BBB9C4095FE8CA503B1FC3A571DD18DF3@EMBX02-HQ.jnpr.net> References: <20111031065020.28833.69830.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Pce] Comments on the capability negotiation in draft-crabbe-pce-stateful-pce-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, 31 Oct 2011 23:27:54 -0000 All,=20 Some thoughts around the extensibility of the stateful PCE capability negot= iation mechanism defined in this draft. Stateful PCE capability is currentl= y advertised as a single bit in the PCE capability TLV. This works well und= er two assumptions: 1) all implementations of the draft support setting the= attributes currently defined, and 2) no new attributes (or support for ven= dor-specific attributes) will be added in the future.=20 In the event more attributes need to be supported in the future, there need= s to be a way to ensure that the PCC and the PCE can agree on what is suppo= rted by each end. One way to accomplish this is by sending error messages = when a request comes in for an unsupported attribute, and another is by exp= licitly advertising the supported attributes and agreeing on a common set (= or closing the session if this is unacceptable).=20 I believe explicit negotiation gives more flexibility and cleaner implement= ation. Here is strawman proposal:=20 * Capabilities are advertised at the time the session is set up, in a capa= bilities tlv, with sub-tlvs for every attribute supported. =20 * When receiving the advertisement, each end has to decide if they like wha= t the other end supports, and may choose to close the session and send an e= rror message if it doesn't like the capabilities supported by the other end= .=20 * After the advertisements, it is assumed that each end will honor what the= other end advertised. However, if this is not the case, the request is ig= nored and an error sent. For example, if capability A, B were advertised, = but PCE sets A, B, C, then the entire request is ignored and error sent (th= is would be the result of a software bug).=20 Thank you,=20 Ina=20