From julien.meuric@orange-ftgroup.com Tue Oct 6 00:57:32 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7DDB28C0F6 for ; Tue, 6 Oct 2009 00:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfEzqi70zkC5 for ; Tue, 6 Oct 2009 00:57:32 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 9977228C0E5 for ; Tue, 6 Oct 2009 00:57:31 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 09:59:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 6 Oct 2009 09:59:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 76th IETF - DRAFT Agenda Thread-Index: AcpGMQuJs/MgElYqQE+z3Q+2gSnFRgAKKwYA From: To: X-OriginalArrivalTime: 06 Oct 2009 07:59:04.0971 (UTC) FILETIME=[DFD43DB0:01CA465A] Subject: [Pce] FW: 76th IETF - DRAFT Agenda X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 07:57:32 -0000 SGkgYWxsLg0KDQpUaGUgKmRyYWZ0KiBhZ2VuZGEgZm9yIElFVEYgNzYgaXMgb24gbGluZS4gUGxl YXNlIG5vdGUgdGhhdCB0aGUgUENFIG1lZXRpbmcgaXMgY3VycmVudGx5IHNjaGVkdWxlZCBvbiBG cmlkYXkgYWZ0ZXJub29uLg0KDQpSZWdhcmRzDQoNCkp1bGllbg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiB3Z2NoYWlycy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86d2dj aGFpcnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFVEYgQWdlbmRhDQoNClRoZSBk cmFmdCBhZ2VuZGEgaGFzIGJlZW4gcG9zdGVkIG9uIHRoZSA3NnRoIG1lZXRpbmcgd2ViIHBhZ2UN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy83Ni8gZm9yIHJldmlldyBhbmQgY29tbWVudC4g DQo= From julien.meuric@orange-ftgroup.com Wed Oct 7 06:28:04 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA153A6AA9; Wed, 7 Oct 2009 06:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8vRDq8K5Gbl; Wed, 7 Oct 2009 06:28:04 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 1AC773A6AA1; Wed, 7 Oct 2009 06:28:02 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 15:29:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Oct 2009 15:29:41 +0200 Message-ID: In-Reply-To: <20091006154703.666E23A6A05@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-l3vpn-e2e-rsvp-te-reqts (Requirements forsupporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN) toInformational RFC Thread-Index: AcpGnItsrkzElNoLRzShR1TLhDzOUQAr+f2g References: <20091006154703.666E23A6A05@core3.amsl.com> From: To: X-OriginalArrivalTime: 07 Oct 2009 13:29:42.0454 (UTC) FILETIME=[3A4DAD60:01CA4752] Cc: pce@ietf.org, l3vpn@ietf.org Subject: Re: [Pce] Last Call: draft-ietf-l3vpn-e2e-rsvp-te-reqts (Requirements forsupporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN) toInformational RFC X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 13:28:04 -0000 Hi all. Just a few minor comments: - The I-D refers to the "EXP" field several times (pages 11, 13, 15, 17...) whereas it is now named "Traffic Class", as per RFC 5462. - Section 5.8 tackles PCE, thus putting some requirements on the PCE WG: do we expect that they are endorsed tacitly? In this specific case, it is only specified as "SHOULD", so impact is limited, but what is the status of this kind of draft defining requirements over multiple WGs? In case it be superset by draft-ietf-pce-vpn-req, a reference would be welcome. Thanks, Julien -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG The IESG has received a request from the Layer 3 Virtual Private Networks=20 WG (l3vpn) to consider the following document: - 'Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-20. Exceptionally,=20 comments may be sent to iesg@ietf.org instead. In either case, please=20 retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-e2e-rsvp-te-reqts-0 4.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 17192&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From root@core3.amsl.com Fri Oct 16 11:15:01 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 98D6A3A67EF; Fri, 16 Oct 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091016181501.98D6A3A67EF@core3.amsl.com> Date: Fri, 16 Oct 2009 11:15:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Author(s) : S. Yasukawa, A. Farrel Filename : draft-ietf-pce-p2mp-req-03.txt Pages : 11 Date : 2009-10-16 The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-p2mp-req-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-p2mp-req-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-16111021.I-D@ietf.org> --NextPart-- From adrian@olddog.co.uk Fri Oct 16 11:36:03 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B5B3A66B4 for ; Fri, 16 Oct 2009 11:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7srVtWoEOP2c for ; Fri, 16 Oct 2009 11:36:02 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 3E2103A635F for ; Fri, 16 Oct 2009 11:36:02 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9GIZmaA027368; Fri, 16 Oct 2009 19:35:49 +0100 Received: from your029b8cecfe (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9GIZm3H027362; Fri, 16 Oct 2009 19:35:48 +0100 Message-ID: <97A1BDA796ED4ED3AFA91C12BF20AB77@your029b8cecfe> From: "Adrian Farrel" To: References: <20091016181501.98D6A3A67EF@core3.amsl.com> Date: Fri, 16 Oct 2009 19:35:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Seisho Yasukawa Subject: Re: [Pce] I-D Action:draft-ietf-pce-p2mp-req-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:36:03 -0000 Hi PCE, After a long pause sitting on this I-D, the protocol extensions (http://tools.ietf.org/html/draft-ietf-pce-pcep-p2mp-extensions) have stabilised. Although there will be another revision of that I-D they have firmed up all of the requirements (including one new one) and so we are able to update this I-D. Thus, this revision includes: - fixes to a couple of comments made on the list - one new requirement in 2.1.14 - add requirement numbers. The authors now believe that this document is complete and would be happy to see it last called whenever that fits into the WG schedule. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Friday, October 16, 2009 7:15 PM Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-03.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 : PCC-PCE Communication Requirements for Point to > Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > Author(s) : S. Yasukawa, A. Farrel > Filename : draft-ietf-pce-p2mp-req-03.txt > Pages : 11 > Date : 2009-10-16 > > The Path Computation Element (PCE) provides path computation > functions in support of traffic engineering in Multi-Protocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > Extensions to the MPLS and GMPLS signaling and routing protocols have > been made in support of point-to-multipoint (P2MP) Traffic Engineered > (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is > already established, and since P2MP TE LSP routes are sometimes > complex to compute, it is likely that PCE will be used for P2MP LSPs. > > Generic requirements for a communication protocol between Path > Computation Clients (PCCs) and PCEs are presented in "Path > Computation Element (PCE) Communication Protocol Generic > Requirements". This document complements the generic requirements and > presents a detailed set of PCC-PCE communication protocol > requirements for point-to-multipoint MPLS/GMPLS traffic engineering. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-p2mp-req-03.txt > From adrian@olddog.co.uk Mon Oct 19 04:35:15 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAC13A67D7 for ; Mon, 19 Oct 2009 04:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDY3-q9Ld-SF for ; Mon, 19 Oct 2009 04:35:15 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id CC19E3A67A8 for ; Mon, 19 Oct 2009 04:35:14 -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 n9JBZ3bx030660; Mon, 19 Oct 2009 12:35:08 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9JBZ07X030626; Mon, 19 Oct 2009 12:35:02 +0100 Message-ID: <6F6E3ADF045940EB8042709796C04996@your029b8cecfe> From: "Adrian Farrel" To: , , References: <20091019083001.8E8C528C0D8@core3.amsl.com> Date: Mon, 19 Oct 2009 12:29:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: pce@ietf.org Subject: Re: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 11:35:15 -0000 While this is a reasonably well-written draft, I don't see that it adds anything to what we already have in the core RFCs. In section 4.3 you have... There are two options for PCE to send pre-configured route as follows: PCRep is used to respond route computation result naturally. If it is used to send pre-configured route, a new flag SHOULD be defined to indicate the route carried is pre-configured route. Two questions: 1. What is the other option? You only list one option. 2. Why do you need a flag to indicate that a route is pre- configured? Why does the PCC care how the route was derived? You slighlty answer question 2, in section 5.1 where you say... When PCC requests pre-configured route ...but why would the PCC ask for a pre-configured route? It just wants a route. If there is a policy to be applied by the PCE in selection of the route, this should be indicated using the normal policy functions. If there is an objective function/algorithm to be applied in selecting the route, this should be indicated using the OF object. So I think that you don't need the pre-configured route flag. Cheers, Adrian From cyril.margaria@nsn.com Mon Oct 19 05:39:10 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3AFA28C173 for ; Mon, 19 Oct 2009 05:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7ChEWBLOUaL for ; Mon, 19 Oct 2009 05:39:09 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 30E8628C134 for ; Mon, 19 Oct 2009 05:39:08 -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 n9JCdDSW002389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2009 14:39:13 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9JCdDfw024197; Mon, 19 Oct 2009 14:39:13 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 14:39:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Oct 2009 14:39:11 +0200 Message-ID: In-Reply-To: <6F6E3ADF045940EB8042709796C04996@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt Thread-Index: AcpQsEDRUAz899eXSNGYZ+eS0BdmxwAAzB0w References: <20091019083001.8E8C528C0D8@core3.amsl.com> <6F6E3ADF045940EB8042709796C04996@your029b8cecfe> From: "Margaria, Cyril (NSN - DE/Munich)" To: "Adrian Farrel" , , , X-OriginalArrivalTime: 19 Oct 2009 12:39:12.0894 (UTC) FILETIME=[298081E0:01CA50B9] Cc: pce@ietf.org Subject: Re: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 12:39:10 -0000 Hi,=20 I think the term pre-configured route is a bit misleading, I understand the scenario as the PCC ask for 3 routes, the first one will be signaled, the 2 other kept in case a failure happens on the first route. If I am not misunderstood this can be achieved by using the svec with 3 time the same endpoints and bandwidth.=20 Regarding the indication that a route has changed, the PCE could send a PCRep with RRO (not allowed in rfc5440) and ERO containing the new Path, but what should be the request id of the PCRep? In addition the PCC could also be aware that the route failed and request a new Path computation for the failed path.=20 In this context I do not see the need to have a new flag in the RP object for this use case. Best Regards Cyril Margaria -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of ext Adrian Farrel Sent: Monday, October 19, 2009 1:29 PM To: Bao.Yuanlin@zte.com.cn; fu.xihua@zte.com.cn; xie.gang@zte.com.cn Cc: pce@ietf.org Subject: Re: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt While this is a reasonably well-written draft, I don't see that it adds=20 anything to what we already have in the core RFCs. In section 4.3 you have... There are two options for PCE to send pre-configured route as follows: PCRep is used to respond route computation result naturally. If it is used to send pre-configured route, a new flag SHOULD be defined to indicate the route carried is pre-configured route. Two questions: 1. What is the other option? You only list one option. 2. Why do you need a flag to indicate that a route is pre- configured? Why does the PCC care how the route was derived? You slighlty answer question 2, in section 5.1 where you say... When PCC requests pre-configured route ...but why would the PCC ask for a pre-configured route? It just wants a route. If there is a policy to be applied by the PCE in selection of the route, this should be indicated using the normal policy functions. If there=20 is an objective function/algorithm to be applied in selecting the route, this should be indicated using the OF object. So I think that you don't need the pre-configured route flag. Cheers, Adrian=20 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From root@core3.amsl.com Mon Oct 19 06:15:01 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9F7043A69A3; Mon, 19 Oct 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019131501.9F7043A69A3@core3.amsl.com> Date: Mon, 19 Oct 2009 06:15:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-vpn-req-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 13:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCC-PCE Communication Requirements for VPNs Author(s) : S. Yasukawa, A. Farrel Filename : draft-ietf-pce-vpn-req-01.txt Pages : 16 Date : 2009-10-19 The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. An important application of MPLS and GMPLS networks is Virtual Private Networks (VPNs) that may be constructed using Label Switched Paths (LSPs) in the MPLS and GMPLS networks as VPN tunnels. PCE may be applied as a tool to compute the paths of such tunnels in order to achieve better use of the network resources and to provide better levels of service to the VPN customers. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements that are specific to the application of PCE to VPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-vpn-req-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-vpn-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19061047.I-D@ietf.org> --NextPart-- From adrian@olddog.co.uk Mon Oct 19 06:26:12 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A02528C120 for ; Mon, 19 Oct 2009 06:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.138 X-Spam-Level: X-Spam-Status: No, score=-1.138 tagged_above=-999 required=5 tests=[AWL=1.460, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx5Xl6Kc+5FR for ; Mon, 19 Oct 2009 06:26:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 53CF33A67A6 for ; Mon, 19 Oct 2009 06:26:08 -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 n9JDPv0t010019; Mon, 19 Oct 2009 14:26:02 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9JDPujv010013; Mon, 19 Oct 2009 14:25:57 +0100 Message-ID: From: "Adrian Farrel" To: "Margaria, Cyril \(NSN - DE/Munich\)" , , , References: <20091019083001.8E8C528C0D8@core3.amsl.com> <6F6E3ADF045940EB8042709796C04996@your029b8cecfe> Date: Mon, 19 Oct 2009 14:20:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: pce@ietf.org Subject: Re: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 13:26:12 -0000 Hi Cyril, Fine with what you say, but... We did consider allowing the PCE to push unsolicited routes to the PCC. We decided this was not actually the correct information or processing flow. The point is that a "new route" is only available if a new computation is performed. But the PCE only performs computations on demand. How would it know that the network event should cause it to perform a new computation, and how would it know whether the newly computed route was wanted by the PCC. However a third party tool (for example, the NMS, or the VNTM, depending on the scenario) should be able to perform this function that is heavily associated with local network and per-LSP policy. In these cases, it is the management entity that is requesting path computations as the PCC, and it will push those paths to the LER according to policy. Of course, the LER could be the PCC and could request the paths, but it is less likely to be in control of the necessary triggers. This behavior is actually very similar to what you might expect for reoptimization. Cheers, Adrian ----- Original Message ----- From: "Margaria, Cyril (NSN - DE/Munich)" To: "Adrian Farrel" ; ; ; Cc: Sent: Monday, October 19, 2009 1:39 PM Subject: RE: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt Hi, I think the term pre-configured route is a bit misleading, I understand the scenario as the PCC ask for 3 routes, the first one will be signaled, the 2 other kept in case a failure happens on the first route. If I am not misunderstood this can be achieved by using the svec with 3 time the same endpoints and bandwidth. Regarding the indication that a route has changed, the PCE could send a PCRep with RRO (not allowed in rfc5440) and ERO containing the new Path, but what should be the request id of the PCRep? In addition the PCC could also be aware that the route failed and request a new Path computation for the failed path. In this context I do not see the need to have a new flag in the RP object for this use case. Best Regards Cyril Margaria -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of ext Adrian Farrel Sent: Monday, October 19, 2009 1:29 PM To: Bao.Yuanlin@zte.com.cn; fu.xihua@zte.com.cn; xie.gang@zte.com.cn Cc: pce@ietf.org Subject: Re: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt While this is a reasonably well-written draft, I don't see that it adds anything to what we already have in the core RFCs. In section 4.3 you have... There are two options for PCE to send pre-configured route as follows: PCRep is used to respond route computation result naturally. If it is used to send pre-configured route, a new flag SHOULD be defined to indicate the route carried is pre-configured route. Two questions: 1. What is the other option? You only list one option. 2. Why do you need a flag to indicate that a route is pre- configured? Why does the PCC care how the route was derived? You slighlty answer question 2, in section 5.1 where you say... When PCC requests pre-configured route ...but why would the PCC ask for a pre-configured route? It just wants a route. If there is a policy to be applied by the PCE in selection of the route, this should be indicated using the normal policy functions. If there is an objective function/algorithm to be applied in selecting the route, this should be indicated using the OF object. So I think that you don't need the pre-configured route flag. Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From adrian@olddog.co.uk Mon Oct 19 06:46:21 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD6A28C158 for ; Mon, 19 Oct 2009 06:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=1.251, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTwnYuxsfI7Z for ; Mon, 19 Oct 2009 06:46:20 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 87F7828C14C for ; Mon, 19 Oct 2009 06:46:20 -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 n9JDkQVC016424; Mon, 19 Oct 2009 14:46:26 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9JDkPAp016414; Mon, 19 Oct 2009 14:46:25 +0100 Message-ID: <49BA35979CBB4006B623CE85636FAF7A@your029b8cecfe> From: "Adrian Farrel" To: References: <20091019131501.9F7043A69A3@core3.amsl.com> Date: Mon, 19 Oct 2009 14:46:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Seisho Yasukawa Subject: Re: [Pce] I-D Action:draft-ietf-pce-vpn-req-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 13:46:21 -0000 Hi, Just a keepalive as no new requirements have been forthcoming. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, October 19, 2009 2:15 PM Subject: [Pce] I-D Action:draft-ietf-pce-vpn-req-01.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Path Computation Element Working Group of > the IETF. > > > Title : PCC-PCE Communication Requirements for VPNs > Author(s) : S. Yasukawa, A. Farrel > Filename : draft-ietf-pce-vpn-req-01.txt > Pages : 16 > Date : 2009-10-19 > > The Path Computation Element (PCE) provides path computation > functions in support of traffic engineering in Multiprotocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > An important application of MPLS and GMPLS networks is Virtual > Private Networks (VPNs) that may be constructed using Label Switched > Paths (LSPs) in the MPLS and GMPLS networks as VPN tunnels. PCE may > be applied as a tool to compute the paths of such tunnels in order to > achieve better use of the network resources and to provide better > levels of service to the VPN customers. > > Generic requirements for a communication protocol between Path > Computation Clients (PCCs) and PCEs are presented in "Path > Computation Element (PCE) Communication Protocol Generic > Requirements". This document complements the generic requirements and > presents a detailed set of PCC-PCE communication protocol > requirements that are specific to the application of PCE to VPNs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-vpn-req-01.txt From ylee@huawei.com Mon Oct 19 15:54:14 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306B728C188; Mon, 19 Oct 2009 15:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah24ziOPdwcW; Mon, 19 Oct 2009 15:54:11 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 70C1D3A6914; Mon, 19 Oct 2009 15:54:11 -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 <0KRS00DN2AAHMK@usaga04-in.huawei.com>; Mon, 19 Oct 2009 17:54:18 -0500 (CDT) Received: from L73682 ([10.124.12.76]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRS002ZXAABDD@usaga04-in.huawei.com>; Mon, 19 Oct 2009 17:54:17 -0500 (CDT) Date: Mon, 19 Oct 2009 17:54:11 -0500 From: Young Lee To: 'CCAMP' , pce@ietf.org Message-id: <000f01ca510f$13f91250$4c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_nZJ26SsYEn3t3l3mgy0HXg)" Thread-index: AcpRDxJELzyTSoABToKuuzhRCpXYHg== Subject: [Pce] signal compatibility drafts X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 22:54:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_nZJ26SsYEn3t3l3mgy0HXg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, We have recently uploaded WSON signal compatibility related drafts in both CCAMP and PCE WG's. Here are the three sets of drafts that address signal compatibility and processing constraints in WSON. http://tools.ietf.org/id/draft-bernstein-ccamp-wson-compatibility-01.txt (Framework) http://tools.ietf.org/id/draft-lee-ccamp-wson-signal-compatibility-ospf-00.t xt (OSPF extensions) http://tools.ietf.org/id/draft-lee-pce-wson-signal-compatibility-00.txt (PCEP extensions) We'd appreciate your interest and comments for these drafts. Thanks. Young --Boundary_(ID_nZJ26SsYEn3t3l3mgy0HXg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi, =

 

