From cyril.margaria@nsn.com Tue Jan 5 01:44:36 2010 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 57D993A68B1 for ; Tue, 5 Jan 2010 01:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 6uWgPz9NAyfD for ; Tue, 5 Jan 2010 01:44:35 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 29FF13A6842 for ; Tue, 5 Jan 2010 01:44:34 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o059iVhS020994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Jan 2010 10:44:31 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o059iVWn029607 for ; Tue, 5 Jan 2010 10:44:31 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 10:44:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jan 2010 10:44:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft: draft-margaria-pce-gmpls-pcep-extensions-00 Thread-Index: AcqN663m8A/aENpPQwq+b5EeaGmVxg== From: "Margaria, Cyril (NSN - DE/Munich)" To: X-OriginalArrivalTime: 05 Jan 2010 09:44:31.0418 (UTC) FILETIME=[AE46B1A0:01CA8DEB] Subject: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00 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, 05 Jan 2010 09:44:36 -0000 Dear PCEers, We have just submitted a new drat on "PCEP extensions for GMPLS".=20 The draft specifies optional extensions to the PCEP protocol to comply = with the GMPLS requirements for PCEP. These extensions may be also = applicable in the WSON context. We urge you to review the draft and provide your valuable comments.=20 The draft can be found at = http://www.ietf.org/internet-drafts/draft-margaria-pce-gmpls-pcep-extensi= ons-00.txt=20 Thanks and best regards, Cyril Margaria Nokia Siemens Networks GmbH & Co. KG Broadband Connectivity Solutions St.Martin-Str. 76 D-81541 M=FCnchen Germany mailto:cyril.margaria@nsn.com Phone: +49-89-5159-16934 Fax: +49-89-636-40288 ----------------------------------------------------------------=20 Nokia Siemens Networks GmbH & Co. KG Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 WEEE-Reg.-Nr.: DE 52984304 Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens = Networks Management GmbH Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri = Kivinen Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 From gregimirsky@gmail.com Tue Jan 5 15:20:07 2010 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 6075B3A681A for ; Tue, 5 Jan 2010 15:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqtHS6j8FlSm for ; Tue, 5 Jan 2010 15:20:05 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id CCBAA3A659C for ; Tue, 5 Jan 2010 15:20:04 -0800 (PST) Received: by bwz23 with SMTP id 23so10749478bwz.29 for ; Tue, 05 Jan 2010 15:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=eJv7TdBhmFW4JJCGIovcYKOOmcsN+pRagn7zSFOwsJ0=; b=leMepP3nmRAGUhXvFM3uoL81nw901+Wy7ouQDAarS5X2217+tqqADCDJeOh29rL2cI ypO96xZQ2/L7SHncMPDfyiQ4q5spfRUquKsno77gi1AlNxW/zLy9wQMlWgW1jtmINrz/ bEevX7L/Is1+OJDPfufVFF/W9uj0Ce6KG25o0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GnVMoLVnt2viSQI3YksS+Q2ltRFhTQpjCwu96qRGXvwIVwBFdH1NBTsgpa//Yt6ZG5 WNYxQUmG/t0cKl1Cswx/y0m2sKH21wL6jgQ87ncs8Geco3M/B1OCdWaEH72jMJp7/PRK ZQT2oyW7lSTAfw5o/W+tQopqnvOtxixPgRINU= MIME-Version: 1.0 Received: by 10.204.160.131 with SMTP id n3mr5102185bkx.122.1262733600114; Tue, 05 Jan 2010 15:20:00 -0800 (PST) In-Reply-To: <4E30AC53-5DCA-4220-80DA-200F90BE955D@cisco.com> References: <001801ca81e8$3f3dc910$0702a8c0@china.huawei.com> <4E30AC53-5DCA-4220-80DA-200F90BE955D@cisco.com> Date: Tue, 5 Jan 2010 15:19:59 -0800 Message-ID: <787be2781001051519t27c01af8g14d9f40502ce87c8@mail.gmail.com> From: Greg Mirsky To: JP Vasseur Content-Type: multipart/alternative; boundary=0015175cd8beae481c047c731335 Cc: pce@ietf.org, Quintin Zhao Subject: Re: [Pce] Inter-domain-p2mp-procedures 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, 05 Jan 2010 23:20:07 -0000 --0015175cd8beae481c047c731335 Content-Type: text/plain; charset=ISO-8859-1 Hi Quintin and JP, in regard to applicability of p2p FRR protection of links of p2mp LSP I agree with JP that such applicability is questionable and very much depends on network topology, its meshiness. I think that because we can not guarantee that the immediate LSR will be the merging point of p2p backup LSP one can not assume that a single p2p can be used to provide protection for local link failure case. I believe that strong case can be made to recommend use p2mp for local link protection as well as when node protection required. Regards, Greg 2009/12/23 JP Vasseur > Hi, > > > On Dec 21, 2009, at 3:49 AM, Quintin Zhao wrote: > > JP, >> >> Good question! I guess that I should use "more complex to be implemented" >> instead of "less applicable" in my previous email when I refer to using >> FRR >> for P2MP node protection. >> >> > Well this is arguable though .. > > > What I was trying to mean is that p2p backup is easily to be used for the >> link protection for p2mp. To use FRR for the node protection in p2mp, it >> is >> not that straight forward comparing to p2p node protection, especially >> from >> the point view of bandwidth cost and label allocation. >> > > Well it all depends on how you compute your P2P backup, and this may be > used > for a very short period of time. There are excellent off-line algorithms to > achieve > some good level of efficiency. > > > For example, to use >> the p2p tunnel to backup the branch node, we need multiple p2p tunnels to >> protect a single branch node. If the p2mp backup tunnel is used for the >> branch node protection, then the upstream label allocation might be >> needed. >> > > Which is not a major issue. See long discussions on the list some time ago > on the > subject matter. > > Thanks. > > JP. > > > >> >> Regards, >> Quintin >> >> -----Original Message----- >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Saturday, December 19, 2009 4:51 AM >> To: Quintin Zhao >> Cc: pce@ietf.org >> Subject: Re: [Pce] Inter-domain-p2mp-procedures >> >> Hi, >> >> On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote: >> >> >>> JP, >>> >>> Thanks for your comments and suggestions. >>> >>> I agree with you that for a quickly recovery, FRR is a good choice. >>> For the >>> p2mp TE LSP, if the failures are about link failures, FRR can be >>> used for >>> the recovery. If the failures are about the p2mp nodes which can be >>> the >>> root/branch/bud/leaf nodes, FRR might not be an easy way to cover >>> these >>> cases. >>> >> >> What makes you think that the use of FRR is less applicable to node >> failures ? >> (for which you could either use a set of P2P backup or a single P2MP >> backup) >> >> Thanks >> >> JP. >> >> This may lead to other possible solutions and the pre-computed >>> backup sub-tree or the whole backup tree might be needed for the >>> possible >>> solutions. As you mentioned, using the FRR itself will eventually >>> need the >>> head end reoptimization using a make before break. >>> >>> The pre-computed backup p2mp path/sub-path or the new computed path >>> during >>> reoptimization process using make before breaks are the optimal path >>> subject >>> to the OF and all other current constrains when the path is computed >>> by the >>> PCE. I agree with you that we can not draw the conclusion on the >>> potentially >>> level of sub-optimality of performing local reroute as opposed to >>> global >>> reoptimization. >>> >>> Also we can not draw the conclusion if these backup path or >>> optimized path >>> after the failure is better or worse than the primary path. These >>> pre-computed backup paths/sub-paths or the optimized paths under the >>> failure >>> condition are the best path which can be used for the recovery of the >>> failure while satisfying all the conditions. >>> >>> Regards, >>> Quintin >>> >>> >>> -----Original Message----- >>> From: JP Vasseur [mailto:jvasseur@cisco.com] >>> Sent: Thursday, December 17, 2009 1:26 PM >>> To: Quintin Zhao >>> Cc: pce@ietf.org >>> Subject: Re: [Pce] Inter-domain-p2mp-procedures >>> >>> Hi, >>> >>> Note that this is a fairly well-known issue. The aim of local repair >>> has always been to quickly recover from the failure. The degree of >>> resources guarantees and optimality depends on the amount of resources >>> dedicated to backup, several assumptions with regards to potential >>> simultaneous failures, the algorithms used to pre-compute backup >>> tunnels, etc ... The approach taken by P2P FRR has been to first >>> locally reroute and trigger a head-end reoptimization using a make >>> before break. I do not think that you can draw any conclusion on the >>> potentially level of sub-optimality of performing local reroute as >>> opposed to global reoptimization. It depends on a number of factors. >>> >>> JP. >>> >>> On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: >>> >>> >>>> Hello PCE'rs, >>>> >>>> I would like to follow-up on some discussions from our PCE WG >>>> session last >>>> month. Specifically regarding Dajiang's failure and recomputation >>>> observations on our draft. We are very interested to hear comments >>>> regarding >>>> the need for computing secondary paths in the event of failure. >>>> Currently >>>> our thinking is to recompute the sub-tree based in the domain where >>>> the >>>> failure has occurred. In this case we would not need to perform a >>>> recalculation of the entire tree. We could also recompute the entire >>>> tree, >>>> and avoid the failed areas, as long as the TED has the updated >>>> topology. >>>> Realistically one might have a backup core tree pre-computed so you >>>> can >>>> switch over in the event of failure. There are also other >>>> considerations. >>>> Would a partial recomputation provide a "worse" SPT or MCT tree, or >>>> would a >>>> full tree recomputation provide a "better" SPT or MCT? I can think of >>>> scenarios for both a partial and full recomputation, so perhaps we >>>> need to >>>> implement both but allow the PCC to decide when to issue a partial >>>> or full >>>> recomputation based on some criterion. >>>> >>>> Thanks, >>>> >>>> Quintin >>>> >>>> _______________________________________________ >>>> 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 > --0015175cd8beae481c047c731335 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Quintin and JP,
in regard to applicability of p2p FRR protection of l= inks of p2mp LSP I agree with JP that such applicability is questionable an= d very much depends on network topology, its meshiness. I think that becaus= e we can not guarantee that the immediate LSR will be the merging point of = p2p backup LSP one can not assume that a single p2p can be used to provide = protection for local link failure case. I believe that strong case can be m= ade to recommend use p2mp for local link protection as well as when node pr= otection required.

Regards,
Greg

2009/12/23 JP Vasseu= r <jvasseur@cisc= o.com>
Hi,


On Dec 21, 2009, at 3:49 AM, Quintin Zhao wrote:

JP,

Good question! I guess that I should use "more complex to be implement= ed"
instead of "less applicable" in my previous email when I refer to= using FRR
for P2MP node protection.


Well this is arguable though ..


What I was trying to mean is that p2p backup is easily to be used for the link protection for p2mp. To use FRR for the node protection in p2mp, it is=
not that straight forward comparing to p2p node protection, especially from=
the point view of bandwidth cost and label allocation.

Well it all depends on how you compute your P2P backup, and this may be use= d
for a very short period of time. There are excellent off-line algorithms to= achieve
some good level of efficiency.


For example, to use
the p2p tunnel to backup the branch node, we need multiple p2p tunnels to protect a single branch node. If the p2mp backup tunnel is used for the
branch node protection, then the upstream label allocation might be needed.=

Which is not a major issue. See long discussions on the list some time ago = on the
subject matter.

Thanks.

JP.




Regards,
Quintin

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Saturday, December 19, 2009 4:51 AM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote:


JP,

Thanks for your comments and suggestions.

I agree with you that for a quickly recovery, FRR is a good choice.
For the
p2mp TE LSP, if the failures are about link failures, FRR can be
used for
the recovery. If the failures are about the p2mp nodes which can be
the
root/branch/bud/leaf nodes, FRR might not be an easy way to cover
these
cases.=A1=A1

What makes you think that the use of FRR is less applicable to node
failures ?
(for which you could either use a set of P2P backup or a single P2MP
backup)

Thanks

JP.

This may lead to other possible solutions and the pre-computed
backup sub-tree or the whole backup tree might be needed for the
possible
solutions. As you mentioned, using the FRR itself will eventually
need the
head end reoptimization using a make before break.

The pre-computed backup p2mp path/sub-path or the new computed path
during
reoptimization process using make before breaks are the optimal path
subject
to the OF and all other current constrains when the path is computed
by the
PCE. I agree with you that we can not draw the conclusion on the
potentially
level of sub-optimality of performing local reroute as opposed to
global
reoptimization.

Also we can not draw the conclusion if these backup path or
optimized path
after the failure is better or worse than the primary path. These
pre-computed backup paths/sub-paths or the optimized paths under the
failure
condition are the best path which can be used for the recovery of the
failure while satisfying all the conditions.

Regards,
Quintin


-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Thursday, December 17, 2009 1:26 PM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

Note that this is a fairly well-known issue. The aim of local repair
has always been to quickly recover from the failure. The degree of
resources guarantees and optimality depends on the amount of resources
dedicated to backup, several assumptions with regards to potential
simultaneous failures, the algorithms used to pre-compute backup
tunnels, etc ... The approach taken by P2P FRR has been to first
locally reroute and trigger a head-end reoptimization using a make
before break. I do not think that you can draw any conclusion on the
potentially level of sub-optimality of performing local reroute as
opposed to global reoptimization. It depends on a number of factors.

JP.

On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote:


Hello PCE'rs,

I would like to follow-up on some discussions from our PCE WG
session last
month. Specifically regarding Dajiang's failure and recomputation
observations on our draft. We are very interested to hear comments
regarding
the need for computing secondary paths in the event of failure.
Currently
our thinking is to recompute the sub-tree based in the domain where
the
failure has occurred. In this case we would not need to perform a
recalculation of the entire tree. We could also recompute the entire
tree,
and avoid the failed areas, as long as the TED has the updated
topology.
Realistically one might have a backup core tree pre-computed so you
can
switch over in the event of failure. There are also other
considerations.
Would a partial recomputation provide a "worse" SPT or MCT tree, = or
would a
full tree recomputation provide a "better" SPT or MCT? I can thin= k of
scenarios for both a partial and full recomputation, so perhaps we
need to
implement both but allow the PCC to decide when to issue a partial
or full
recomputation based on some criterion.

Thanks,

Quintin

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




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

--0015175cd8beae481c047c731335-- From zhangfatai@huawei.com Tue Jan 5 17:34:09 2010 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 864953A6923 for ; Tue, 5 Jan 2010 17:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 Sou3cubQnpbc for ; Tue, 5 Jan 2010 17:34:08 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 523103A62C1 for ; Tue, 5 Jan 2010 17:34:08 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVS003JCXOTI6@szxga04-in.huawei.com> for pce@ietf.org; Wed, 06 Jan 2010 09:34:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVS00ITCXOTKU@szxga04-in.huawei.com> for pce@ietf.org; Wed, 06 Jan 2010 09:34:05 +0800 (CST) Received: from Z41162C ([10.70.76.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVS006C3XOSSO@szxml04-in.huawei.com> for pce@ietf.org; Wed, 06 Jan 2010 09:34:05 +0800 (CST) Date: Wed, 06 Jan 2010 09:34:04 +0800 From: Fatai Zhang To: "Margaria, Cyril (NSN - DE/Munich)" Message-id: <007401ca8e70$54e97db0$604c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_gS76qGZ7Dw9cGWddnRreCw)" X-Priority: 3 X-MSMail-priority: Normal References: Cc: pce@ietf.org Subject: Re: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00 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, 06 Jan 2010 01:34:09 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gS76qGZ7Dw9cGWddnRreCw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 SGkgQ3lyaWwsDQoNCldoYXQgYSBjb2luY2lkZW5jZSB0byBzZWUgeW91ciBkcmFmdCBhZnRlciB3 ZSBqdXN0IHN1Ym1pdGVkIG91ciBkcmFmdCAoZHJhZnQtemhhbmctcGNlLXBjZXAtZXh0ZW5zaW9u cy1mb3Itc2RoLTAwLnR4dCkgW2RyYWZ0LXpoYW5nLXBjZXAtZXh0XS4NCg0KR3JlYXQgbWluZHMg dGhpbmsgYWxpa2UuICBIYXBweSB0byBzZWUgdGhhdCBoYXBwZW5lZC4NCg0KSG9wZSB5b3UgY2Fu IHNwYXJlIHNvbWUgdGltZSB0byByZXZpZXcgW2RyYWZ0LXpoYW5nLXBjZXAtZXh0XS4gV2UgYXJl IGxvb2tpbmcgZm9yd2FyZCB0byBkaXNjdXNzaW5nIG1vcmUgd2l0aCB5b3UuDQoNCldlIGFsc28g aW52aXRlIGFsbCB0aGUgZXhwZXJ0cyBmcm9tIFBDRSBXRyB0byByZXZpZXcgIFtkcmFmdC16aGFu Zy1wY2VwLWV4dF0uDQoNCg0KDQpUaGFua3MNCiANCkZhdGFpDQogDQpBZHZhbmNlZCBUZWNobm9s b2d5IERlcGFydG1lbnQNCldpcmVsaW5lIE5ldHdvcmtpbmcgQnVzaW5lc3MgVW5pdA0KSHVhd2Vp IFRlY2hub2xvZ2llcyBDby4sIExURC4NCkh1YXdlaSBCYXNlLCBCYW50aWFuLCBMb25nZ2FuZywN ClNoZW56aGVuIDUxODEyOSBQLlIuQ2hpbmENClRlbDogKzg2LTc1NS0yODk3MjkxMg0KRmF4OiAr ODYtNzU1LTI4OTcyOTM1DQoNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJv bTogIk1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSIgPGN5cmlsLm1hcmdhcmlhQG5z bi5jb20+DQpUbzogPHBjZUBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMDUsIDIw MTAgNTo0NCBQTQ0KU3ViamVjdDogW1BjZV0gTmV3IGRyYWZ0OiBkcmFmdC1tYXJnYXJpYS1wY2Ut Z21wbHMtcGNlcC1leHRlbnNpb25zLTAwDQoNCg0KDQpEZWFyIFBDRWVycywNCg0KV2UgaGF2ZSBq dXN0IHN1Ym1pdHRlZCBhIG5ldyBkcmF0IG9uICJQQ0VQIGV4dGVuc2lvbnMgZm9yIEdNUExTIi4g DQpUaGUgZHJhZnQgc3BlY2lmaWVzIG9wdGlvbmFsIGV4dGVuc2lvbnMgdG8gdGhlIFBDRVAgcHJv dG9jb2wgdG8gY29tcGx5IHdpdGggdGhlIEdNUExTIHJlcXVpcmVtZW50cyBmb3IgUENFUC4gVGhl c2UgZXh0ZW5zaW9ucyBtYXkgYmUgYWxzbyBhcHBsaWNhYmxlIGluIHRoZSBXU09OIGNvbnRleHQu DQpXZSB1cmdlIHlvdSB0byByZXZpZXcgdGhlIGRyYWZ0IGFuZCBwcm92aWRlIHlvdXIgdmFsdWFi bGUgY29tbWVudHMuIA0KVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdCBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXJnYXJpYS1wY2UtZ21wbHMtcGNlcC1leHRlbnNp b25zLTAwLnR4dCANCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMsDQpDeXJpbCBNYXJnYXJpYQ0K DQpOb2tpYSBTaWVtZW5zIE5ldHdvcmtzIEdtYkggJiBDby4gS0cNCkJyb2FkYmFuZCBDb25uZWN0 aXZpdHkgU29sdXRpb25zDQpTdC5NYXJ0aW4tU3RyLiA3Ng0KRC04MTU0MSBN/G5jaGVuDQpHZXJt YW55DQptYWlsdG86Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbQ0KUGhvbmU6ICs0OS04OS01MTU5LTE2 OTM0DQpGYXg6ICAgKzQ5LTg5LTYzNi00MDI4OA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCk5va2lhIFNpZW1lbnMgTmV0 d29ya3MgR21iSCAmIENvLiBLRw0KU2l0eiBkZXIgR2VzZWxsc2NoYWZ0OiBN/G5jaGVuIC8gUmVn aXN0ZXJlZCBvZmZpY2U6IE11bmljaA0KUmVnaXN0ZXJnZXJpY2h0OiBN/G5jaGVuIC8gQ29tbWVy Y2lhbCByZWdpc3RyeTogTXVuaWNoLCBIUkEgODg1MzcNCldFRUUtUmVnLi1Oci46IERFIDUyOTg0 MzA0DQoNClBlcnP2bmxpY2ggaGFmdGVuZGUgR2VzZWxsc2NoYWZ0ZXJpbiAvIEdlbmVyYWwgUGFy dG5lcjogTm9raWEgU2llbWVucyBOZXR3b3JrcyBNYW5hZ2VtZW50IEdtYkgNCkdlc2No5GZ0c2xl aXR1bmcgLyBCb2FyZCBvZiBEaXJlY3RvcnM6IEx5ZGlhIFNvbW1lciwgT2xhZiBIb3JzdGhlbWtl DQpWb3JzaXR6ZW5kZXIgZGVzIEF1ZnNpY2h0c3JhdHMgLyBDaGFpcm1hbiBvZiBzdXBlcnZpc29y eSBib2FyZDogTGF1cmkgS2l2aW5lbg0KU2l0eiBkZXIgR2VzZWxsc2NoYWZ0OiBN/G5jaGVuIC8g UmVnaXN0ZXJlZCBvZmZpY2U6IE11bmljaA0KUmVnaXN0ZXJnZXJpY2h0OiBN/G5jaGVuIC8gQ29t bWVyY2lhbCByZWdpc3RyeTogTXVuaWNoLCBIUkIgMTYzNDE2DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNl --Boundary_(ID_gS76qGZ7Dw9cGWddnRreCw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4yOTEyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmIGJhY2tncm91bmQ9IiI+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWw+SGkgQ3lyaWwsPEJSPjxCUj5XaGF0IGEgY29pbmNpZGVuY2UgdG8gc2VlIHlvdXIgZHJh ZnQgDQphZnRlciB3ZSBqdXN0IHN1Ym1pdGVkIG91ciBkcmFmdCANCihkcmFmdC16aGFuZy1wY2Ut cGNlcC1leHRlbnNpb25zLWZvci1zZGgtMDAudHh0KSANCltkcmFmdC16aGFuZy1wY2VwLWV4dF0u PEJSPjxCUj5HcmVhdCBtaW5kcyB0aGluayBhbGlrZS4mbmJzcDsgSGFwcHkgdG8gc2VlIHRoYXQg DQpoYXBwZW5lZC48QlI+PEJSPkhvcGUgeW91IGNhbiBzcGFyZSBzb21lIHRpbWUgdG8gcmV2aWV3 IFtkcmFmdC16aGFuZy1wY2VwLWV4dF0uIA0KV2UmbmJzcDthcmUgbG9va2luZyBmb3J3YXJkIHRv IGRpc2N1c3NpbmcgbW9yZSB3aXRoIHlvdS48QlI+PEJSPldlIGFsc28gaW52aXRlIA0KYWxsIHRo ZSBleHBlcnRzIGZyb20gUENFIFdHIHRvIHJldmlldyZuYnNwOyBbZHJhZnQtemhhbmctcGNlcC1l eHRdLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj5UaGFua3M8 QlI+Jm5ic3A7PEJSPkZhdGFpPEJSPiZuYnNwOzxCUj5BZHZhbmNlZCBUZWNobm9sb2d5IA0KRGVw YXJ0bWVudDxCUj5XaXJlbGluZSBOZXR3b3JraW5nIEJ1c2luZXNzIFVuaXQ8QlI+SHVhd2VpIFRl Y2hub2xvZ2llcyBDby4sIA0KTFRELjxCUj5IdWF3ZWkgQmFzZSwgQmFudGlhbiwgTG9uZ2dhbmcs PEJSPlNoZW56aGVuIDUxODEyOSBQLlIuQ2hpbmE8QlI+VGVsOiANCis4Ni03NTUtMjg5NzI5MTI8 QlI+RmF4OiArODYtNzU1LTI4OTcyOTM1PEJSPjxCUj48QlI+PEJSPi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgDQotLS0tLSA8QlI+RnJvbTogIk1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNo KSIgDQombHQ7Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbSZndDs8QlI+VG86ICZsdDtwY2VAaWV0Zi5v cmcmZ3Q7PEJSPlNlbnQ6IFR1ZXNkYXksIA0KSmFudWFyeSAwNSwgMjAxMCA1OjQ0IFBNPEJSPlN1 YmplY3Q6IFtQY2VdIE5ldyBkcmFmdDogDQpkcmFmdC1tYXJnYXJpYS1wY2UtZ21wbHMtcGNlcC1l eHRlbnNpb25zLTAwPEJSPjxCUj48QlI+PEJSPkRlYXIgDQpQQ0VlcnMsPEJSPjxCUj5XZSBoYXZl IGp1c3Qgc3VibWl0dGVkIGEgbmV3IGRyYXQgb24gIlBDRVAgZXh0ZW5zaW9ucyBmb3IgR01QTFMi LiANCjxCUj5UaGUgZHJhZnQgc3BlY2lmaWVzIG9wdGlvbmFsIGV4dGVuc2lvbnMgdG8gdGhlIFBD RVAgcHJvdG9jb2wgdG8gY29tcGx5IHdpdGggDQp0aGUgR01QTFMgcmVxdWlyZW1lbnRzIGZvciBQ Q0VQLiBUaGVzZSBleHRlbnNpb25zIG1heSBiZSBhbHNvIGFwcGxpY2FibGUgaW4gdGhlIA0KV1NP TiBjb250ZXh0LjxCUj5XZSB1cmdlIHlvdSB0byByZXZpZXcgdGhlIGRyYWZ0IGFuZCBwcm92aWRl IHlvdXIgdmFsdWFibGUgDQpjb21tZW50cy4gPEJSPlRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQg DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXJnYXJpYS1wY2Ut Z21wbHMtcGNlcC1leHRlbnNpb25zLTAwLnR4dCANCjxCUj48QlI+VGhhbmtzIGFuZCBiZXN0IHJl Z2FyZHMsPEJSPkN5cmlsIE1hcmdhcmlhPEJSPjxCUj5Ob2tpYSBTaWVtZW5zIE5ldHdvcmtzIA0K R21iSCAmYW1wOyBDby4gS0c8QlI+QnJvYWRiYW5kIENvbm5lY3Rpdml0eSBTb2x1dGlvbnM8QlI+ U3QuTWFydGluLVN0ci4gDQo3NjxCUj5ELTgxNTQxIE38bmNoZW48QlI+R2VybWFueTxCUj5tYWls dG86Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbTxCUj5QaG9uZTogDQorNDktODktNTE1OS0xNjkzNDxC Uj5GYXg6Jm5ic3A7Jm5ic3A7IA0KKzQ5LTg5LTYzNi00MDI4ODxCUj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KPEJSPk5v a2lhIFNpZW1lbnMgTmV0d29ya3MgR21iSCAmYW1wOyBDby4gS0c8QlI+U2l0eiBkZXIgR2VzZWxs c2NoYWZ0OiBN/G5jaGVuIC8gDQpSZWdpc3RlcmVkIG9mZmljZTogTXVuaWNoPEJSPlJlZ2lzdGVy Z2VyaWNodDogTfxuY2hlbiAvIENvbW1lcmNpYWwgcmVnaXN0cnk6IA0KTXVuaWNoLCBIUkEgODg1 Mzc8QlI+V0VFRS1SZWcuLU5yLjogREUgNTI5ODQzMDQ8QlI+PEJSPlBlcnP2bmxpY2ggaGFmdGVu ZGUgDQpHZXNlbGxzY2hhZnRlcmluIC8gR2VuZXJhbCBQYXJ0bmVyOiBOb2tpYSBTaWVtZW5zIE5l dHdvcmtzIE1hbmFnZW1lbnQgDQpHbWJIPEJSPkdlc2No5GZ0c2xlaXR1bmcgLyBCb2FyZCBvZiBE aXJlY3RvcnM6IEx5ZGlhIFNvbW1lciwgT2xhZiANCkhvcnN0aGVta2U8QlI+Vm9yc2l0emVuZGVy IGRlcyBBdWZzaWNodHNyYXRzIC8gQ2hhaXJtYW4gb2Ygc3VwZXJ2aXNvcnkgYm9hcmQ6IA0KTGF1 cmkgS2l2aW5lbjxCUj5TaXR6IGRlciBHZXNlbGxzY2hhZnQ6IE38bmNoZW4gLyBSZWdpc3RlcmVk IG9mZmljZTogDQpNdW5pY2g8QlI+UmVnaXN0ZXJnZXJpY2h0OiBN/G5jaGVuIC8gQ29tbWVyY2lh bCByZWdpc3RyeTogTXVuaWNoLCBIUkIgDQoxNjM0MTY8QlI+PEJSPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPlBjZSBtYWlsaW5nIA0KbGlzdDxCUj5Q Y2VAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2U8 L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_gS76qGZ7Dw9cGWddnRreCw)-- From cyril.margaria@nsn.com Thu Jan 7 05:10:03 2010 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 E1B103A6810 for ; Thu, 7 Jan 2010 05:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 HWz135OiZa-q for ; Thu, 7 Jan 2010 05:10:02 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 18A0C3A676A for ; Thu, 7 Jan 2010 05:10:01 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o07D9hh1030340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2010 14:09:43 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o07D9gdp015240; Thu, 7 Jan 2010 14:09:42 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 14:09:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jan 2010 14:09:41 +0100 Message-ID: In-Reply-To: <007401ca8e70$54e97db0$604c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00 Thread-Index: AcqOcFfxvK4AdyVgQ5iiE93DO815VABHf+pg References: <007401ca8e70$54e97db0$604c460a@china.huawei.com> From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext Fatai Zhang" X-OriginalArrivalTime: 07 Jan 2010 13:09:42.0838 (UTC) FILETIME=[AD47CD60:01CA8F9A] Cc: pce@ietf.org Subject: Re: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00 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, 07 Jan 2010 13:10:04 -0000 Hi Fatai,=20 I am also happy to see work going in this direction.=20 I have some questions and remarks on your draft. Section "4.1. RP Object Extension" The NT field is specifying for which kind of network the request is.=20 I think the information on the type on network could also be represented = by SWITCH-LAYER object from draft-ietf-pce-inter-layer-ext. This information seems also redundant with the encoding and switching = type provided in the "4.1.1. Requested GMPLS Label Information". Its also not clear to me what is the processing of this field, = especially in the case of multilayer network type. Regarding "4.1.1. Requested GMPLS Label Information", its stated that = this object is used if the resources required are requested using = generalized label. Is this to be used in a PCReq or PCRep? To which = generalized labels does this subtlv-refers to, I can see label in the = ERO and the other route object, but those may represent a multi-layer = route, where the generalized labels might have different encodings. = Which labels are meant here? in case a multilayer request is considered and a generalied label is = used, the PCEP may carry labels for several layers, so only considering = the first "Requested GMPLS Label Information " subtlv may not be = sufficient, on the other hand its=20 For the Qos section, the section 4.4.1 does not allow different = forward/reverse Traffic spec as in RFC5467, and its not clear how to = distnguish the old QoS from the new Qos in case of reoptimization = requests. In "4.4.2. LSP Protection Information TLV", I think reusing the RFC4872 = and RFC3471 LSP flags and Link flags would be more in line with RSVP-TE = signaling.=20 In this section its not clear on how to use the Protection information, = some fields seems to go in the direction of a statefull PCE (Segment = Recovery, Associated LSP ID), however its not clear how those fields are = to be used and processed, for instance the associated LSP id can be used = only if the LSP ids are known to the PCE. I am looking forward to discuss those two draft with you. Thanks,=20 Cyril Margaria=20 > ----- Original Message -----=20 > From: ext Fatai Zhang [mailto:zhangfatai@huawei.com]=20 > Sent: Wednesday, January 06, 2010 2:34 AM > To: Margaria, Cyril (NSN - DE/Munich) > Cc: pce@ietf.org; sureshbr@huawei.com > Subject: Re: [Pce] New draft: = draft-margaria-pce-gmpls-pcep-extensions-00 > > > Hi Cyril, >=20 > What a coincidence to see your draft after we just submited our draft = (draft-zhang-pce-pcep-extensions-for-sdh-00.txt) [draft-zhang-pcep-ext]. >=20 > Great minds think alike. Happy to see that happened. >=20 > Hope you can spare some time to review [draft-zhang-pcep-ext]. We are = looking forward to discussing more with you. >=20 > We also invite all the experts from PCE WG to review = [draft-zhang-pcep-ext]. > =20 > =20 >=20 > Thanks > =20 > Fatai > =20 > 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 >=20 >=20 >=20 > > ----- Original Message -----=20 > > From: "Margaria, Cyril (NSN - DE/Munich)" > > To: > > Sent: Tuesday, January 05, 2010 5:44 PM > > Subject: [Pce] New draft: = draft-margaria-pce-gmpls-pcep-extensions-00 > >=20 > >=20 > >=20 > > Dear PCEers, > >=20 > > We have just submitted a new drat on "PCEP extensions for GMPLS".=20 > > The draft specifies optional extensions to the PCEP protocol to = comply with the GMPLS requirements for PCEP. These extensions may be = also applicable in the WSON context. > > We urge you to review the draft and provide your valuable comments.=20 > > The draft can be found at = http://www.ietf.org/internet-drafts/draft-margaria-pce-gmpls-pcep-extensi= ons-00.txt=20 > >=20 > > Thanks and best regards, > > Cyril Margaria > >=20 > > Nokia Siemens Networks GmbH & Co. KG > > Broadband Connectivity Solutions > > St.Martin-Str. 76 > > D-81541 M=FCnchen > > Germany > > mailto:cyril.margaria@nsn.com > > Phone: +49-89-5159-16934 > > Fax: +49-89-636-40288 > > ----------------------------------------------------------------=20 > > Nokia Siemens Networks GmbH & Co. KG > > Sitz der Gesellschaft: M=FCnchen / Registered office: Munich > > Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 > > WEEE-Reg.-Nr.: DE 52984304 > >=20 > > Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia = Siemens Networks Management GmbH > > Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf = Horsthemke > > Vorsitzender des Aufsichtsrats / Chairman of supervisory board: = Lauri Kivinen > > Sitz der Gesellschaft: M=FCnchen / Registered office: Munich > > Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 > >=20 > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce From julien.meuric@orange-ftgroup.com Thu Jan 7 05:57:16 2010 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 7C1F83A6784 for ; Thu, 7 Jan 2010 05:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 Y8VdGCPA8fso for ; Thu, 7 Jan 2010 05:57:15 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 60F823A67EA for ; Thu, 7 Jan 2010 05:57:15 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id B499D1045B1; Thu, 7 Jan 2010 14:57:12 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9B23C27C058; Thu, 7 Jan 2010 14:57:12 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 14:57:12 +0100 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: Thu, 7 Jan 2010 14:57:11 +0100 Message-ID: <22437_1262872632_4B45E838_22437_7085_1_D109C8C97C15294495117745780657AE0C369AF0@ftrdmel1> In-Reply-To: <001901ca81e9$cbdea690$0702a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures Thread-Index: AcqB6cs8TiSNSOV7SDKQ0LgQicHNugNtq9ZQ References: <001901ca81e9$cbdea690$0702a8c0@china.huawei.com> From: To: X-OriginalArrivalTime: 07 Jan 2010 13:57:12.0660 (UTC) FILETIME=[4FE82140:01CA8FA1] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.7.133035 Cc: pce@ietf.org Subject: Re: [Pce] Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures 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, 07 Jan 2010 13:57:16 -0000 Hi Quintin. It is a significant step that authors of both drafts agreed on working on a single document and we congratulate all of you for that. During IETF 76, you also mentioned "Lots of work and analysis ahead" and a need to "continue to review requirements and select the technique that best meets the requirements". Indeed, the current version of the document looks more like a solution list than an actual merge of former proposals. Considering the complexity induced by an inter-domain P2MP extension, we would appreciate before taking any decision that you elaborate on the way you intend to move forward towards a common solution. Thanks Julien ________________________________ From: Quintin Zhao [mailto:qzhao@huawei.com]=20 Hi Co-Chairs and PCE WG, Different parties have been working on solutions for computing P2MP paths across multi-domain networks. At IETF 75 we were requested by JP, to formulate a plan and resolve any issues in order to move the work forward. After calls and emails between draft-ali-pce-brpc-p2mp-ext and draft-zhao-pce-pcep-inter-domain-p2mp-procedure authors, we felt there was concurrence to merge the solutions and work together on a unified solution. At IETF 76 we presented our initial/combined PCE-based Shortest Constrained P2MP Inter-domain TE-LSP solution (draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02).=20 We would like to know if the co-chairs and WG would be in favor of the document becoming a WG draft? Regards, Quintin ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From zhangfatai@huawei.com Thu Jan 7 23:27:18 2010 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 83F233A672E for ; Thu, 7 Jan 2010 23:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 EuF8Gn1XJP8D for ; Thu, 7 Jan 2010 23:27:17 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3CDFD3A63EB for ; Thu, 7 Jan 2010 23:27:12 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVX00B8E3D84Q@szxga01-in.huawei.com> for pce@ietf.org; Fri, 08 Jan 2010 15:27:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVX00MV43D8I9@szxga01-in.huawei.com> for pce@ietf.org; Fri, 08 Jan 2010 15:27:08 +0800 (CST) Received: from Z41162C ([10.70.76.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVX008S83D8W5@szxml04-in.huawei.com> for pce@ietf.org; Fri, 08 Jan 2010 15:27:08 +0800 (CST) Date: Fri, 08 Jan 2010 15:27:08 +0800 From: Fatai Zhang To: "Margaria, Cyril (NSN - DE/Munich)" Message-id: <02cb01ca9033$fc1f9320$604c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_0dJFKVAFufBk9urlqYAJ2g)" X-Priority: 3 X-MSMail-priority: Normal References: <007401ca8e70$54e97db0$604c460a@china.huawei.com> Cc: pce@ietf.org Subject: Re: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00 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, 08 Jan 2010 07:27:18 -0000 This is a multi-part message in MIME format. --Boundary_(ID_0dJFKVAFufBk9urlqYAJ2g) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 SGkgQ3lyaWwsDQoNClRoYW5rcyBmb3IgeW91ciB2YWx1YWJsZSBjb21tZW50cy4gUGxlYXNlIHNl ZSB0aGUgaW4tbGluZSByZXNwb25zZS4NCg0KDQoNClRoYW5rcw0KIA0KRmF0YWkNCiANCkFkdmFu Y2VkIFRlY2hub2xvZ3kgRGVwYXJ0bWVudA0KV2lyZWxpbmUgTmV0d29ya2luZyBCdXNpbmVzcyBV bml0DQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTFRELg0KSHVhd2VpIEJhc2UsIEJhbnRpYW4s IExvbmdnYW5nLA0KU2hlbnpoZW4gNTE4MTI5IFAuUi5DaGluYQ0KVGVsOiArODYtNzU1LTI4OTcy OTEyDQpGYXg6ICs4Ni03NTUtMjg5NzI5MzUNCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQpGcm9tOiAiTWFyZ2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpIiA8Y3lyaWwu bWFyZ2FyaWFAbnNuLmNvbT4NClRvOiAiZXh0IEZhdGFpIFpoYW5nIiA8emhhbmdmYXRhaUBodWF3 ZWkuY29tPg0KQ2M6IDxwY2VAaWV0Zi5vcmc+OyA8c3VyZXNoYnJAaHVhd2VpLmNvbT4NClNlbnQ6 IFRodXJzZGF5LCBKYW51YXJ5IDA3LCAyMDEwIDk6MDkgUE0NClN1YmplY3Q6IFJFOiBbUGNlXSBO ZXcgZHJhZnQ6IGRyYWZ0LW1hcmdhcmlhLXBjZS1nbXBscy1wY2VwLWV4dGVuc2lvbnMtMDANCg0K DQoNCkhpIEZhdGFpLCANCg0KSSBhbSBhbHNvIGhhcHB5IHRvIHNlZSB3b3JrIGdvaW5nIGluIHRo aXMgZGlyZWN0aW9uLiANCkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhbmQgcmVtYXJrcyBvbiB5b3Vy IGRyYWZ0Lg0KDQpTZWN0aW9uICI0LjEuIFJQIE9iamVjdCBFeHRlbnNpb24iDQpUaGUgTlQgZmll bGQgaXMgc3BlY2lmeWluZyBmb3Igd2hpY2gga2luZCBvZiBuZXR3b3JrIHRoZSByZXF1ZXN0IGlz LiANCkkgdGhpbmsgdGhlIGluZm9ybWF0aW9uIG9uIHRoZSB0eXBlIG9uIG5ldHdvcmsgY291bGQg YWxzbyBiZSByZXByZXNlbnRlZCBieSBTV0lUQ0gtTEFZRVIgb2JqZWN0IGZyb20gZHJhZnQtaWV0 Zi1wY2UtaW50ZXItbGF5ZXItZXh0Lg0KVGhpcyBpbmZvcm1hdGlvbiBzZWVtcyBhbHNvIHJlZHVu ZGFudCB3aXRoIHRoZSBlbmNvZGluZyBhbmQgc3dpdGNoaW5nIHR5cGUgcHJvdmlkZWQgaW4gdGhl ICI0LjEuMS4gUmVxdWVzdGVkIEdNUExTIExhYmVsIEluZm9ybWF0aW9uIi4NCkl0cyBhbHNvIG5v dCBjbGVhciB0byBtZSB3aGF0IGlzIHRoZSBwcm9jZXNzaW5nIG9mIHRoaXMgZmllbGQsIGVzcGVj aWFsbHkgaW4gdGhlIGNhc2Ugb2YgbXVsdGlsYXllciBuZXR3b3JrIHR5cGUuDQoNCltGYXRhaV06 IEFncmVlIHdpdGggeW91LiBXZSBjYW4ganVzdCBpZGVudGlmeSBuZXR3b3JrIHR5cGUgKGUuZy4s IFNESCBvciBXRE0uLi4pIHRocm91Z2ggU3dpdGNoaW5nIFR5cGUuDQogDQpSZWdhcmRpbmcgIjQu MS4xLiBSZXF1ZXN0ZWQgR01QTFMgTGFiZWwgSW5mb3JtYXRpb24iLCBpdHMgc3RhdGVkIHRoYXQg dGhpcyBvYmplY3QgaXMgdXNlZCBpZiB0aGUgcmVzb3VyY2VzIHJlcXVpcmVkIGFyZSByZXF1ZXN0 ZWQgdXNpbmcgZ2VuZXJhbGl6ZWQgbGFiZWwuIElzIHRoaXMgdG8gYmUgdXNlZCBpbiBhIFBDUmVx IG9yIFBDUmVwPyBUbyB3aGljaCBnZW5lcmFsaXplZCBsYWJlbHMgZG9lcyB0aGlzIHN1YnRsdi1y ZWZlcnMgdG8sIEkgY2FuIHNlZSBsYWJlbCBpbiB0aGUgRVJPIGFuZCB0aGUgb3RoZXIgcm91dGUg b2JqZWN0LCBidXQgdGhvc2UgbWF5IHJlcHJlc2VudCBhIG11bHRpLWxheWVyIHJvdXRlLCB3aGVy ZSB0aGUgZ2VuZXJhbGl6ZWQgbGFiZWxzIG1pZ2h0IGhhdmUgZGlmZmVyZW50IGVuY29kaW5ncy4g V2hpY2ggbGFiZWxzIGFyZSBtZWFudCBoZXJlPw0KDQpbRmF0YWldOiBJdCBpcyB1c2VkIGluIFBD UmVxIGFuZCBpdCByZWZlcnMgdG8gU0RIIGxheWVyLg0KDQppbiBjYXNlIGEgbXVsdGlsYXllciBy ZXF1ZXN0IGlzIGNvbnNpZGVyZWQgYW5kIGEgZ2VuZXJhbGllZCBsYWJlbCBpcyB1c2VkLCB0aGUg UENFUCBtYXkgY2FycnkgbGFiZWxzIGZvciBzZXZlcmFsIGxheWVycywgc28gb25seSBjb25zaWRl cmluZyB0aGUgZmlyc3QgIlJlcXVlc3RlZCBHTVBMUyBMYWJlbCBJbmZvcm1hdGlvbiAiIHN1YnRs diBtYXkgbm90IGJlIHN1ZmZpY2llbnQsIG9uIHRoZSBvdGhlciBoYW5kIGl0cyANCg0KW0ZhdGFp XTogV2UgaGF2ZSBub3QgY29uc2lkZXJlZCBtdWx0aS1sYXllcmVkIHNjZW5hcmlvLiBJZiBNdXRs aS1sYXllciBzaG91bGQgYmUgY29uc2lkZXJlZCwgd2UgY2FuIHJlLXVzZSB0aGUgZXh0ZW5zaW9u cyBkZWZpbmVkIGluIFtQQ0UtTUxOLUV4dF0uDQoNCkZvciB0aGUgUW9zIHNlY3Rpb24sIHRoZSBz ZWN0aW9uIDQuNC4xIGRvZXMgbm90IGFsbG93IGRpZmZlcmVudCBmb3J3YXJkL3JldmVyc2UgVHJh ZmZpYyBzcGVjIGFzIGluIFJGQzU0NjcsIGFuZCBpdHMgbm90IGNsZWFyIGhvdyB0byBkaXN0bmd1 aXNoIHRoZSBvbGQgUW9TIGZyb20gdGhlIG5ldyBRb3MgaW4gY2FzZSBvZiByZW9wdGltaXphdGlv biByZXF1ZXN0cy4NCg0KW0ZhdGFpXTogT3VyIGRyYWZ0IGlzIGZvciBTREggbmV0d29ya3MuIFdl IGtub3cgdXN1YWxseSB0aGVyZSBpcyBubyB0aGlzIGNhc2UgZm9yIGFzeW1tZXRyaWMgYmFuZHdp ZHRoIGJpZGlyZWN0aW9uYWwgTFNQIGluIFNESCBuZXR3b3JrcyhpLmUuLCBiaWRpcmVjdGlvbmFs IExTUCBpcyBjb25zaWRlcmVkIHdpdGggc2FtZSBRb1Mgb24gYm90aCBkaXJlY3Rpb25zKS4gT2Yg Y291cmNlLCBpZiB3ZSBuZWVkIHRvIGNvdmVyIHRoZSByZXF1aXJlbWVudHMgaW4gUkZDNTQ2Nywg SSB0aGluayB3ZSBjYW4ganVzdCBhZGQgW1Vwc3RyZWFtLUJhbmR3aWR0aF0gdG8gaWRlbnRpZnkg YXN5bW1ldHJpYyBiYW5kd2lkdGguIFJlb3B0aW1pemF0aW9uIGlzIGFscmVhZHkgY2FwdHVyZWQg aW4gUkZDNTQ0MC4NCg0KSW4gIjQuNC4yLiBMU1AgUHJvdGVjdGlvbiBJbmZvcm1hdGlvbiBUTFYi LCBJIHRoaW5rIHJldXNpbmcgdGhlIFJGQzQ4NzIgYW5kIFJGQzM0NzEgTFNQIGZsYWdzIGFuZCBM aW5rIGZsYWdzIHdvdWxkIGJlIG1vcmUgaW4gbGluZSB3aXRoIFJTVlAtVEUgc2lnbmFsaW5nLiAN CkluIHRoaXMgc2VjdGlvbiBpdHMgbm90IGNsZWFyIG9uIGhvdyB0byB1c2UgdGhlIFByb3RlY3Rp b24gaW5mb3JtYXRpb24sIHNvbWUgZmllbGRzIHNlZW1zIHRvIGdvIGluIHRoZSBkaXJlY3Rpb24g b2YgYSBzdGF0ZWZ1bGwgUENFIChTZWdtZW50IFJlY292ZXJ5LCBBc3NvY2lhdGVkIExTUCBJRCks IGhvd2V2ZXIgaXRzIG5vdCBjbGVhciBob3cgdGhvc2UgZmllbGRzIGFyZSB0byBiZSB1c2VkIGFu ZCBwcm9jZXNzZWQsIGZvciBpbnN0YW5jZSB0aGUgYXNzb2NpYXRlZCBMU1AgaWQgY2FuIGJlIHVz ZWQgb25seSBpZiB0aGUgTFNQIGlkcyBhcmUga25vd24gdG8gdGhlIFBDRS4NCg0KW0ZhdGFpXTog V2UgY2FuIHJlZmVyZW5jZSB0aGUgcHJvdGVjdGlvbiBvYmplY3QgZGVmaW5lZCBpbiBSRkM0ODcy IG9yIFJGQzQ4NzMsIGJ1dCB3ZSBjYW4gbm90IHNpbXBseSBjb3B5IHRoZSBvYmplY3QgZGVmaW5l ZCBpbiBSRkM0ODcyIG9yIFJGQzQ4NzMgKGkuZS4sIHNvbWUgZmllbGRzIHNob3VsZCBiZSByZW1v dmVkIGFuZCBhZGQgc29tZSBuZXcgZmllbGRzIGFkZGl0aW9uYWxseSkuIFdlIHdpbGwgY2hlY2sg dGhlIG9iamVjdCBhZ2FpbiBhbmQgcmVtb3ZlIEFzc29jaWF0ZWQgTFNQIElELg0KDQpJIGFtIGxv b2tpbmcgZm9yd2FyZCB0byBkaXNjdXNzIHRob3NlIHR3byBkcmFmdCB3aXRoIHlvdS4NCg0KVGhh bmtzLCANCkN5cmlsIE1hcmdhcmlhIA0KDQoNCg0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIA0KPiBGcm9tOiBleHQgRmF0YWkgWmhhbmcgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5j b21dIA0KPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMDYsIDIwMTAgMjozNCBBTQ0KPiBUbzog TWFyZ2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpDQo+IENjOiBwY2VAaWV0Zi5vcmc7IHN1 cmVzaGJyQGh1YXdlaS5jb20NCj4gU3ViamVjdDogUmU6IFtQY2VdIE5ldyBkcmFmdDogZHJhZnQt bWFyZ2FyaWEtcGNlLWdtcGxzLXBjZXAtZXh0ZW5zaW9ucy0wMA0KPg0KPg0KPiBIaSBDeXJpbCwN Cj4gDQo+IFdoYXQgYSBjb2luY2lkZW5jZSB0byBzZWUgeW91ciBkcmFmdCBhZnRlciB3ZSBqdXN0 IHN1Ym1pdGVkIG91ciBkcmFmdCAoZHJhZnQtemhhbmctcGNlLXBjZXAtZXh0ZW5zaW9ucy1mb3It c2RoLTAwLnR4dCkgW2RyYWZ0LXpoYW5nLXBjZXAtZXh0XS4NCj4gDQo+IEdyZWF0IG1pbmRzIHRo aW5rIGFsaWtlLiAgSGFwcHkgdG8gc2VlIHRoYXQgaGFwcGVuZWQuDQo+IA0KPiBIb3BlIHlvdSBj YW4gc3BhcmUgc29tZSB0aW1lIHRvIHJldmlldyBbZHJhZnQtemhhbmctcGNlcC1leHRdLiBXZSBh cmUgbG9va2luZyBmb3J3YXJkIHRvIGRpc2N1c3NpbmcgbW9yZSB3aXRoIHlvdS4NCj4gDQo+IFdl IGFsc28gaW52aXRlIGFsbCB0aGUgZXhwZXJ0cyBmcm9tIFBDRSBXRyB0byByZXZpZXcgIFtkcmFm dC16aGFuZy1wY2VwLWV4dF0uDQo+ICANCj4gIA0KPiANCj4gVGhhbmtzDQo+ICANCj4gRmF0YWkN Cj4gIA0KPiBBZHZhbmNlZCBUZWNobm9sb2d5IERlcGFydG1lbnQNCj4gV2lyZWxpbmUgTmV0d29y a2luZyBCdXNpbmVzcyBVbml0DQo+IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMVEQuDQo+IEh1 YXdlaSBCYXNlLCBCYW50aWFuLCBMb25nZ2FuZywNCj4gU2hlbnpoZW4gNTE4MTI5IFAuUi5DaGlu YQ0KPiBUZWw6ICs4Ni03NTUtMjg5NzI5MTINCj4gRmF4OiArODYtNzU1LTI4OTcyOTM1DQo+IA0K PiANCj4gDQo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4gPiBGcm9tOiAiTWFy Z2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpIiA8Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbT4N Cj4gPiBUbzogPHBjZUBpZXRmLm9yZz4NCj4gPiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDA1LCAy MDEwIDU6NDQgUE0NCj4gPiBTdWJqZWN0OiBbUGNlXSBOZXcgZHJhZnQ6IGRyYWZ0LW1hcmdhcmlh LXBjZS1nbXBscy1wY2VwLWV4dGVuc2lvbnMtMDANCj4gPiANCj4gPiANCj4gPiANCj4gPiBEZWFy IFBDRWVycywNCj4gPiANCj4gPiBXZSBoYXZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IGRyYXQgb24g IlBDRVAgZXh0ZW5zaW9ucyBmb3IgR01QTFMiLiANCj4gPiBUaGUgZHJhZnQgc3BlY2lmaWVzIG9w dGlvbmFsIGV4dGVuc2lvbnMgdG8gdGhlIFBDRVAgcHJvdG9jb2wgdG8gY29tcGx5IHdpdGggdGhl IEdNUExTIHJlcXVpcmVtZW50cyBmb3IgUENFUC4gVGhlc2UgZXh0ZW5zaW9ucyBtYXkgYmUgYWxz byBhcHBsaWNhYmxlIGluIHRoZSBXU09OIGNvbnRleHQuDQo+ID4gV2UgdXJnZSB5b3UgdG8gcmV2 aWV3IHRoZSBkcmFmdCBhbmQgcHJvdmlkZSB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLiANCj4gPiBU aGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LW1hcmdhcmlhLXBjZS1nbXBscy1wY2VwLWV4dGVuc2lvbnMtMDAudHh0IA0KPiA+ IA0KPiA+IFRoYW5rcyBhbmQgYmVzdCByZWdhcmRzLA0KPiA+IEN5cmlsIE1hcmdhcmlhDQo+ID4g DQo+ID4gTm9raWEgU2llbWVucyBOZXR3b3JrcyBHbWJIICYgQ28uIEtHDQo+ID4gQnJvYWRiYW5k IENvbm5lY3Rpdml0eSBTb2x1dGlvbnMNCj4gPiBTdC5NYXJ0aW4tU3RyLiA3Ng0KPiA+IEQtODE1 NDEgTfxuY2hlbg0KPiA+IEdlcm1hbnkNCj4gPiBtYWlsdG86Y3lyaWwubWFyZ2FyaWFAbnNuLmNv bQ0KPiA+IFBob25lOiArNDktODktNTE1OS0xNjkzNA0KPiA+IEZheDogICArNDktODktNjM2LTQw Mjg4DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSANCj4gPiBOb2tpYSBTaWVtZW5zIE5ldHdvcmtzIEdtYkggJiBDby4g S0cNCj4gPiBTaXR6IGRlciBHZXNlbGxzY2hhZnQ6IE38bmNoZW4gLyBSZWdpc3RlcmVkIG9mZmlj ZTogTXVuaWNoDQo+ID4gUmVnaXN0ZXJnZXJpY2h0OiBN/G5jaGVuIC8gQ29tbWVyY2lhbCByZWdp c3RyeTogTXVuaWNoLCBIUkEgODg1MzcNCj4gPiBXRUVFLVJlZy4tTnIuOiBERSA1Mjk4NDMwNA0K PiA+IA0KPiA+IFBlcnP2bmxpY2ggaGFmdGVuZGUgR2VzZWxsc2NoYWZ0ZXJpbiAvIEdlbmVyYWwg UGFydG5lcjogTm9raWEgU2llbWVucyBOZXR3b3JrcyBNYW5hZ2VtZW50IEdtYkgNCj4gPiBHZXNj aORmdHNsZWl0dW5nIC8gQm9hcmQgb2YgRGlyZWN0b3JzOiBMeWRpYSBTb21tZXIsIE9sYWYgSG9y c3RoZW1rZQ0KPiA+IFZvcnNpdHplbmRlciBkZXMgQXVmc2ljaHRzcmF0cyAvIENoYWlybWFuIG9m IHN1cGVydmlzb3J5IGJvYXJkOiBMYXVyaSBLaXZpbmVuDQo+ID4gU2l0eiBkZXIgR2VzZWxsc2No YWZ0OiBN/G5jaGVuIC8gUmVnaXN0ZXJlZCBvZmZpY2U6IE11bmljaA0KPiA+IFJlZ2lzdGVyZ2Vy aWNodDogTfxuY2hlbiAvIENvbW1lcmNpYWwgcmVnaXN0cnk6IE11bmljaCwgSFJCIDE2MzQxNg0K PiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gUGNlIG1haWxpbmcgbGlzdA0KPiA+IFBjZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNl --Boundary_(ID_0dJFKVAFufBk9urlqYAJ2g) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4yOTEyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmIGJhY2tncm91bmQ9IiI+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWw+SGkgQ3lyaWwsPEJSPjxCUj5UaGFua3MgZm9yIHlvdXIgdmFsdWFibGUgY29tbWVudHMu IFBsZWFzZSANCnNlZSB0aGUgaW4tbGluZSANCnJlc3BvbnNlLjxCUj48QlI+PEJSPjxCUj5UaGFu a3M8QlI+Jm5ic3A7PEJSPkZhdGFpPEJSPiZuYnNwOzxCUj5BZHZhbmNlZCANClRlY2hub2xvZ3kg RGVwYXJ0bWVudDxCUj5XaXJlbGluZSBOZXR3b3JraW5nIEJ1c2luZXNzIFVuaXQ8QlI+SHVhd2Vp IA0KVGVjaG5vbG9naWVzIENvLiwgTFRELjxCUj5IdWF3ZWkgQmFzZSwgQmFudGlhbiwgTG9uZ2dh bmcsPEJSPlNoZW56aGVuIDUxODEyOSANClAuUi5DaGluYTxCUj5UZWw6ICs4Ni03NTUtMjg5NzI5 MTI8QlI+RmF4OiArODYtNzU1LTI4OTcyOTM1PEJSPjxCUj48QlI+PEJSPi0tLS0tIA0KT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSA8QlI+RnJvbTogIk1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVu aWNoKSIgDQombHQ7Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbSZndDs8QlI+VG86ICJleHQgRmF0YWkg WmhhbmciIA0KJmx0O3poYW5nZmF0YWlAaHVhd2VpLmNvbSZndDs8QlI+Q2M6ICZsdDtwY2VAaWV0 Zi5vcmcmZ3Q7OyANCiZsdDtzdXJlc2hickBodWF3ZWkuY29tJmd0OzxCUj5TZW50OiBUaHVyc2Rh eSwgSmFudWFyeSAwNywgMjAxMCA5OjA5IA0KUE08QlI+U3ViamVjdDogUkU6IFtQY2VdIE5ldyBk cmFmdDogDQpkcmFmdC1tYXJnYXJpYS1wY2UtZ21wbHMtcGNlcC1leHRlbnNpb25zLTAwPEJSPjxC Uj48QlI+PEJSPkhpIEZhdGFpLCA8QlI+PEJSPkkgDQphbSBhbHNvIGhhcHB5IHRvIHNlZSB3b3Jr IGdvaW5nIGluIHRoaXMgZGlyZWN0aW9uLiA8QlI+SSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFuZCAN CnJlbWFya3Mgb24geW91ciBkcmFmdC48QlI+PEJSPlNlY3Rpb24gIjQuMS4gUlAgT2JqZWN0IEV4 dGVuc2lvbiI8QlI+VGhlIE5UIGZpZWxkIA0KaXMgc3BlY2lmeWluZyBmb3Igd2hpY2gga2luZCBv ZiBuZXR3b3JrIHRoZSByZXF1ZXN0IGlzLiA8QlI+SSB0aGluayB0aGUgDQppbmZvcm1hdGlvbiBv biB0aGUgdHlwZSBvbiBuZXR3b3JrIGNvdWxkIGFsc28gYmUgcmVwcmVzZW50ZWQgYnkgU1dJVENI LUxBWUVSIA0Kb2JqZWN0IGZyb20gZHJhZnQtaWV0Zi1wY2UtaW50ZXItbGF5ZXItZXh0LjxCUj5U aGlzIGluZm9ybWF0aW9uIHNlZW1zIGFsc28gDQpyZWR1bmRhbnQgd2l0aCB0aGUgZW5jb2Rpbmcg YW5kIHN3aXRjaGluZyB0eXBlIHByb3ZpZGVkIGluIHRoZSAiNC4xLjEuIFJlcXVlc3RlZCANCkdN UExTIExhYmVsIEluZm9ybWF0aW9uIi48QlI+SXRzIGFsc28gbm90IGNsZWFyIHRvIG1lIHdoYXQg aXMgdGhlIHByb2Nlc3Npbmcgb2YgDQp0aGlzIGZpZWxkLCBlc3BlY2lhbGx5IGluIHRoZSBjYXNl IG9mIG11bHRpbGF5ZXIgbmV0d29yayB0eXBlLjxCUj48Rk9OVCANCmNvbG9yPSMwMDAwZmY+PC9G T05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBjb2xvcj0jMDAw MGZmPltGYXRhaV06IEFncmVlIHdpdGggeW91LiBXZSBjYW4ganVzdCANCmlkZW50aWZ5IG5ldHdv cmsgdHlwZSAoZS5nLiwgU0RIIG9yIFdETS4uLikgdGhyb3VnaCBTd2l0Y2hpbmcgDQpUeXBlLjwv Rk9OVD48QlI+Jm5ic3A7PEJSPlJlZ2FyZGluZyAiNC4xLjEuIFJlcXVlc3RlZCBHTVBMUyBMYWJl bCBJbmZvcm1hdGlvbiIsIA0KaXRzIHN0YXRlZCB0aGF0IHRoaXMgb2JqZWN0IGlzIHVzZWQgaWYg dGhlIHJlc291cmNlcyByZXF1aXJlZCBhcmUgcmVxdWVzdGVkIA0KdXNpbmcgZ2VuZXJhbGl6ZWQg bGFiZWwuIElzIHRoaXMgdG8gYmUgdXNlZCBpbiBhIFBDUmVxIG9yIFBDUmVwPyBUbyB3aGljaCAN CmdlbmVyYWxpemVkIGxhYmVscyBkb2VzIHRoaXMgc3VidGx2LXJlZmVycyB0bywgSSBjYW4gc2Vl IGxhYmVsIGluIHRoZSBFUk8gYW5kIA0KdGhlIG90aGVyIHJvdXRlIG9iamVjdCwgYnV0IHRob3Nl IG1heSByZXByZXNlbnQgYSBtdWx0aS1sYXllciByb3V0ZSwgd2hlcmUgdGhlIA0KZ2VuZXJhbGl6 ZWQgbGFiZWxzIG1pZ2h0IGhhdmUgZGlmZmVyZW50IGVuY29kaW5ncy4gV2hpY2ggbGFiZWxzIGFy ZSBtZWFudCANCmhlcmU/PEJSPjxGT05UIGNvbG9yPSMwMDAwZmY+PC9GT05UPjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBjb2xvcj0jMDAwMGZmPltGYXRhaV06IEl0 IGlzIHVzZWQgaW4gUENSZXEgYW5kIGl0IA0KcmVmZXJzIHRvIFNESCBsYXllci48L0ZPTlQ+PEJS PjxCUj5pbiBjYXNlIGEgbXVsdGlsYXllciByZXF1ZXN0IGlzIGNvbnNpZGVyZWQgDQphbmQgYSBn ZW5lcmFsaWVkIGxhYmVsIGlzIHVzZWQsIHRoZSBQQ0VQIG1heSBjYXJyeSBsYWJlbHMgZm9yIHNl dmVyYWwgbGF5ZXJzLCBzbyANCm9ubHkgY29uc2lkZXJpbmcgdGhlIGZpcnN0ICJSZXF1ZXN0ZWQg R01QTFMgTGFiZWwgSW5mb3JtYXRpb24gIiBzdWJ0bHYgbWF5IG5vdCANCmJlIHN1ZmZpY2llbnQs IG9uIHRoZSBvdGhlciBoYW5kIGl0cyA8QlI+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPjwvRk9OVD48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZj5b RmF0YWldOiBXZSBoYXZlIG5vdCBjb25zaWRlcmVkIA0KbXVsdGktbGF5ZXJlZCBzY2VuYXJpby4g SWYgTXV0bGktbGF5ZXIgc2hvdWxkIGJlIGNvbnNpZGVyZWQsIHdlIGNhbiByZS11c2UgdGhlIA0K ZXh0ZW5zaW9ucyBkZWZpbmVkIGluIFtQQ0UtTUxOLUV4dF0uPC9GT05UPjxCUj48QlI+Rm9yIHRo ZSBRb3Mgc2VjdGlvbiwgdGhlIA0Kc2VjdGlvbiA0LjQuMSBkb2VzIG5vdCBhbGxvdyBkaWZmZXJl bnQgZm9yd2FyZC9yZXZlcnNlIFRyYWZmaWMgc3BlYyBhcyBpbiANClJGQzU0NjcsIGFuZCBpdHMg bm90IGNsZWFyIGhvdyB0byBkaXN0bmd1aXNoIHRoZSBvbGQgUW9TIGZyb20gdGhlIG5ldyBRb3Mg aW4gDQpjYXNlIG9mIHJlb3B0aW1pemF0aW9uIHJlcXVlc3RzLjxCUj48QlI+PEZPTlQgY29sb3I9 IzAwMDBmZj5bRmF0YWldOiBPdXIgZHJhZnQgDQppcyBmb3IgU0RIIG5ldHdvcmtzLiBXZSBrbm93 IHVzdWFsbHkgdGhlcmUgaXMgbm8gdGhpcyBjYXNlIGZvciBhc3ltbWV0cmljIA0KYmFuZHdpZHRo IGJpZGlyZWN0aW9uYWwgTFNQIGluIFNESCBuZXR3b3JrcyhpLmUuLCBiaWRpcmVjdGlvbmFsIExT UCBpcyANCmNvbnNpZGVyZWQgd2l0aCBzYW1lIFFvUyBvbiBib3RoIGRpcmVjdGlvbnMpLiBPZiBj b3VyY2UsIGlmIHdlIG5lZWQgdG8gY292ZXIgdGhlIA0KcmVxdWlyZW1lbnRzIGluIFJGQzU0Njcs IEkgdGhpbmsgd2UgY2FuIGp1c3QgYWRkIFtVcHN0cmVhbS1CYW5kd2lkdGhdIHRvIA0KaWRlbnRp ZnkgYXN5bW1ldHJpYyBiYW5kd2lkdGguIFJlb3B0aW1pemF0aW9uIGlzIGFscmVhZHkgY2FwdHVy ZWQgaW4gDQpSRkM1NDQwLjwvRk9OVD48QlI+PEJSPkluICI0LjQuMi4gTFNQIFByb3RlY3Rpb24g SW5mb3JtYXRpb24gVExWIiwgSSB0aGluayANCnJldXNpbmcgdGhlIFJGQzQ4NzIgYW5kIFJGQzM0 NzEgTFNQIGZsYWdzIGFuZCBMaW5rIGZsYWdzIHdvdWxkIGJlIG1vcmUgaW4gbGluZSANCndpdGgg UlNWUC1URSBzaWduYWxpbmcuIDxCUj5JbiB0aGlzIHNlY3Rpb24gaXRzIG5vdCBjbGVhciBvbiBo b3cgdG8gdXNlIHRoZSANClByb3RlY3Rpb24gaW5mb3JtYXRpb24sIHNvbWUgZmllbGRzIHNlZW1z IHRvIGdvIGluIHRoZSBkaXJlY3Rpb24gb2YgYSBzdGF0ZWZ1bGwgDQpQQ0UgKFNlZ21lbnQgUmVj b3ZlcnksIEFzc29jaWF0ZWQgTFNQIElEKSwgaG93ZXZlciBpdHMgbm90IGNsZWFyIGhvdyB0aG9z ZSANCmZpZWxkcyBhcmUgdG8gYmUgdXNlZCBhbmQgcHJvY2Vzc2VkLCBmb3IgaW5zdGFuY2UgdGhl IGFzc29jaWF0ZWQgTFNQIGlkIGNhbiBiZSANCnVzZWQgb25seSBpZiB0aGUgTFNQIGlkcyBhcmUg a25vd24gdG8gdGhlIFBDRS48QlI+PEJSPjxGT05UIA0KY29sb3I9IzAwMDBmZj5bRmF0YWldOiBX ZSBjYW4gcmVmZXJlbmNlIHRoZSBwcm90ZWN0aW9uIG9iamVjdCBkZWZpbmVkIGluIFJGQzQ4NzIg DQpvciBSRkM0ODczLCBidXQgd2UgY2FuIG5vdCBzaW1wbHkgY29weSB0aGUgb2JqZWN0IGRlZmlu ZWQgaW4gUkZDNDg3MiBvciBSRkM0ODczIA0KKGkuZS4sIHNvbWUgZmllbGRzIHNob3VsZCBiZSBy ZW1vdmVkIGFuZCBhZGQgc29tZSBuZXcgZmllbGRzIGFkZGl0aW9uYWxseSkuIFdlIA0Kd2lsbCBj aGVjayB0aGUgb2JqZWN0IGFnYWluIGFuZCByZW1vdmUgQXNzb2NpYXRlZCBMU1AgSUQuPEJSPjwv Rk9OVD48QlI+SSBhbSANCmxvb2tpbmcgZm9yd2FyZCB0byBkaXNjdXNzIHRob3NlIHR3byBkcmFm dCB3aXRoIHlvdS48QlI+PEJSPlRoYW5rcywgPEJSPkN5cmlsIA0KTWFyZ2FyaWEgPEJSPjxCUj48 QlI+PEJSPiZndDsgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8QlI+Jmd0OyBGcm9tOiBl eHQgDQpGYXRhaSBaaGFuZyBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0gPEJSPiZndDsg U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA2LCANCjIwMTAgMjozNCBBTTxCUj4mZ3Q7IFRvOiBN YXJnYXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmljaCk8QlI+Jmd0OyBDYzogDQpwY2VAaWV0Zi5v cmc7IHN1cmVzaGJyQGh1YXdlaS5jb208QlI+Jmd0OyBTdWJqZWN0OiBSZTogW1BjZV0gTmV3IGRy YWZ0OiANCmRyYWZ0LW1hcmdhcmlhLXBjZS1nbXBscy1wY2VwLWV4dGVuc2lvbnMtMDA8QlI+Jmd0 OzxCUj4mZ3Q7PEJSPiZndDsgSGkgDQpDeXJpbCw8QlI+Jmd0OyA8QlI+Jmd0OyBXaGF0IGEgY29p bmNpZGVuY2UgdG8gc2VlIHlvdXIgZHJhZnQgYWZ0ZXIgd2UganVzdCANCnN1Ym1pdGVkIG91ciBk cmFmdCAoZHJhZnQtemhhbmctcGNlLXBjZXAtZXh0ZW5zaW9ucy1mb3Itc2RoLTAwLnR4dCkgDQpb ZHJhZnQtemhhbmctcGNlcC1leHRdLjxCUj4mZ3Q7IDxCUj4mZ3Q7IEdyZWF0IG1pbmRzIHRoaW5r IGFsaWtlLiZuYnNwOyBIYXBweSB0byANCnNlZSB0aGF0IGhhcHBlbmVkLjxCUj4mZ3Q7IDxCUj4m Z3Q7IEhvcGUgeW91IGNhbiBzcGFyZSBzb21lIHRpbWUgdG8gcmV2aWV3IA0KW2RyYWZ0LXpoYW5n LXBjZXAtZXh0XS4gV2UgYXJlIGxvb2tpbmcgZm9yd2FyZCB0byBkaXNjdXNzaW5nIG1vcmUgd2l0 aCANCnlvdS48QlI+Jmd0OyA8QlI+Jmd0OyBXZSBhbHNvIGludml0ZSBhbGwgdGhlIGV4cGVydHMg ZnJvbSBQQ0UgV0cgdG8gcmV2aWV3Jm5ic3A7IA0KW2RyYWZ0LXpoYW5nLXBjZXAtZXh0XS48QlI+ Jmd0OyZuYnNwOyA8QlI+Jmd0OyZuYnNwOyA8QlI+Jmd0OyA8QlI+Jmd0OyANClRoYW5rczxCUj4m Z3Q7Jm5ic3A7IDxCUj4mZ3Q7IEZhdGFpPEJSPiZndDsmbmJzcDsgPEJSPiZndDsgQWR2YW5jZWQg VGVjaG5vbG9neSANCkRlcGFydG1lbnQ8QlI+Jmd0OyBXaXJlbGluZSBOZXR3b3JraW5nIEJ1c2lu ZXNzIFVuaXQ8QlI+Jmd0OyBIdWF3ZWkgVGVjaG5vbG9naWVzIA0KQ28uLCBMVEQuPEJSPiZndDsg SHVhd2VpIEJhc2UsIEJhbnRpYW4sIExvbmdnYW5nLDxCUj4mZ3Q7IFNoZW56aGVuIDUxODEyOSAN ClAuUi5DaGluYTxCUj4mZ3Q7IFRlbDogKzg2LTc1NS0yODk3MjkxMjxCUj4mZ3Q7IEZheDogKzg2 LTc1NS0yODk3MjkzNTxCUj4mZ3Q7IA0KPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgJmd0OyAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDxCUj4mZ3Q7ICZndDsgRnJvbTogDQoiTWFyZ2Fy aWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpIiAmbHQ7Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbSZn dDs8QlI+Jmd0OyAmZ3Q7IA0KVG86ICZsdDtwY2VAaWV0Zi5vcmcmZ3Q7PEJSPiZndDsgJmd0OyBT ZW50OiBUdWVzZGF5LCBKYW51YXJ5IDA1LCAyMDEwIDU6NDQgDQpQTTxCUj4mZ3Q7ICZndDsgU3Vi amVjdDogW1BjZV0gTmV3IGRyYWZ0OiANCmRyYWZ0LW1hcmdhcmlhLXBjZS1nbXBscy1wY2VwLWV4 dGVuc2lvbnMtMDA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgDQomZ3Q7IDxC Uj4mZ3Q7ICZndDsgRGVhciBQQ0VlcnMsPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IFdlIGhh dmUganVzdCANCnN1Ym1pdHRlZCBhIG5ldyBkcmF0IG9uICJQQ0VQIGV4dGVuc2lvbnMgZm9yIEdN UExTIi4gPEJSPiZndDsgJmd0OyBUaGUgZHJhZnQgDQpzcGVjaWZpZXMgb3B0aW9uYWwgZXh0ZW5z aW9ucyB0byB0aGUgUENFUCBwcm90b2NvbCB0byBjb21wbHkgd2l0aCB0aGUgR01QTFMgDQpyZXF1 aXJlbWVudHMgZm9yIFBDRVAuIFRoZXNlIGV4dGVuc2lvbnMgbWF5IGJlIGFsc28gYXBwbGljYWJs ZSBpbiB0aGUgV1NPTiANCmNvbnRleHQuPEJSPiZndDsgJmd0OyBXZSB1cmdlIHlvdSB0byByZXZp ZXcgdGhlIGRyYWZ0IGFuZCBwcm92aWRlIHlvdXIgdmFsdWFibGUgDQpjb21tZW50cy4gPEJSPiZn dDsgJmd0OyBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFyZ2FyaWEtcGNlLWdtcGxzLXBjZXAtZXh0ZW5zaW9ucy0w MC50eHQgDQo8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgVGhhbmtzIGFuZCBiZXN0IHJlZ2Fy ZHMsPEJSPiZndDsgJmd0OyBDeXJpbCANCk1hcmdhcmlhPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAm Z3Q7IE5va2lhIFNpZW1lbnMgTmV0d29ya3MgR21iSCAmYW1wOyBDby4gDQpLRzxCUj4mZ3Q7ICZn dDsgQnJvYWRiYW5kIENvbm5lY3Rpdml0eSBTb2x1dGlvbnM8QlI+Jmd0OyAmZ3Q7IFN0Lk1hcnRp bi1TdHIuIA0KNzY8QlI+Jmd0OyAmZ3Q7IEQtODE1NDEgTfxuY2hlbjxCUj4mZ3Q7ICZndDsgR2Vy bWFueTxCUj4mZ3Q7ICZndDsgDQptYWlsdG86Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbTxCUj4mZ3Q7 ICZndDsgUGhvbmU6ICs0OS04OS01MTU5LTE2OTM0PEJSPiZndDsgJmd0OyANCkZheDombmJzcDsm bmJzcDsgKzQ5LTg5LTYzNi00MDI4ODxCUj4mZ3Q7ICZndDsgDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxCUj4mZ3Q7ICZn dDsgDQpOb2tpYSBTaWVtZW5zIE5ldHdvcmtzIEdtYkggJmFtcDsgQ28uIEtHPEJSPiZndDsgJmd0 OyBTaXR6IGRlciBHZXNlbGxzY2hhZnQ6IA0KTfxuY2hlbiAvIFJlZ2lzdGVyZWQgb2ZmaWNlOiBN dW5pY2g8QlI+Jmd0OyAmZ3Q7IFJlZ2lzdGVyZ2VyaWNodDogTfxuY2hlbiAvIA0KQ29tbWVyY2lh bCByZWdpc3RyeTogTXVuaWNoLCBIUkEgODg1Mzc8QlI+Jmd0OyAmZ3Q7IFdFRUUtUmVnLi1Oci46 IERFIA0KNTI5ODQzMDQ8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgUGVyc/ZubGljaCBoYWZ0 ZW5kZSBHZXNlbGxzY2hhZnRlcmluIC8gDQpHZW5lcmFsIFBhcnRuZXI6IE5va2lhIFNpZW1lbnMg TmV0d29ya3MgTWFuYWdlbWVudCBHbWJIPEJSPiZndDsgJmd0OyANCkdlc2No5GZ0c2xlaXR1bmcg LyBCb2FyZCBvZiBEaXJlY3RvcnM6IEx5ZGlhIFNvbW1lciwgT2xhZiBIb3JzdGhlbWtlPEJSPiZn dDsgDQomZ3Q7IFZvcnNpdHplbmRlciBkZXMgQXVmc2ljaHRzcmF0cyAvIENoYWlybWFuIG9mIHN1 cGVydmlzb3J5IGJvYXJkOiBMYXVyaSANCktpdmluZW48QlI+Jmd0OyAmZ3Q7IFNpdHogZGVyIEdl c2VsbHNjaGFmdDogTfxuY2hlbiAvIFJlZ2lzdGVyZWQgb2ZmaWNlOiANCk11bmljaDxCUj4mZ3Q7 ICZndDsgUmVnaXN0ZXJnZXJpY2h0OiBN/G5jaGVuIC8gQ29tbWVyY2lhbCByZWdpc3RyeTogTXVu aWNoLCBIUkIgDQoxNjM0MTY8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7ICZndDsgUGNlIG1h aWxpbmcgDQpsaXN0PEJSPiZndDsgJmd0OyBQY2VAaWV0Zi5vcmc8QlI+Jmd0OyAmZ3Q7IA0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2U8L0ZPTlQ+PC9ESVY+PC9CT0RZ PjwvSFRNTD4NCg== --Boundary_(ID_0dJFKVAFufBk9urlqYAJ2g)-- From daniel@olddog.co.uk Fri Jan 8 04:02:36 2010 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 88FD13A6824 for ; Fri, 8 Jan 2010 04:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3KW0vS3d+2p for ; Fri, 8 Jan 2010 04:02:35 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 6F0823A67EB for ; Fri, 8 Jan 2010 04:02:34 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o08C2Hvs010802; Fri, 8 Jan 2010 12:02:17 GMT Received: from Serenity (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 o08C2GbL010778; Fri, 8 Jan 2010 12:02:16 GMT From: "Daniel King" To: =?UTF-8?B?J+i1teawuOWIqSc=?= References: In-Reply-To: Date: Fri, 8 Jan 2010 12:02:16 -0000 Message-ID: <002701ca905a$6c3d1800$44b74800$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcqMWW6oLbvdXK/SQ76df2Rn+uVWsQD/121g Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] question on draft-king-hierarchy-fwk-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, 08 Jan 2010 12:02:36 -0000 Hi Yongli, Thanks for reviewing the draft. In response to your questions: 1. The Parent PCE will determine the likely domain paths from the source = to the destination. The Parent PCE will then send an edge-to-edge = request to a Child PCE in the ingress domain (ingress-to-edge), and = requests to a Child PCE in each candidate transmit domain (edge-to-edge) = and finally a Child PCE in the egress domain (edge-to-egress). Once the = responses are collated a suitable path can be identified and selected by = Parent PCE. The Parent PCE will then send a response back to the Child = PCE in the ingress domain. The Child PCE will then send an ERO response = to the PCC that requested the inter-domain path.=20 2. H-PCE has been designed so the Parent PCE will not have the same = detailed internal domain topology information of the Child PCE's it = services. However the Parent PCE does know capabilities of the links = that connect the domains together. The inter-domain link information = would be reported by the Child PCE during the initial Child and Parent = PCE information exchange. The Child PCE can learn about its inter-domain = links via its domain IGP. During "step 9" of the example procedure the = Parent PCE has the opportunity to apply network or policy constraints = based on its knowledge of the inter-domain links selected for the = candidate path. So in summary, one aim of H-PCE is to avoid the need for anyone one = entity to have a detailed topology view of each transit domain. A Child = PCE per domain, is used to compute a segment of the end-to-end path. The = Child PCE can also replace its path segment information with a path-key = [RFC5520] to further maintain confidentiality.=20 On review of the step 9 procedure, we will update the text so the = process and actual network topology view is clearer. =20 Br, Dan. From: =E8=B5=B5=E6=B0=B8=E5=88=A9 [mailto:yufengx386@gmail.com]=20 Sent: 03 January 2010 09:45 To: daniel@olddog.co.uk Cc: pce@ietf.org Subject: question on draft-king-hierarchy-fwk-03.txt Hi Dan, I have two questions on the document = "draft-king-hierarchy-fwk-03.txt".=20 (1) In the procedure of section 5.6.2, three domain paths have been = gained, and PCEs 1 to 4 have received the path compuation requests from = the parent PCE. Does it mean that the parent PCE will send edge-to-edge = path computation requests to all the PCEs along all the domain paths? =20 (2) In step 9 of the same section, it seems not very clear about the = compuation responses in the sentence of "PCE 5 correlates all the = computation responses from each child PCE". Does it mean the detailed = constraint-based path segments in the local domain?=20 Thank you very much. =20 Best regards. =20 =20 Yongli Zhao Beijing University of Posts and Telecommunications Beijing, China From qzhao@huawei.com Fri Jan 8 08:59:12 2010 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 4587D3A68AE for ; Fri, 8 Jan 2010 08:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvrRQ9bBDPBU for ; Fri, 8 Jan 2010 08:59:02 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 663D53A67AE for ; Fri, 8 Jan 2010 08:59:02 -0800 (PST) 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 <0KVX001ZYTUC3G@usaga04-in.huawei.com> for pce@ietf.org; Fri, 08 Jan 2010 10:59:00 -0600 (CST) Received: from Z73671a ([10.192.21.57]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVX00FLGTU94E@usaga04-in.huawei.com> for pce@ietf.org; Fri, 08 Jan 2010 10:58:59 -0600 (CST) Date: Fri, 08 Jan 2010 11:58:57 -0500 From: Quintin Zhao To: "'mailto:gregimirsky"@gmail.com' Message-id: <000401ca9083$defa1f90$3915c00a@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_ap3+XzE340yJHNsEp2uRMQ)" Thread-index: AcqOXZ2PFWeJCc+JRsSaYR/cOWEXuQCHa0yQ Cc: pce@ietf.org Subject: [Pce] FW: Inter-domain-p2mp-procedures 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, 08 Jan 2010 16:59:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ap3+XzE340yJHNsEp2uRMQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Greg, =20 Thanks for the comments and suggestions!=20 =20 Can you elaborate a little more on what you mean here? =20 =93I think that because we can not guarantee that the immediate LSR will = be the merging point of p2p backup LSP one can not assume that a single p2p = can be used to provide protection for local link failure case.=94 =20 Quintin =20 _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: Tuesday, January 05, 2010 6:20 PM To: JP Vasseur Cc: Quintin Zhao; pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures =20 Hi Quintin and JP, in regard to applicability of p2p FRR protection of links of p2mp LSP I agree with JP that such applicability is questionable and very much = depends on network topology, its meshiness. I think that because we can not guarantee that the immediate LSR will be the merging point of p2p backup = LSP one can not assume that a single p2p can be used to provide protection = for local link failure case. I believe that strong case can be made to = recommend use p2mp for local link protection as well as when node protection = required. Regards, Greg 2009/12/23 JP Vasseur Hi, On Dec 21, 2009, at 3:49 AM, Quintin Zhao wrote: JP, Good question! I guess that I should use "more complex to be = implemented" instead of "less applicable" in my previous email when I refer to using = FRR for P2MP node protection. =20 Well this is arguable though .. =20 What I was trying to mean is that p2p backup is easily to be used for = the link protection for p2mp. To use FRR for the node protection in p2mp, it = is not that straight forward comparing to p2p node protection, especially = from the point view of bandwidth cost and label allocation. =20 Well it all depends on how you compute your P2P backup, and this may be = used for a very short period of time. There are excellent off-line algorithms = to achieve some good level of efficiency. =20 For example, to use the p2p tunnel to backup the branch node, we need multiple p2p tunnels = to protect a single branch node. If the p2mp backup tunnel is used for the branch node protection, then the upstream label allocation might be = needed. =20 Which is not a major issue. See long discussions on the list some time = ago on the subject matter. Thanks. JP. =20 Regards, Quintin -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Saturday, December 19, 2009 4:51 AM To: Quintin Zhao Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures Hi, On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote: JP, Thanks for your comments and suggestions. I agree with you that for a quickly recovery, FRR is a good choice. For the p2mp TE LSP, if the failures are about link failures, FRR can be used for the recovery. If the failures are about the p2mp nodes which can be the root/branch/bud/leaf nodes, FRR might not be an easy way to cover these cases.=A1=A1 What makes you think that the use of FRR is less applicable to node failures ? (for which you could either use a set of P2P backup or a single P2MP backup) Thanks JP. This may lead to other possible solutions and the pre-computed backup sub-tree or the whole backup tree might be needed for the possible solutions. As you mentioned, using the FRR itself will eventually need the head end reoptimization using a make before break. The pre-computed backup p2mp path/sub-path or the new computed path during reoptimization process using make before breaks are the optimal path subject to the OF and all other current constrains when the path is computed by the PCE. I agree with you that we can not draw the conclusion on the potentially level of sub-optimality of performing local reroute as opposed to global reoptimization. Also we can not draw the conclusion if these backup path or optimized path after the failure is better or worse than the primary path. These pre-computed backup paths/sub-paths or the optimized paths under the failure condition are the best path which can be used for the recovery of the failure while satisfying all the conditions. Regards, Quintin -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, December 17, 2009 1:26 PM To: Quintin Zhao Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures Hi, Note that this is a fairly well-known issue. The aim of local repair has always been to quickly recover from the failure. The degree of resources guarantees and optimality depends on the amount of resources dedicated to backup, several assumptions with regards to potential simultaneous failures, the algorithms used to pre-compute backup tunnels, etc ... The approach taken by P2P FRR has been to first locally reroute and trigger a head-end reoptimization using a make before break. I do not think that you can draw any conclusion on the potentially level of sub-optimality of performing local reroute as opposed to global reoptimization. It depends on a number of factors. JP. On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: Hello PCE'rs, I would like to follow-up on some discussions from our PCE WG session last month. Specifically regarding Dajiang's failure and recomputation observations on our draft. We are very interested to hear comments regarding the need for computing secondary paths in the event of failure. Currently our thinking is to recompute the sub-tree based in the domain where the failure has occurred. In this case we would not need to perform a recalculation of the entire tree. We could also recompute the entire tree, and avoid the failed areas, as long as the TED has the updated topology. Realistically one might have a backup core tree pre-computed so you can switch over in the event of failure. There are also other considerations. Would a partial recomputation provide a "worse" SPT or MCT tree, or would a full tree recomputation provide a "better" SPT or MCT? I can think of scenarios for both a partial and full recomputation, so perhaps we need to implement both but allow the PCC to decide when to issue a partial or full recomputation based on some criterion. Thanks, Quintin _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce =20 =20 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce =20 --Boundary_(ID_ap3+XzE340yJHNsEp2uRMQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi Greg,

 

Thanks for the comments and suggestions! =

 

Can you elaborate a little more on what you mean = here?

 

“I think that because we can not guarantee that = the immediate LSR will be the merging point of p2p backup LSP one can not = assume that a single p2p can be used to provide protection for local link = failure case.”

 

Quintin

 

From: Greg = Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, January = 05, 2010 6:20 PM
To: JP Vasseur
Cc: Quintin Zhao; = pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

 

Hi Quintin and JP,
in regard to applicability of p2p FRR protection of links of p2mp LSP I = agree with JP that such applicability is questionable and very much depends on network topology, its meshiness. I think that because we can not = guarantee that the immediate LSR will be the merging point of p2p backup LSP one can = not assume that a single p2p can be used to provide protection for local = link failure case. I believe that strong case can be made to recommend use p2mp for = local link protection as well as when node protection required.

Regards,
Greg

2009/12/23 JP Vasseur <jvasseur@cisco.com><= /span>

Hi,



On Dec 21, 2009, at 3:49 AM, Quintin Zhao = wrote:

JP,

Good question! I guess that I should use "more complex to be implemented"
instead of "less applicable" in my previous email when I refer = to using FRR
for P2MP node protection.

 

Well this is arguable though ..

 

What I was trying to mean is that p2p backup is easily to be = used for the
link protection for p2mp. To use FRR for the node protection in p2mp, it = is
not that straight forward comparing to p2p node protection, especially = from
the point view of bandwidth cost and label = allocation.

 

Well it all depends on how you compute your P2P backup, and this = may be used
for a very short period of time. There are excellent off-line algorithms = to achieve
some good level of efficiency.

 

For example, to use
the p2p tunnel to backup the branch node, we need multiple p2p tunnels = to
protect a single branch node. If the p2mp backup tunnel is used for = the
branch node protection, then the upstream label allocation might be = needed.

 

Which is not a major issue. See long discussions on the list = some time ago on the
subject matter.

Thanks.

JP.

 



Regards,
Quintin

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Saturday, December 19, 2009 4:51 AM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

On Dec 18, 2009, at 9:41 PM, Quintin Zhao = wrote:


JP,

Thanks for your comments and suggestions.

I agree with you that for a quickly recovery, FRR is a good choice.
For the
p2mp TE LSP, if the failures are about link failures, FRR can be
used for
the recovery. If the failures are about the p2mp nodes which can be
the
root/branch/bud/leaf nodes, FRR might not be an easy way to cover
these
cases.=A1=A1


What makes you think that the use of FRR is less applicable to node
failures ?
(for which you could either use a set of P2P backup or a single P2MP
backup)

Thanks

JP.

This may lead = to other possible solutions and the pre-computed
backup sub-tree or the whole backup tree might be needed for the
possible
solutions. As you mentioned, using the FRR itself will eventually
need the
head end reoptimization using a make before break.

The pre-computed backup p2mp path/sub-path or the new computed path
during
reoptimization process using make before breaks are the optimal path
subject
to the OF and all other current constrains when the path is computed
by the
PCE. I agree with you that we can not draw the conclusion on the
potentially
level of sub-optimality of performing local reroute as opposed to
global
reoptimization.

Also we can not draw the conclusion if these backup path or
optimized path
after the failure is better or worse than the primary path. These
pre-computed backup paths/sub-paths or the optimized paths under the
failure
condition are the best path which can be used for the recovery of = the
failure while satisfying all the conditions.

Regards,
Quintin


-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Thursday, December 17, 2009 1:26 PM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

Note that this is a fairly well-known issue. The aim of local repair
has always been to quickly recover from the failure. The degree of
resources guarantees and optimality depends on the amount of = resources
dedicated to backup, several assumptions with regards to potential
simultaneous failures, the algorithms used to pre-compute backup
tunnels, etc ... The approach taken by P2P FRR has been to first
locally reroute and trigger a head-end reoptimization using a make
before break. I do not think that you can draw any conclusion on the
potentially level of sub-optimality of performing local reroute as
opposed to global reoptimization. It depends on a number of factors.

JP.

On Dec 14, 2009, at 10:15 PM, Quintin Zhao = wrote:


Hello PCE'rs,

I would like to follow-up on some discussions from our PCE WG
session last
month. Specifically regarding Dajiang's failure and recomputation
observations on our draft. We are very interested to hear comments
regarding
the need for computing secondary paths in the event of failure.
Currently
our thinking is to recompute the sub-tree based in the domain where
the
failure has occurred. In this case we would not need to perform a
recalculation of the entire tree. We could also recompute the entire
tree,
and avoid the failed areas, as long as the TED has the updated
topology.
Realistically one might have a backup core tree pre-computed so you
can
switch over in the event of failure. There are also other
considerations.
Would a partial recomputation provide a "worse" SPT or MCT = tree, or
would a
full tree recomputation provide a "better" SPT or MCT? I can = think of
scenarios for both a partial and full recomputation, so perhaps we
need to
implement both but allow the PCC to decide when to issue a partial
or full
recomputation based on some criterion.

Thanks,

Quintin

_______________________________________________
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_ap3+XzE340yJHNsEp2uRMQ)-- From qzhao@huawei.com Fri Jan 8 12:22:17 2010 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 9DA5F3A6835 for ; Fri, 8 Jan 2010 12:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] 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 Xo7Q-WKLOQwi for ; Fri, 8 Jan 2010 12:22:16 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 7A62D3A67C0 for ; Fri, 8 Jan 2010 12:22:16 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVY00GSZ391XJ@usaga02-in.huawei.com> for pce@ietf.org; Fri, 08 Jan 2010 12:22:14 -0800 (PST) Received: from Z73671a ([10.192.21.57]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVY00FQV390YP@usaga02-in.huawei.com> for pce@ietf.org; Fri, 08 Jan 2010 12:22:13 -0800 (PST) Date: Fri, 08 Jan 2010 15:22:12 -0500 From: Quintin Zhao In-reply-to: <22437_1262872632_4B45E838_22437_7085_1_D109C8C97C15294495117745780657AE0C369AF0@ftrdmel1> To: julien.meuric@orange-ftgroup.com Message-id: <000c01ca90a0$43809db0$3915c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcqB6cs8TiSNSOV7SDKQ0LgQicHNugNtq9ZQAD+lNRA= References: <001901ca81e9$cbdea690$0702a8c0@china.huawei.com> <22437_1262872632_4B45E838_22437_7085_1_D109C8C97C15294495117745780657AE0C369AF0@ftrdmel1> Cc: pce@ietf.org Subject: Re: [Pce] Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures 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, 08 Jan 2010 20:22:17 -0000 Hi Julien, Yes, we still believe that we have a lot of work ahead them regarding this work item. We hope that adoption of this work item by the WG would make the work more visible and generate further interest in developing the overall solution. I believe we have a broad consensus across the co-authors for how to move this work forward. Please give me a few days to confirm our plan with my co-authors and then I will mail you and the WG our intended strategy. Regards, Quintin -----Original Message----- From: julien.meuric@orange-ftgroup.com [mailto:julien.meuric@orange-ftgroup.com] Sent: Thursday, January 07, 2010 8:57 AM To: qzhao@huawei.com Cc: pce@ietf.org; jvasseur@cisco.com Subject: RE: Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures Hi Quintin. It is a significant step that authors of both drafts agreed on working on a single document and we congratulate all of you for that. During IETF 76, you also mentioned "Lots of work and analysis ahead" and a need to "continue to review requirements and select the technique that best meets the requirements". Indeed, the current version of the document looks more like a solution list than an actual merge of former proposals. Considering the complexity induced by an inter-domain P2MP extension, we would appreciate before taking any decision that you elaborate on the way you intend to move forward towards a common solution. Thanks Julien ________________________________ From: Quintin Zhao [mailto:qzhao@huawei.com] Hi Co-Chairs and PCE WG, Different parties have been working on solutions for computing P2MP paths across multi-domain networks. At IETF 75 we were requested by JP, to formulate a plan and resolve any issues in order to move the work forward. After calls and emails between draft-ali-pce-brpc-p2mp-ext and draft-zhao-pce-pcep-inter-domain-p2mp-procedure authors, we felt there was concurrence to merge the solutions and work together on a unified solution. At IETF 76 we presented our initial/combined PCE-based Shortest Constrained P2MP Inter-domain TE-LSP solution (draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02). We would like to know if the co-chairs and WG would be in favor of the document becoming a WG draft? Regards, Quintin ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** From daniel@olddog.co.uk Fri Jan 8 14:19:33 2010 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 7D18C3A68E0 for ; Fri, 8 Jan 2010 14:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 GcrMNW19fY6A for ; Fri, 8 Jan 2010 14:19:32 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id B6C753A68C5 for ; Fri, 8 Jan 2010 14:19:30 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o08MIs2s028445; Fri, 8 Jan 2010 22:19:00 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o08MIrHg028438; Fri, 8 Jan 2010 22:18:54 GMT From: "Daniel King" To: "'JP Vasseur'" References: <018101ca7da6$de1435b0$9a3ca110$@co.uk> <28361E9D-2D43-42B8-BD82-8B6169A487C8@cisco.com> In-Reply-To: Date: Fri, 8 Jan 2010 22:18:54 -0000 Message-ID: <002401ca90b0$9115f6a0$b341e3e0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcqIrnrVeNIPlLEJSzuQPNx8AXmPKgH/4oGw Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-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: Fri, 08 Jan 2010 22:19:33 -0000 Hi JP, all, If the P2MP Requirements document (draft-ietf-pce-p2mp-req-04) has finished LC, and I think it completed LC with no changes needed. Are we able to start LC for the solutions (draft-ietf-pce-pcep-p2mp-extensions-06) document? Br, Dan -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 29 December 2009 17:44 To: pce@ietf.org Cc: JP Vasseur; Daniel King Subject: Re: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt Hi, As I understand this discussion, the resolution is that there is no change needed to the P2MP Requirements draft. So WG last call completed without any changes needed. Ready to move on? Cheers, Adrian ----- Original Message ----- From: "JP Vasseur" To: "Daniel King" Cc: Sent: Thursday, December 17, 2009 6:17 PM Subject: Re: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp-req-04.txt Hi Dan, On Dec 15, 2009, at 5:51 PM, Daniel King wrote: > Hi JP, All, > > As a co-editor of the P2MP Solutions (draft-ietf-pce-pcep-p2mp- > extensions-05) I would like to state that the authors of the P2MP > Requirements (draft-ietf-pce-p2mp-req-04) added all the additional > requirements that we identified during the development of the P2MP > solutions document. So I believe that the P2MP Requirements document > is in fairly good shape. > > We do however have one outstanding issue regarding the solutions > document. I do not believe this directly impacts the P2MP > Requirements document itself, but it's certainly worth discussing > the issue on the list. The P2MP Requirements draft mentions the > requirement for reoptimization of P2MP TE LSPs: > > >> > 2.1.10. Reoptimization of P2MP TE LSPs > > R11: Reoptimization MUST be supported for P2MP TE LSPs as described > for P2P LSPs in [RFC4657]. > << > > There is a further request in this section that states "that a P2MP > Path Computation Request SHOULD contain a parameter that allows the > PCC to express a cost-benefit reoptimization threshold for the whole > LSP as well as per destination". This seems like a sensible request. > After all, why switch to a new path if the reoptimization request > returns a path that's no better, or even worse, than the existing > path? > > We support Objective Functions [RFC5541] in the P2MP Solutions > document, and our solutions allows a path to be computed using a > Shortest Path Tree (SPT) or Minimum Cost Tree (MCT), these will be > processed according to the rules defined in RFC5541, but we do not > currently have a "reoptimization threshold" function. Some of the > authors of the P2MP Solution draft think the reoptimization > threshold function is relevant to both P2P and P2MP, and threshold > solution should be applicable to both P2P and P2MP. Therefore the > current P2MP Solutions would state that this requirement will be > resolved in a future document. > > We would really like to hear comments or suggestions regarding the > threshold reoptimization function. Both from the perspective of a > future solution that supports both P2P and P2MP, and/or this feature > should be specifically part of the existing P2MP Solutions draft. Good question and for people having long memories, this was discussed almost 5 years ago (!). I had personally advocated for such a solution so I'm clearly in favor of it and I also believe that the same mechanism should apply to both P2P and P2MP. Of course, there might be a need for specific threshold in light of the OF. For example, if we end up defining an OF for P2MP according which the objective is to minimize the path cost difference between each leaf and the head-end (to guaranty fairness delivery for mcast traffic for example), we may need a P2MP specific threshold. So let's try to make the threshold mechanisms as generic and modular as possible. Back to your question I would suggest to leave it out from the P2MP solution draft and have a separate ID covering both the P2P and P2MP threshold solutions. Thanks. JP. > > Br, Dan/P2MP Solutions Authors. > > > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: 07 December 2009 19:08 > To: pce@ietf.org > Subject: [Pce] WG Last Call on I-D Action:draft-ietf-pce-p2mp- > req-04.txt > > Dear WG, > > Although the discussion on this ID has been relatively moderate, the > document has been stable for a while and discussed at several WG > meetings. > > This starts a 2-week WG Last Call on I-D Action:draft-ietf-pce-p2mp- > req-04.txt. > > Please send your comment to the authors and copy the list by Dec 15, > noon ET. > > Thanks. > > JP and Julien. ---------------------------------------------------------------------------- ---- > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From yufengx386@gmail.com Sun Jan 10 04:28:45 2010 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 CB7EA3A680A for ; Sun, 10 Jan 2010 04:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.352 X-Spam-Level: *** X-Spam-Status: No, score=3.352 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_CHARSET_FARAWAY=2.45] 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 WdU9wejYwc3f for ; Sun, 10 Jan 2010 04:28:44 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 862DB3A67E1 for ; Sun, 10 Jan 2010 04:28:44 -0800 (PST) Received: by pwi20 with SMTP id 20so962841pwi.29 for ; Sun, 10 Jan 2010 04:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=eQJJVrWt8Ee/2GGQYx+Gly5BJoLOrwumGkITL/A0qFg=; b=mMOQXasty6MOwNeJ9TfOG96EB8Lmj1qGa1MrbJ3YMJdKjhK1LFuI2WNYKJmZOu60bN SIao6n+2q9cychOUDDcV1usN7WYojYYxpUyoFGr9UlVR0Wp4QPqjIPfMiPkXkbAyVXd1 mJjtfe+gRPm0B8pDdQTqD5uC445DIMGRdTxl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=onz3CpqEbYJrzi5TvVt3R5hdJ2j2G+f2a7UWqbZLBzjeAiS5JvFBiKG+Sy8a67gABW LhH2wHvHCu0+Adaww46lRJUvgLFOPZuU4iyc4iErU0pKg5iw5JUK95oTNvoydAqB4nEI SWwb5/PVyDVBDFoZaC2D74fpzeyyeMVQF8mOI= MIME-Version: 1.0 Received: by 10.142.66.21 with SMTP id o21mr4066802wfa.47.1263126519829; Sun, 10 Jan 2010 04:28:39 -0800 (PST) In-Reply-To: <002701ca905a$6c3d1800$44b74800$@co.uk> References: <002701ca905a$6c3d1800$44b74800$@co.uk> Date: Sun, 10 Jan 2010 20:28:39 +0800 Message-ID: From: =?GB2312?B?1dTTwMD7?= To: Daniel King Content-Type: multipart/alternative; boundary=001636e908a1855773047cce8f7e Cc: pce@ietf.org Subject: Re: [Pce] question on draft-king-hierarchy-fwk-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: Sun, 10 Jan 2010 12:28:45 -0000 --001636e908a1855773047cce8f7e Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Dan Thank you very much for your answers. Ok. The Parent PCE can determine a likely domain path based on its knowledge of the inter-domain links. However, the domain path may not be optimal because it does not know the detailed information in each domain. Maybe there is a balance between the optimization and the complexity. Do yo= u think so? I am always wondering about the optimal end-to-end path in the current framework. Another question. Can we abstract the detailed information in each domain into some simple forms and provide them to the parent PCE? For example, if we compute the shortest path according to the hop numbers. We can gain the hop numbers between each border nodes pair in each domain by the child PCE, and provide them to the parent PCE. Then the parent PCE can gain the optimal the end-to-end path across multi-domains. Best regards. Yongli Zhao Beijing University of Posts and Telecommunications Beijing, China 2010/1/8 Daniel King > Hi Yongli, > > Thanks for reviewing the draft. In response to your questions: > > 1. The Parent PCE will determine the likely domain paths from the source = to > the destination. The Parent PCE will then send an edge-to-edge request to= a > Child PCE in the ingress domain (ingress-to-edge), and requests to a Chil= d > PCE in each candidate transmit domain (edge-to-edge) and finally a Child = PCE > in the egress domain (edge-to-egress). Once the responses are collated a > suitable path can be identified and selected by Parent PCE. The Parent PC= E > will then send a response back to the Child PCE in the ingress domain. Th= e > Child PCE will then send an ERO response to the PCC that requested the > inter-domain path. > > 2. H-PCE has been designed so the Parent PCE will not have the same > detailed internal domain topology information of the Child PCE's it > services. However the Parent PCE does know capabilities of the links that > connect the domains together. The inter-domain link information would be > reported by the Child PCE during the initial Child and Parent PCE > information exchange. The Child PCE can learn about its inter-domain link= s > via its domain IGP. During "step 9" of the example procedure the Parent P= CE > has the opportunity to apply network or policy constraints based on its > knowledge of the inter-domain links selected for the candidate path. > > So in summary, one aim of H-PCE is to avoid the need for anyone one entit= y > to have a detailed topology view of each transit domain. A Child PCE per > domain, is used to compute a segment of the end-to-end path. The Child PC= E > can also replace its path segment information with a path-key [RFC5520] t= o > further maintain confidentiality. > > On review of the step 9 procedure, we will update the text so the process > and actual network topology view is clearer. > > Br, Dan. > > From: =D5=D4=D3=C0=C0=FB [mailto:yufengx386@gmail.com] > Sent: 03 January 2010 09:45 > To: daniel@olddog.co.uk > Cc: pce@ietf.org > Subject: question on draft-king-hierarchy-fwk-03.txt > > Hi Dan, > I have two questions on the document "draft-king-hierarchy-fwk-03.txt= ". > (1) In the procedure of section 5.6.2, three domain paths have been gaine= d, > and PCEs 1 to 4 have received the path compuation requests from the paren= t > PCE. Does it mean that the parent PCE will send edge-to-edge path > computation requests to all the PCEs along all the domain paths? > > (2) In step 9 of the same section, it seems not very clear about the > compuation responses in the sentence of "PCE 5 correlates all the > computation responses from each child PCE". Does it mean the detailed > constraint-based path segments in the local domain? > Thank you very much. > > Best regards. > > > Yongli Zhao > > Beijing University of Posts and Telecommunications > Beijing, China > > --001636e908a1855773047cce8f7e Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Dan
    Thank you very much for your answers.
     Ok. The Parent PCE can determine a likely dom= ain path based on its knowledge of the inter-domain links. However, th= e domain path may not be optimal because it does not know the detailed info= rmation in each domain. Maybe there is a balance between the optimization a= nd the complexity. Do you think so?