We have recently uploaded WSON signal compatibility = related drafts in both CCAMP and PCE WG’s. Here are the three sets of = drafts that address signal compatibility and processing constraints in WSON. =

 

http://tools.ietf.org/id/draft-bernstein-ccamp-wson-compatibilit= y-01.txt (Framework)

http://tools.ietf.org/id/draft-lee-ccamp-wson-signal-compa= tibility-ospf-00.txt (OSPF extensions)

http://tools.ietf.org/id/draft-lee-pce-wson-signal-compatibility-= 00.txt (PCEP extensions)

 

We’d appreciate your interest and comments for = these drafts. Thanks.

 

Young

--Boundary_(ID_nZJ26SsYEn3t3l3mgy0HXg)-- From rfc-editor@rfc-editor.org Mon Oct 19 17:12:59 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2D33A681A; Mon, 19 Oct 2009 17:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.167 X-Spam-Level: X-Spam-Status: No, score=-17.167 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3Tjz0ALZOh5; Mon, 19 Oct 2009 17:12:59 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 1320D3A69C6; Mon, 19 Oct 2009 17:12:59 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 9E46934C9BD; Mon, 19 Oct 2009 17:10:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091020001038.9E46934C9BD@bosco.isi.edu> Date: Mon, 19 Oct 2009 17:10:38 -0700 (PDT) Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] RFC 5671 on Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 00:12:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5671 Title: Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) Author: S. Yasukawa, A. Farrel, Ed. Status: Informational Date: October 2009 Mailbox: yasukawa.seisho@lab.ntt.co.jp, adrian@olddog.co.uk Pages: 15 Characters: 35176 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-p2mp-app-02.txt URL: http://www.rfc-editor.org/rfc/rfc5671.txt The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate. This memo provides information for the Internet community. This document is a product of the Path Computation Element Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From bao.yuanlin@zte.com.cn Tue Oct 20 01:23:26 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781643A6882 for ; Tue, 20 Oct 2009 01:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qraSKEgp43w for ; Tue, 20 Oct 2009 01:23:25 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 03EEE3A6810 for ; Tue, 20 Oct 2009 01:23:24 -0700 (PDT) Received: from [10.30.17.102] by mx5.zte.com.cn with surfront esmtp id 111641441414862; Tue, 20 Oct 2009 15:57:38 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.102] with StormMail ESMTP id 87118.1551313158; Tue, 20 Oct 2009 16:15:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n9K8NIUr071928; Tue, 20 Oct 2009 16:23:21 +0800 (CST) (envelope-from Bao.Yuanlin@zte.com.cn) In-Reply-To: <6F6E3ADF045940EB8042709796C04996@your029b8cecfe> To: "Adrian Farrel" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: Bao.Yuanlin@zte.com.cn Date: Tue, 20 Oct 2009 16:24:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-10-20 16:23:13, Serialize complete at 2009-10-20 16:23:13 Content-Type: multipart/alternative; boundary="=_alternative 002E0F0A48257655_=" X-MAIL: mse1.zte.com.cn n9K8NIUr071928 Cc: pce@ietf.org, xie.gang@zte.com.cn Subject: [Pce] =?gb2312?b?tPC4tDogUmU6IEktRCBBY3Rpb246ZHJhZnQtYmFvLXBjZS1w?= =?gb2312?b?cmUtY29uZmlndXJlZC1yb3V0aW5nLTAwLnR4dA==?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 08:23:26 -0000 This is a multipart message in MIME format. --=_alternative 002E0F0A48257655_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQWRyaWFuLCANCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQpUaGUgbWFpbiBpZGVh IG9mIHRoaXMgZHJhZnQgaXMgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgcG90ZW50aWFsIA0KdW5h dmFpbGFiaWxpdHkgDQpvZiBwcmUtY29uZmlndXJlZCByb3V0ZXMgYW5kIHRvIHByb3ZpZGUgYmV0 dGVyIHNlcnZpY2UsIHdoaWNoIGlzIGRlc2NyaWJlZCANCmluIA0Kc2VjdGlvbiAyLg0KDQpGb3Ig dGhlIGZpcnN0IHF1ZXN0aW9uLCBJJ20gc29ycnkgZm9yIHRoZSBtaXN0YWtlLCBhbmQgdGhpcyB3 aWxsIGJlIA0KcmVjdGlmaWVkDQppbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQpGb3IgdGhlIHNlY29u ZCBxdWVzdGlvbiwgdGhlIGZsYWcgZGVmaW5lZCBpbiB0aGUgZHJhZnQgaXMgdG8gbGV0IFBDRSBr bm93IA0KUENDIG5lZWQNCnByZS1jb25maWd1cmVkIHJvdXRlIHNlcnZpY2UuIEFuZCBQQ0MgZG9l c24ndCBjYXJlIGhvdyB0aGUgcm91dGUgd2FzIA0KZGVyaXZlZC4gDQpQQ0MgY2FuIHVwZGF0ZSB0 aGUgc3RvcmVkIHByZS1jb25maWd1cmVkIHJvdXRlIHdoZW4gaXQgcmVjZWl2ZXMgYSBQQ1JlcCAN Cm1lc3NhZ2Ugd2l0aA0KdGhlIGZsYWcgc2V0LiBGb3IgUENFLCB3aGVuIGl0IHJlY2VpdmVzIGEg UENSZXEgbWVzc2FnZSB3aXRoIGZsYWcgc2V0LCBpdCANCmNhbg0KcmVjb2duaXplIGEgcHJlLWNv bmZpZ3VyZWQgcm91dGUgc2VydmljZSBpcyByZXF1ZXN0ZWQgZnJvbSBQQ0MuIFNvIFBDRSBjYW4g DQpjb21wdXRlDQphbmQgc2VuZCB0aGUgdXBkYXRlZCBwcmUtY29uZmlndXJlZCByb3V0ZSB0byBQ Q0Mgd2hlbiB0aGUgY29ycmVzcG9uZGluZyANCmNvbmRpdGlvbiANCm1lZXRzLg0KDQoNCkJlc3Qg cmVnYXJkcywNCll1YW5saW4gQmFvDQoNCg0KDQoiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRk b2cuY28udWs+INC009ogMjAwOS0xMC0xOSAxOToyOToxMToNCg0KPiBXaGlsZSB0aGlzIGlzIGEg cmVhc29uYWJseSB3ZWxsLXdyaXR0ZW4gZHJhZnQsIEkgZG9uJ3Qgc2VlIHRoYXQgaXQgYWRkcyAN Cj4gYW55dGhpbmcgdG8gd2hhdCB3ZSBhbHJlYWR5IGhhdmUgaW4gdGhlIGNvcmUgUkZDcy4NCj4g DQo+IEluIHNlY3Rpb24gNC4zIHlvdSBoYXZlLi4uDQo+IA0KPiAgICBUaGVyZSBhcmUgdHdvIG9w dGlvbnMNCj4gICAgZm9yIFBDRSB0byBzZW5kIHByZS1jb25maWd1cmVkIHJvdXRlIGFzIGZvbGxv d3M6DQo+ICAgIFBDUmVwIGlzIHVzZWQgdG8gcmVzcG9uZCByb3V0ZSBjb21wdXRhdGlvbiByZXN1 bHQgbmF0dXJhbGx5LiAgSWYgaXQNCj4gICAgaXMgdXNlZCB0byBzZW5kIHByZS1jb25maWd1cmVk IHJvdXRlLCBhIG5ldyBmbGFnIFNIT1VMRCBiZSBkZWZpbmVkIHRvDQo+ICAgIGluZGljYXRlIHRo ZSByb3V0ZSBjYXJyaWVkIGlzIHByZS1jb25maWd1cmVkIHJvdXRlLg0KPiANCj4gVHdvIHF1ZXN0 aW9uczoNCj4gMS4gV2hhdCBpcyB0aGUgb3RoZXIgb3B0aW9uPyBZb3Ugb25seSBsaXN0IG9uZSBv cHRpb24uDQo+IDIuIFdoeSBkbyB5b3UgbmVlZCBhIGZsYWcgdG8gaW5kaWNhdGUgdGhhdCBhIHJv dXRlIGlzIHByZS0NCj4gICAgY29uZmlndXJlZD8gV2h5IGRvZXMgdGhlIFBDQyBjYXJlIGhvdyB0 aGUgcm91dGUgd2FzDQo+ICAgIGRlcml2ZWQ/DQo+IA0KPiBZb3Ugc2xpZ2hsdHkgYW5zd2VyIHF1 ZXN0aW9uIDIsIGluIHNlY3Rpb24gNS4xIHdoZXJlIHlvdSBzYXkuLi4NCj4gDQo+ICAgIFdoZW4g UENDIHJlcXVlc3RzIHByZS1jb25maWd1cmVkIHJvdXRlDQo+IA0KPiAuLi5idXQgd2h5IHdvdWxk IHRoZSBQQ0MgYXNrIGZvciBhIHByZS1jb25maWd1cmVkIHJvdXRlPyBJdCBqdXN0IHdhbnRzIGEg DQoNCj4gcm91dGUuIElmIHRoZXJlIGlzIGEgcG9saWN5IHRvIGJlIGFwcGxpZWQgYnkgdGhlIFBD RSBpbiBzZWxlY3Rpb24gb2YgdGhlIA0KDQo+IHJvdXRlLCB0aGlzIHNob3VsZCBiZSBpbmRpY2F0 ZWQgdXNpbmcgdGhlIG5vcm1hbCBwb2xpY3kgZnVuY3Rpb25zLiBJZiANCnRoZXJlIA0KPiBpcyBh biBvYmplY3RpdmUgZnVuY3Rpb24vYWxnb3JpdGhtIHRvIGJlIGFwcGxpZWQgaW4gc2VsZWN0aW5n IHRoZSByb3V0ZSwgDQoNCj4gdGhpcyBzaG91bGQgYmUgaW5kaWNhdGVkIHVzaW5nIHRoZSBPRiBv YmplY3QuDQo+IA0KPiBTbyBJIHRoaW5rIHRoYXQgeW91IGRvbid0IG5lZWQgdGhlIHByZS1jb25m aWd1cmVkIHJvdXRlIGZsYWcuDQo+IA0KPiBDaGVlcnMsDQo+IEFkcmlhbiANCj4gDQo+IA0KDQo= --=_alternative 002E0F0A48257655_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFkcmlhbiwgPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHlvdXIg Y29tbWVudHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5UaGUgbWFpbiBpZGVhIG9mIHRoaXMgZHJhZnQgaXMgdG8gc29sdmUNCnRoZSBwcm9ibGVtIG9m IHBvdGVudGlhbCB1bmF2YWlsYWJpbGl0eSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPm9mIHByZS1jb25maWd1cmVkIHJvdXRlcyBhbmQgdG8gcHJvdmlkZQ0KYmV0 dGVyIHNlcnZpY2UsIHdoaWNoIGlzIGRlc2NyaWJlZCBpbiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNlY3Rpb24gMi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZvciB0aGUgZmlyc3QgcXVlc3Rpb24sIEknbSBzb3Jy eSBmb3INCnRoZSBtaXN0YWtlLCBhbmQgdGhpcyB3aWxsIGJlIDwvZm9udD48Zm9udCBzaXplPTI+ cmVjdGlmaWVkPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj5pbiB0aGUgbmV4dCB2ZXJzaW9uLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Rm9yIHRoZSBz ZWNvbmQgcXVlc3Rpb24sIHRoZSBmbGFnIGRlZmluZWQNCmluIHRoZSBkcmFmdCBpcyB0byBsZXQg UENFIGtub3cgUENDIG5lZWQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPnByZS1jb25maWd1cmVkIHJvdXRlIHNlcnZpY2UuIEFuZCBQQ0MNCmRvZXNuJ3QgY2FyZSBo b3cgdGhlIHJvdXRlIHdhcyBkZXJpdmVkLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlBDQyBjYW4gdXBkYXRlIHRoZSBzdG9yZWQgcHJlLWNvbmZpZ3VyZWQNCnJv dXRlIHdoZW4gaXQgcmVjZWl2ZXMgYSBQQ1JlcCBtZXNzYWdlIHdpdGg8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoZSBmbGFnIHNldC4gRm9yIFBDRSwgd2hlbiBp dCByZWNlaXZlcw0KYSBQQ1JlcSBtZXNzYWdlIHdpdGggZmxhZyBzZXQsIGl0IGNhbjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cmVjb2duaXplIGEgcHJlLWNvbmZp Z3VyZWQgcm91dGUgc2VydmljZQ0KaXMgcmVxdWVzdGVkIGZyb20gUENDLiBTbyBQQ0UgY2FuIGNv bXB1dGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFuZCBzZW5k IHRoZSB1cGRhdGVkIHByZS1jb25maWd1cmVkDQpyb3V0ZSB0byBQQ0Mgd2hlbiB0aGUgY29ycmVz cG9uZGluZyBjb25kaXRpb24gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5tZWV0cy48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkJlc3QgcmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPll1YW5saW4gQmFvPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+JnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90OyAmbHQ7YWRyaWFuQG9sZGRvZy5j by51ayZndDsNCtC009ogMjAwOS0xMC0xOSAxOToyOToxMTo8YnI+DQo8YnI+DQomZ3Q7IFdoaWxl IHRoaXMgaXMgYSByZWFzb25hYmx5IHdlbGwtd3JpdHRlbiBkcmFmdCwgSSBkb24ndCBzZWUgdGhh dCBpdA0KYWRkcyA8YnI+DQomZ3Q7IGFueXRoaW5nIHRvIHdoYXQgd2UgYWxyZWFkeSBoYXZlIGlu IHRoZSBjb3JlIFJGQ3MuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIHNlY3Rpb24gNC4zIHlvdSBo YXZlLi4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGVyZSBhcmUgdHdvIG9w dGlvbnM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtmb3IgUENFIHRvIHNlbmQgcHJlLWNvbmZpZ3Vy ZWQgcm91dGUgYXMgZm9sbG93czo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtQQ1JlcCBpcyB1c2Vk IHRvIHJlc3BvbmQgcm91dGUgY29tcHV0YXRpb24gcmVzdWx0IG5hdHVyYWxseS4NCiZuYnNwO0lm IGl0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7aXMgdXNlZCB0byBzZW5kIHByZS1jb25maWd1cmVk IHJvdXRlLCBhIG5ldyBmbGFnIFNIT1VMRA0KYmUgZGVmaW5lZCB0bzxicj4NCiZndDsgJm5ic3A7 ICZuYnNwO2luZGljYXRlIHRoZSByb3V0ZSBjYXJyaWVkIGlzIHByZS1jb25maWd1cmVkIHJvdXRl Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUd28gcXVlc3Rpb25zOjxicj4NCiZndDsgMS4gV2hhdCBp cyB0aGUgb3RoZXIgb3B0aW9uPyBZb3Ugb25seSBsaXN0IG9uZSBvcHRpb24uPGJyPg0KJmd0OyAy LiBXaHkgZG8geW91IG5lZWQgYSBmbGFnIHRvIGluZGljYXRlIHRoYXQgYSByb3V0ZSBpcyBwcmUt PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Y29uZmlndXJlZD8gV2h5IGRvZXMgdGhlIFBDQyBjYXJl IGhvdyB0aGUgcm91dGUgd2FzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ZGVyaXZlZD88YnI+DQom Z3Q7IDxicj4NCiZndDsgWW91IHNsaWdobHR5IGFuc3dlciBxdWVzdGlvbiAyLCBpbiBzZWN0aW9u IDUuMSB3aGVyZSB5b3Ugc2F5Li4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtX aGVuIFBDQyByZXF1ZXN0cyBwcmUtY29uZmlndXJlZCByb3V0ZTxicj4NCiZndDsgPGJyPg0KJmd0 OyAuLi5idXQgd2h5IHdvdWxkIHRoZSBQQ0MgYXNrIGZvciBhIHByZS1jb25maWd1cmVkIHJvdXRl PyBJdCBqdXN0IHdhbnRzDQphIDxicj4NCiZndDsgcm91dGUuIElmIHRoZXJlIGlzIGEgcG9saWN5 IHRvIGJlIGFwcGxpZWQgYnkgdGhlIFBDRSBpbiBzZWxlY3Rpb24NCm9mIHRoZSA8YnI+DQomZ3Q7 IHJvdXRlLCB0aGlzIHNob3VsZCBiZSBpbmRpY2F0ZWQgdXNpbmcgdGhlIG5vcm1hbCBwb2xpY3kg ZnVuY3Rpb25zLg0KSWYgdGhlcmUgPGJyPg0KJmd0OyBpcyBhbiBvYmplY3RpdmUgZnVuY3Rpb24v YWxnb3JpdGhtIHRvIGJlIGFwcGxpZWQgaW4gc2VsZWN0aW5nIHRoZQ0Kcm91dGUsIDxicj4NCiZn dDsgdGhpcyBzaG91bGQgYmUgaW5kaWNhdGVkIHVzaW5nIHRoZSBPRiBvYmplY3QuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFNvIEkgdGhpbmsgdGhhdCB5b3UgZG9uJ3QgbmVlZCB0aGUgcHJlLWNvbmZp Z3VyZWQgcm91dGUgZmxhZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgQ2hlZXJzLDxicj4NCiZndDsg QWRyaWFuIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 002E0F0A48257655_=-- From bao.yuanlin@zte.com.cn Tue Oct 20 01:50:58 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B5B3A6820 for ; Tue, 20 Oct 2009 01:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LsrhJXZChPE for ; Tue, 20 Oct 2009 01:50:57 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 34BF03A6359 for ; Tue, 20 Oct 2009 01:50:56 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101441414862; Tue, 20 Oct 2009 16:31:27 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 55259.3169173865; Tue, 20 Oct 2009 16:39:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n9K8oq9p096443; Tue, 20 Oct 2009 16:50:53 +0800 (CST) (envelope-from Bao.Yuanlin@zte.com.cn) In-Reply-To: To: "Margaria, Cyril (NSN - DE/Munich)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: Bao.Yuanlin@zte.com.cn Date: Tue, 20 Oct 2009 16:51:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-10-20 16:50:44, Serialize complete at 2009-10-20 16:50:44 Content-Type: multipart/alternative; boundary="=_alternative 0030951E48257655_=" X-MAIL: mse1.zte.com.cn n9K8oq9p096443 Cc: pce@ietf.org, xie.gang@zte.com.cn Subject: [Pce] =?gb2312?b?tPC4tDogUkU6ICBJLUQgQWN0aW9uOmRyYWZ0LWJhby1wY2Ut?= =?gb2312?b?cHJlLWNvbmZpZ3VyZWQtcm91dGluZy0wMC50eHQ=?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 08:50:59 -0000 This is a multipart message in MIME format. --=_alternative 0030951E48257655_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQ3lyaWwsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KSWYgeW91IGZpbmQgYSBi ZXR0ZXIgdGVybSB0byBzdWJzdGl0dXRlIHRoZSB0ZXJtICJwcmUtY29uZmlndXJlZCByb3V0ZSIs IA0KcGxlYXNlDQpsZXQgbWUga25vdy4gQW55b25lIHdobyBpcyBpbnRlcmVzdGVkIGlzIHdlbGNv bWVkIHRvIGJlIGEgY28tYXV0aG9yLg0KDQpTaW5jZSB0aGUgbWFpbiBpZGVhIG9mIHRoaXMgZHJh ZnQgaXMgdG8gc29sdmUgdGhlIHBvdGVudGlhbCBwcm9ibGVtIG9mIHVuDQphdmFpbGFiaWxpdHkN Cm9mIHByZS1jb25maWd1cmVkIHJvdXRlcywgc28gSSBkb24ndCB0aGluayBpdCB3aWxsIGJlIGFj aGlldmVkIGJ5IHVzaW5nIA0KdGhlIHN2ZWMtbGlzdC4NCkJlYXVzZSB1c2luZyBzdmVjIHdpdGgg bXVsdGkgdGltZXMgY2FuJ3QgcHJvdmlkZSB0aGUgcmVxdWVzdGVkIHBhdGggaXMgDQphdmFpbGFi bGUgd2hlbg0KdGhlIHByaW1hcnkgcGF0aCBmYWlscy4NCg0KVGhlcmUgcmVhbGx5IGV4aXN0cyBh IHByb2JsZW0gb2YgcmVxdWVzdCBpZCBvZiB0aGUgUENSZXAsIGlmIHlvdSBoYXZlIGFueSANCmdv b2QNCmlkZWEsIHdlIGNhbiBjb29wZXJhdGUuDQoNClBDQyBjYW4gYmUgYXdhcmUgdGhhdCB0aGUg cm91dGUgZmFpbGVkIGFuZCByZXF1ZXN0IGEgbmV3IFBhdGggY29tcHV0YXRpb24gDQpmb3IgdGhl IGZhaWxlZA0KcGF0aC4gSG93ZXZlciwgdGhpcyB3aWxsIG1ha2UgbG9uZ2VyIHRpbWUgZGVsYXkg b2YgcmVzdG9yYXRpb24gcHJvY2VzcyAsIA0Kc2luY2UgUENDIG5lZWRzIA0KdG8gc2VuZCBQQ1Jl cSBhbmQgUENFIG5lZWRzIHRvIGNvbXB1dGUgYW5kIHNlbmQgUENSZXAgdG8gUENDLg0KDQpUaGlz IGNvbnRleHQgZG9lc24ndCBkZWZpbmUgYW55IG5ldyBmbGFnIGluIHRoZSBSUCBvYmplY3QsIG9u bHkgYSBuZXcgZmxhZyANCmluIExTUEEgb2JqZWN0Lg0KDQoNCkJlc3QgUmVnYXJkcywNCll1YW5s aW4gQmFvDQoNCg0KIk1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSIgPGN5cmlsLm1h cmdhcmlhQG5zbi5jb20+INC009ogDQoyMDA5LTEwLTE5IDIwOjM5OjExOg0KDQo+IEhpLCANCj4g DQo+IEkgdGhpbmsgdGhlIHRlcm0gcHJlLWNvbmZpZ3VyZWQgcm91dGUgaXMgYSBiaXQgbWlzbGVh ZGluZywgSSB1bmRlcnN0YW5kDQo+IHRoZSBzY2VuYXJpbyBhcyB0aGUgUENDIGFzayBmb3IgMyBy b3V0ZXMsIHRoZSBmaXJzdCBvbmUgd2lsbCBiZQ0KPiBzaWduYWxlZCwgdGhlIDIgb3RoZXIga2Vw dCBpbiBjYXNlIGEgZmFpbHVyZSBoYXBwZW5zIG9uIHRoZSBmaXJzdCByb3V0ZS4NCj4gDQo+IElm IEkgYW0gbm90IG1pc3VuZGVyc3Rvb2QgdGhpcyBjYW4gYmUgYWNoaWV2ZWQgYnkgdXNpbmcgdGhl IHN2ZWMgd2l0aCAzDQo+IHRpbWUgdGhlIHNhbWUgZW5kcG9pbnRzIGFuZCBiYW5kd2lkdGguIA0K PiANCj4gUmVnYXJkaW5nIHRoZSBpbmRpY2F0aW9uIHRoYXQgYSByb3V0ZSBoYXMgY2hhbmdlZCwg dGhlIFBDRSBjb3VsZCBzZW5kIGENCj4gUENSZXAgd2l0aCBSUk8gKG5vdCBhbGxvd2VkIGluIHJm YzU0NDApIGFuZCBFUk8gY29udGFpbmluZyB0aGUgbmV3IFBhdGgsDQo+IGJ1dCB3aGF0IHNob3Vs ZCBiZSB0aGUgcmVxdWVzdCBpZCBvZiB0aGUgUENSZXA/DQo+IA0KPiBJbiBhZGRpdGlvbiB0aGUg UENDIGNvdWxkIGFsc28gYmUgYXdhcmUgdGhhdCB0aGUgcm91dGUgZmFpbGVkIGFuZA0KPiByZXF1 ZXN0IGEgbmV3IFBhdGggY29tcHV0YXRpb24gZm9yIHRoZSBmYWlsZWQgcGF0aC4gDQo+IA0KPiBJ biB0aGlzIGNvbnRleHQgSSBkbyBub3Qgc2VlIHRoZSBuZWVkIHRvIGhhdmUgYSBuZXcgZmxhZyBp biB0aGUgUlANCj4gb2JqZWN0IGZvciB0aGlzIHVzZSBjYXNlLg0KPiANCj4gDQo+IEJlc3QgUmVn YXJkcw0KPiBDeXJpbCBNYXJnYXJpYQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mDQo+IGV4dCBBZHJpYW4gRmFycmVsDQo+IFNlbnQ6IE1vbmRheSwgT2N0 b2JlciAxOSwgMjAwOSAxOjI5IFBNDQo+IFRvOiBCYW8uWXVhbmxpbkB6dGUuY29tLmNuOyBmdS54 aWh1YUB6dGUuY29tLmNuOyB4aWUuZ2FuZ0B6dGUuY29tLmNuDQo+IENjOiBwY2VAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtQY2VdIEktRA0KPiBBY3Rpb246ZHJhZnQtYmFvLXBjZS1wcmUtY29u ZmlndXJlZC1yb3V0aW5nLTAwLnR4dA0KPiANCj4gV2hpbGUgdGhpcyBpcyBhIHJlYXNvbmFibHkg d2VsbC13cml0dGVuIGRyYWZ0LCBJIGRvbid0IHNlZSB0aGF0IGl0IGFkZHMgDQo+IGFueXRoaW5n IHRvIHdoYXQgd2UgYWxyZWFkeSBoYXZlIGluIHRoZSBjb3JlIFJGQ3MuDQo+IA0KPiBJbiBzZWN0 aW9uIDQuMyB5b3UgaGF2ZS4uLg0KPiANCj4gICAgVGhlcmUgYXJlIHR3byBvcHRpb25zDQo+ICAg IGZvciBQQ0UgdG8gc2VuZCBwcmUtY29uZmlndXJlZCByb3V0ZSBhcyBmb2xsb3dzOg0KPiAgICBQ Q1JlcCBpcyB1c2VkIHRvIHJlc3BvbmQgcm91dGUgY29tcHV0YXRpb24gcmVzdWx0IG5hdHVyYWxs eS4gIElmIGl0DQo+ICAgIGlzIHVzZWQgdG8gc2VuZCBwcmUtY29uZmlndXJlZCByb3V0ZSwgYSBu ZXcgZmxhZyBTSE9VTEQgYmUgZGVmaW5lZCB0bw0KPiAgICBpbmRpY2F0ZSB0aGUgcm91dGUgY2Fy cmllZCBpcyBwcmUtY29uZmlndXJlZCByb3V0ZS4NCj4gDQo+IFR3byBxdWVzdGlvbnM6DQo+IDEu IFdoYXQgaXMgdGhlIG90aGVyIG9wdGlvbj8gWW91IG9ubHkgbGlzdCBvbmUgb3B0aW9uLg0KPiAy LiBXaHkgZG8geW91IG5lZWQgYSBmbGFnIHRvIGluZGljYXRlIHRoYXQgYSByb3V0ZSBpcyBwcmUt DQo+ICAgIGNvbmZpZ3VyZWQ/IFdoeSBkb2VzIHRoZSBQQ0MgY2FyZSBob3cgdGhlIHJvdXRlIHdh cw0KPiAgICBkZXJpdmVkPw0KPiANCj4gWW91IHNsaWdobHR5IGFuc3dlciBxdWVzdGlvbiAyLCBp biBzZWN0aW9uIDUuMSB3aGVyZSB5b3Ugc2F5Li4uDQo+IA0KPiAgICBXaGVuIFBDQyByZXF1ZXN0 cyBwcmUtY29uZmlndXJlZCByb3V0ZQ0KPiANCj4gLi4uYnV0IHdoeSB3b3VsZCB0aGUgUENDIGFz ayBmb3IgYSBwcmUtY29uZmlndXJlZCByb3V0ZT8gSXQganVzdCB3YW50cyBhDQo+IA0KPiByb3V0 ZS4gSWYgdGhlcmUgaXMgYSBwb2xpY3kgdG8gYmUgYXBwbGllZCBieSB0aGUgUENFIGluIHNlbGVj dGlvbiBvZiB0aGUNCj4gDQo+IHJvdXRlLCB0aGlzIHNob3VsZCBiZSBpbmRpY2F0ZWQgdXNpbmcg dGhlIG5vcm1hbCBwb2xpY3kgZnVuY3Rpb25zLiBJZg0KPiB0aGVyZSANCj4gaXMgYW4gb2JqZWN0 aXZlIGZ1bmN0aW9uL2FsZ29yaXRobSB0byBiZSBhcHBsaWVkIGluIHNlbGVjdGluZyB0aGUgcm91 dGUsDQo+IA0KPiB0aGlzIHNob3VsZCBiZSBpbmRpY2F0ZWQgdXNpbmcgdGhlIE9GIG9iamVjdC4N Cj4gDQo+IFNvIEkgdGhpbmsgdGhhdCB5b3UgZG9uJ3QgbmVlZCB0aGUgcHJlLWNvbmZpZ3VyZWQg cm91dGUgZmxhZy4NCj4gDQo+IENoZWVycywNCj4gQWRyaWFuIA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUGNlIG1haWxpbmcgbGlzdA0K PiBQY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w Y2UNCj4gDQoNCg== --=_alternative 0030951E48257655_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIDwvZm9udD48dHQ+PGZvbnQg c2l6ZT0yPkN5cmlsPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiw8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBm b3IgeW91ciBjb21tZW50cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPklmIHlvdSBmaW5kIGEgYmV0dGVyIHRlcm0gdG8gc3Vic3RpdHV0ZQ0KdGhlIHRl cm0gPC9mb250Pjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7cHJlLWNvbmZpZ3VyZWQgcm91dGUmcXVv dDssIHBsZWFzZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+bGV0IG1lIGtub3cu IEFueW9uZSB3aG8gaXMgaW50ZXJlc3RlZCBpcyB3ZWxjb21lZA0KdG8gYmUgYSBjby1hdXRob3Iu PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5TaW5jZSB0aGUgbWFpbiBp ZGVhIG9mIHRoaXMgZHJhZnQgaXMgdG8gc29sdmUgdGhlDQpwb3RlbnRpYWwgcHJvYmxlbSBvZiB1 bmF2YWlsYWJpbGl0eTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+b2YgcHJlLWNv bmZpZ3VyZWQgcm91dGVzLCBzbyBJIGRvbid0IHRoaW5rIGl0IHdpbGwNCmJlIGFjaGlldmVkIGJ5 IHVzaW5nIHRoZSBzdmVjLWxpc3QuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5C ZWF1c2UgdXNpbmcgc3ZlYyB3aXRoIG11bHRpIHRpbWVzIGNhbid0IHByb3ZpZGUgdGhlDQpyZXF1 ZXN0ZWQgcGF0aCBpcyBhdmFpbGFibGUgd2hlbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+dGhlIHByaW1hcnkgcGF0aCBmYWlscy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPlRoZXJlIHJlYWxseSBleGlzdHMgYSBwcm9ibGVtIG9mIHJlcXVlc3QgaWQg b2YgdGhlDQpQQ1JlcCwgaWYgeW91IGhhdmUgYW55IGdvb2Q8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPmlkZWEsIHdlIGNhbiBjb29wZXJhdGUuPC9mb250PjwvdHQ+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5QQ0MgY2FuIGJlIGF3YXJlIHRoYXQgdGhlIHJvdXRlIGZhaWxl ZCBhbmQgcmVxdWVzdA0KYSBuZXcgUGF0aCBjb21wdXRhdGlvbiBmb3IgdGhlIGZhaWxlZDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+cGF0aC4gSG93ZXZlciwgdGhpcyB3aWxsIG1h a2UgbG9uZ2VyIHRpbWUgZGVsYXkgb2YNCnJlc3RvcmF0aW9uIHByb2Nlc3MgLCBzaW5jZSBQQ0Mg bmVlZHMgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj50byBzZW5kIFBDUmVxIGFu ZCBQQ0UgbmVlZHMgdG8gY29tcHV0ZSBhbmQgc2VuZCBQQ1JlcA0KdG8gUENDLjwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhpcyBjb250ZXh0IGRvZXNuJ3QgZGVmaW5l IGFueSBuZXcgZmxhZyBpbiB0aGUgUlANCm9iamVjdCwgb25seSBhIG5ldyBmbGFnIGluIExTUEEg b2JqZWN0LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQpCZXN0IFJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5ZdWFubGluIEJhbzwvZm9udD4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZxdW90O01hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSZxdW90OyAmbHQ7 Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbSZndDsNCtC009ogMjAwOS0xMC0xOSAyMDozOToxMTo8YnI+ DQo8YnI+DQomZ3Q7IEhpLCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayB0aGUgdGVybSBw cmUtY29uZmlndXJlZCByb3V0ZSBpcyBhIGJpdCBtaXNsZWFkaW5nLCBJIHVuZGVyc3RhbmQ8YnI+ DQomZ3Q7IHRoZSBzY2VuYXJpbyBhcyB0aGUgUENDIGFzayBmb3IgMyByb3V0ZXMsIHRoZSBmaXJz dCBvbmUgd2lsbCBiZTxicj4NCiZndDsgc2lnbmFsZWQsIHRoZSAyIG90aGVyIGtlcHQgaW4gY2Fz ZSBhIGZhaWx1cmUgaGFwcGVucyBvbiB0aGUgZmlyc3QNCnJvdXRlLjxicj4NCiZndDsgPGJyPg0K Jmd0OyBJZiBJIGFtIG5vdCBtaXN1bmRlcnN0b29kIHRoaXMgY2FuIGJlIGFjaGlldmVkIGJ5IHVz aW5nIHRoZSBzdmVjIHdpdGgNCjM8YnI+DQomZ3Q7IHRpbWUgdGhlIHNhbWUgZW5kcG9pbnRzIGFu ZCBiYW5kd2lkdGguIDxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRpbmcgdGhlIGluZGljYXRp b24gdGhhdCBhIHJvdXRlIGhhcyBjaGFuZ2VkLCB0aGUgUENFIGNvdWxkIHNlbmQNCmE8YnI+DQom Z3Q7IFBDUmVwIHdpdGggUlJPIChub3QgYWxsb3dlZCBpbiByZmM1NDQwKSBhbmQgRVJPIGNvbnRh aW5pbmcgdGhlIG5ldw0KUGF0aCw8YnI+DQomZ3Q7IGJ1dCB3aGF0IHNob3VsZCBiZSB0aGUgcmVx dWVzdCBpZCBvZiB0aGUgUENSZXA/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIGFkZGl0aW9uIHRo ZSBQQ0MgY291bGQgYWxzbyBiZSBhd2FyZSB0aGF0IHRoZSByb3V0ZSBmYWlsZWQgYW5kPGJyPg0K Jmd0OyByZXF1ZXN0IGEgbmV3IFBhdGggY29tcHV0YXRpb24gZm9yIHRoZSBmYWlsZWQgcGF0aC4g PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIHRoaXMgY29udGV4dCBJIGRvIG5vdCBzZWUgdGhlIG5l ZWQgdG8gaGF2ZSBhIG5ldyBmbGFnIGluIHRoZSBSUDxicj4NCiZndDsgb2JqZWN0IGZvciB0aGlz IHVzZSBjYXNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3QgUmVnYXJkczxi cj4NCiZndDsgQ3lyaWwgTWFyZ2FyaWE8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IHBjZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KT2Y8YnI+DQomZ3Q7IGV4dCBBZHJp YW4gRmFycmVsPGJyPg0KJmd0OyBTZW50OiBNb25kYXksIE9jdG9iZXIgMTksIDIwMDkgMToyOSBQ TTxicj4NCiZndDsgVG86IEJhby5ZdWFubGluQHp0ZS5jb20uY247IGZ1LnhpaHVhQHp0ZS5jb20u Y247IHhpZS5nYW5nQHp0ZS5jb20uY248YnI+DQomZ3Q7IENjOiBwY2VAaWV0Zi5vcmc8YnI+DQom Z3Q7IFN1YmplY3Q6IFJlOiBbUGNlXSBJLUQ8YnI+DQomZ3Q7IEFjdGlvbjpkcmFmdC1iYW8tcGNl LXByZS1jb25maWd1cmVkLXJvdXRpbmctMDAudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoaWxl IHRoaXMgaXMgYSByZWFzb25hYmx5IHdlbGwtd3JpdHRlbiBkcmFmdCwgSSBkb24ndCBzZWUgdGhh dCBpdA0KYWRkcyA8YnI+DQomZ3Q7IGFueXRoaW5nIHRvIHdoYXQgd2UgYWxyZWFkeSBoYXZlIGlu IHRoZSBjb3JlIFJGQ3MuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIHNlY3Rpb24gNC4zIHlvdSBo YXZlLi4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGVyZSBhcmUgdHdvIG9w dGlvbnM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtmb3IgUENFIHRvIHNlbmQgcHJlLWNvbmZpZ3Vy ZWQgcm91dGUgYXMgZm9sbG93czo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtQQ1JlcCBpcyB1c2Vk IHRvIHJlc3BvbmQgcm91dGUgY29tcHV0YXRpb24gcmVzdWx0IG5hdHVyYWxseS4NCiZuYnNwO0lm IGl0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7aXMgdXNlZCB0byBzZW5kIHByZS1jb25maWd1cmVk IHJvdXRlLCBhIG5ldyBmbGFnIFNIT1VMRA0KYmUgZGVmaW5lZCB0bzxicj4NCiZndDsgJm5ic3A7 ICZuYnNwO2luZGljYXRlIHRoZSByb3V0ZSBjYXJyaWVkIGlzIHByZS1jb25maWd1cmVkIHJvdXRl Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUd28gcXVlc3Rpb25zOjxicj4NCiZndDsgMS4gV2hhdCBp cyB0aGUgb3RoZXIgb3B0aW9uPyBZb3Ugb25seSBsaXN0IG9uZSBvcHRpb24uPGJyPg0KJmd0OyAy LiBXaHkgZG8geW91IG5lZWQgYSBmbGFnIHRvIGluZGljYXRlIHRoYXQgYSByb3V0ZSBpcyBwcmUt PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Y29uZmlndXJlZD8gV2h5IGRvZXMgdGhlIFBDQyBjYXJl IGhvdyB0aGUgcm91dGUgd2FzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ZGVyaXZlZD88YnI+DQom Z3Q7IDxicj4NCiZndDsgWW91IHNsaWdobHR5IGFuc3dlciBxdWVzdGlvbiAyLCBpbiBzZWN0aW9u IDUuMSB3aGVyZSB5b3Ugc2F5Li4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtX aGVuIFBDQyByZXF1ZXN0cyBwcmUtY29uZmlndXJlZCByb3V0ZTxicj4NCiZndDsgPGJyPg0KJmd0 OyAuLi5idXQgd2h5IHdvdWxkIHRoZSBQQ0MgYXNrIGZvciBhIHByZS1jb25maWd1cmVkIHJvdXRl PyBJdCBqdXN0IHdhbnRzDQphPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHJvdXRlLiBJZiB0aGVyZSBp cyBhIHBvbGljeSB0byBiZSBhcHBsaWVkIGJ5IHRoZSBQQ0UgaW4gc2VsZWN0aW9uDQpvZiB0aGU8 YnI+DQomZ3Q7IDxicj4NCiZndDsgcm91dGUsIHRoaXMgc2hvdWxkIGJlIGluZGljYXRlZCB1c2lu ZyB0aGUgbm9ybWFsIHBvbGljeSBmdW5jdGlvbnMuDQpJZjxicj4NCiZndDsgdGhlcmUgPGJyPg0K Jmd0OyBpcyBhbiBvYmplY3RpdmUgZnVuY3Rpb24vYWxnb3JpdGhtIHRvIGJlIGFwcGxpZWQgaW4g c2VsZWN0aW5nIHRoZQ0Kcm91dGUsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHRoaXMgc2hvdWxkIGJl IGluZGljYXRlZCB1c2luZyB0aGUgT0Ygb2JqZWN0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBTbyBJ IHRoaW5rIHRoYXQgeW91IGRvbid0IG5lZWQgdGhlIHByZS1jb25maWd1cmVkIHJvdXRlIGZsYWcu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7IEFkcmlhbiA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7IFBjZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IFBjZUBpZXRmLm9yZzxicj4N CiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2U8YnI+DQomZ3Q7 IDxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 0030951E48257655_=-- From takeda.tomonori@lab.ntt.co.jp Tue Oct 20 03:33:38 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4D43A6874 for ; Tue, 20 Oct 2009 03:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDcBwUM6ZRA0 for ; Tue, 20 Oct 2009 03:33:37 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 9D4053A6840 for ; Tue, 20 Oct 2009 03:33:37 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.3/8.14.3) with ESMTP id n9KAXiRx013521 for ; Tue, 20 Oct 2009 19:33:44 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 94BC96ACA for ; Tue, 20 Oct 2009 19:33:44 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 751156A40 for ; Tue, 20 Oct 2009 19:33:44 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.55]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n9KAXfxK016873 for ; Tue, 20 Oct 2009 19:33:44 +0900 (JST) Message-ID: <4ADD9189.6040003@lab.ntt.co.jp> Date: Tue, 20 Oct 2009 19:31:37 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Pce] Status of draft-ietf-pce-inter-layer-req X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 10:33:38 -0000 Hi, It would be good time to inform status of this draft. http://www.ietf.org/id/draft-ietf-pce-inter-layer-req-10.txt The authors think that we have captured all of the requirements and that the draft is complete. We note that there is some solutions work, but that it has not introduced any more requirements, and we think that progressing this draft now would be helpful to the people doing the solutions work. Thank you, Tomonori From julien.meuric@orange-ftgroup.com Tue Oct 20 08:44:04 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55FA28C139 for ; Tue, 20 Oct 2009 08:44:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqxDhTbOdxl3 for ; Tue, 20 Oct 2009 08:44:04 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 94B5D28C138 for ; Tue, 20 Oct 2009 08:44:03 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 17:44:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 17:44:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slot Request for IETF 76 Thread-Index: AcpRnCnl9bSnL3e7TZqV/M7/YwaHSg== From: To: X-OriginalArrivalTime: 20 Oct 2009 15:44:09.0952 (UTC) FILETIME=[2A46EE00:01CA519C] Subject: [Pce] Slot Request for IETF 76 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 15:44:05 -0000 Hi PCE-ers. As you know, the PCE WG session in Hiroshima is scheduled on Friday at 1 = PM. Should you need a (or several) slot(s) in the agenda, you can send = your requests to me and JP. You may also CC Dan, the WG secretary. Thanks, Julien From zhangfatai@huawei.com Thu Oct 22 01:54:29 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E013A682D for ; Thu, 22 Oct 2009 01:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.92 X-Spam-Level: * X-Spam-Status: No, score=1.92 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R01ot+yLfSrg for ; Thu, 22 Oct 2009 01:54:28 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id A4BD33A63EC for ; Thu, 22 Oct 2009 01:54:27 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRW005IYREQ8X@szxga02-in.huawei.com> for pce@ietf.org; Thu, 22 Oct 2009 16:54:26 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRW00LBAREQ8T@szxga02-in.huawei.com> for pce@ietf.org; Thu, 22 Oct 2009 16:54:26 +0800 (CST) Received: from z41162b ([10.70.76.112]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRW00L42REQ58@szxml04-in.huawei.com> for pce@ietf.org; Thu, 22 Oct 2009 16:54:26 +0800 (CST) Date: Thu, 22 Oct 2009 16:54:25 +0800 From: Fatai Zhang To: Adrian Farrel , "Margaria, Cyril (NSN - DE/Munich)" , Bao.Yuanlin@zte.com.cn, fu.xihua@zte.com.cn, xie.gang@zte.com.cn Message-id: <01d501ca52f5$42001fd0$704c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_uiD7efwyTNxQgTJIrgk7pw)" X-Priority: 3 X-MSMail-priority: Normal References: <20091019083001.8E8C528C0D8@core3.amsl.com> <6F6E3ADF045940EB8042709796C04996@your029b8cecfe> Cc: pce@ietf.org Subject: Re: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 08:54:29 -0000 This is a multi-part message in MIME format. --Boundary_(ID_uiD7efwyTNxQgTJIrgk7pw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, I am also wondering what is PCE. Can PCE give a route or routes to someone unsolicitedly without path computation request (PCReq) from PCC? Thanks Fatai Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Adrian Farrel To: Margaria, Cyril (NSN - DE/Munich) ; Bao.Yuanlin@zte.com.cn ; fu.xihua@zte.com.cn ; xie.gang@zte.com.cn Cc: pce@ietf.org Sent: Monday, October 19, 2009 9:20 PM Subject: Re: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt Hi Cyril, Fine with what you say, but... We did consider allowing the PCE to push unsolicited routes to the PCC. We decided this was not actually the correct information or processing flow. The point is that a "new route" is only available if a new computation is performed. But the PCE only performs computations on demand. How would it know that the network event should cause it to perform a new computation, and how would it know whether the newly computed route was wanted by the PCC. However a third party tool (for example, the NMS, or the VNTM, depending on the scenario) should be able to perform this function that is heavily associated with local network and per-LSP policy. In these cases, it is the management entity that is requesting path computations as the PCC, and it will push those paths to the LER according to policy. Of course, the LER could be the PCC and could request the paths, but it is less likely to be in control of the necessary triggers. This behavior is actually very similar to what you might expect for reoptimization. Cheers, Adrian ----- Original Message ----- From: "Margaria, Cyril (NSN - DE/Munich)" To: "Adrian Farrel" ; ; ; Cc: Sent: Monday, October 19, 2009 1:39 PM Subject: RE: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt Hi, I think the term pre-configured route is a bit misleading, I understand the scenario as the PCC ask for 3 routes, the first one will be signaled, the 2 other kept in case a failure happens on the first route. If I am not misunderstood this can be achieved by using the svec with 3 time the same endpoints and bandwidth. Regarding the indication that a route has changed, the PCE could send a PCRep with RRO (not allowed in rfc5440) and ERO containing the new Path, but what should be the request id of the PCRep? In addition the PCC could also be aware that the route failed and request a new Path computation for the failed path. In this context I do not see the need to have a new flag in the RP object for this use case. Best Regards Cyril Margaria -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of ext Adrian Farrel Sent: Monday, October 19, 2009 1:29 PM To: Bao.Yuanlin@zte.com.cn; fu.xihua@zte.com.cn; xie.gang@zte.com.cn Cc: pce@ietf.org Subject: Re: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt While this is a reasonably well-written draft, I don't see that it adds anything to what we already have in the core RFCs. In section 4.3 you have... There are two options for PCE to send pre-configured route as follows: PCRep is used to respond route computation result naturally. If it is used to send pre-configured route, a new flag SHOULD be defined to indicate the route carried is pre-configured route. Two questions: 1. What is the other option? You only list one option. 2. Why do you need a flag to indicate that a route is pre- configured? Why does the PCC care how the route was derived? You slighlty answer question 2, in section 5.1 where you say... When PCC requests pre-configured route ...but why would the PCC ask for a pre-configured route? It just wants a route. If there is a policy to be applied by the PCE in selection of the route, this should be indicated using the normal policy functions. If there is an objective function/algorithm to be applied in selecting the route, this should be indicated using the OF object. So I think that you don't need the pre-configured route flag. Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_uiD7efwyTNxQgTJIrgk7pw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi all,
 
I am also wondering what is PCE.
 
Can PCE give a route or routes to someone unsolicitedly without path computation request (PCReq) from PCC?
 
 
 
Thanks
 
Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- Original Message -----
Sent: Monday, October 19, 2009 9:20 PM
Subject: Re: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt

Hi Cyril,

Fine with what you say, but...

We did consider allowing the PCE to push unsolicited routes to the PCC. We
decided this was not actually the correct information or processing flow.

The point is that a "new route" is only available if a new computation is
performed. But the PCE only performs computations on demand. How would it
know that the network event should cause it to perform a new computation,
and how would it know whether the newly computed route was wanted by the
PCC.

However a third party tool (for example, the NMS, or the VNTM, depending on
the scenario) should be able to perform this function that is heavily
associated with local network and per-LSP policy. In these cases, it is the
management entity that is requesting path computations as the PCC, and it
will push those paths to the LER according to policy.

Of course, the LER could be the PCC and could request the paths, but it is
less likely to be in control of the necessary triggers. This behavior is
actually very similar to what you might expect for reoptimization.

Cheers,
Adrian

----- Original Message -----
From: "Margaria, Cyril (NSN - DE/Munich)" <cyril.margaria@nsn.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>; <Bao.Yuanlin@zte.com.cn>;
<fu.xihua@zte.com.cn>; <xie.gang@zte.com.cn>
Cc: <pce@ietf.org>
Sent: Monday, October 19, 2009 1:39 PM
Subject: RE: [Pce] I-D Action:draft-bao-pce-pre-configured-routing-00.txt