I am always wondering about the optimal end-to-end path in the current= framework.
     Another question. Can we abstract the detaile= d information in each domain into some simple forms and provide them to the= parent PCE? For example, if we compute the shortest path according to the = hop numbers. We can gain the hop numbers between each border nodes pair in = each domain by the child PCE, and provide them to the parent PCE. Then the = parent PCE can gain the optimal the end-to-end path across multi-domains. <= /div>
 
Best regards.
 
Yongli Zhao

Beijing University of Posts and Telecommunications<= br>Beijing, China


2010/1/8 Daniel King <daniel@olddog.co.uk>
Hi Yongli,

Thanks for rev= iewing the draft. In response to your questions:

1. The Parent PCE w= ill determine the likely domain paths from the source to the destination. T= he Parent PCE will then send an edge-to-edge request to a Child PCE in the = ingress domain (ingress-to-edge), and requests to a Child PCE in each candi= date transmit domain (edge-to-edge) and finally a Child PCE in the egress d= omain (edge-to-egress). Once the responses are collated a suitable path can= be identified and selected by Parent PCE. The Parent PCE will then send a = response back to the Child PCE in the ingress domain. The Child PCE will th= en send an ERO response to the PCC that requested the inter-domain path.
2. H-PCE has been designed so the Parent PCE will not have the same det= ailed internal domain topology information of the Child PCE's it servic= es. However the Parent PCE does know capabilities of the links that connect= the domains together. The inter-domain link information would be reported = by the Child PCE during the initial Child and Parent PCE information exchan= ge. The Child PCE can learn about its inter-domain links via its domain IGP= . During "step 9" of the example procedure the Parent PCE has the= opportunity to apply network or policy constraints based on its knowledge = of the inter-domain links selected for the candidate path.

So in summary, one aim of H-PCE is to avoid the need for anyone one ent= ity to have a detailed topology view of each transit domain. A Child PCE pe= r domain, is used to compute a segment of the end-to-end path. The Child PC= E can also replace its path segment information with a path-key [RFC5520] t= o further maintain confidentiality.

On review of the step 9 procedure, we will update the text so the proce= ss and actual network topology view is clearer.

Br, Dan.

From= : =D5=D4=D3=C0=C0=FB [mailto:yufeng= x386@gmail.com]
Sent: 03 January 2010 09:45
To: d= aniel@olddog.co.uk
Cc: pce@ietf.org<= /a>
Subject: question on draft-king-hierarchy-fwk-03.txt

Hi Dan,
    I have two questions on the = document "draft-king-hierarchy-fwk-03.txt".
(1) In the procedu= re of section 5.6.2, three domain paths have been gained, and PCEs 1 to 4 h= ave received the path compuation requests from the parent PCE. Does it mean= that the parent PCE will send edge-to-edge path computation requests to al= l the PCEs along all the domain paths?

(2) In step 9 of the same section, it seems not very clear about the co= mpuation responses in the sentence of  "PCE 5 correlates all the = computation responses from each child PCE". Does it mean the detailed = constraint-based path segments in the local domain?
   Thank you very much.

Best regards.


Yongli Zh= ao

Beijing University of Posts and Telecommunications
Beijing, Ch= ina