Hi,

I think the term pre-configured route is a bit misleading, I understand
the scenario as the PCC ask for 3 routes, the first one will be
signaled, the 2 other kept in case a failure happens on the first route.

If I am not misunderstood this can be achieved by using the svec with 3
time the same endpoints and bandwidth.

Regarding the indication that a route has changed, the PCE could send a
PCRep with RRO (not allowed in rfc5440) and ERO containing the new Path,
but what should be the request id of the PCRep?

In addition the PCC could also be aware that the route failed and
request a new Path computation for the failed path.

In this context I do not see the need to have a new flag in the RP
object for this use case.


Best Regards
Cyril Margaria

-----Original Message-----
From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of
ext Adrian Farrel
Sent: Monday, October 19, 2009 1:29 PM
To: Bao.Yuanlin@zte.com.cn; fu.xihua@zte.com.cn; xie.gang@zte.com.cn
Cc: pce@ietf.org
Subject: Re: [Pce] I-D
Action:draft-bao-pce-pre-configured-routing-00.txt

While this is a reasonably well-written draft, I don't see that it adds
anything to what we already have in the core RFCs.

In section 4.3 you have...

   There are two options
   for PCE to send pre-configured route as follows:
   PCRep is used to respond route computation result naturally.  If it
   is used to send pre-configured route, a new flag SHOULD be defined to
   indicate the route carried is pre-configured route.