--001636e908a1855773047cce8f7e-- From peng.he.2000@gmail.com Sun Jan 10 08:40:13 2010 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 AEEF93A6844 for ; Sun, 10 Jan 2010 08:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] 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 LuTFR3GHubFO for ; Sun, 10 Jan 2010 08:40:12 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 5DAB93A67EA for ; Sun, 10 Jan 2010 08:40:12 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so4402201eye.51 for ; Sun, 10 Jan 2010 08:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dicX7YHQy1AsPJ8+qszxJGfF3zkU3RbE+nXhMN23c1Y=; b=i+JHW4gT6urVsj/mj2gsvWj4N6ltI/vK1Idl4esSLByzSBi/hZO8yKHrL2Ppwkw3nb RlmHBlL7TcXDZCcSh7uPHney6tTrlUrEvc62EDzQcOlMXQ3QTwrTihqSduToZjzrz3Wt 7pr8KPdv0IGE8rV/b6zafCBVBvMZiu9XcVu7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Lk2RKZPwxJ3rht/hPr1AMaOcQpIdJ6h7eBiQyFCYCnyQGQ1zKuLfVavlirxe+ZuXJ+ K7e4tx9oRHTZnapj6L2SSM08/ZulKBi5/ko3XGiwmJ3cdsdJXA2kt7Wc53ydV3IfPWS/ SJTb/acQBym5RMY+E/gzVOy4t+gkDPwZ2Lds8= MIME-Version: 1.0 Received: by 10.213.38.208 with SMTP id c16mr8201817ebe.7.1263141605993; Sun, 10 Jan 2010 08:40:05 -0800 (PST) In-Reply-To: References: <002701ca905a$6c3d1800$44b74800$@co.uk> Date: Sun, 10 Jan 2010 11:40:05 -0500 Message-ID: <406e32c01001100840k4b783765x5b1ccde5cf4e9654@mail.gmail.com> From: Peng He To: =?GB2312?B?1dTTwMD7?= Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org Subject: Re: [Pce] question on draft-king-hierarchy-fwk-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: Sun, 10 Jan 2010 16:40:13 -0000 kind of distributed-computing system; if considering abstract say (TE) info from domain internal to parent PCE, the fundamental question might be what almost-exact information that are gonna be abstracted and also need to make sure by abstracting the global end-to-end optimal pach can still be achieved with no scalability concerns ... Regards, Peng 2010/1/10 =D5=D4=D3=C0=C0=FB : > Hi Dan > Thank you very much for your answers. > Ok. The Parent PCE can determine a likely domain path based on its > knowledge of the inter-domain links. However, the domain path may not be > optimal because it does not know the detailed information in each domain. > Maybe there is a balance between the optimization and the complexity. Do = you > think so? > I am always wondering about the optimal end-to-end path in the current > framework. > Another question. Can we abstract the detailed information in each > domain into some simple forms and provide them to the parent PCE? For > example, if we compute the shortest path according to the hop numbers. We > can gain the hop numbers between each border nodes pair in each domain by > the child PCE, and provide them to the parent PCE. Then the parent PCE ca= n > gain the optimal the end-to-end path across multi-domains. > > Best regards. > > Yongli Zhao > > Beijing University of Posts and Telecommunications > Beijing, China > > > 2010/1/8 Daniel King >> >> Hi Yongli, >> >> Thanks for reviewing the draft. In response to your questions: >> >> 1. The Parent PCE will determine the likely domain paths from the source >> to the destination. The Parent PCE will then send an edge-to-edge reques= t to >> a Child PCE in the ingress domain (ingress-to-edge), and requests to a C= hild >> PCE in each candidate transmit domain (edge-to-edge) and finally a Child= PCE >> in the egress domain (edge-to-egress). Once the responses are collated a >> suitable path can be identified and selected by Parent PCE. The Parent P= CE >> will then send a response back to the Child PCE in the ingress domain. T= he >> Child PCE will then send an ERO response to the PCC that requested the >> inter-domain path. >> >> 2. H-PCE has been designed so the Parent PCE will not have the same >> detailed internal domain topology information of the Child PCE's it >> services. However the Parent PCE does know capabilities of the links tha= t >> connect the domains together. The inter-domain link information would be >> reported by the Child PCE during the initial Child and Parent PCE >> information exchange. The Child PCE can learn about its inter-domain lin= ks >> via its domain IGP. During "step 9" of the example procedure the Parent = PCE >> has the opportunity to apply network or policy constraints based on its >> knowledge of the inter-domain links selected for the candidate path. >> >> So in summary, one aim of H-PCE is to avoid the need for anyone one enti= ty >> to have a detailed topology view of each transit domain. A Child PCE per >> domain, is used to compute a segment of the end-to-end path. The Child P= CE >> can also replace its path segment information with a path-key [RFC5520] = to >> further maintain confidentiality. >> >> On review of the step 9 procedure, we will update the text so the proces= s >> and actual network topology view is clearer. >> >> Br, Dan. >> >> From: =D5=D4=D3=C0=C0=FB [mailto:yufengx386@gmail.com] >> Sent: 03 January 2010 09:45 >> To: daniel@olddog.co.uk >> Cc: pce@ietf.org >> Subject: question on draft-king-hierarchy-fwk-03.txt >> >> Hi Dan, >> I have two questions on the document >> "draft-king-hierarchy-fwk-03.txt". >> (1) In the procedure of section 5.6.2, three domain paths have been >> gained, and PCEs 1 to 4 have received the path compuation requests from = the >> parent PCE. Does it mean that the parent PCE will send edge-to-edge path >> computation requests to all the PCEs along all the domain paths? >> >> (2) In step 9 of the same section, it seems not very clear about the >> compuation responses in the sentence of "PCE 5 correlates all the >> computation responses from each child PCE". Does it mean the detailed >> constraint-based path segments in the local domain? >> Thank you very much. >> >> Best regards. >> >> >> Yongli Zhao >> >> Beijing University of Posts and Telecommunications >> Beijing, China >> > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From adrian@olddog.co.uk Sun Jan 10 12:21:33 2010 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 9398A3A68A2 for ; Sun, 10 Jan 2010 12:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, 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 gUeLfTE60AM5 for ; Sun, 10 Jan 2010 12:21:32 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 598583A677C for ; Sun, 10 Jan 2010 12:21:32 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o0AKLEMo008976; Sun, 10 Jan 2010 20:21:14 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o0AKLC82008966; Sun, 10 Jan 2010 20:21:13 GMT Message-ID: <7B44314A48344B5485D7E7B46CA8417F@your029b8cecfe> From: "Adrian Farrel" To: =?gb2312?B?1dTTwMD7?= References: <002701ca905a$6c3d1800$44b74800$@co.uk> Date: Sun, 10 Jan 2010 20:20:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; 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] question on draft-king-hierarchy-fwk-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: Sun, 10 Jan 2010 20:21:33 -0000 Hi Yongli, [speaking as an individual and co-author] > The Parent PCE can determine a likely domain path based on > its knowledge of the inter-domain links. However, the > domain path may not be optimal because it does not know > the detailed information in each domain. I think there is something missing here. There would be zero value in this hierarchical PCE approach if it could not generate optimal paths! The parent PCE is able to determine all potential end-to-end domain paths. It can then ask the child PCEs responsible for each domain to compute optimal paths across the domains and return those paths together with their costs. The parent PCE can combining these paths to construct a set of potential end-to-end paths and can easily determine which is optimal by summing the costs of the segments. Of course, the parent PCE does not need to perform this work for *all* potential domain paths if it can apply policy to guess that some domain paths are likely to result in suboptimal solutions. Furthermore, the parent PCE can make a trade-off. By issuing computation requests to the children one at a time and using the returned information to prune domains from the set of potential domain paths. This (obviously) reduces the number of child PCEs involved and simplifies the computations they have to perform, but may take longer to reach a solution. > Maybe there is a balance between the optimization and > the complexity. Do you think so? This is always the case. But we aim to produce a simple (non-complex) architecture that can be used in complex or simple environments, and that can provide optimal solutions. > I am always wondering about the optimal end-to-end path in > the current framework. > > Another question. Can we abstract the detailed information > in each domain into some simple forms and provide them to > the parent PCE? For example, if we compute the shortest > path according to the hop numbers. We can gain the hop > numbers between each border nodes pair in each domain by > the child PCE, and provide them to the parent PCE. Then > the parent PCE can gain the optimal the end-to-end path > across multi-domains. I am strongly opposed to this idea. Operating on a single metric like hop count, it appears that this approach might be practicable. It might suffer some instability during link failures, but this could be damped leading to sub-optimal paths in those windows. But what value is this information is a sophisticated TE environment? If your definition of an "optimal" end-to-end path is limited to just least number of end-to-end hops, this mechanism can work. But the constraints on TE paths include *at*least* bandwidth availability as well. It becomes radically more complex to abstract the available bandwidth and tie it to the hop counts for all edge-to-edge connectivity across a domain. It is also likely that this information will change every time some unrelated LSP is set up within the domain. The result is a very large data set with a high rate of change and non-trivial abstraction processing. Of course, an option is to aggregate the information by introducing approximations. This can reduce the size of the data set considerably, and will also reduce the flapping, but might not reduce the processing requirements. BUT, the main concern with such aggregation is that it loses information; and any loss of information risks the optimality of the final solution. Moreover, when we extend the PCE model beyond "simple" packet TE environments to use cases with multiple constraints (consider the WSON work currently in hand) this abstraction becomes hopelessly complex. So, the solution we have developed uses just a topological abstraction (i.e., what inter-domain links exist). It leaves every other item of the determination of cross-domain paths as the responsibility of the child PCEs. Hope this helps. Cheers, Adrian From yufengx386@gmail.com Sun Jan 10 18:05:52 2010 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 40B203A697B for ; Sun, 10 Jan 2010 18:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.127 X-Spam-Level: ** X-Spam-Status: No, score=2.127 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuGce9cyE04q for ; Sun, 10 Jan 2010 18:05:51 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id E9BA23A6859 for ; Sun, 10 Jan 2010 18:05:50 -0800 (PST) Received: by pxi16 with SMTP id 16so6319784pxi.29 for ; Sun, 10 Jan 2010 18:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=o0GHYTnTgK7bcQtqxVQ1d03KwK85wb1f3k76v3op2QA=; b=l7Xtun9Q6ax9ZGq3A0I0CKYiEScplGAD4xAvYNz1nXtQCxVKRapgqle0xH5WY1jzj/ glkevPpVRnU47lyX3u6GiY3mP7yCc6cSNWvQxz6cQKp2BPen3JGB+pOcDQPm9KAARvzJ hhx4uDu681OrtHL/TbEwmBy3Cau6nY300pcL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o4ej/zMOzdqLnezoPcfu4Hxo5fW/GsQg98qVIpOZQiNP+n0ok6fXuKQBZKtSkBNikf 6T1BAgFuBBqV2laFE6dKrPWbD1mVWRpgmvi+8aCKkI1MJkUD/HD8krnOuGGsrLSlP4aB VLQZGZl+Rp7rWfPn/gFc83P8cMQz/nHjgFkKA= MIME-Version: 1.0 Received: by 10.142.121.15 with SMTP id t15mr140674wfc.66.1263175546348; Sun, 10 Jan 2010 18:05:46 -0800 (PST) In-Reply-To: <7B44314A48344B5485D7E7B46CA8417F@your029b8cecfe> References: <002701ca905a$6c3d1800$44b74800$@co.uk> <7B44314A48344B5485D7E7B46CA8417F@your029b8cecfe> Date: Mon, 11 Jan 2010 10:05:46 +0800 Message-ID: From: =?GB2312?B?1dTTwMD7?= To: Adrian Farrel , peng.he.2000@gmail.com Content-Type: multipart/alternative; boundary=001636e0a880baa3ff047cd9f905 Cc: pce@ietf.org Subject: Re: [Pce] question on draft-king-hierarchy-fwk-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: Mon, 11 Jan 2010 02:05:52 -0000 --001636e0a880baa3ff047cd9f905 Content-Type: text/plain; charset=ISO-8859-1 Hello Adrian and peng, Thank you for your valueable answers. I support the hierarchical PCE approach. I understand the parent PCE can gain the optimal paths across diverse domains if it asks all child PCEs along all potential end-to-end domain paths. However, it is at the cost of comlexity. So the parent PCE can make a trafe-off and apply some policy to gain the suboptimal solutions which is practical in most environments. Is it right? If we want to compute the optimal paths at lower complexity, some optimal approaches are necessary, such as the pruning approach Adrian said. Actually, there are some problems with the abstracting method, such as the instability and the complexity. However, all the information is also necessary when the parent PCE asks the child PCEs. So can the child PCEs compute and maintain the link information between each border nodes pair in each domain in advance? Then the parent PCE can gain the end-to-end path quickly. Furthermore, the child PCEs can compute and maintain the information easily because they keep all the detailed information in the local domain. What information and constraints are to compute and maintain is same to that we consider in other documents. Thanks. Br. Yongli 2010/1/11 Adrian Farrel > Hi Yongli, > > [speaking as an individual and co-author] > > > The Parent PCE can determine a likely domain path based on >> its knowledge of the inter-domain links. However, the >> domain path may not be optimal because it does not know >> the detailed information in each domain. >> > > I think there is something missing here. There would be zero value in this > hierarchical PCE approach if it could not generate optimal paths! > > The parent PCE is able to determine all potential end-to-end domain paths. > It can then ask the child PCEs responsible for each domain to compute > optimal paths across the domains and return those paths together with their > costs. > > The parent PCE can combining these paths to construct a set of potential > end-to-end paths and can easily determine which is optimal by summing the > costs of the segments. > > Of course, the parent PCE does not need to perform this work for *all* > potential domain paths if it can apply policy to guess that some domain > paths are likely to result in suboptimal solutions. > > Furthermore, the parent PCE can make a trade-off. By issuing computation > requests to the children one at a time and using the returned information to > prune domains from the set of potential domain paths. This (obviously) > reduces the number of child PCEs involved and simplifies the computations > they have to perform, but may take longer to reach a solution. > > > Maybe there is a balance between the optimization and >> the complexity. Do you think so? >> > > This is always the case. But we aim to produce a simple (non-complex) > architecture that can be used in complex or simple environments, and that > can provide optimal solutions. > > > I am always wondering about the optimal end-to-end path in >> the current framework. >> >> Another question. Can we abstract the detailed information >> in each domain into some simple forms and provide them to >> the parent PCE? For example, if we compute the shortest >> path according to the hop numbers. We can gain the hop >> numbers between each border nodes pair in each domain by >> the child PCE, and provide them to the parent PCE. Then >> the parent PCE can gain the optimal the end-to-end path >> across multi-domains. >> > > I am strongly opposed to this idea. Operating on a single metric like hop > count, it appears that this approach might be practicable. It might suffer > some instability during link failures, but this could be damped leading to > sub-optimal paths in those windows. > > But what value is this information is a sophisticated TE environment? If > your definition of an "optimal" end-to-end path is limited to just least > number of end-to-end hops, this mechanism can work. But the constraints on > TE paths include *at*least* bandwidth availability as well. It becomes > radically more complex to abstract the available bandwidth and tie it to the > hop counts for all edge-to-edge connectivity across a domain. It is also > likely that this information will change every time some unrelated LSP is > set up within the domain. The result is a very large data set with a high > rate of change and non-trivial abstraction processing. > > Of course, an option is to aggregate the information by introducing > approximations. This can reduce the size of the data set considerably, and > will also reduce the flapping, but might not reduce the processing > requirements. BUT, the main concern with such aggregation is that it loses > information; and any loss of information risks the optimality of the final > solution. > > Moreover, when we extend the PCE model beyond "simple" packet TE > environments to use cases with multiple constraints (consider the WSON work > currently in hand) this abstraction becomes hopelessly complex. > > So, the solution we have developed uses just a topological abstraction > (i.e., what inter-domain links exist). It leaves every other item of the > determination of cross-domain paths as the responsibility of the child PCEs. > > Hope this helps. > Cheers, > Adrian > > > --001636e0a880baa3ff047cd9f905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Adrian and peng,
=A0=A0=A0=A0=A0Thank you=A0for your valueable answers. I support the h= ierarchical PCE approach.
=A0=A0=A0=A0 I understand the parent PCE can gain the optimal paths ac= ross diverse domains if it asks all child PCEs along all potential end-to-e= nd domain paths. However, it is at the cost of comlexity. So the parent PCE= can make a trafe-off and apply some policy to gain the suboptimal solution= s which is practical in most environments. Is it right?
=A0=A0=A0=A0 If we want to compute the optimal paths at lower complexi= ty, some optimal approaches are necessary, such as the pruning approach Adr= ian said. Actually, there are some problems with the abstracting method, su= ch as the instability=A0and the complexity. However, all the information is= also necessary when the parent PCE asks the child PCEs. So can the child P= CEs compute and maintain the link information between each border nodes pai= r in each domain in advance? Then the parent PCE can gain the end-to-end pa= th quickly. Furthermore, the child PCEs can compute and maintain the inform= ation easily because they keep all the detailed information in the local do= main.
=A0=A0=A0 What information and constraints are to compute and maintain= is same to that we consider in other documents.
=A0
=A0
Thanks.
Br.
Yongli
=A0
=A0
2010/1/11 Adrian Farrel <adrian@olddog.co.uk<= /a>>
Hi Yongli,

[speaking as a= n individual and co-author]=20


The Parent PCE can determine a l= ikely domain path based on
its knowledge of the inter-domain links. Howe= ver, the
domain path may not be optimal because it does not know
the detailed inf= ormation in each domain.

I think there is somethi= ng missing here. There would be zero value in this hierarchical PCE approac= h if it could not generate optimal paths!

The parent PCE is able to determine all potential end-to-end domain pat= hs. It can then ask the child PCEs responsible for each domain to compute o= ptimal paths across the domains and return those paths together with their = costs.

The parent PCE can combining these paths to construct a set of potentia= l end-to-end paths and can easily determine which is optimal by summing the= costs of the segments.

Of course, the parent PCE does not need to p= erform this work for *all* potential domain paths if it can apply policy to= guess that some domain paths are likely to result in suboptimal solutions.=

Furthermore, the parent PCE can make a trade-off. By issuing computatio= n requests to the children one at a time and using the returned information= to prune domains from the set of potential domain paths. This (obviously) = reduces the number of child PCEs involved and simplifies the computations t= hey have to perform, but may take longer to reach a solution.=20


Maybe there is a balance between= the optimization and
the complexity. Do you think so?

This is always the case. But we aim to produce a simple (non-comp= lex) architecture that can be used in complex or simple environments, and t= hat can provide optimal solutions.=20


I am always wondering about the = optimal end-to-end path in
the current framework.

Another questio= n. Can we abstract the detailed information
in each domain into some simple forms and provide them to
the parent PCE= ? For example, if we compute the shortest
path according to the hop numb= ers. We can gain the hop
numbers between each border nodes pair in each = domain by
the child PCE, and provide them to the parent PCE. Then
the parent PCE c= an gain the optimal the end-to-end path
across multi-domains.

I am strongly opposed to this idea. Operating on a single m= etric like hop count, it appears that this approach might be practicable. I= t might suffer some instability during link failures, but this could be dam= ped leading to sub-optimal paths in those windows.

But what value is this information is a sophisticated TE environment? I= f your definition of an "optimal" end-to-end path is limited to j= ust least number of end-to-end hops, this mechanism can work. But the const= raints on TE paths include *at*least* bandwidth availability as well. It be= comes radically more complex to abstract the available bandwidth and tie it= to the hop counts for all edge-to-edge connectivity across a domain. It is= also likely that this information will change every time some unrelated LS= P is set up within the domain. The result is a very large data set with a h= igh rate of change and non-trivial abstraction processing.

Of course, an option is to aggregate the information by introducing app= roximations. This can reduce the size of the data set considerably, and wil= l also reduce the flapping, but might not reduce the processing requirement= s. BUT, the main concern with such aggregation is that it loses information= ; and any loss of information risks the optimality of the final solution.
Moreover, when we extend the PCE model beyond "simple" packet= TE environments to use cases with multiple constraints (consider the WSON = work currently in hand) this abstraction becomes hopelessly complex.

So, the solution we have developed uses just a topological abstraction = (i.e., what inter-domain links exist). It leaves every other item of the de= termination of cross-domain paths as the responsibility of the child PCEs.<= br>
Hope this helps.
Cheers,
Adrian



--001636e0a880baa3ff047cd9f905-- From adrian@olddog.co.uk Tue Jan 12 09:55:50 2010 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 A3FC128C11D for ; Tue, 12 Jan 2010 09:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=1.079, 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 OitWJ7199-Gh for ; Tue, 12 Jan 2010 09:55:49 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 582793A6A63 for ; Tue, 12 Jan 2010 09:55:46 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o0CHtPpZ015644; Tue, 12 Jan 2010 17:55:25 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o0CHtOmW015630; Tue, 12 Jan 2010 17:55:24 GMT Message-ID: <38F4B1AED0BA47398FDBBAADC02D6FFA@your029b8cecfe> From: "Adrian Farrel" To: "???" , References: <002701ca905a$6c3d1800$44b74800$@co.uk> <7B44314A48344B5485D7E7B46CA8417F@your029b8cecfe> Date: Tue, 12 Jan 2010 17:53:54 -0000 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] question on draft-king-hierarchy-fwk-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: Tue, 12 Jan 2010 17:55:50 -0000 Hi, Sure, a child PCE implementation could pre-compute paths across the domain, and supply those responses to the parent PCE when requested. In fact, any PCE is free to pre-compute any path. In some circumstances this might be very sensible. In others, it might be a very poor solution. I don't believe there is any change to the PCE architecture, protocols, or procedures to build such implementations. Regards, Adrian ----- Original Message ----- From: "???" To: "Adrian Farrel" ; Cc: ; "Daniel King" Sent: Monday, January 11, 2010 2:05 AM Subject: Re: [Pce] question on draft-king-hierarchy-fwk-03.txt > Hello Adrian and peng, > Thank you for your valueable answers. I support the hierarchical PCE > approach. > I understand the parent PCE can gain the optimal paths across diverse > domains if it asks all child PCEs along all potential end-to-end domain > paths. However, it is at the cost of comlexity. So the parent PCE can make > a > trafe-off and apply some policy to gain the suboptimal solutions which is > practical in most environments. Is it right? > If we want to compute the optimal paths at lower complexity, some > optimal approaches are necessary, such as the pruning approach Adrian > said. > Actually, there are some problems with the abstracting method, such as the > instability and the complexity. However, all the information is also > necessary when the parent PCE asks the child PCEs. So can the child PCEs > compute and maintain the link information between each border nodes pair > in > each domain in advance? Then the parent PCE can gain the end-to-end path > quickly. Furthermore, the child PCEs can compute and maintain the > information easily because they keep all the detailed information in the > local domain. > What information and constraints are to compute and maintain is same to > that we consider in other documents. > > > Thanks. > Br. > Yongli > > > 2010/1/11 Adrian Farrel > >> Hi Yongli, >> >> [speaking as an individual and co-author] >> >> >> The Parent PCE can determine a likely domain path based on >>> its knowledge of the inter-domain links. However, the >>> domain path may not be optimal because it does not know >>> the detailed information in each domain. >>> >> >> I think there is something missing here. There would be zero value in >> this >> hierarchical PCE approach if it could not generate optimal paths! >> >> The parent PCE is able to determine all potential end-to-end domain >> paths. >> It can then ask the child PCEs responsible for each domain to compute >> optimal paths across the domains and return those paths together with >> their >> costs. >> >> The parent PCE can combining these paths to construct a set of potential >> end-to-end paths and can easily determine which is optimal by summing the >> costs of the segments. >> >> Of course, the parent PCE does not need to perform this work for *all* >> potential domain paths if it can apply policy to guess that some domain >> paths are likely to result in suboptimal solutions. >> >> Furthermore, the parent PCE can make a trade-off. By issuing computation >> requests to the children one at a time and using the returned information >> to >> prune domains from the set of potential domain paths. This (obviously) >> reduces the number of child PCEs involved and simplifies the computations >> they have to perform, but may take longer to reach a solution. >> >> >> Maybe there is a balance between the optimization and >>> the complexity. Do you think so? >>> >> >> This is always the case. But we aim to produce a simple (non-complex) >> architecture that can be used in complex or simple environments, and that >> can provide optimal solutions. >> >> >> I am always wondering about the optimal end-to-end path in >>> the current framework. >>> >>> Another question. Can we abstract the detailed information >>> in each domain into some simple forms and provide them to >>> the parent PCE? For example, if we compute the shortest >>> path according to the hop numbers. We can gain the hop >>> numbers between each border nodes pair in each domain by >>> the child PCE, and provide them to the parent PCE. Then >>> the parent PCE can gain the optimal the end-to-end path >>> across multi-domains. >>> >> >> I am strongly opposed to this idea. Operating on a single metric like hop >> count, it appears that this approach might be practicable. It might >> suffer >> some instability during link failures, but this could be damped leading >> to >> sub-optimal paths in those windows. >> >> But what value is this information is a sophisticated TE environment? If >> your definition of an "optimal" end-to-end path is limited to just least >> number of end-to-end hops, this mechanism can work. But the constraints >> on >> TE paths include *at*least* bandwidth availability as well. It becomes >> radically more complex to abstract the available bandwidth and tie it to >> the >> hop counts for all edge-to-edge connectivity across a domain. It is also >> likely that this information will change every time some unrelated LSP is >> set up within the domain. The result is a very large data set with a high >> rate of change and non-trivial abstraction processing. >> >> Of course, an option is to aggregate the information by introducing >> approximations. This can reduce the size of the data set considerably, >> and >> will also reduce the flapping, but might not reduce the processing >> requirements. BUT, the main concern with such aggregation is that it >> loses >> information; and any loss of information risks the optimality of the >> final >> solution. >> >> Moreover, when we extend the PCE model beyond "simple" packet TE >> environments to use cases with multiple constraints (consider the WSON >> work >> currently in hand) this abstraction becomes hopelessly complex. >> >> So, the solution we have developed uses just a topological abstraction >> (i.e., what inter-domain links exist). It leaves every other item of the >> determination of cross-domain paths as the responsibility of the child >> PCEs. >> >> Hope this helps. >> Cheers, >> Adrian >> >> >> > From gregimirsky@gmail.com Thu Jan 14 12:42:40 2010 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 57EAD3A69C5 for ; Thu, 14 Jan 2010 12:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z848yw3v8Gyi for ; Thu, 14 Jan 2010 12:42:38 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id B6E063A6809 for ; Thu, 14 Jan 2010 12:42:03 -0800 (PST) Received: by bwz23 with SMTP id 23so63509bwz.29 for ; Thu, 14 Jan 2010 12:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lkERR9ynfj4imfJQWRiIFbWXcf6RbmesgTSkGR5LTM0=; b=kAdeeH0allHh6FMaBP4euOSlacd+iiT45hUXdMmRXdH/SL222vNuPCjdrKId++otnN Vch6mMw4znUsL4HfVufiYeYLp04g/V7Z8bWcDb7M9lEcPxRljXK6Ijcv7uvZnhmjmJSV w9nXASt72Lu80nOUoqmyrJgAjTzSU3qozIx0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fDXeUPXiXeHN0GqOxUkTFz2ZpXvN3ewJX80pHtOaW2WA4b/vuF880vS0/qkIFoSlSl jLOqNArUFHZRlAZS77KZwwEf8IGiGZ2dAgAgjGz5/uWJwMCalBJsYcetzArNXCIAjrB1 VKCxjm4KjxeNAEHoCztXfhvAD2GTQ5LaoQk+8= MIME-Version: 1.0 Received: by 10.204.15.3 with SMTP id i3mr756546bka.71.1263501716093; Thu, 14 Jan 2010 12:41:56 -0800 (PST) In-Reply-To: <000401ca9083$defa1f90$3915c00a@china.huawei.com> References: <000401ca9083$defa1f90$3915c00a@china.huawei.com> Date: Thu, 14 Jan 2010 12:41:55 -0800 Message-ID: <787be2781001141241n750d4c72ie23ceb07ee167c5b@mail.gmail.com> From: Greg Mirsky To: Quintin Zhao Content-Type: multipart/alternative; boundary=00032555a0bef5fe2a047d25eaea Cc: pce@ietf.org Subject: Re: [Pce] FW: Inter-domain-p2mp-procedures 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, 14 Jan 2010 20:42:40 -0000 --00032555a0bef5fe2a047d25eaea Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Quintin, sorry for delayed reply. If we take Fig.1 from RFC 4090 and remove link [R3]-[R8], then that will change R1's Backup: [R1]------[R2]------[R3]-----[R4]------[R5] \ \ / \ / [R6]------[R7]--------[R8]-------[R9] Protected LSP: [R1->R2->R3->R4->R5] R1's Backup: [R1->R6->R7->R8->R4] R2's Backup: [R2->R7->R8->R4] R4's Backup: [R4->R9->R5] As result of lower meshiness of the network the Merge point is moved from R= 3 to R4. If only Link protection desired, then, with the topology as above: R1's Backup: [R1->R6->R7->R2] R2's Backup: [R2->R7->R8->R4] Thus we see, that protecting even an immediate link is not always possible to merge onto Next Hop LSR and depends on level of connectivity (meshiness) of the network. In my view, using p2mp LSP to provide local protection for the p2mp LSP is more generic approach. Kind regards, Greg On Fri, Jan 8, 2010 at 8:58 AM, Quintin Zhao wrote: > Hi Greg, > > > > Thanks for the comments and suggestions! > > > > Can you elaborate a little more on what you mean here? > > > > =93I think that because we can not guarantee that the immediate LSR will = be > the merging point of p2p backup LSP one can not assume that a single p2p = can > be used to provide protection for local link failure case.=94 > > > > Quintin > > > ------------------------------ > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Tuesday, January 05, 2010 6:20 PM > *To:* JP Vasseur > *Cc:* Quintin Zhao; pce@ietf.org > > *Subject:* Re: [Pce] Inter-domain-p2mp-procedures > > > > Hi Quintin and JP, > in regard to applicability of p2p FRR protection of links of p2mp LSP I > agree with JP that such applicability is questionable and very much depen= ds > on network topology, its meshiness. I think that because we can not > guarantee that the immediate LSR will be the merging point of p2p backup = LSP > one can not assume that a single p2p can be used to provide protection fo= r > local link failure case. I believe that strong case can be made to recomm= end > use p2mp for local link protection as well as when node protection requir= ed. > > Regards, > Greg > > 2009/12/23 JP Vasseur > > Hi, > > > > On Dec 21, 2009, at 3:49 AM, Quintin Zhao wrote: > > JP, > > Good question! I guess that I should use "more complex to be implemented" > instead of "less applicable" in my previous email when I refer to using F= RR > for P2MP node protection. > > > > Well this is arguable though .. > > > > What I was trying to mean is that p2p backup is easily to be used for the > link protection for p2mp. To use FRR for the node protection in p2mp, it = is > not that straight forward comparing to p2p node protection, especially fr= om > the point view of bandwidth cost and label allocation. > > > > Well it all depends on how you compute your P2P backup, and this may be > used > for a very short period of time. There are excellent off-line algorithms = to > achieve > some good level of efficiency. > > > > For example, to use > the p2p tunnel to backup the branch node, we need multiple p2p tunnels to > protect a single branch node. If the p2mp backup tunnel is used for the > branch node protection, then the upstream label allocation might be neede= d. > > > > Which is not a major issue. See long discussions on the list some time ag= o > on the > subject matter. > > Thanks. > > JP. > > > > > > Regards, > Quintin > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Saturday, December 19, 2009 4:51 AM > To: Quintin Zhao > Cc: pce@ietf.org > Subject: Re: [Pce] Inter-domain-p2mp-procedures > > Hi, > > On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote: > > > JP, > > Thanks for your comments and suggestions. > > I agree with you that for a quickly recovery, FRR is a good choice. > For the > p2mp TE LSP, if the failures are about link failures, FRR can be > used for > the recovery. If the failures are about the p2mp nodes which can be > the > root/branch/bud/leaf nodes, FRR might not be an easy way to cover > these > cases.=A1=A1 > > > What makes you think that the use of FRR is less applicable to node > failures ? > (for which you could either use a set of P2P backup or a single P2MP > backup) > > Thanks > > JP. > > This may lead to other possible solutions and the pre-computed > backup sub-tree or the whole backup tree might be needed for the > possible > solutions. As you mentioned, using the FRR itself will eventually > need the > head end reoptimization using a make before break. > > The pre-computed backup p2mp path/sub-path or the new computed path > during > reoptimization process using make before breaks are the optimal path > subject > to the OF and all other current constrains when the path is computed > by the > PCE. I agree with you that we can not draw the conclusion on the > potentially > level of sub-optimality of performing local reroute as opposed to > global > reoptimization. > > Also we can not draw the conclusion if these backup path or > optimized path > after the failure is better or worse than the primary path. These > pre-computed backup paths/sub-paths or the optimized paths under the > failure > condition are the best path which can be used for the recovery of the > failure while satisfying all the conditions. > > Regards, > Quintin > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, December 17, 2009 1:26 PM > To: Quintin Zhao > Cc: pce@ietf.org > Subject: Re: [Pce] Inter-domain-p2mp-procedures > > Hi, > > Note that this is a fairly well-known issue. The aim of local repair > has always been to quickly recover from the failure. The degree of > resources guarantees and optimality depends on the amount of resources > dedicated to backup, several assumptions with regards to potential > simultaneous failures, the algorithms used to pre-compute backup > tunnels, etc ... The approach taken by P2P FRR has been to first > locally reroute and trigger a head-end reoptimization using a make > before break. I do not think that you can draw any conclusion on the > potentially level of sub-optimality of performing local reroute as > opposed to global reoptimization. It depends on a number of factors. > > JP. > > On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: > > > Hello PCE'rs, > > I would like to follow-up on some discussions from our PCE WG > session last > month. Specifically regarding Dajiang's failure and recomputation > observations on our draft. We are very interested to hear comments > regarding > the need for computing secondary paths in the event of failure. > Currently > our thinking is to recompute the sub-tree based in the domain where > the > failure has occurred. In this case we would not need to perform a > recalculation of the entire tree. We could also recompute the entire > tree, > and avoid the failed areas, as long as the TED has the updated > topology. > Realistically one might have a backup core tree pre-computed so you > can > switch over in the event of failure. There are also other > considerations. > Would a partial recomputation provide a "worse" SPT or MCT tree, or > would a > full tree recomputation provide a "better" SPT or MCT? I can think of > scenarios for both a partial and full recomputation, so perhaps we > need to > implement both but allow the PCC to decide when to issue a partial > or full > recomputation based on some criterion. > > Thanks, > > Quintin > > _______________________________________________ > 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 > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --00032555a0bef5fe2a047d25eaea Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Quintin,
sorry for delayed reply. If we take Fig.1 from RFC 4090 and = remove link [R3]-[R8], then that will change R1's Backup:
 [R1]------[R2]------[R3]-----[R4]------[R5]=


      \           \                    /        \      /
    [R6]------[=
R7]--------[R8]-------[R9]

Protected LSP: [R1->R2-&g= t;R3->R4->R5]
R= 1's Backup: [R1->R6->R7->R8->R4]
R2's Bac= kup: [R2->R7->R8->R4]
R= 4's Backup: [R4->R9->R5]

As result of lower meshiness of the network the Merge point is moved from R= 3 to R4.
If only Link protection desired, then, with the topology as abo= ve:

R1's Backup: [R1->= ;R6->R7->R2]
R2's Backup: [R2->R7->R8->R4]

Thus we see, that p= rotecting even an immediate link is not always possible to merge onto Next = Hop LSR and depends on level of connectivity (meshiness) of the network. In= my view, using p2mp LSP to provide local protection for the p2mp LSP is mo= re generic approach.

Kind regards,
Greg

On Fri, Jan 8, = 2010 at 8:58 AM, Quintin Zhao <qzhao@huawei.com> wrote:

Hi Greg,

=A0

Thanks for the comments and suggestions! <= /span>

=A0

Can you elaborate a little more on what yo= u mean here?

=A0

=93I think that because we can not guarant= ee that the immediate LSR will be the merging point of p2p backup LSP one can not assum= e that a single p2p can be used to provide protection for local link failure case.=94

=A0

Quintin

=A0

From: Greg Mirsky [mailto:gregimir= sky@gmail.com]
Sent: Tuesday, January 05,= 2010 6:20 PM
To: JP Vasseur
Cc: Quintin Zhao; pce@ietf.org

=

Subject: Re: [Pce] Inter-domain-p2mp-procedures

<= div class=3D"h5">

=A0

Hi Quintin and= JP,
in regard to applicability of p2p FRR protection of links of p2mp LSP I agr= ee with JP that such applicability is questionable and very much depends on network topology, its meshiness. I think that because we can not guarantee = that the immediate LSR will be the merging point of p2p backup LSP one can not assume that a single p2p can be used to provide protection for local link f= ailure case. I believe that strong case can be made to recommend use p2mp for loca= l link protection as well as when node protection required.

Regards,
Greg

2009/12/23 JP Vasseur <jvasseur@cisco.com>

Hi,



On Dec 21, 2009, at 3:49 AM, Quintin Zhao wrote:

JP,

Good question! I guess that I should use "more complex to be implemented"
instead of "less applicable" in my previous email when I refer to using FRR
for P2MP node protection.

=A0

Well this is arguable though ..

=A0

What I was trying to mean is that p2p backup is easi= ly to be used for the
link protection for p2mp. To use FRR for the node protection in p2mp, it is=
not that straight forward comparing to p2p node protection, especially from=
the point view of bandwidth cost and label allocation.

=A0

Well it all depends on how you compute your P2P back= up, and this may be used
for a very short period of time. There are excellent off-line algorithms to achieve
some good level of efficiency.

=A0

For example, to use
the p2p tunnel to backup the branch node, we need multiple p2p tunnels to protect a single branch node. If the p2mp backup tunnel is used for the
branch node protection, then the upstream label allocation might be needed.=

=A0

Which is not a major issue. See long discussions on = the list some time ago on the
subject matter.

Thanks.

JP.

=A0



Regards,
Quintin

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Saturday, December 19, 2009 4:51 AM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote:


JP,

Thanks for your comments and suggestions.

I agree with you that for a quickly recovery, FRR is a good choice.
For the
p2mp TE LSP, if the failures are about link failures, FRR can be
used for
the recovery. If the failures are about the p2mp nodes which can be
the
root/branch/bud/leaf nodes, FRR might not be an easy way to cover
these
cases.=A1=A1


What makes you think that the use of FRR is less applicable to node
failures ?
(for which you could either use a set of P2P backup or a single P2MP
backup)

Thanks

JP.

This may lead to othe= r possible solutions and the pre-computed
backup sub-tree or the whole backup tree might be needed for the
possible
solutions. As you mentioned, using the FRR itself will eventually
need the
head end reoptimization using a make before break.

The pre-computed backup p2mp path/sub-path or the new computed path
during
reoptimization process using make before breaks are the optimal path
subject
to the OF and all other current constrains when the path is computed
by the
PCE. I agree with you that we can not draw the conclusion on the
potentially
level of sub-optimality of performing local reroute as opposed to
global
reoptimization.

Also we can not draw the conclusion if these backup path or
optimized path
after the failure is better or worse than the primary path. These
pre-computed backup paths/sub-paths or the optimized paths under the
failure
condition are the best path which can be used for the recovery of the
failure while satisfying all the conditions.

Regards,
Quintin


-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Thursday, December 17, 2009 1:26 PM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

Note that this is a fairly well-known issue. The aim of local repair
has always been to quickly recover from the failure. The degree of
resources guarantees and optimality depends on the amount of resources
dedicated to backup, several assumptions with regards to potential
simultaneous failures, the algorithms used to pre-compute backup
tunnels, etc ... The approach taken by P2P FRR has been to first
locally reroute and trigger a head-end reoptimization using a make
before break. I do not think that you can draw any conclusion on the
potentially level of sub-optimality of performing local reroute as
opposed to global reoptimization. It depends on a number of factors.

JP.

On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote:


Hello PCE'rs,

I would like to follow-up on some discussions from our PCE WG
session last
month. Specifically regarding Dajiang's failure and recomputation
observations on our draft. We are very interested to hear comments
regarding
the need for computing secondary paths in the event of failure.
Currently
our thinking is to recompute the sub-tree based in the domain where
the
failure has occurred. In this case we would not need to perform a
recalculation of the entire tree. We could also recompute the entire
tree,
and avoid the failed areas, as long as the TED has the updated
topology.
Realistically one might have a backup core tree pre-computed so you
can
switch over in the event of failure. There are also other
considerations.
Would a partial recomputation provide a "worse" SPT or MCT tree, = or
would a
full tree recomputation provide a "better" SPT or MCT? I can thin= k of
scenarios for both a partial and full recomputation, so perhaps we
need to
implement both but allow the PCC to decide when to issue a partial
or full
recomputation based on some criterion.

Thanks,

Quintin

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

=A0

=A0


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

=A0


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


--00032555a0bef5fe2a047d25eaea-- From qzhao@huawei.com Thu Jan 14 15:40:02 2010 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 F2D263A6884 for ; Thu, 14 Jan 2010 15:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRAXvFManaPy for ; Thu, 14 Jan 2010 15:39:51 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 44F463A67AA for ; Thu, 14 Jan 2010 15:39:51 -0800 (PST) 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 <0KW900EU3GEBM6@usaga04-in.huawei.com> for pce@ietf.org; Thu, 14 Jan 2010 17:39:48 -0600 (CST) Received: from Z73671a ([10.192.21.57]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KW900IJ4GE9T7@usaga04-in.huawei.com> for pce@ietf.org; Thu, 14 Jan 2010 17:39:47 -0600 (CST) Date: Thu, 14 Jan 2010 18:39:49 -0500 From: Quintin Zhao In-reply-to: <787be2781001141241n750d4c72ie23ceb07ee167c5b@mail.gmail.com> To: 'Greg Mirsky' Message-id: <002801ca9572$dd35ee70$3915c00a@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_wCaMbJR9x4iF2PAjqqlwgg)" Thread-index: AcqVWgXGvrLeWffER62g5DkmdHgY2AAFhZkQ References: <000401ca9083$defa1f90$3915c00a@china.huawei.com> <787be2781001141241n750d4c72ie23ceb07ee167c5b@mail.gmail.com> Cc: pce@ietf.org Subject: Re: [Pce] FW: Inter-domain-p2mp-procedures 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, 14 Jan 2010 23:40:02 -0000 This is a multi-part message in MIME format. --Boundary_(ID_wCaMbJR9x4iF2PAjqqlwgg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Greg, =20 Thanks for the clarification! =20 Quintin =20 _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: Thursday, January 14, 2010 3:42 PM To: Quintin Zhao Cc: pce@ietf.org Subject: Re: [Pce] FW: Inter-domain-p2mp-procedures =20 Hi Quintin, sorry for delayed reply. If we take Fig.1 from RFC 4090 and remove link [R3]-[R8], then that will change R1's Backup: [R1]------[R2]------[R3]-----[R4]------[R5] \ \ / \ / [R6]------[R7]--------[R8]-------[R9] Protected LSP: [R1->R2->R3->R4->R5] R1's Backup: [R1->R6->R7->R8->R4] R2's Backup: [R2->R7->R8->R4] R4's Backup: [R4->R9->R5] =20 As result of lower meshiness of the network the Merge point is moved = from R3 to R4. If only Link protection desired, then, with the topology as above: R1's Backup: [R1->R6->R7->R2] R2's Backup: [R2->R7->R8->R4] Thus we see, that protecting even an immediate link is not always = possible to merge onto Next Hop LSR and depends on level of connectivity = (meshiness) of the network. In my view, using p2mp LSP to provide local protection = for the p2mp LSP is more generic approach. Kind regards, Greg On Fri, Jan 8, 2010 at 8:58 AM, Quintin Zhao wrote: Hi Greg, =20 Thanks for the comments and suggestions!=20 =20 Can you elaborate a little more on what you mean here? =20 =93I think that because we can not guarantee that the immediate LSR will = be the merging point of p2p backup LSP one can not assume that a single p2p = can be used to provide protection for local link failure case.=94 =20 Quintin =20 _____ =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: Tuesday, January 05, 2010 6:20 PM To: JP Vasseur Cc: Quintin Zhao; pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures =20 Hi Quintin and JP, in regard to applicability of p2p FRR protection of links of p2mp LSP I agree with JP that such applicability is questionable and very much = depends on network topology, its meshiness. I think that because we can not guarantee that the immediate LSR will be the merging point of p2p backup = LSP one can not assume that a single p2p can be used to provide protection = for local link failure case. I believe that strong case can be made to = recommend use p2mp for local link protection as well as when node protection = required. Regards, Greg 2009/12/23 JP Vasseur Hi, On Dec 21, 2009, at 3:49 AM, Quintin Zhao wrote: JP, Good question! I guess that I should use "more complex to be = implemented" instead of "less applicable" in my previous email when I refer to using = FRR for P2MP node protection. =20 Well this is arguable though .. =20 What I was trying to mean is that p2p backup is easily to be used for = the link protection for p2mp. To use FRR for the node protection in p2mp, it = is not that straight forward comparing to p2p node protection, especially = from the point view of bandwidth cost and label allocation. =20 Well it all depends on how you compute your P2P backup, and this may be = used for a very short period of time. There are excellent off-line algorithms = to achieve some good level of efficiency. =20 For example, to use the p2p tunnel to backup the branch node, we need multiple p2p tunnels = to protect a single branch node. If the p2mp backup tunnel is used for the branch node protection, then the upstream label allocation might be = needed. =20 Which is not a major issue. See long discussions on the list some time = ago on the subject matter. Thanks. JP. =20 Regards, Quintin -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Saturday, December 19, 2009 4:51 AM To: Quintin Zhao Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures Hi, On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote: JP, Thanks for your comments and suggestions. I agree with you that for a quickly recovery, FRR is a good choice. For the p2mp TE LSP, if the failures are about link failures, FRR can be used for the recovery. If the failures are about the p2mp nodes which can be the root/branch/bud/leaf nodes, FRR might not be an easy way to cover these cases.=A1=A1 What makes you think that the use of FRR is less applicable to node failures ? (for which you could either use a set of P2P backup or a single P2MP backup) Thanks JP. This may lead to other possible solutions and the pre-computed backup sub-tree or the whole backup tree might be needed for the possible solutions. As you mentioned, using the FRR itself will eventually need the head end reoptimization using a make before break. The pre-computed backup p2mp path/sub-path or the new computed path during reoptimization process using make before breaks are the optimal path subject to the OF and all other current constrains when the path is computed by the PCE. I agree with you that we can not draw the conclusion on the potentially level of sub-optimality of performing local reroute as opposed to global reoptimization. Also we can not draw the conclusion if these backup path or optimized path after the failure is better or worse than the primary path. These pre-computed backup paths/sub-paths or the optimized paths under the failure condition are the best path which can be used for the recovery of the failure while satisfying all the conditions. Regards, Quintin -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, December 17, 2009 1:26 PM To: Quintin Zhao Cc: pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures Hi, Note that this is a fairly well-known issue. The aim of local repair has always been to quickly recover from the failure. The degree of resources guarantees and optimality depends on the amount of resources dedicated to backup, several assumptions with regards to potential simultaneous failures, the algorithms used to pre-compute backup tunnels, etc ... The approach taken by P2P FRR has been to first locally reroute and trigger a head-end reoptimization using a make before break. I do not think that you can draw any conclusion on the potentially level of sub-optimality of performing local reroute as opposed to global reoptimization. It depends on a number of factors. JP. On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: Hello PCE'rs, I would like to follow-up on some discussions from our PCE WG session last month. Specifically regarding Dajiang's failure and recomputation observations on our draft. We are very interested to hear comments regarding the need for computing secondary paths in the event of failure. Currently our thinking is to recompute the sub-tree based in the domain where the failure has occurred. In this case we would not need to perform a recalculation of the entire tree. We could also recompute the entire tree, and avoid the failed areas, as long as the TED has the updated topology. Realistically one might have a backup core tree pre-computed so you can switch over in the event of failure. There are also other considerations. Would a partial recomputation provide a "worse" SPT or MCT tree, or would a full tree recomputation provide a "better" SPT or MCT? I can think of scenarios for both a partial and full recomputation, so perhaps we need to implement both but allow the PCC to decide when to issue a partial or full recomputation based on some criterion. Thanks, Quintin _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce =20 =20 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce =20 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce =20 --Boundary_(ID_wCaMbJR9x4iF2PAjqqlwgg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Greg,

 

Thanks for the = clarification!

 

Quintin

=

 

From: Greg = Mirsky [mailto:gregimirsky@gmail.com]
Sent: Thursday, January = 14, 2010 3:42 PM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] FW: Inter-domain-p2mp-procedures

 

Hi Quintin,
sorry for delayed reply. If we take Fig.1 from RFC 4090 and remove link [R3]-[R8], then that will change R1's Backup:

=A0[R1]------[R2]------[R3=
]-----[R4]------[R5]




=A0=A0=A0=A0=A0 =
\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0/=A0=A0=A0=A0=A0=A0=A0 \=A0=A0=A0=A0=A0 /

=A0=A0=A0 [R6]------[R7]--------[R8]-------[R9]

Protected LSP: = [R1->R2->R3->R4->R5]
R1's Backup: = [R1->R6->R7->R8->R4]
R2's Backup: = [R2->R7->R8->R4]
R4's Backup: [R4->R9->R5]

 

As = result of lower meshiness of the network the Merge point is moved from R3 to = R4.
If only Link protection desired, then, with the topology as = above:

R1's Backup: [R1->R6->R7->R2]
R2's Backup: [R2->R7->R8->R4]


Thus we see, that protecting even an immediate link is not always = possible to merge onto Next Hop LSR and depends on level of connectivity (meshiness) = of the network. In my view, using p2mp LSP to provide local protection for the = p2mp LSP is more generic approach.

Kind regards,
Greg

On Fri, Jan 8, 2010 at 8:58 AM, Quintin Zhao <qzhao@huawei.com> = wrote:

Hi = Greg,

 

Thanks for the comments and suggestions!

 

Can you elaborate a little more on what you mean = here?

 

“I think that because we can not guarantee that the immediate LSR will be = the merging point of p2p backup LSP one can not assume that a single p2p can = be used to provide protection for local link failure = case.”

 

Quintin

 

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, January = 05, 2010 6:20 PM
To: JP Vasseur
Cc: Quintin Zhao; pce@ietf.org


Subject: Re: [Pce] Inter-domain-p2mp-procedures

 

Hi = Quintin and JP,
in regard to applicability of p2p FRR protection of links of p2mp LSP I = agree with JP that such applicability is questionable and very much depends on network topology, its meshiness. I think that because we can not = guarantee that the immediate LSR will be the merging point of p2p backup LSP one can = not assume that a single p2p can be used to provide protection for local = link failure case. I believe that strong case can be made to recommend use = p2mp for local link protection as well as when node protection required.

Regards,
Greg

2009/12/23 JP Vasseur <jvasseur@cisco.com>

=

Hi,



On Dec 21, 2009, at 3:49 AM, Quintin Zhao = wrote:

JP,

Good question! I guess that I should use "more complex to be implemented"
instead of "less applicable" in my previous email when I refer = to using FRR
for P2MP node protection.

 

Well = this is arguable though ..

 

What = I was trying to mean is that p2p backup is easily to be used for the
link protection for p2mp. To use FRR for the node protection in p2mp, it = is
not that straight forward comparing to p2p node protection, especially = from
the point view of bandwidth cost and label = allocation.

 

Well = it all depends on how you compute your P2P backup, and this may be used
for a very short period of time. There are excellent off-line algorithms = to achieve
some good level of efficiency.

 

For = example, to use
the p2p tunnel to backup the branch node, we need multiple p2p tunnels = to
protect a single branch node. If the p2mp backup tunnel is used for = the
branch node protection, then the upstream label allocation might be = needed.

 

Which = is not a major issue. See long discussions on the list some time ago on the
subject matter.

Thanks.

JP.

 



Regards,
Quintin

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Saturday, December 19, 2009 4:51 AM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

On Dec 18, 2009, at 9:41 PM, Quintin Zhao = wrote:


JP,

Thanks for your comments and suggestions.

I agree with you that for a quickly recovery, FRR is a good choice.
For the
p2mp TE LSP, if the failures are about link failures, FRR can be
used for
the recovery. If the failures are about the p2mp nodes which can be
the
root/branch/bud/leaf nodes, FRR might not be an easy way to cover
these
cases.=A1=A1


What makes you think that the use of FRR is less applicable to node
failures ?
(for which you could either use a set of P2P backup or a single P2MP
backup)

Thanks

JP.

This = may lead to other possible solutions and the pre-computed
backup sub-tree or the whole backup tree might be needed for the
possible
solutions. As you mentioned, using the FRR itself will eventually
need the
head end reoptimization using a make before break.

The pre-computed backup p2mp path/sub-path or the new computed path
during
reoptimization process using make before breaks are the optimal path
subject
to the OF and all other current constrains when the path is computed
by the
PCE. I agree with you that we can not draw the conclusion on the
potentially
level of sub-optimality of performing local reroute as opposed to
global
reoptimization.

Also we can not draw the conclusion if these backup path or
optimized path
after the failure is better or worse than the primary path. These
pre-computed backup paths/sub-paths or the optimized paths under the
failure
condition are the best path which can be used for the recovery of = the
failure while satisfying all the conditions.

Regards,
Quintin


-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Thursday, December 17, 2009 1:26 PM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

Note that this is a fairly well-known issue. The aim of local repair
has always been to quickly recover from the failure. The degree of
resources guarantees and optimality depends on the amount of = resources
dedicated to backup, several assumptions with regards to potential
simultaneous failures, the algorithms used to pre-compute backup
tunnels, etc ... The approach taken by P2P FRR has been to first
locally reroute and trigger a head-end reoptimization using a make
before break. I do not think that you can draw any conclusion on the
potentially level of sub-optimality of performing local reroute as
opposed to global reoptimization. It depends on a number of factors.

JP.

On Dec 14, 2009, at 10:15 PM, Quintin Zhao = wrote:


Hello PCE'rs,

I would like to follow-up on some discussions from our PCE WG
session last
month. Specifically regarding Dajiang's failure and recomputation
observations on our draft. We are very interested to hear comments
regarding
the need for computing secondary paths in the event of failure.
Currently
our thinking is to recompute the sub-tree based in the domain where
the
failure has occurred. In this case we would not need to perform a
recalculation of the entire tree. We could also recompute the entire
tree,
and avoid the failed areas, as long as the TED has the updated
topology.
Realistically one might have a backup core tree pre-computed so you
can
switch over in the event of failure. There are also other
considerations.
Would a partial recomputation provide a "worse" SPT or MCT = tree, or
would a
full tree recomputation provide a "better" SPT or MCT? I can = think of
scenarios for both a partial and full recomputation, so perhaps we
need to
implement both but allow the PCC to decide when to issue a partial
or full
recomputation based on some criterion.

Thanks,

Quintin

_______________________________________________
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

 


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

 