Two questions:
1. What is the other option? You only list one option.
2. Why do you need a flag to indicate that a route is pre-
   configured? Why does the PCC care how the route was
   derived?

You slighlty answer question 2, in section 5.1 where you say...

   When PCC requests pre-configured route

...but why would the PCC ask for a pre-configured route? It just wants a

route. If there is a policy to be applied by the PCE in selection of the

route, this should be indicated using the normal policy functions. If
there
is an objective function/algorithm to be applied in selecting the route,

this should be indicated using the OF object.

So I think that you don't need the pre-configured route flag.

Cheers,
Adrian

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

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--Boundary_(ID_uiD7efwyTNxQgTJIrgk7pw)-- From root@core3.amsl.com Mon Oct 26 05:00:01 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E9D1F28C24A; Mon, 26 Oct 2009 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026120001.E9D1F28C24A@core3.amsl.com> Date: Mon, 26 Oct 2009 05:00:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-disc-mib-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Definitions of Managed Objects for Path Computation Element Discovery Author(s) : E. Stephan, et al. Filename : draft-ietf-pce-disc-mib-04.txt Pages : 24 Date : 2009-10-26 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing Path Computation Elements Discovery. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Stephan, et al. Expires April 27, 2009 [page 1] draft-ietf-pce-disc-mib-04 October 2009 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disc-mib-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-disc-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26045148.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 05:15:01 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A87703A6A6D; Mon, 26 Oct 2009 05:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026121501.A87703A6A6D@core3.amsl.com> Date: Mon, 26 Oct 2009 05:15:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-tc-mib-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Definitions of Textual Conventions for Path Computation Element Author(s) : E. Stephan, et al. Filename : draft-ietf-pce-tc-mib-05.txt Pages : 6 Date : 2009-10-26 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Stephan, et al. [page 1] draft-ietf-pce-tc-mib-05 October 2009 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-tc-mib-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-tc-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26050320.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 12:30:02 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2ED9D3A6AD8; Mon, 26 Oct 2009 12:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026193002.2ED9D3A6AD8@core3.amsl.com> Date: Mon, 26 Oct 2009 12:30:02 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-pcep-p2mp-extensions-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 19:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Author(s) : Q. Zhao, et al. Filename : draft-ietf-pce-pcep-p2mp-extensions-05.txt Pages : 31 Date : 2009-10-26 Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 28, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-p2mp-extensions-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-pcep-p2mp-extensions-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26122215.I-D@ietf.org> --NextPart-- From julien.meuric@orange-ftgroup.com Wed Oct 28 01:48:01 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3727728C0FA for ; Wed, 28 Oct 2009 01:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IFUwCKOC+TL for ; Wed, 28 Oct 2009 01:48:00 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id CD6E128C0EE for ; Wed, 28 Oct 2009 01:47:59 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 09:48:13 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 28 Oct 2009 09:48:11 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "LS97 - SG15 OTNT Standardization Work Plan" Thread-Index: AcpXq2FAY0o+3+nxRS26ZWdvK6OVGA== From: To: X-OriginalArrivalTime: 28 Oct 2009 08:48:13.0231 (UTC) FILETIME=[623783F0:01CA57AB] Subject: [Pce] FW: New Liaison Statement, "LS97 - SG15 OTNT Standardization Work Plan" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 08:48:01 -0000 SGkuDQoNCkZvciBzb21lIHJlYXNvbiwgdGhlIGNvcHkgb2YgbWVzc2FnZSBiZWxvdyB3YXMgZGlz Y2FyZGVkIGJlZm9yZSByZWFjaGluZyB0aGUgUENFIG1haWxpbmcgbGlzdC4NCg0KQ29tbWVudHMg YXJlIGV4cGVjdGVkIGZyb20gSUVURiAoQ0NBTVAsIFBDRSBhbmQgTVBMUyBXR3MpIGJlZm9yZSBB cHJpbCAzMHRoIDIwMTAuDQoNCkp1bGllbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBHcmVnIEpvbmVzKElUVS1UIFNHIDE1KSBbbWFpbHRvOnRzYnNnMTVAaXR1LmludF0g DQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI3LCAyMDA5IDExOjQyIFBNDQpUbzogZGJydW5nYXJk QGF0dC5jb207IGxiZXJnZXJAbGFibi5uZXQ7IGpwdkBjaXNjby5jb207IE1FVVJJQyBKdWxpZW4g UkQtQ09SRS1MQU47IHN3YWxsb3dAY2lzY28uY29tOyBsb2FAcGkubnUNCkNjOiBwYWZAY2lzY28u Y29tOyBhZHJpYW4uZmFycmVsQGh1YXdlaS5jb207IHJjYWxsb25AanVuaXBlci5uZXQ7IGNjYW1w QGlldGYub3JnOyBwY2VAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IHlvaWNoaS5tYWVkYUBudHQt YXQuY28uanA7IHNqdHJvd2JyaWRnZUBhbGNhdGVsLWx1Y2VudC5jb207IHRzYnNnMTVAaXR1Lmlu dDsgZ3JlZy5qb25lc0BpdHUuaW50OyBoaXJvc2hpLm90YUBpdHUuaW50OyBnZW9yZ2VfeW91bmdA bGFicy5hdHQuY29tOyBrb2lrZS55b3NoaW5vcmlAbGFiLm50dC5jby5qcA0KU3ViamVjdDogTmV3 IExpYWlzb24gU3RhdGVtZW50LCAiTFM5NyAtIFNHMTUgT1ROVCBTdGFuZGFyZGl6YXRpb24gV29y ayBQbGFuIiANCg0KDQpUaXRsZTogTFM5NyAtIFNHMTUgT1ROVCBTdGFuZGFyZGl6YXRpb24gV29y ayBQbGFuDQpTdWJtaXNzaW9uIERhdGU6IDIwMDktMTAtMjcNClVSTCBvZiB0aGUgSUVURiBXZWIg cGFnZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9wdWJsaWMvbGlhaXNvbl9kZXRhaWwu Y2dpP2RldGFpbF9pZD02MDUgDQpQbGVhc2UgcmVwbHkgYnkgMjAxMC0wNC0zMA0KDQpGcm9tOiBH cmVnIEpvbmVzKElUVS1UIFNHIDE1KSA8dHNic2cxNUBpdHUuaW50Pg0KVG86IElFVEYgKGNjYW1w LCBwY2UgYW5kIG1wbHMgV0dzKShkYnJ1bmdhcmRAYXR0LmNvbSxsYmVyZ2VyQGxhYm4ubmV0LGpw dkBjaXNjby5jb20sanVsaWVuLm1ldXJpY0BvcmFuZ2UtZnRncm91cC5jb20sc3dhbGxvd0BjaXNj by5jb20sbG9hQHBpLm51KQ0KQ2M6IHBhZkBjaXNjby5jb20NCmFkcmlhbi5mYXJyZWxAaHVhd2Vp LmNvbQ0KcmNhbGxvbkBqdW5pcGVyLm5ldA0KY2NhbXBAaWV0Zi5vcmcNCnBjZUBpZXRmLm9yZw0K bXBsc0BpZXRmLm9yZw0KeW9pY2hpLm1hZWRhQG50dC1hdC5jby5qcA0Kc2p0cm93YnJpZGdlQGFs Y2F0ZWwtbHVjZW50LmNvbQ0KUmVwb25zZSBDb250YWN0OiB0c2JzZzE1QGl0dS5pbnQNCmdyZWcu am9uZXNAaXR1LmludA0KaGlyb3NoaS5vdGFAaXR1LmludA0KVGVjaG5pY2FsIENvbnRhY3Q6IGdl b3JnZV95b3VuZ0BsYWJzLmF0dC5jb20NCmtvaWtlLnlvc2hpbm9yaUBsYWIubnR0LmNvLmpwDQpQ dXJwb3NlOiBGb3IgY29tbWVudCANCkJvZHk6IA0KQXR0YWNobWVudChzKToNCiAgICAgTFM5NyAt IFNHMTUgT1ROVCBTdGFuZGFyZGl6YXRpb24gV29yayBQbGFuIC0gcGRmIChodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvY3VtZW50cy9MSUFJU09OL2ZpbGU3MjEucGRmKQ0KICAgICBMUzk3 IC0gRHJhZnQgUmV2aXNlZCBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3JrcyAmIFRlY2hub2xvZ2ll cyBTdGFuZGFyZGl6YXRpb24gV29yayBQbGFuLCBJc3N1ZSAxMiAtIHBkZiAoaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2N1bWVudHMvTElBSVNPTi9maWxlNzIyLnBkZikNCg0KDQoNCg==