--Boundary_(ID_wCaMbJR9x4iF2PAjqqlwgg)-- From wwwrun@core3.amsl.com Fri Jan 15 13:40:53 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7C8E83A6988; Fri, 15 Jan 2010 13:40:53 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100115214053.7C8E83A6988@core3.amsl.com> Date: Fri, 15 Jan 2010 13:40:53 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-p2mp-req (PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)) to Informational RFC X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 21:40:53 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-01-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-p2mp-req-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17671&rfc_flag=0 From jvasseur@cisco.com Sun Jan 17 23:04:31 2010 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 2B1A43A68C6 for ; Sun, 17 Jan 2010 23:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.925 X-Spam-Level: X-Spam-Status: No, score=-9.925 tagged_above=-999 required=5 tests=[AWL=0.673, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSQYn1Dw8xqV for ; Sun, 17 Jan 2010 23:04:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9CD1D3A680E for ; Sun, 17 Jan 2010 23:04:29 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYAAK+WU0uQ/uCWe2dsb2JhbACCFplmAQEWJAajWZNjhDIE X-IronPort-AV: E=Sophos;i="4.49,294,1262563200"; d="scan'208,217";a="56238021" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Jan 2010 07:04:25 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0I74Pqu013125 for ; Mon, 18 Jan 2010 07:04:25 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 08:04:25 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 08:04:24 +0100 Message-Id: From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-54--124381185 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 18 Jan 2010 08:02:23 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Jan 2010 07:04:24.0645 (UTC) FILETIME=[77903750:01CA980C] Subject: [Pce] IETF 77 - Important dates 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, 18 Jan 2010 07:04:31 -0000 --Apple-Mail-54--124381185 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 2010-02-26 (Friday): Final agenda to be published. 2010-03-01 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Submission Tool. 2010-03-08 (Monday): Internet Draft final submission cut-off by 17:00 PST (01:00 Tuesday, March 9 UTC), upload using IETF ID Submission Tool. 2010-03-10 (Wednesday): Draft Working Group agendas due by 17:00 PST (01:00 Thursday, March 11 UTC), upload using IETF Meeting Materials Management Tool. 2010-03-12 (Friday): Early Bird registration and payment cut-off at 17:00 PST (01:00 Saturday, March 13 UTC). 2010-03-15 (Monday): Revised Working Group agendas due by 17:00 PDT (24:00 UTC), upload using IETF Meeting Materials Management Tool. 2010-03-15 (Monday): Registration cancellation cut-off at 17:00 PDT (24:00 UTC). 2010-03-19 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 PDT (24:00 UTC). 2010-03-21 - 2010-03-26: 77th IETF Meeting in Anaheim, California, USA. --Apple-Mail-54--124381185 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
  • 2010-02-26 = (Friday): Final agenda to be published.
  • 2010-03-01 (Monday): = Internet Draft Cut-off for initial document (-00) submission by 17:00 = PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Submission = Tool.
  • IETF ID Submission = Tool.
  • IETF = Meeting Materials Management Tool.
  • 2010-03-12 (Friday): Early = Bird registration and payment cut-off at 17:00 PST (01:00 Saturday, = March 13 UTC).
  • IETF = Meeting Materials Management Tool.
  • 2010-03-15 (Monday): = Registration cancellation cut-off at 17:00 PDT (24:00 UTC).
  • 2010-03-19 = (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 PDT (24:00 UTC).
  • 2010-03-21 - 2010-03-26: 77th IETF Meeting in = Anaheim, California, USA.
= --Apple-Mail-54--124381185-- From jvasseur@cisco.com Sun Jan 17 23:04:45 2010 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 21C1B3A6A80 for ; Sun, 17 Jan 2010 23:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep-BznmhUIBe for ; Sun, 17 Jan 2010 23:04:44 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3BBB63A6A7F for ; Sun, 17 Jan 2010 23:04:44 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAK+WU0utJV2Y/2dsb2JhbACCFr4Bk2OEMgQ X-IronPort-AV: E=Sophos;i="4.49,294,1262563200"; d="scan'208,217";a="468549163" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 18 Jan 2010 07:04:36 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0I73DwM001482 for ; Mon, 18 Jan 2010 07:04:36 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 08:04:30 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 08:04:30 +0100 Message-Id: <2A63201E-6D14-4284-B383-F68371E70092@cisco.com> From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-56--124255188 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 18 Jan 2010 08:04:29 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Jan 2010 07:04:30.0114 (UTC) FILETIME=[7AD2B820:01CA980C] Subject: [Pce] IETF 77 - Important dates 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, 18 Jan 2010 07:04:45 -0000 --Apple-Mail-56--124255188 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 2010-02-26 (Friday): Final agenda to be published. 2010-03-01 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Submission Tool. 2010-03-08 (Monday): Internet Draft final submission cut-off by 17:00 PST (01:00 Tuesday, March 9 UTC), upload using IETF ID Submission Tool. 2010-03-10 (Wednesday): Draft Working Group agendas due by 17:00 PST (01:00 Thursday, March 11 UTC), upload using IETF Meeting Materials Management Tool. 2010-03-12 (Friday): Early Bird registration and payment cut-off at 17:00 PST (01:00 Saturday, March 13 UTC). 2010-03-15 (Monday): Revised Working Group agendas due by 17:00 PDT (24:00 UTC), upload using IETF Meeting Materials Management Tool. 2010-03-15 (Monday): Registration cancellation cut-off at 17:00 PDT (24:00 UTC). 2010-03-19 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 PDT (24:00 UTC). 2010-03-21 - 2010-03-26: 77th IETF Meeting in Anaheim, California, USA. --Apple-Mail-56--124255188 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
  • 2010-02-26 = (Friday): Final agenda to be published.
  • 2010-03-01 (Monday): = Internet Draft Cut-off for initial document (-00) submission by 17:00 = PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Submission = Tool.
  • IETF ID Submission = Tool.
  • IETF = Meeting Materials Management Tool.
  • 2010-03-12 (Friday): Early = Bird registration and payment cut-off at 17:00 PST (01:00 Saturday, = March 13 UTC).
  • IETF = Meeting Materials Management Tool.
  • 2010-03-15 (Monday): = Registration cancellation cut-off at 17:00 PDT (24:00 UTC).
  • 2010-03-19 = (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 PDT (24:00 UTC).
  • 2010-03-21 - 2010-03-26: 77th IETF Meeting in = Anaheim, California, USA.
= --Apple-Mail-56--124255188-- From Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Mon Jan 18 19:12:54 2010 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 0C5E53A69E3 for ; Mon, 18 Jan 2010 19:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.71 X-Spam-Level: *** X-Spam-Status: No, score=3.71 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CAiZJJXcTQg for ; Mon, 18 Jan 2010 19:12:53 -0800 (PST) Received: from mx04.melco.co.jp (mx04.melco.co.jp [192.218.140.144]) by core3.amsl.com (Postfix) with ESMTP id 0C7623A69DC for ; Mon, 18 Jan 2010 19:12:52 -0800 (PST) Received: from mr04.melco.co.jp (mr04 [133.141.98.166]) by mx04.melco.co.jp (Postfix) with ESMTP id D06B55D043 for ; Tue, 19 Jan 2010 12:12:47 +0900 (JST) Received: from mr04.melco.co.jp (localhost [127.0.0.1]) by mr04.imss (Postfix) with ESMTP id ADD8B12F4C for ; Tue, 19 Jan 2010 12:12:47 +0900 (JST) Received: from elgw.isl.melco.co.jp (unknown [133.141.13.130]) by mr04.melco.co.jp (Postfix) with ESMTP id 7AB6112DDF for ; Tue, 19 Jan 2010 12:12:47 +0900 (JST) Received: from iswall2a.isl.melco.co.jp (iswall2a.isl.melco.co.jp [10.74.245.24]) by elgw.isl.melco.co.jp (Postfix) with ESMTP id 55EB831F3CD for ; Tue, 19 Jan 2010 12:12:47 +0900 (JST) Received: from iswall2a.isl.melco.co.jp (localhost.localdomain [127.0.0.1]) by localhost.isl.melco.co.jp (Postfix) with ESMTP id E709422CBDB for ; Tue, 19 Jan 2010 12:12:46 +0900 (JST) Received: from LeakStopper186 (stopper2.isl.melco.co.jp [10.74.245.36]) by iswall2a.isl.melco.co.jp (Postfix) with SMTP id D15EA22CBB5 for ; Tue, 19 Jan 2010 12:12:46 +0900 (JST) Received: (qmail 19380 invoked by uid 507); 19 Jan 2010 12:12:46 +0900 Received: from unknown (HELO ELSTEFANY) (10.74.8.38) by 0 with SMTP; 19 Jan 2010 12:12:11 +0900 From: "Shoichiro Seno" To: , , , Date: Tue, 19 Jan 2010 12:12:12 +0900 Message-ID: <4A36DA5B2730468085BBA1763D601B93@ad.melco.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: AcqYtTHqIuCpJnDtRyCuJ37u9PFqhw== Subject: [Pce] iPOP 2010 Call for Presentation 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, 19 Jan 2010 03:12:54 -0000 Dear CAMP, PCE, MPLS and MPLS-TP subscribers, (Apologies for multiple copies, appreciated if you can forward to potentially interested people.) ----------------------------------------------------------------------- Call for Presentation 6th International Conference on IP + Optical Network (iPOP 2010) June 10-11, 2010 NTT Musashino R&D Center, Tokyo, Japan http://www.pilab.jp/ipop2010/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 19, 2010 Notification of acceptance: April 2, 2010 Submission deadline of final presentation slides: April 23, 2010 The Technical Program Committee for iPOP 2010 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstracts of a 400 words and a maximum of 1 page, including figures and diagrams, speaker's name, affiliation, and contact information to the Technical Program Committee at ipop2010-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2010/ for more details. General Chairs: Tomonori Aoyama, Keio University, Japan Bijan Jabbari, ISOCORE, USA Hisashi Koumura, NTT, Japan Organization Committee Co-Chairs: Naoaki Yamanaka, Keio University, Japan Atsushi Hiramatsu, NTT, Japan Soichiro Araki, NEC, Japan Exhibition Committee Co-Chairs: Kohei Shiomoto, NTT, Japan Munefumi Tsurusawa, KDDI R&D, Japan Technical Program Committee Co-Chairs: Eiji Oki, University of Electro-Communications, Japan Monique Morrow, Cisco Systems, USA -------------------------------------------------------------------------------- - Kind regards, Sho Seno Publication Chair, iPOP 2010 -- Shoichiro Seno (E-mail) Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Information Technology R&D Center, Mitsubishi Electric Corporation From root@core3.amsl.com Wed Jan 20 09:45:04 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A08393A6A15; Wed, 20 Jan 2010 09:45:04 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100120174504.A08393A6A15@core3.amsl.com> Date: Wed, 20 Jan 2010 09:45:04 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-monitoring-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:45:04 -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 : A set of monitoring tools for Path Computation Element based Architecture Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-monitoring-08.txt Pages : 27 Date : 2010-01-20 A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential resource contention states and statistics in term of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. 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 July 24, 2010. Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-08.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-monitoring-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-20094418.I-D@ietf.org> --NextPart-- From qzhao@huawei.com Thu Jan 21 12:12:41 2010 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 F03A33A67AF for ; Thu, 21 Jan 2010 12:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 AisY93rPs-TS for ; Thu, 21 Jan 2010 12:12:40 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id E46E93A69C6 for ; Thu, 21 Jan 2010 12:12:40 -0800 (PST) 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 <0KWM0047C5H0Z0@usaga04-in.huawei.com> for pce@ietf.org; Thu, 21 Jan 2010 14:12:36 -0600 (CST) Received: from Z73671a ([10.192.21.51]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWM00GUO5GXMS@usaga04-in.huawei.com> for pce@ietf.org; Thu, 21 Jan 2010 14:12:36 -0600 (CST) Date: Thu, 21 Jan 2010 15:12:34 -0500 From: Quintin Zhao In-reply-to: To: julien.meuric@orange-ftgroup.com Message-id: <002c01ca9ad6$12f1dd40$3315c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcqB6cs8TiSNSOV7SDKQ0LgQicHNugNtq9ZQAD+lNRACjaxWYA== References: <001901ca81e9$cbdea690$0702a8c0@china.huawei.com> <22437_1262872632_4B45E838_22437_7085_1_D109C8C97C15294495117745780657AE0C369AF0@ftrdmel1> Cc: pce@ietf.org Subject: Re: [Pce] Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures 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, 21 Jan 2010 20:12:42 -0000 Julien, The authors of draft-zhao-pce-pcep-inter-domain-p2mp-procedures have discussed (thanks to co-authors for comments!) the strategy for the work and our plan is as follows: 1. Review the requirements. Our operator co-authors are very useful for having these discussions, but we would like feedback from the WG as well; 2. Create a single hybrid solution. We feel we can create a good solution that utilizes the strengths of BRPC and Core Tree technologies; 3. Continue to compare requirements against selected solution and modify as necessary; 5. Implement and complete! Our purpose is to converge on a single solution. We do not think multiple inter-domain P2MP solutions are wanted or necessary. We agree that we have a lot of time ahead of us in developing our solution. We have already received comments from the WG and we would like more feedback. Thank you! Quintin -----Original Message----- From: Quintin Zhao [mailto:qzhao@huawei.com] Sent: Friday, January 08, 2010 3:22 PM To: 'julien.meuric@orange-ftgroup.com' Cc: 'pce@ietf.org'; 'jvasseur@cisco.com' Subject: RE: Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures Hi Julien, Yes, we still believe that we have a lot of work ahead them regarding this work item. We hope that adoption of this work item by the WG would make the work more visible and generate further interest in developing the overall solution. I believe we have a broad consensus across the co-authors for how to move this work forward. Please give me a few days to confirm our plan with my co-authors and then I will mail you and the WG our intended strategy. Regards, Quintin -----Original Message----- From: julien.meuric@orange-ftgroup.com [mailto:julien.meuric@orange-ftgroup.com] Sent: Thursday, January 07, 2010 8:57 AM To: qzhao@huawei.com Cc: pce@ietf.org; jvasseur@cisco.com Subject: RE: Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures Hi Quintin. It is a significant step that authors of both drafts agreed on working on a single document and we congratulate all of you for that. During IETF 76, you also mentioned "Lots of work and analysis ahead" and a need to "continue to review requirements and select the technique that best meets the requirements". Indeed, the current version of the document looks more like a solution list than an actual merge of former proposals. Considering the complexity induced by an inter-domain P2MP extension, we would appreciate before taking any decision that you elaborate on the way you intend to move forward towards a common solution. Thanks Julien ________________________________ From: Quintin Zhao [mailto:qzhao@huawei.com] Hi Co-Chairs and PCE WG, Different parties have been working on solutions for computing P2MP paths across multi-domain networks. At IETF 75 we were requested by JP, to formulate a plan and resolve any issues in order to move the work forward. After calls and emails between draft-ali-pce-brpc-p2mp-ext and draft-zhao-pce-pcep-inter-domain-p2mp-procedure authors, we felt there was concurrence to merge the solutions and work together on a unified solution. At IETF 76 we presented our initial/combined PCE-based Shortest Constrained P2MP Inter-domain TE-LSP solution (draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02). We would like to know if the co-chairs and WG would be in favor of the document becoming a WG draft? Regards, Quintin ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** From zhangfatai@huawei.com Thu Jan 21 19:23:57 2010 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 8D7B13A6863 for ; Thu, 21 Jan 2010 19:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, 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 09+MuyvmRNtH for ; Thu, 21 Jan 2010 19:23:54 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CE52A3A67F8 for ; Thu, 21 Jan 2010 19:23:49 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWM00M48PF6ZY@szxga03-in.huawei.com> for pce@ietf.org; Fri, 22 Jan 2010 11:23:30 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWM002XDPF63G@szxga03-in.huawei.com> for pce@ietf.org; Fri, 22 Jan 2010 11:23:30 +0800 (CST) Received: from Z41162C ([10.70.76.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWM00MM1PF5CP@szxml04-in.huawei.com> for pce@ietf.org; Fri, 22 Jan 2010 11:23:30 +0800 (CST) Date: Fri, 22 Jan 2010 11:23:29 +0800 From: Fatai Zhang To: pce@ietf.org Message-id: <03c701ca9b12$444ffd90$604c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/mixed; boundary="Boundary_(ID_5xVwszzl5yXyx5E+/s9gHg)" X-Priority: 3 X-MSMail-priority: Normal References: <20100121063113.16D383A69C9@core3.amsl.com> Cc: Jun Sun Subject: Re: [Pce] New Version Notification for draft-zhang-pce-udp-for-pcecp-00 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, 22 Jan 2010 03:23:57 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5xVwszzl5yXyx5E+/s9gHg) Content-type: multipart/alternative; boundary="Boundary_(ID_YUdwOhLPbQm6Q7vfhMhH/Q)" --Boundary_(ID_YUdwOhLPbQm6Q7vfhMhH/Q) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Hi PCEers, We just uploaded a draft, which is about PCECP over UDP. I think it is very interesting to investigate the feasibility and advantages of using UDP as transport protocol for PCECP. If you are interested in this topic, hope you can have a look and review this draft. We would like to appreciate your comments or suggestions. Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: "IETF I-D Submission Tool" To: Cc: ; ; Sent: Thursday, January 21, 2010 2:31 PM Subject: New Version Notification for draft-zhang-pce-udp-for-pcecp-00 > > A new version of I-D, draft-zhang-pce-udp-for-pcecp-00.txt has been successfuly submitted by Fatai Zhang and posted to the IETF repository. > > Filename: draft-zhang-pce-udp-for-pcecp > Revision: 00 > Title: UDP as Transport Protocol for PCECP > Creation_date: 2010-01-21 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > The Path Computation Element Communication Protocol defines a > request/response protocol used for the communication between a Path > Computation Client (PCC) and a Path Computation Element (PCE), or > between two PCEs. PCEP employs Transmission Control Protocol (TCP) as > the transport layer protocol by using a registered TCP port. > > This document proposes the possibility of employing UDP as the > transport layer protocol instead of TCP. > > UDP is a connectionless protocol within TCP/IP protocol suite that > corresponds to the transport layer in the ISO/OSI reference model. > UDP converts data messages generated by an application into packets > to be sent through IP. The reliability is not guaranteed by UDP and > should be ensured by the application that generates the data message. > > The PCECP application is flexible to ensure the reliability of PCECP > messages. This document explains on how the reliability of the PCECP > messages can be achieved by means of PCECP, while operating PCECP > over UDP. > > > > The IETF Secretariat. > > > --Boundary_(ID_YUdwOhLPbQm6Q7vfhMhH/Q) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMjkxMiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5IaSBQQ0VlcnMs PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbD5XZSBqdXN0IHVwbG9hZGVkIGEgZHJhZnQsIHdoaWNoIGlz IGFib3V0IFBDRUNQIG92ZXIgDQpVRFAuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5JIHRoaW5rIGl0 IGlzIHZlcnkgaW50ZXJlc3RpbmcgdG8gaW52ZXN0aWdhdGUgdGhlIA0KZmVhc2liaWxpdHkgYW5k IGFkdmFudGFnZXMgb2YgdXNpbmcgVURQIGFzIHRyYW5zcG9ydCBwcm90b2NvbCBmb3IgDQpQQ0VD UC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPklmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiB0aGlzIHRv cGljLCBob3BlIHlvdSBjYW4gaGF2ZSBhIA0KbG9vayBhbmQgcmV2aWV3IHRoaXMgZHJhZnQuPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbD5XZSB3b3VsZCBsaWtlIHRvIGFwcHJlY2lhdGUgeW91ciBjb21t ZW50cyBvciANCnN1Z2dlc3Rpb25zLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEJSPjxGT05UIGZhY2U9QXJpYWw+VGhhbmtzPEJSPiZuYnNwOzxCUj5GYXRhaTxCUj4mbmJzcDs8 QlI+SHVhd2VpIA0KVGVjaG5vbG9naWVzIENvLiwgTFRELjxCUj5IdWF3ZWkgQmFzZSwgQmFudGlh biwgTG9uZ2dhbmcsPEJSPlNoZW56aGVuIDUxODEyOSANClAuUi5DaGluYTxCUj5UZWw6ICs4Ni03 NTUtMjg5NzI5MTI8QlI+RmF4OiArODYtNzU1LTI4OTcyOTM1PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bD48QlI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkZyb206 ICJJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wiICZsdDs8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86 aWRzdWJtaXNzaW9uQGlldGYub3JnIj48Rk9OVCANCmZhY2U9QXJpYWw+aWRzdWJtaXNzaW9uQGll dGYub3JnPC9GT05UPjwvQT48Rk9OVCBmYWNlPUFyaWFsPiZndDs8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWw+VG86ICZsdDs8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86emhhbmdm YXRhaUBodWF3ZWkuY29tIj48Rk9OVCANCmZhY2U9QXJpYWw+emhhbmdmYXRhaUBodWF3ZWkuY29t PC9GT05UPjwvQT48Rk9OVCBmYWNlPUFyaWFsPiZndDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWw+Q2M6ICZsdDs8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOnN1cmVzaGJyQGh1YXdl aS5jb20iPjxGT05UIA0KZmFjZT1BcmlhbD5zdXJlc2hickBodWF3ZWkuY29tPC9GT05UPjwvQT48 Rk9OVCBmYWNlPUFyaWFsPiZndDs7ICZsdDs8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86c3NlbnRo aWxrdW1hckBodWF3ZWkuY29tIj48Rk9OVCANCmZhY2U9QXJpYWw+c3NlbnRoaWxrdW1hckBodWF3 ZWkuY29tPC9GT05UPjwvQT48Rk9OVCBmYWNlPUFyaWFsPiZndDs7IA0KJmx0OzwvRk9OVD48QSBo cmVmPSJtYWlsdG86am9obnN1bkBodWF3ZWkuY29tIj48Rk9OVCANCmZhY2U9QXJpYWw+am9obnN1 bkBodWF3ZWkuY29tPC9GT05UPjwvQT48Rk9OVCBmYWNlPUFyaWFsPiZndDs8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+U2VudDogVGh1cnNkYXksIEphbnVhcnkgMjEsIDIwMTAg MjozMSBQTTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5TdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KZHJhZnQtemhhbmctcGNlLXVkcC1mb3ItcGNlY3At MDA8L0ZPTlQ+PC9ESVY+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEJSPjwvRk9OVD48 L0RJVj48Rk9OVCBmYWNlPUFyaWFsPiZndDsgPEJSPiZndDsgQSBuZXcgDQp2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtemhhbmctcGNlLXVkcC1mb3ItcGNlY3AtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3Nm dWx5IA0Kc3VibWl0dGVkIGJ5IEZhdGFpIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS48QlI+Jmd0OyA8QlI+Jmd0OyANCkZpbGVuYW1lOiBkcmFmdC16aGFuZy1wY2UtdWRw LWZvci1wY2VjcDxCUj4mZ3Q7IFJldmlzaW9uOiAwMDxCUj4mZ3Q7IFRpdGxlOiBVRFAgDQphcyBU cmFuc3BvcnQgUHJvdG9jb2wgZm9yIFBDRUNQPEJSPiZndDsgQ3JlYXRpb25fZGF0ZTogMjAxMC0w MS0yMTxCUj4mZ3Q7IFdHIElEOiANCkluZGVwZW5kZW50IFN1Ym1pc3Npb248QlI+Jmd0OyBOdW1i ZXJfb2ZfcGFnZXM6IDE3PEJSPiZndDsgPEJSPiZndDsgDQpBYnN0cmFjdDo8QlI+Jmd0OyBUaGUg UGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IENvbW11bmljYXRpb24gUHJvdG9jb2wgZGVmaW5lcyBh IA0KPEJSPiZndDsgcmVxdWVzdC9yZXNwb25zZSBwcm90b2NvbCB1c2VkIGZvciB0aGUgY29tbXVu aWNhdGlvbiBiZXR3ZWVuIGEgUGF0aCANCjxCUj4mZ3Q7IENvbXB1dGF0aW9uIENsaWVudCAoUEND KSBhbmQgYSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgKFBDRSksIG9yIA0KPEJSPiZndDsgYmV0 d2VlbiB0d28gUENFcy4gUENFUCBlbXBsb3lzIFRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29s IChUQ1ApIGFzIA0KPEJSPiZndDsgdGhlIHRyYW5zcG9ydCBsYXllciBwcm90b2NvbCBieSB1c2lu ZyBhIHJlZ2lzdGVyZWQgVENQIHBvcnQuIDxCUj4mZ3Q7IA0KPEJSPiZndDsgVGhpcyBkb2N1bWVu dCBwcm9wb3NlcyB0aGUgcG9zc2liaWxpdHkgb2YgZW1wbG95aW5nIFVEUCBhcyB0aGUgPEJSPiZn dDsgDQp0cmFuc3BvcnQgbGF5ZXIgcHJvdG9jb2wgaW5zdGVhZCBvZiBUQ1AuIDxCUj4mZ3Q7IDxC Uj4mZ3Q7IFVEUCBpcyBhIA0KY29ubmVjdGlvbmxlc3MgcHJvdG9jb2wgd2l0aGluIFRDUC9JUCBw cm90b2NvbCBzdWl0ZSB0aGF0IDxCUj4mZ3Q7IGNvcnJlc3BvbmRzIA0KdG8gdGhlIHRyYW5zcG9y dCBsYXllciBpbiB0aGUgSVNPL09TSSByZWZlcmVuY2UgbW9kZWwuIDxCUj4mZ3Q7IFVEUCBjb252 ZXJ0cyANCmRhdGEgbWVzc2FnZXMgZ2VuZXJhdGVkIGJ5IGFuIGFwcGxpY2F0aW9uIGludG8gcGFj a2V0cyA8QlI+Jmd0OyB0byBiZSBzZW50IA0KdGhyb3VnaCBJUC4gVGhlIHJlbGlhYmlsaXR5IGlz IG5vdCBndWFyYW50ZWVkIGJ5IFVEUCBhbmQgPEJSPiZndDsgc2hvdWxkIGJlIA0KZW5zdXJlZCBi eSB0aGUgYXBwbGljYXRpb24gdGhhdCBnZW5lcmF0ZXMgdGhlIGRhdGEgbWVzc2FnZS4gPEJSPiZn dDsgPEJSPiZndDsgDQpUaGUgUENFQ1AgYXBwbGljYXRpb24gaXMgZmxleGlibGUgdG8gZW5zdXJl IHRoZSByZWxpYWJpbGl0eSBvZiBQQ0VDUCA8QlI+Jmd0OyANCm1lc3NhZ2VzLiBUaGlzIGRvY3Vt ZW50IGV4cGxhaW5zIG9uIGhvdyB0aGUgcmVsaWFiaWxpdHkgb2YgdGhlIFBDRUNQIDxCUj4mZ3Q7 IA0KbWVzc2FnZXMgY2FuIGJlIGFjaGlldmVkIGJ5IG1lYW5zIG9mIFBDRUNQLCB3aGlsZSBvcGVy YXRpbmcgUENFQ1AgPEJSPiZndDsgb3ZlciANClVEUC48QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCjxCUj4mZ3Q7IDxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoZSBJRVRGIFNlY3Jl dGFyaWF0LjxCUj4mZ3Q7IDxCUj4mZ3Q7IA0KPEJSPiZndDs8L0ZPTlQ+IDwvQk9EWT48L0hUTUw+ DQo= --Boundary_(ID_YUdwOhLPbQm6Q7vfhMhH/Q)-- --Boundary_(ID_5xVwszzl5yXyx5E+/s9gHg) Content-type: text/plain; name=draft-zhang-pce-udp-for-pcecp-00.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-zhang-pce-udp-for-pcecp-00.txt Network Working Group Fatai Zhang Internet Draft Suresh B R Category: Standards Track SenthilKumarS Jun Sun Huawei Expires: July 21, 2010 January 21, 2010 UDP as Transport Protocol for PCECP draft-zhang-pce-udp-for-pcecp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Copyright (c) <2010> 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 July 20, 2010. zhang Expires July 2010 [Page 1] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 Abstract The Path Computation Element Communication Protocol defines a request/response protocol used for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. PCEP employs Transmission Control Protocol (TCP) as the transport layer protocol by using a registered TCP port. This document proposes the possibility of employing UDP as the transport layer protocol instead of TCP. UDP is a connectionless protocol within TCP/IP protocol suite that corresponds to the transport layer in the ISO/OSI reference model. UDP converts data messages generated by an application into packets to be sent through IP. The reliability is not guaranteed by UDP and should be ensured by the application that generates the data message. The PCECP application is flexible to ensure the reliability of PCECP messages. This document explains on how the reliability of the PCECP messages can be achieved by means of PCECP, while operating PCECP over UDP. Table of Contents 1. Introduction..................................................3 1.1. Requirements Language....................................3 2. Terminology...................................................3 3. Requirements..................................................4 3.1. Motivations for Using UDP as the transport protocol for PCECP........................................................5 3.2. Benefits from PCECP over UDP.............................6 4. Proposing UDP for PCECP Transport Protocol....................6 4.1. Reliability of PCECP Messages............................7 4.1.1. Fast Request Retransmission with Exponential or Linear Back-off Mechanism..................................7 4.1.2. Retransmission Parameters...........................8 4.2. Handling Duplication.....................................8 4.3. Congestion Control.......................................9 4.4. PCECP Messages and Object Formats........................9 5. UDP Port.....................................................10 6. Security Considerations......................................10 6.1. Authentication of PCECP Messages........................10 6.1.1. RDM Monotonic Counter TLV (64-bits)................11 6.1.2. HMAC-MD5 TLV.......................................11 6.1.3. Message Validation.................................12 zhang Expires July 2010 [Page 2] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 6.1.4. Key Utilization....................................13 7. Conclusion...................................................13 8. IANA Considerations..........................................13 8.1. UDP Port................................................13 8.2. PCECP Objects...........................................13 8.3. PCECP TLV Type Indicators...............................13 9. Acknowledgments..............................................14 10. References..................................................14 10.1. Normative References...................................14 10.2. Informative References.................................14 11. Authors' Addresses..........................................14 1. Introduction [RFC4655] describes the motivation and architecture for a Path Computation Element (PCE) based model for the computation of Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). The PCE is an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. The Path Computation Client (PCC) is any client application requesting a path computation to be performed by a PCE. [RFC5440] specifies the Path Computation Element communication Protocol (PCEP) used for communication between a PCC and PCE in compliance with [RFC4657]. The PCECP(PCE Communication Protocol) is an application layer communication protocol employed between PCC and PCE, as well between PCE and PCE (In this document, we refer to all communications as PCC-PCE regardless of whether they are PCC-PCE or PCE-PCE.). The purpose of PCECP is to carry TE-LSP computation requests, responses and other notifications between PCC and PCE or between PCE and PCE. The PCECP operates over a transport layer protocol for transmitting the PCECP messages between the PCECP peers. [RFC5440] has defined TCP as the transport protocol for PCECP. This document explains how to operate PCECP over UDP instead of TCP, and defines the necessary changes and extensions to PCEP. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. 2. Terminology The following terminology is used in this document. zhang Expires July 2010 [Page 3] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 GMPLS: Generalized Multi-Protocol Label Switching IP: Internet Protocol. IP governs the break up of data messages into packets, the routing of the packets from sender to destination network and station, and the reassembly of the packets into the original data messages at the destination. PCC: Path Computation Client. Any client application requesting a path computation to be performed by the Path Computation Element. PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. PCECP: Path Computation Element Communication Protocol, which is a request/response protocol used for the communication between a PCC and a PCE, or between two PCEs PCEP: A kind of specific protocol defined in [RFC5440] for PCECP. PCECP Peer: An element involved in a PCECP session (For example, a PCC or a PCE). PCECP Session: The PCECP session is a logical connection established automatically between the PCECP peers. TE LSP: Traffic Engineering MPLS Label Switched Path. TCP: Transmission Control Protocol. TCP is a connection-oriented, end-to-end reliable protocol that governs the break up of data messages into packets to be sent through IP (Internet Protocol), and the reassembly and verification of the complete messages from packets received by IP. UDP: User Datagram Protocol. UDP is a connectionless protocol that converts data messages generated by an application into packets to be sent through IP. 3. Requirements In GMPLS networks, the service has to be restored within the minimum restoring time to avoid service interruption in the event of fiber or node failure. In such scenarios, establishing a PCECP session, controlling request retransmission, message/packet overhead over the bandwidth constrained in-band signaling channels becomes critical. zhang Expires July 2010 [Page 4] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 3.1. Motivations for Using UDP as the transport protocol for PCECP The following are the motivations for using UDP as the transport protocol: Absence of Initial Connection Establishment: TCP employs three-way handshake mechanism before sending the PCEP messages. Unlike TCP, UDP does not establish end-to-end connection between PCECP peers. UDP communication consequently does not incur connection establishment and teardown overheads. Absence of Connection State: TCP maintains the connection state in the transport layer of PCECP peers. This includes the connection state, receive and send buffers, congestion control parameters, and sequence numbers. This information is used to realize the reliable data transfer of TCP and the congestion control that leads to high memory and CPU usage. UDP does not maintain any such connection state and does not track the congestion parameters or the sequence numbers. As a result, a PCE can typically support more number of PCCs when the PCECP runs over UDP rather than TCP. Minimum Segment Overhead: The TCP segment has 20 bytes of header overhead in each segment to guarantee the reliable transfer of messages. The UDP only has 8 bytes of overhead. Absence of Inherent Data Rate: TCP has a congestion control mechanism that restricts the PCECP peer when one or more links between sender and receiver becomes excessively congested. This restriction can have a severe impact for path request/response when a TE-LSP is rerouted. On the other hand, using UDP the application can send data that is constrained by the rate at which the application generates data and the process capabilities of the source. Application Flexibility for Reliability: The built-in reliability mechanism in TCP leads to additional overhead and resource usage in the network. The PCECP can realize its own reliable mechanism to ensure the reliability of messages. For example, the PCC can realize appropriate retransmission strategy to guarantee the reliable delivery of PCECP messages. The PCC can decide to retransmit the request to the same PCE or to a different PCE (based on the availability) in case if no response is received. Absence of Message Boundary: TCP is a stream oriented protocol and a read from the socket does not guarantee the complete message. To receive a complete message, the state oriented message assembler is zhang Expires July 2010 [Page 5] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 required. Unlike TCP, the message assembler is not required for UDP. A single UDP datagram consists of complete message and the message boundaries are guaranteed irrespective of link/path MTU. 3.2. Benefits from PCECP over UDP The following are the advantages of UDP: o No time is spent in establishing a TCP connection to the PCE server. Directly PCECP session establishment can be initiated using UDP. o Complexity of PCECP message parser is reduced as complete PCECP message is carried by one UDP datagram. This will enhance the PCECP parser performance. o PCC has the complete control about the retransmission and can choose a different PCE upon retransmission failure. Custom retransmission algorithm and policy can be implemented based on the network. o If the number of PCC is huge, then number of sessions to be handled is also huge. Using TCP needs more memory and more processing. Using UDP this problem can be solved. By operating PCECP over UDP, the above mentioned requirements are satisfied. 4. Proposing UDP for PCECP Transport Protocol UDP is a connectionless protocol that provides a minimal, best-effort, message-passing transport with minimum protocol mechanism. The service provided by UDP is unreliable that provides no guarantee for delivery. The simplicity of UDP reduces the overhead from using the protocol and the services may be adequate in many cases. When PCECP uses UDP as transport protocol, an UDP datagram must contain exactly one PCECP message. So while using UDP, the application has to realize its own mechanisms to guarantee the reliable delivery of messages, handle duplication, and congestion of messages. The following sections explain on how PCECP can handle the reliable delivery of PCECP messages avoiding duplication and congestion on a UDP based PCECP session. zhang Expires July 2010 [Page 6] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 4.1. Reliability of PCECP Messages The PCC or PCE originating the PCECP message is responsible for the reliable delivery of PCECP messages. For example, when a PCC is sending a TE-LSP path request to PCE, PCC is responsible to keep track of the request. The PCC must retransmit its PCECP message, if it fails to receive the response message, either the path response or error response from the PCE. [draft-ietf-pce-monitoring] 4.1.1. Fast Request Retransmission with Exponential or Linear Back- off Mechanism The PCC will transmit a request message to the selected PCE. The message exchange terminates when either the PCC receives the appropriate PCECP response successfully, or when the message exchange has failed as per the retransmission mechanism. The retransmission behaviour is controlled and described by the following variables: RT: Retransmission timeout IRT: Initial retransmission time MRT: Maximum retransmission time MRC: Maximum retransmission count MRD: Maximum retransmission duration RAND: Randomization factor. The RAND is a random number chosen with a uniform distribution between -0.3 and +0.3. The PCC controls the retransmission behaviour using exponential back- off mechanism as explained below. o With each request transmission or retransmission, the PCC sets RT. The RT for the first message retransmission is based on IRT. RT =(1 + RAND)*IRT o On the expiry of RT, if the PCC has not received a response to the PCReq, the PCC recomputes RT and retransmits the message. Each of the computations of a new RT includes a RAND. The RAND is included to minimize synchronization of messages transmitted by PCCs. The RT for each subsequent message transmission is based on the previous value of RT. zhang Expires July 2010 [Page 7] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 RT = (Back-off * RTprev) + (RAND * RTprev), where Back-off = 1 for Linear and 2 for Exponential. o The MRT specifies a boundary value for RT (disregarding the randomization added by the use of RAND). If MRT is 0, then there is no upper limit on the value of RT. Otherwise, when RT > MRT, RT is recalculated using, RT = (1 + RAND)*MRT. o The MRC specifies a boundary value on the number of times a PCC may retransmit a message. Unless MRC is zero, the message exchange fails once the PCC has retransmitted the message MRC times. o MRD specifies a boundary value on the length of time a PCC may retransmit a message. Unless MRD is zero, the message exchange fails once MRD seconds have elapsed since the PCC first transmitted the message. o When MRC and MRD are non-zero, the message exchange fails whenever either of the conditions specified in the previous points is met. If both MRC and MRD are zero, the PCC continues to transmit the message until it receives a response, but setting both MRC and MRD to zero is not recommended. The same retransmission mechanism either exponential back-off or linear mechanism is followed during PCE switching. 4.1.2. Retransmission Parameters This section presents the default values used to describe the message transmission behaviour. Parameter Default Value Range IRT 1 sec 0.1 sec to 8 secs MRC 3 0 to 8 MRT 2 secs 0.5 sec to 16 secs MRD 8 secs 1.0 sec to 64 secs MPC 2 0 to 16 4.2. Handling Duplication UDP does not protect against any message duplication, but PCECP can follow the below mentioned mechanism to gracefully handle duplication. A duplicate PCECP message is identified by a repeated PCECP request- ID received from the same PCC. zhang Expires July 2010 [Page 8] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 o When a PCE receives a duplicate request message, and if it is still processing the original message (path computation is still in progress or queued, and the path response is not sent), the newly received request message is dropped. o When a PCE receives a duplicate request message for which the path response is already sent, PCE accepts the request and process it. This is because the PCE may not be able to identify that the received request is duplicate unless otherwise it maintains the history. o When a PCC receives a duplicate response message, it discards it as it will not be able to locate the original request message that was processed earlier. 4.3. Congestion Control UDP does not provide any means to handle congestion. Moreover, when UDP is used as the transport layer protocol, the rate at which the message is generated and transmitted is based on the application capabilities. This may lead to congestion at PCE when multiple PCCs are sending large number of requests. In such case, the PCE MAY drop the additional requests that are governed by the load attributes such as memory, CPU, etc. The PCE MAY not send any notification to the PCC that the request message is dropped. When the request is dropped, PCC will retransmit the PCECP message based on its retransmission strategies. However, based on a hysteresis, PCE can notify the corresponding PCC before dropping the received response message during overload. At once PCE is recovered from the high load condition it can continue to provide the path computation service. In the event of congestion in the network, UDP datagrams (carrying PCECP messages) can be dropped and PCC or PCE may be unaware of this. Handling of such messages is not required and is out of scope from this document. However, this results in PCC retransmitting the corresponding request message. 4.4. PCECP Messages and Object Formats No new messages and objects are introduced in this document. The PCECP messages and objects are the same as defined in [RFC5440]. zhang Expires July 2010 [Page 9] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 5. UDP Port The PCECP operates over UDP using a registered UDP port (4189). All PCECP messages MUST be sent using the registered UDP port. 6. Security Considerations The PCECP messages could be the target of the following security issues: o Spoofing (PCC or PCE impersonation) o Snooping (message interception) o Falsification o Denial of Service When UDP is used, the application MUST address these security issues. This can be achieved using authenticated message exchange along with an appropriate replay detection scheme. At once authentication is enabled; PCECP peers can verify the integrity of message before processing it. PCECP peer drops the received message in the event of authentication failure. 6.1. Authentication of PCECP Messages The authentication of PCECP messages plays a vital role in resolving the falsification of messages, integrality, and denial of service attacks. PCECP peers can be preconfigured with authentication keys to be used during the message exchange. The authentication keys can be configured manually or by employing an appropriate key-exchange protocol which is out of scope from this document. The authentication of PCECP message can be achieved by carrying the authentication information in the Authentication object to reliably identify the source of a PCECP message and to confirm that the contents of the PCECP message have not been tampered with. The Authentication object carries authentication information to authenticate the identity and contents of PCECP messages. The format of the Authentication object is as follows: zhang Expires July 2010 [Page 10] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Object-Class=27| OT=1 |Res|P|I| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following are the TLVs: TLV type Length Name 1 64 bits RDM Monotonic Counter TLV 2 128 bits HMAC-MD5 TLV 6.1.1. RDM Monotonic Counter TLV (64-bits) The RDM Monotonic Counter TLV specifies the type of replay detection to be used. The replay detection field MUST be set to the value of a monotonically increasing counter. Using a counter value, such as the current time of day (for example, an NTP-format timestamp), can reduce the danger of replay attacks. Hence, the replay detection scheme can detect the replayed message and can drop the message even when the intruder has captured the valid message (say path request message) and is playing it back. If Replay is not detected, this may lead to denial of service where PCE will be overloaded (PCE will perform repeated path computation for the path request it has received from the intruder as PCE is assuming that the valid PCC has submitted the path request) 6.1.2. HMAC-MD5 TLV The use of a particular technique based on the HMAC protocol [RFC2104] using the MD5 hash [RFC1321] is defined here, however, mechanism like SHA can also be used. The format of the HMAC-MD5 TLV is as follows: zhang Expires July 2010 [Page 11] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCECP realm | | (variable length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC-MD5 | | (128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCECP realm: The PCECP realm identifies the administrative domain under which PCC and PCE are deployed. key ID: The key identifier that identifies the key used to generate the HMAC-MD5 value. HMAC-MD5: The message authentication code generated by applying MD5 to the PCECP message using the key identified by the PCECP realm, PCC IP address, and key ID. The sender computes the MAC using the HMAC generation algorithm and the MD5 hash function. The entire PCECP message (setting the MAC field of the authentication option to zero), including the PCECP message header and the options field, is used as input to the HMAC- MD5 computation function. 6.1.3. Message Validation To validate an incoming message, the receiver computes the MAC. The entire PCECP message (setting the MAC field of the authentication option to 0) is used as input to the HMAC-MD5 computation function. If the MAC computed by the receiver does not match the MAC contained in the authentication option, the receiver MUST discard the PCECP message. zhang Expires July 2010 [Page 12] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 6.1.4. Key Utilization Each PCC and PCE is assigned with a set of key. Each key is uniquely identified by the IP address of the peer. The PCC and PCE use the assigned keys to authenticate PCECP messages during a session. 7. Conclusion UDP can be used as the transport layer protocol for PCECP instead of TCP. The application will become responsible for the reliable delivery of the messages and also monitors the congestion. The PCECP session holds good even when UDP being the transport layer protocol. 8. IANA Considerations 8.1. UDP Port PCECP will use a registered UDP port to be assigned by IANA (4189). 8.2. PCECP Objects The PCECP Objects registry contains a sub registry, PCECP Objects. IANA is requested to make some allocations for the Authentication object. Object-Class Value Name Reference 27 Authentication This document Object-Type-1 8.3. PCECP TLV Type Indicators IANA is requested to create a registry for the following TLVs that appear in the Authentication object. Value Meaning Reference 1 RDM Monotonic Counter TLV This document 2 HMAC-MD5 TLV This document zhang Expires July 2010 [Page 13] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 9. Acknowledgments The authors would like to thank Adrian Farrel, Pradeep Shastry, Thiyagarajan Manickam, Hemalatha G for their suggestions during the development of this draft. 10. References 10.1. Normative References [RFC1321] Rivet, R., "The MD5 Message-Digest Algorithm", April 1992. [RFC2104] Canetti, R., Bellare, M., and H. Krawczyk, "HMAC: Keyed- Hashing for Message Authentication", February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", May 2008. [RFC768] Postel, J., "User Datagram Protocol", August 1980. 10.2. Informative References [RFC4655] Vasseur, J. and J. Ash, "A Path Computation Element (PCE)- Based Architecture", August 2006. [RFC4657] Ash, J. and J. Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", September 2006. [RFC5440] Ash, J. and J. Roux, "Path Computation Element (PCE) communication Protocol (PCEP)", March 2009. 11. Authors' Addresses Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972912 zhang Expires July 2010 [Page 14] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 Email: zhangfatai@huawei.com Suresh BR Huawei Technologies Shenzhen China Email: sureshbr@huawei.com SenthilKumar S Huawei Technologies Shenzhen China Email: ssenthilkumar@huawei.com Jun Sun Huawei Technologies Shenzhen China Phone: +86-755-28977297 Email: johnsun@huawei.com Intellectual Property The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr zhang Expires July 2010 [Page 15] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement 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). zhang Expires July 2010 [Page 16] draft-zhang-pce-udp-for-pcecp-00.txt January 2010 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. zhang Expires July 2010 [Page 17] --Boundary_(ID_5xVwszzl5yXyx5E+/s9gHg)-- From jvasseur@cisco.com Fri Jan 22 02:30:46 2010 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 ACBE93A698A for ; Fri, 22 Jan 2010 02:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.878 X-Spam-Level: X-Spam-Status: No, score=-9.878 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL4Mh7MCESCZ for ; Fri, 22 Jan 2010 02:30:45 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3B04A3A6958 for ; Fri, 22 Jan 2010 02:30:43 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALsMWUutJV2c/2dsb2JhbADCR5Y9hDwE X-IronPort-AV: E=Sophos;i="4.49,323,1262563200"; d="scan'208,217";a="81435532" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 22 Jan 2010 10:30:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o0MAUYX7013097; Fri, 22 Jan 2010 10:30:37 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 11:30:36 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 11:30:35 +0100 Message-Id: From: JP Vasseur To: Fatai Zhang , Jun Sun In-Reply-To: <03c701ca9b12$444ffd90$604c460a@china.huawei.com> Content-Type: multipart/alternative; boundary=Apple-Mail-36-233709634 Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Fri, 22 Jan 2010 11:30:34 +0100 References: <20100121063113.16D383A69C9@core3.amsl.com> <03c701ca9b12$444ffd90$604c460a@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Jan 2010 10:30:35.0435 (UTC) FILETIME=[EEC7F7B0:01CA9B4D] Cc: pce@ietf.org Subject: Re: [Pce] New Version Notification for draft-zhang-pce-udp-for-pcecp-00 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, 22 Jan 2010 10:30:46 -0000 --Apple-Mail-36-233709634 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On Jan 22, 2010, at 4:23 AM, Fatai Zhang wrote: > Hi PCEers, > > We just uploaded a draft, which is about PCECP over UDP. > > I think it is very interesting to investigate the feasibility and > advantages of using UDP as transport protocol for PCECP. > > If you are interested in this topic, hope you can have a look and > review this draft. > > We would like to appreciate your comments or suggestions. Co-chair Hat off. Do you see an issue with TCP that motivates this ID ? BAsed on experience, experimentation and deployment, I do not see any reason for proposing an alternative to TCP in this context. Thanks. JP. > > > > > Thanks > > Fatai > > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28972912 > Fax: +86-755-28972935 > > > > ----- Original Message ----- > From: "IETF I-D Submission Tool" > To: > Cc: ; ; > > Sent: Thursday, January 21, 2010 2:31 PM > Subject: New Version Notification for draft-zhang-pce-udp-for-pcecp-00 > > > > > A new version of I-D, draft-zhang-pce-udp-for-pcecp-00.txt has > been successfuly submitted by Fatai Zhang and posted to the IETF > repository. > > > > Filename: draft-zhang-pce-udp-for-pcecp > > Revision: 00 > > Title: UDP as Transport Protocol for PCECP > > Creation_date: 2010-01-21 > > WG ID: Independent Submission > > Number_of_pages: 17 > > > > Abstract: > > The Path Computation Element Communication Protocol defines a > > request/response protocol used for the communication between a Path > > Computation Client (PCC) and a Path Computation Element (PCE), or > > between two PCEs. PCEP employs Transmission Control Protocol (TCP) > as > > the transport layer protocol by using a registered TCP port. > > > > This document proposes the possibility of employing UDP as the > > transport layer protocol instead of TCP. > > > > UDP is a connectionless protocol within TCP/IP protocol suite that > > corresponds to the transport layer in the ISO/OSI reference model. > > UDP converts data messages generated by an application into packets > > to be sent through IP. The reliability is not guaranteed by UDP and > > should be ensured by the application that generates the data > message. > > > > The PCECP application is flexible to ensure the reliability of PCECP > > messages. This document explains on how the reliability of the PCECP > > messages can be achieved by means of PCECP, while operating PCECP > > over UDP. > > > > > > > > The IETF Secretariat. > > > > > > pcecp-00.txt>_______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Apple-Mail-36-233709634 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

On Jan = 22, 2010, at 4:23 AM, Fatai Zhang wrote:

Hi = PCEers,
 
We just = uploaded a draft, which is about PCECP over UDP.
 
I think it = is very interesting to investigate the feasibility and advantages of = using UDP as transport protocol for PCECP.
 
If you are = interested in this topic, hope you can have a look and review this = draft.
 
We would like to appreciate your comments or = suggestions.

= Co-chair Hat off.

Do you see an issue with TCP = that motivates this ID ?
BAsed on experience, experimentation = and deployment, I do not see any reason for proposing an alternative to = TCP in this = context.

Thanks.

JP.
 
 
 

Thanks
 
Fatai
 
Huawei = Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen = 518129 P.R.China
Tel: +86-755-28972912
Fax: = +86-755-28972935
 

 
----- = Original Message -----
From: "IETF I-D = Submission Tool" <idsubmission@ietf.org>
Sent: = Thursday, January 21, 2010 2:31 PM
Subject: New Version Notification for = draft-zhang-pce-udp-for-pcecp-00

> 
> A new version of = I-D, draft-zhang-pce-udp-for-pcecp-00.txt has been successfuly submitted = by Fatai Zhang and posted to the IETF repository.
> 
> Filename: = draft-zhang-pce-udp-for-pcecp
> Revision: 00
> Title: UDP as = Transport Protocol for PCECP
> Creation_date: 2010-01-21
> = WG ID: Independent Submission
> Number_of_pages: 17
> 
> Abstract:
> = The Path Computation Element Communication Protocol defines a 
> request/response = protocol used for the communication between a Path 
> Computation Client = (PCC) and a Path Computation Element (PCE), or 
> between two PCEs. = PCEP employs Transmission Control Protocol (TCP) as 
> the transport = layer protocol by using a registered TCP port. 
> 
> This document = proposes the possibility of employing UDP as the 
> transport layer = protocol instead of TCP. 
> 
> UDP is a = connectionless protocol within TCP/IP protocol suite that 
> corresponds to the = transport layer in the ISO/OSI reference model. 
> UDP converts data = messages generated by an application into packets 
> to be sent through = IP. The reliability is not guaranteed by UDP and 
> should be ensured = by the application that generates the data message. 
> 
> The PCECP = application is flexible to ensure the reliability of PCECP 
> messages. This = document explains on how the reliability of the PCECP 
> messages can be = achieved by means of PCECP, while operating PCECP 
> over = UDP.
>          &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =           
> 
> 
> The IETF = Secretariat.
> 
> 
> <draft-zhang-pce-udp= -for-pcecp-00.txt>______________________________________________= _
Pce mailing list
Pce@ietf.org
https://www.ietf.org/ma= ilman/listinfo/pce

= --Apple-Mail-36-233709634-- From zhangfatai@huawei.com Sun Jan 24 17:24:03 2010 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 095BE3A686D for ; Sun, 24 Jan 2010 17:24:03 -0800 (PST) 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 7XXFnygmgM7z for ; Sun, 24 Jan 2010 17:24:01 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8C7573A6867 for ; Sun, 24 Jan 2010 17:24:01 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWS0091I3VR2R@szxga03-in.huawei.com> for pce@ietf.org; Mon, 25 Jan 2010 09:23:51 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWS00KV13VQ88@szxga03-in.huawei.com> for pce@ietf.org; Mon, 25 Jan 2010 09:23:50 +0800 (CST) Received: from Z41162C ([10.70.76.96]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWS002T63VQ1Y@szxml06-in.huawei.com> for pce@ietf.org; Mon, 25 Jan 2010 09:23:50 +0800 (CST) Date: Mon, 25 Jan 2010 09:23:50 +0800 From: Fatai Zhang To: Jun Sun , JP Vasseur Message-id: <007e01ca9d5d$0c9bfff0$604c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_HfCO5PsZ9uLjMSqOenKhgw)" X-Priority: 3 X-MSMail-priority: Normal References: <20100121063113.16D383A69C9@core3.amsl.com> <03c701ca9b12$444ffd90$604c460a@china.huawei.com> Cc: pce@ietf.org Subject: Re: [Pce] New Version Notification for draft-zhang-pce-udp-for-pcecp-00 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, 25 Jan 2010 01:24:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_HfCO5PsZ9uLjMSqOenKhgw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi JP, We have already given the advantages of using UDP rather than TCP in section 3.2 and 3.1 of our draft. You know if PCE is deployed in the network element, it is usually desirable to use a kind of light transpoft protocol for PCECP(e.g., UDP) to reduce the burden of memory and CPU. In addition, if we use UDP, it does not need to create session before sending path computation request, so it can get the required route more quickly, especially, it is very important in the case of recovery. We also have clearly explained other advantages like parsing effectiveness, retransmission control, overall simplicity of UDP compared to TCP etc., Thanks Fatai ----- Original Message ----- From: JP Vasseur To: Fatai Zhang ; Jun Sun Cc: pce@ietf.org Sent: Friday, January 22, 2010 6:30 PM Subject: Re: [Pce] New Version Notification for draft-zhang-pce-udp-for-pcecp-00 Hi, On Jan 22, 2010, at 4:23 AM, Fatai Zhang wrote: Hi PCEers, We just uploaded a draft, which is about PCECP over UDP. I think it is very interesting to investigate the feasibility and advantages of using UDP as transport protocol for PCECP. If you are interested in this topic, hope you can have a look and review this draft. We would like to appreciate your comments or suggestions. Co-chair Hat off. Do you see an issue with TCP that motivates this ID ? BAsed on experience, experimentation and deployment, I do not see any reason for proposing an alternative to TCP in this context. Thanks. JP. Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: "IETF I-D Submission Tool" To: Cc: ; ; Sent: Thursday, January 21, 2010 2:31 PM Subject: New Version Notification for draft-zhang-pce-udp-for-pcecp-00 > > A new version of I-D, draft-zhang-pce-udp-for-pcecp-00.txt has been successfuly submitted by Fatai Zhang and posted to the IETF repository. > > Filename: draft-zhang-pce-udp-for-pcecp > Revision: 00 > Title: UDP as Transport Protocol for PCECP > Creation_date: 2010-01-21 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > The Path Computation Element Communication Protocol defines a > request/response protocol used for the communication between a Path > Computation Client (PCC) and a Path Computation Element (PCE), or > between two PCEs. PCEP employs Transmission Control Protocol (TCP) as > the transport layer protocol by using a registered TCP port. > > This document proposes the possibility of employing UDP as the > transport layer protocol instead of TCP. > > UDP is a connectionless protocol within TCP/IP protocol suite that > corresponds to the transport layer in the ISO/OSI reference model. > UDP converts data messages generated by an application into packets > to be sent through IP. The reliability is not guaranteed by UDP and > should be ensured by the application that generates the data message. > > The PCECP application is flexible to ensure the reliability of PCECP > messages. This document explains on how the reliability of the PCECP > messages can be achieved by means of PCECP, while operating PCECP > over UDP. > > > > The IETF Secretariat. > > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_HfCO5PsZ9uLjMSqOenKhgw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi JP,
 
We have already given the advantages of using UDP rather than TCP in section 3.2 and 3.1 of our draft.
You know if PCE is deployed in the network element, it is usually desirable to use a kind of light transpoft protocol for PCECP(e.g., UDP) to reduce the burden of memory and CPU. In addition, if we use UDP, it does not need to create session before sending path computation request, so it can get the required route more quickly, especially, it is very important in the case of recovery.

We also have clearly explained other advantages like parsing effectiveness, retransmission control, overall simplicity of UDP compared to TCP etc.,
 

Thanks
 
Fatai
 

 
----- Original Message -----
From: JP Vasseur
Sent: Friday, January 22, 2010 6:30 PM
Subject: Re: [Pce] New Version Notification for draft-zhang-pce-udp-for-pcecp-00

Hi,

On Jan 22, 2010, at 4:23 AM, Fatai Zhang wrote:

Hi PCEers,
 
We just uploaded a draft, which is about PCECP over UDP.
 
I think it is very interesting to investigate the feasibility and advantages of using UDP as transport protocol for PCECP.
 
If you are interested in this topic, hope you can have a look and review this draft.
 
We would like to appreciate your comments or suggestions.

Co-chair Hat off.

Do you see an issue with TCP that motivates this ID ?
BAsed on experience, experimentation and deployment, I do not see any reason for proposing an alternative to TCP in this context.

Thanks.

JP.

 
 
 

Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
 

 
----- Original Message -----
From: "IETF I-D Submission Tool" <idsubmission@ietf.org>
Sent: Thursday, January 21, 2010 2:31 PM
Subject: New Version Notification for draft-zhang-pce-udp-for-pcecp-00

> 
> A new version of I-D, draft-zhang-pce-udp-for-pcecp-00.txt has been successfuly submitted by Fatai Zhang and posted to the IETF repository.
> 
> Filename: draft-zhang-pce-udp-for-pcecp
> Revision: 00
> Title: UDP as Transport Protocol for PCECP
> Creation_date: 2010-01-21
> WG ID: Independent Submission
> Number_of_pages: 17
> 
> Abstract:
> The Path Computation Element Communication Protocol defines a 
> request/response protocol used for the communication between a Path 
> Computation Client (PCC) and a Path Computation Element (PCE), or 
> between two PCEs. PCEP employs Transmission Control Protocol (TCP) as 
> the transport layer protocol by using a registered TCP port. 
> 
> This document proposes the possibility of employing UDP as the 
> transport layer protocol instead of TCP. 
> 
> UDP is a connectionless protocol within TCP/IP protocol suite that 
> corresponds to the transport layer in the ISO/OSI reference model. 
> UDP converts data messages generated by an application into packets 
> to be sent through IP. The reliability is not guaranteed by UDP and 
> should be ensured by the application that generates the data message. 
> 
> The PCECP application is flexible to ensure the reliability of PCECP 
> messages. This document explains on how the reliability of the PCECP 
> messages can be achieved by means of PCECP, while operating PCECP 
> over UDP.
>                                                                                  
> 
> 
> The IETF Secretariat.
> 
> 
> <draft-zhang-pce-udp-for-pcecp-00.txt>_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

--Boundary_(ID_HfCO5PsZ9uLjMSqOenKhgw)-- From jvasseur@cisco.com Mon Jan 25 05:19:03 2010 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 3A0023A69D3 for ; Mon, 25 Jan 2010 05:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8HDXt5eyOeZ for ; Mon, 25 Jan 2010 05:19:01 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C33A33A69CA for ; Mon, 25 Jan 2010 05:19:01 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEANcoXUurRN+K/2dsb2JhbACCF8EclUiEOwQ X-IronPort-AV: E=Sophos;i="4.49,339,1262563200"; d="scan'208,217";a="78694224" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 25 Jan 2010 13:19:07 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0PDJ7rD014648; Mon, 25 Jan 2010 13:19:07 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 07:19:07 -0600 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 07:19:06 -0600 Message-Id: <1C6B228C-AF0E-41AB-8AE7-F765C5623D66@cisco.com> From: JP Vasseur To: Fatai Zhang In-Reply-To: <007e01ca9d5d$0c9bfff0$604c460a@china.huawei.com> Content-Type: multipart/alternative; boundary=Apple-Mail-63-503018968 Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Mon, 25 Jan 2010 14:19:03 +0100 References: <20100121063113.16D383A69C9@core3.amsl.com> <03c701ca9b12$444ffd90$604c460a@china.huawei.com> <007e01ca9d5d$0c9bfff0$604c460a@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jan 2010 13:19:06.0925 (UTC) FILETIME=[F8F025D0:01CA9DC0] Cc: Jun Sun , pce@ietf.org Subject: Re: [Pce] New Version Notification for draft-zhang-pce-udp-for-pcecp-00 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, 25 Jan 2010 13:19:03 -0000 --Apple-Mail-63-503018968 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Fatai, On Jan 25, 2010, at 2:23 AM, Fatai Zhang wrote: > Hi JP, > > We have already given the advantages of using UDP rather than TCP in > section 3.2 and 3.1 of our draft. > You know if PCE is deployed in the network element, it is usually > desirable to use a kind of light transpoft protocol for PCECP(e.g., > UDP) to reduce the burden of memory and CPU. In addition, if we use > UDP, it does not need to create session before sending path > computation request, so it can get the required route more quickly, > especially, it is very important in the case of recovery. > > We also have clearly explained other advantages like parsing > effectiveness, retransmission control, overall simplicity of UDP > compared to TCP etc., Thanks for your reply. Just to clarify (with co-chair hat off), as you know, there are a number of implementations of PCEP, and I haven't heard any issue related to the use of TCP here. Current stacks can very easily handle a large number of TCP sessions (if at all needed in these environments) and although one can always propose changes and use other transport (e..g UDP but we also had discussion about the use of SCTP for other reason) I must say that I do not see any reasons for doing so. Others on the list will comments of course. Again this is a "co-chair hat off" comment. Thanks. JP. > > > Thanks > > Fatai > > > > ----- Original Message ----- > From: JP Vasseur > To: Fatai Zhang ; Jun Sun > Cc: pce@ietf.org > Sent: Friday, January 22, 2010 6:30 PM > Subject: Re: [Pce] New Version Notification for draft-zhang-pce-udp- > for-pcecp-00 > > Hi, > > On Jan 22, 2010, at 4:23 AM, Fatai Zhang wrote: > >> Hi PCEers, >> >> We just uploaded a draft, which is about PCECP over UDP. >> >> I think it is very interesting to investigate the feasibility and >> advantages of using UDP as transport protocol for PCECP. >> >> If you are interested in this topic, hope you can have a look and >> review this draft. >> >> We would like to appreciate your comments or suggestions. > > Co-chair Hat off. > > Do you see an issue with TCP that motivates this ID ? > BAsed on experience, experimentation and deployment, I do not see > any reason for proposing an alternative to TCP in this context. > > Thanks. > > JP. > >> >> >> >> >> Thanks >> >> Fatai >> >> Huawei Technologies Co., LTD. >> Huawei Base, Bantian, Longgang, >> Shenzhen 518129 P.R.China >> Tel: +86-755-28972912 >> Fax: +86-755-28972935 >> >> >> >> ----- Original Message ----- >> From: "IETF I-D Submission Tool" >> To: >> Cc: ; ; > > >> Sent: Thursday, January 21, 2010 2:31 PM >> Subject: New Version Notification for draft-zhang-pce-udp-for- >> pcecp-00 >> >> > >> > A new version of I-D, draft-zhang-pce-udp-for-pcecp-00.txt has >> been successfuly submitted by Fatai Zhang and posted to the IETF >> repository. >> > >> > Filename: draft-zhang-pce-udp-for-pcecp >> > Revision: 00 >> > Title: UDP as Transport Protocol for PCECP >> > Creation_date: 2010-01-21 >> > WG ID: Independent Submission >> > Number_of_pages: 17 >> > >> > Abstract: >> > The Path Computation Element Communication Protocol defines a >> > request/response protocol used for the communication between a Path >> > Computation Client (PCC) and a Path Computation Element (PCE), or >> > between two PCEs. PCEP employs Transmission Control Protocol >> (TCP) as >> > the transport layer protocol by using a registered TCP port. >> > >> > This document proposes the possibility of employing UDP as the >> > transport layer protocol instead of TCP. >> > >> > UDP is a connectionless protocol within TCP/IP protocol suite that >> > corresponds to the transport layer in the ISO/OSI reference model. >> > UDP converts data messages generated by an application into packets >> > to be sent through IP. The reliability is not guaranteed by UDP and >> > should be ensured by the application that generates the data >> message. >> > >> > The PCECP application is flexible to ensure the reliability of >> PCECP >> > messages. This document explains on how the reliability of the >> PCECP >> > messages can be achieved by means of PCECP, while operating PCECP >> > over UDP. >> > >> > >> > >> > The IETF Secretariat. >> > >> > >> > > pcecp-00.txt>_______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce > > --Apple-Mail-63-503018968 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Fatai,

On = Jan 25, 2010, at 2:23 AM, Fatai Zhang wrote:

Hi = JP,
We have already = given the advantages of using UDP rather than TCP in section 3.2 and 3.1 = of our draft.
You = know if PCE is deployed in the network element, it is usually desirable = to use a kind of light transpoft protocol for PCECP(e.g., UDP) to reduce = the burden of memory and CPU. In addition, if we use UDP, it does not = need to create session before sending path computation request, so it = can get the required route more quickly, especially, it is very = important in the case = of recovery.

We also have clearly explained other = advantages like parsing effectiveness, retransmission control, overall = simplicity of UDP compared to TCP = etc.,

Than= ks for your reply. Just to clarify (with co-chair hat off), as = you know, there are a number of implementations of PCEP, and I haven't = heard any issue related to the use of TCP here. Current stacks can very = easily handle a large number of TCP sessions (if at all needed in these = environments) and although one can always propose changes and use other = transport (e..g UDP but we also had discussion about the use of SCTP for = other reason) I must say that I do not see any reasons for doing = so.

Others on the list will comments of = course.

Again this is a "co-chair hat off" = comment.

Thanks.

JP.
 

Thanks
 
Fatai
 

&n= bsp;
----- Original Message -----
Sent: Friday, January 22, 2010 = 6:30 PM
Subject: Re: [Pce] New Version = Notification for = draft-zhang-pce-udp-for-pcecp-00

Hi,

On Jan 22, 2010, at 4:23 AM, Fatai Zhang wrote:

Hi = PCEers,
 
We just = uploaded a draft, which is about PCECP over UDP.
 
I think it = is very interesting to investigate the feasibility and advantages of = using UDP as transport protocol for PCECP.
 
If you are = interested in this topic, hope you can have a look and review this = draft.
 
We would like to appreciate your comments or = suggestions.

= Co-chair Hat off.

Do you see an issue with TCP = that motivates this ID ?
BAsed on experience, experimentation = and deployment, I do not see any reason for proposing an alternative to = TCP in this context.

Thanks.

JP.<= /div>
 
 
 

Thanks
 
Fatai
 
Huawei = Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen = 518129 P.R.China
Tel: +86-755-28972912
Fax: = +86-755-28972935
 

 
----- = Original Message -----
From: "IETF I-D = Submission Tool" <idsubmission@ietf.org>
Sent: = Thursday, January 21, 2010 2:31 PM
Subject: New Version Notification for = draft-zhang-pce-udp-for-pcecp-00

> 
> A new version of = I-D, draft-zhang-pce-udp-for-pcecp-00.txt has been successfuly submitted = by Fatai Zhang and posted to the IETF repository.
> 
> Filename: = draft-zhang-pce-udp-for-pcecp
> Revision: 00
> Title: UDP as = Transport Protocol for PCECP
> Creation_date: 2010-01-21
> = WG ID: Independent Submission
> Number_of_pages: 17
> 
> Abstract:
> = The Path Computation Element Communication Protocol defines a 
> request/response = protocol used for the communication between a Path 
> Computation Client = (PCC) and a Path Computation Element (PCE), or 
> between two PCEs. = PCEP employs Transmission Control Protocol (TCP) as 
> the transport = layer protocol by using a registered TCP port. 
> 
> This document = proposes the possibility of employing UDP as the 
> transport layer = protocol instead of TCP. 
> 
> UDP is a = connectionless protocol within TCP/IP protocol suite that 
> corresponds to the = transport layer in the ISO/OSI reference model. 
> UDP converts data = messages generated by an application into packets 
> to be sent through = IP. The reliability is not guaranteed by UDP and 
> should be ensured = by the application that generates the data message. 
> 
> The PCECP = application is flexible to ensure the reliability of PCECP 
> messages. This = document explains on how the reliability of the PCECP 
> messages can be = achieved by means of PCECP, while operating PCECP 
> over = UDP.
>          &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =           
> 
> 
> The IETF = Secretariat.
> 
> 
> <draft-zhang-pce-udp= -for-pcecp-00.txt>______________________________________________= _
Pce mailing list
Pce@ietf.org
https://www.ietf.org/ma= ilman/listinfo/pce



= --Apple-Mail-63-503018968-- From root@core3.amsl.com Fri Jan 29 04:45:02 2010 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2FC483A6A4D; Fri, 29 Jan 2010 04:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100129124502.2FC483A6A4D@core3.amsl.com> Date: Fri, 29 Jan 2010 04:45:02 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-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: Fri, 29 Jan 2010 12:45: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 : 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-05.txt Pages : 11 Date : 2010-01-29 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-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-p2mp-req-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-29043026.I-D@ietf.org> --NextPart-- From adrian@olddog.co.uk Fri Jan 29 04:56:04 2010 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 C55F13A6A38 for ; Fri, 29 Jan 2010 04:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 aT3TLx-vhY0D for ; Fri, 29 Jan 2010 04:56:04 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id B3AA03A6A24 for ; Fri, 29 Jan 2010 04:56:03 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o0TCuBtM005822 for ; Fri, 29 Jan 2010 12:56:16 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o0TCuAQn005806 for ; Fri, 29 Jan 2010 12:56:10 GMT Message-ID: From: "Adrian Farrel" To: References: <20100129124502.2FC483A6A4D@core3.amsl.com> Date: Fri, 29 Jan 2010 12:56:00 -0000 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 Subject: Re: [Pce] I-D Action:draft-ietf-pce-p2mp-req-05.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, 29 Jan 2010 12:56:04 -0000 New version addresses the GenArt review from Francis Dupont received during IETF Last Call. The changes are very small editorial nits, and an updated reference. Cheers, Adrian ----- Original Message ----- From: To: Cc: Sent: Friday, January 29, 2010 12:45 PM Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-05.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Path Computation Element Working Group of > the IETF. > > > Title : 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-05.txt > Pages : 11 > Date : 2010-01-29 > > 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-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. > -------------------------------------------------------------------------------- > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >