From pce-bounces@lists.ietf.org Mon May 02 07:49:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQH-0006OI-Mj; Mon, 02 May 2005 07:49:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSWLb-0001rY-3O for pce@megatron.ietf.org; Mon, 02 May 2005 04:32:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14252 for ; Mon, 2 May 2005 04:32:09 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSWZD-0004WP-U9 for pce@ietf.org; Mon, 02 May 2005 04:46:17 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 10:32:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [Pce] WG feedback required on PCE Capability Discovery Date: Mon, 2 May 2005 10:32:05 +0200 Message-ID: Thread-Topic: [Pce] WG feedback required on PCE Capability Discovery Thread-Index: AcVMr99QBVWCbTbOSW2u7eucE63VcACOGMrg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 02 May 2005 08:32:06.0897 (UTC) FILETIME=[6CC6A610:01C54EF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Adrian,=20 >Well, OK. >But let's be really careful about the word Policy. >It has established meaning in other protocols and it sounds=20 >like this is intended to be a different meaning. An example of=20 >a Policy by my lights would be "PCCs from this domain are not=20 >allowed to ask for paths of this type that cross that domain=20 >for this priority traffic except on a Wednesday or when there=20 >is an R in the month." Yes, actually in the current PCE com reqs draft we awkwardly mixed path = selection policies and protocol communication policies (see 6.2.3), and, = in the context of this PCE capability discovery discussion, I thought = you were referring here to the discovery of supported path selection = policies... Note that this will be clarified in next revision (see previous mail = sent by Jerry to Ina).=20 You are right that discovering such policies, if desired, could require = more than just bit flags.=20 By the way for simple policies like "the PCE can only serve requests = sent by PCCs in its AS", I don't think there is a need for policy = discovery, rather the discovery protocol itself must be policed to = restrict PCE discovery to authorized PCCs (in the above example restrict = PCE discovery scope to a single AS). Thanks, JL >-----Message d'origine----- >De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 >Envoy=E9 : vendredi 29 avril 2005 13:38 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org >Objet : Re: [Pce] WG feedback required on PCE Capability Discovery > > >Hi JL, > >Basic agreement. > >Two small points. > >> >(Option 3 is not such a burden since it is a request/response=20 >> >interaction and that is exactly what the PCE-PCC communications=20 >> >protocol does best.) >> >>Yes, but this may lead to multiple PCC-PCE crankbacks (ie >> a PCC may have to try various PCEs before to find the appropriate=20 >>one) > >Yes and no. >Yes, the first time. >No subsequent times. >That is, we may assume that a PCC will retain the PCE=20 >capabilities information regardless of how it is propagated.=20 >Certainly you wouldn't suggest that a PCC that receieves this=20 >information through an IGP would have a problem deciding whihc=20 >PCE to contact because it hasn't received an update for 10 minutes! > >>>Note that the PCE-PCC comms draft currently says that items like=20 >>>Policies must be advertised as part of the PCE capabilities. These=20 >>>could be non-trivial and many in number. >> >>Most of the policies (constraints, criterias...) can IMHO be encoded=20 >>using flags... > >Well, OK. >But let's be really careful about the word Policy. >It has established meaning in other protocols and it sounds=20 >like this is intended to be a different meaning. An example of=20 >a Policy by my lights would be "PCCs from this domain are not=20 >allowed to ask for paths of this type that cross that domain=20 >for this priority traffic except on a Wednesday or when there=20 >is an R in the month." > >A > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon May 02 19:16:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSk9T-0005Rv-Gh; Mon, 02 May 2005 19:16:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSk9R-0005Rq-VA for pce@megatron.ietf.org; Mon, 02 May 2005 19:16:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28972 for ; Mon, 2 May 2005 19:16:31 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSkNC-0005Nw-RL for pce@ietf.org; Mon, 02 May 2005 19:30:48 -0400 Received: from du-069-0073.access.clara.net ([217.158.132.73] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DSk9O-000EpU-I1 for pce@ietf.org; Tue, 03 May 2005 00:16:31 +0100 Message-ID: <08d801c54f6d$416ed7e0$1c849ed9@Puppy> From: "Adrian Farrel" To: Date: Mon, 2 May 2005 22:50:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.9 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Reminder: Enforcement of Updated IPR Boilerplate X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org FYI ----- Original Message ----- From: "IETF Secretariat" Sent: Monday, May 02, 2005 8:42 PM Subject: Reminder: Enforcement of Updated IPR Boilerplate > This message is to remind you that as of Friday, May 6, 2005, > all Internet-Drafts that are submitted to the IETF Secretariat > for posting must include the IPR-related notices and disclaimers > specified in RFC 3978 (BCP 78), "IETF Rights in Contributions." > The required notices and disclaimers can be found in Section 5, > "Notices Required in IETF Documents," of RFC 3978, and in > Section 3, "IPR-Related Notices Required in Internet-Drafts," > of the recently revised "Guidelines to Authors of Internet-Drafts" > (http://www.ietf.org/ietf/1id-guidelines.html). The "Guidelines" > document also provides additional guidance regarding the > placement of these notices. > > Please note that the required notices and disclaimers must > be reproduced verbatim since they have been legally reviewed > and formally adopted as part of the IETF process. The > Secretariat will not accept deviations from the specified > text, nor will it correct the text. Any documents that do > not comply with the requirements of RFC 3978, and with > the most recent version of the "Guidelines" document, will > be returned to the submitter. > > The IETF Secretariat _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue May 03 17:44:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT5CD-0001cD-5x; Tue, 03 May 2005 17:44:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT5CB-0001c8-UP for pce@megatron.ietf.org; Tue, 03 May 2005 17:44:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14693 for ; Tue, 3 May 2005 17:44:44 -0400 (EDT) Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT5Q9-0000Vo-9F for pce@ietf.org; Tue, 03 May 2005 17:59:13 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j43LgwGH019418 for ; Tue, 3 May 2005 16:44:37 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.2.052) id 426289720043575A for pce@ietf.org; Tue, 3 May 2005 17:44:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 May 2005 16:44:37 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE596@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ash-pce-comm-protocol-gen-reqs-01.txt Thread-Index: AcVQH3ODf4W9UQ8BQhGyP6qxjkLVMwAB+6GA From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Pce] RE: I-D ACTION:draft-ash-pce-comm-protocol-gen-reqs-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi All, Please review and comment on "PCE Communication Protocol Generic Requirements" http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-reqs -01.txt. =20 The draft incorporates comments made in the exchanges on the list and Adrian's and JP's comments to the authors. Please review and comment. =20 Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, May 03, 2005 3:55 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ash-pce-comm-protocol-gen-reqs-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PCE Communication Protocol Generic Requirements Author(s) : J. Ash, J.L. Le Roux Filename : draft-ash-pce-comm-protocol-gen-reqs-01.txt Pages : 15 Date : 2005-5-3 =09 Constraint-based path computation is a fundamental building block for traffic engineering systems such as multiprotocol label switching (MPLS) and generalized multiprotocol label switching (GMPLS) networks. Path computation in large, multi-domain or multi-layer networks is highly complex and may require special computational components and cooperation between the different network domains. There are multiple components in the Path Computation Element (PCE)- based path computation model, including PCE discovery and the PCE communication protocol. The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to PCEs. This document specifies generic requirements for a communication protocol between PCCs and PCEs, and between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-reqs -01.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 04 14:03:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTODW-0002H9-RS; Wed, 04 May 2005 14:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTODW-0002Go-7r for pce@megatron.ietf.org; Wed, 04 May 2005 14:03:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08416 for ; Wed, 4 May 2005 14:03:24 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTORd-0006qK-Dw for pce@ietf.org; Wed, 04 May 2005 14:18:03 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 20:03:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE : [Pce] WG feedback required on PCE Capability Discovery Date: Wed, 4 May 2005 20:03:21 +0200 Message-ID: Thread-Topic: [Pce] WG feedback required on PCE Capability Discovery Thread-Index: AcVNYlYhxAfmL8BBT+mzrbz/+JBrUwDbnXpw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Zhang Renhai" X-OriginalArrivalTime: 04 May 2005 18:03:22.0705 (UTC) FILETIME=[8F936410:01C550D3] X-Spam-Score: 0.6 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0372359230==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0372359230== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C550D3.8F5FB344" This is a multi-part message in MIME format. ------_=_NextPart_001_01C550D3.8F5FB344 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zhang, =20 Sorry for this delayed answer. What you propose is interesting, but how a PCE would know detailed = capabilities of other PCEs? =20 Note that in some applications like inter-area TE you may end up with a = large number of PCEs. Hence this would still require an automatic mechanism allowing a PCE = discovering detailed capabilities of other PCEs, and the benefit would IMHO be reduced... =20 Best Regards, =20 JL -----Message d'origine----- De : Zhang Renhai [mailto:zhangrenhai@huawei.com]=20 Envoy=E9 : samedi 30 avril 2005 10:32 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org Objet : Re: [Pce] WG feedback required on PCE Capability Discovery Hi, JL =20 If every PCE know well of the capabilities of other's PCE, before PCE = reject a request because of its computation capabilities , it can get the = appropriate one and=20 return it to PCC. if so ,at any time ,the PCC need not to know the = detailed=20 capabilities,knowing only generic PCE capabilities is enough for PCC. Could this be another choise? =20 Thanks. Zhang =20 ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN=20 To: pce@ietf.org=20 Sent: Monday, April 18, 2005 5:02 PM Subject: [Pce] WG feedback required on PCE Capability Discovery =20 Hi all,=20 =20 There has been several discussions within the PCE com Design Team and = among PCE discovery requirements co-authors, regarding dynamic discovery = of PCE capabilities.=20 =20 Once we agree that there is a need for dynamic PCE capability discovery, = then it appears that there are three options:=20 =20 Option 1: A single specific PCE discovery mechanism is used to discover = all PCE capabilities (as currently required in the PCE discovery = requirements I-D = http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.tx= t). =20 Option 2: All PCE capabilities are discovered through added = functionality in the PCE communication protocol = (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-reqs= -00.txt). =20 Option 3: Discovery of some generic PCE capabilities (computation = domain, scope...) is done by the PCE discovery mechanism and discovery = of detailed capabilities (e.g. type of constraints supported...) relies = on the PCE communication protocol. =20 In 1) since PCC knows all PCE capabilities, it is the reponsibility of = the PCC to select the appropriate PCE for a particular path computation. = So, no capability-related request parameters are needed in the = communication protocol, since the PCC alreay knows what is expected from = the PCE. =20 In 3) PCC knows certain basic capabilities, but for the capabilities = that it is unaware of, it may request specific parameters in the = communication protocol when a path computation request is made to the = PCE. If the PCE is not capable of the requested paramters, then = appropriate failure is reported. =20 Note that this does not take into account discovery of PCE location, = that can be done either statically or dynamically through functionality = in the PCE discovery mechanism (here the PCE communication protocol = cannot help). =20 =20 Note also that PCE capabilities could of course be configured statically = but this is out of the scope of this discussion focused on dynamic = capability discovery. =20 WG feedback on this topic would be highly desired.=20 Please give us your comments and preferences regarding these three = options.=20 =20 JL=20 =20 =20 =20 =20 =20 -------------------------------------------------------------------------= ------- =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C550D3.8F5FB344 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Zhang,
 
Sorry=20 for this delayed answer.
What=20 you propose is interesting, but how a=20 PCE would know detailed capabilities of other PCEs?  =
Note that in some applications like = inter-area TE you=20 may end up with a large number of = PCEs.
Hence this would still require an=20 automatic mechanism allowing a PCE discovering detailed=20 capabilities of other PCEs,
and the benefit would IMHO be=20 reduced...
 
Best=20 Regards,
 
JL
-----Message d'origine-----
De : Zhang Renhai=20 [mailto:zhangrenhai@huawei.com]
Envoy=E9 : samedi 30 = avril 2005=20 10:32
=C0 : LE ROUX Jean-Louis = RD-CORE-LAN
Cc :=20 pce@ietf.org
Objet : Re: [Pce] WG feedback required on = PCE=20 Capability Discovery

Hi, JL
 
If every PCE know well of the capabilities of other's PCE, before = PCE=20 reject
a request because of its computation capabilities , it can = get the=20 appropriate one and
return it to PCC. if so ,at any time ,the PCC = need not=20 to know the detailed
capabilities,knowing only generic PCE = capabilities is=20 enough for PCC.
Could this be  another choise?
 
Thanks.
Zhang
 

----- Original Message -----
From: LE ROUX Jean-Louis = RD-CORE-LAN=20
To: pce@ietf.org
Sent: = Monday, April=20 18, 2005 5:02 PM
Subject: [Pce] WG feedback required on PCE = Capability=20 Discovery
 

Hi all,
 
There has been several discussions within the PCE com Design Team = and=20 among PCE discovery requirements co-authors, regarding dynamic = discovery of=20 PCE capabilities.
 
Once we agree that there is a need for dynamic PCE capability = discovery,=20 then it appears that there are three options:
 
Option 1: A single specific PCE discovery mechanism is used to = discover=20 all PCE capabilities (as currently required in the PCE discovery = requirements=20 I-D http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery= -reqs-00.txt).
 
Option 2: All PCE capabilities are discovered through added = functionality=20 in the PCE communication protocol (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-pr= otocol-gen-reqs-00.txt).
 
Option 3: Discovery of some generic PCE capabilities (computation = domain,=20 scope...) is done by the PCE discovery mechanism and discovery of = detailed=20 capabilities (e.g. type of constraints supported...) relies on the PCE = communication protocol.
 
In 1) since PCC knows all PCE capabilities, it is the = reponsibility of=20 the PCC to select the appropriate PCE for a particular path = computation. So,=20 no capability-related request parameters are needed in the = communication=20 protocol, since the PCC alreay knows what is expected from the = PCE.
 
In 3) PCC knows certain basic capabilities, but for the = capabilities that=20 it is unaware of, it may request specific parameters in the = communication=20 protocol when a path computation request is made to the PCE. If the = PCE is not=20 capable of the requested paramters, then appropriate failure is=20 reported.
 
Note that this does not take into account discovery of PCE = location, that=20 can be done either statically or dynamically through functionality in = the PCE=20 discovery mechanism (here the PCE communication protocol cannot = help). =20
 
Note also that PCE capabilities could of course be configured = statically=20 but this is out of the scope of this discussion focused on dynamic = capability=20 discovery.
 
WG feedback on this topic would be highly desired.
Please = give us=20 your comments and preferences regarding these three options.
 
JL
 
 
 
 
 
=

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

_______________________________________________
Pce = mailing=20 list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce
------_=_NextPart_001_01C550D3.8F5FB344-- --===============0372359230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0372359230==-- From pce-bounces@lists.ietf.org Wed May 04 22:31:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTW9F-0003V0-6f; Wed, 04 May 2005 22:31:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTW9B-0003UO-Hs for pce@megatron.ietf.org; Wed, 04 May 2005 22:31:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10946 for ; Wed, 4 May 2005 22:31:26 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTWNL-0004BA-Al for pce@ietf.org; Wed, 04 May 2005 22:46:10 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IFZ00IRVWH269@szxga01-in.huawei.com> for pce@ietf.org; Thu, 05 May 2005 10:34:15 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IFZ00MHVWH2ZG@szxga01-in.huawei.com> for pce@ietf.org; Thu, 05 May 2005 10:34:14 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IFZ00M4VWNF10@szxml01-in.huawei.com>; Thu, 05 May 2005 10:38:04 +0800 (CST) Date: Thu, 05 May 2005 10:08:40 +0800 From: Zhang Renhai Subject: Re: [Pce] WG feedback required on PCE Capability Discovery To: LE ROUX Jean-Louis RD-CORE-LAN Message-id: <000c01c55117$5e698b00$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 3.3 (+++) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0445239956==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0445239956== Content-type: multipart/alternative; boundary="Boundary_(ID_Q8E2RV9Dw+tfw5z49lt8lw)" This is a multi-part message in MIME format. --Boundary_(ID_Q8E2RV9Dw+tfw5z49lt8lw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 TWVzc2FnZUhpIEpMDQoNCk5ldmVyIG1pbmQgdGhlIGxhdGVuZXNzOi0pSSBzaG91bGQgdGhhbmsg eW91IGZvciB5b3VyIHJlcGx5Lg0KDQpUaGUgcHJpbWFyeSBiZW5lZml0IG9mIG15IGFkdmljZSAs IEkgdGhpbmssIGlzIHRoYXQgaXQgY2FuIA0KcmVkdWNlIHRoZSBQQ0NzJ3MgbWFpbnRhaW5pbmcg dGFzaywgZXNwZWNpYWxseSB3aGVuIG1hbnkgUENFcyBleGl0DQphbmQgdGhlIGNhcGFiaWxpdGll cyBvciBwb2xpY3kgb2YgUENFcyBtYXkgdmFyeS5JbiBzb21lIGVudmlyb25tZW50LA0KbW9zdCBQ Q0NzIG1heWJlIGhhdmUgbm8gb3IgdmVyeSBmZXcgcmVxdWVzdCB0byBQQ0UsIHNob3VsZCB0aGVz ZSBQQ0NzDQptYWludGFpbiBhbGwgY2FwYWJpbGl0aWVzIG9mIGFsbCBQQ0VzID9UaGlzIGtpbmQg b2YgbWFpbnRhaW5pbmcgd2lsbA0KY29uc3VtZSBhIGxvdCBvZiByZXNvdXJjZS4NCkJ5IHRoZSB3 YXksIGFjY29yZGluZyB0byBteSBhZHZpY2UsIFBDRSBkaXNjb3ZlcnkgbWVjaGFuaXNtIGlzIA0K bm90IG9ubHkgYXBwbGllZCB0byBQQ0MsIGJ1dCBhbHNvIHRvIFBDRSB0byBmaW5kIHRoZSBvdGhl ciBQQ0UncyANCmNhcGFiaWxpdGllcywgdGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBQQ0UgZmluZHMg Z2VuZXJpYyBhbmQgDQpkZXRhaWxlZCBjYXBhYmlsaXRpZXMgYnV0IFBDQyBmaW5kIG9ubHkgZ2Vu ZXJpYyBjYXBhYmlsaXRpZXMuDQoNClJlZ2FyZHMsDQpaaGFuZw0KDQogIC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IExFIFJPVVggSmVhbi1Mb3VpcyBSRC1DT1JFLUxBTiAN CiAgVG86IFpoYW5nIFJlbmhhaSANCiAgQ2M6IHBjZUBpZXRmLm9yZyANCiAgU2VudDogVGh1cnNk YXksIE1heSAwNSwgMjAwNSAyOjAzIEFNDQogIFN1YmplY3Q6IFJFIDogW1BjZV0gV0cgZmVlZGJh Y2sgcmVxdWlyZWQgb24gUENFIENhcGFiaWxpdHkgRGlzY292ZXJ5DQoNCg0KICBIaSBaaGFuZywN CiAgIA0KICBTb3JyeSBmb3IgdGhpcyBkZWxheWVkIGFuc3dlci4NCiAgV2hhdCB5b3UgcHJvcG9z ZSBpcyBpbnRlcmVzdGluZywgYnV0IGhvdyBhIFBDRSB3b3VsZCBrbm93IGRldGFpbGVkIGNhcGFi aWxpdGllcyBvZiBvdGhlciBQQ0VzPyAgDQogIE5vdGUgdGhhdCBpbiBzb21lIGFwcGxpY2F0aW9u cyBsaWtlIGludGVyLWFyZWEgVEUgeW91IG1heSBlbmQgdXAgd2l0aCBhIGxhcmdlIG51bWJlciBv ZiBQQ0VzLg0KICBIZW5jZSB0aGlzIHdvdWxkIHN0aWxsIHJlcXVpcmUgYW4gYXV0b21hdGljIG1l Y2hhbmlzbSBhbGxvd2luZyBhIFBDRSBkaXNjb3ZlcmluZyBkZXRhaWxlZCBjYXBhYmlsaXRpZXMg b2Ygb3RoZXIgUENFcywNCiAgYW5kIHRoZSBiZW5lZml0IHdvdWxkIElNSE8gYmUgcmVkdWNlZC4u Lg0KICAgDQogIEJlc3QgUmVnYXJkcywNCiAgIA0KICBKTA0KICAgIC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KICAgIERlIDogWmhhbmcgUmVuaGFpIFttYWlsdG86emhhbmdyZW5oYWlAaHVh d2VpLmNvbV0gDQogICAgRW52b3npIDogc2FtZWRpIDMwIGF2cmlsIDIwMDUgMTA6MzINCiAgICDA IDogTEUgUk9VWCBKZWFuLUxvdWlzIFJELUNPUkUtTEFODQogICAgQ2MgOiBwY2VAaWV0Zi5vcmcN CiAgICBPYmpldCA6IFJlOiBbUGNlXSBXRyBmZWVkYmFjayByZXF1aXJlZCBvbiBQQ0UgQ2FwYWJp bGl0eSBEaXNjb3ZlcnkNCg0KDQogICAgSGksIEpMDQoNCiAgICBJZiBldmVyeSBQQ0Uga25vdyB3 ZWxsIG9mIHRoZSBjYXBhYmlsaXRpZXMgb2Ygb3RoZXIncyBQQ0UsIGJlZm9yZSBQQ0UgcmVqZWN0 DQogICAgYSByZXF1ZXN0IGJlY2F1c2Ugb2YgaXRzIGNvbXB1dGF0aW9uIGNhcGFiaWxpdGllcyAs IGl0IGNhbiBnZXQgdGhlIGFwcHJvcHJpYXRlIG9uZSBhbmQgDQogICAgcmV0dXJuIGl0IHRvIFBD Qy4gaWYgc28gLGF0IGFueSB0aW1lICx0aGUgUENDIG5lZWQgbm90IHRvIGtub3cgdGhlIGRldGFp bGVkIA0KICAgIGNhcGFiaWxpdGllcyxrbm93aW5nIG9ubHkgZ2VuZXJpYyBQQ0UgY2FwYWJpbGl0 aWVzIGlzIGVub3VnaCBmb3IgUENDLg0KICAgIENvdWxkIHRoaXMgYmUgIGFub3RoZXIgY2hvaXNl Pw0KDQogICAgVGhhbmtzLg0KICAgIFpoYW5nDQoNCg0KICAgIC0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQogICAgRnJvbTogTEUgUk9VWCBKZWFuLUxvdWlzIFJELUNPUkUtTEFOIA0KICAg IFRvOiBwY2VAaWV0Zi5vcmcgDQogICAgU2VudDogTW9uZGF5LCBBcHJpbCAxOCwgMjAwNSA1OjAy IFBNDQogICAgU3ViamVjdDogW1BjZV0gV0cgZmVlZGJhY2sgcmVxdWlyZWQgb24gUENFIENhcGFi aWxpdHkgRGlzY292ZXJ5DQoNCg0KICAgIEhpIGFsbCwgDQoNCiAgICBUaGVyZSBoYXMgYmVlbiBz ZXZlcmFsIGRpc2N1c3Npb25zIHdpdGhpbiB0aGUgUENFIGNvbSBEZXNpZ24gVGVhbSBhbmQgYW1v bmcgUENFIGRpc2NvdmVyeSByZXF1aXJlbWVudHMgY28tYXV0aG9ycywgcmVnYXJkaW5nIGR5bmFt aWMgZGlzY292ZXJ5IG9mIFBDRSBjYXBhYmlsaXRpZXMuIA0KDQogICAgT25jZSB3ZSBhZ3JlZSB0 aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3IgZHluYW1pYyBQQ0UgY2FwYWJpbGl0eSBkaXNjb3Zlcnks IHRoZW4gaXQgYXBwZWFycyB0aGF0IHRoZXJlIGFyZSB0aHJlZSBvcHRpb25zOiANCg0KICAgIE9w dGlvbiAxOiBBIHNpbmdsZSBzcGVjaWZpYyBQQ0UgZGlzY292ZXJ5IG1lY2hhbmlzbSBpcyB1c2Vk IHRvIGRpc2NvdmVyIGFsbCBQQ0UgY2FwYWJpbGl0aWVzIChhcyBjdXJyZW50bHkgcmVxdWlyZWQg aW4gdGhlIFBDRSBkaXNjb3ZlcnkgcmVxdWlyZW1lbnRzIEktRCBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sZXJvdXgtcGNlLWRpc2NvdmVyeS1yZXFzLTAwLnR4dCku DQoNCiAgICBPcHRpb24gMjogQWxsIFBDRSBjYXBhYmlsaXRpZXMgYXJlIGRpc2NvdmVyZWQgdGhy b3VnaCBhZGRlZCBmdW5jdGlvbmFsaXR5IGluIHRoZSBQQ0UgY29tbXVuaWNhdGlvbiBwcm90b2Nv bCAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYXNoLXBjZS1jb21t LXByb3RvY29sLWdlbi1yZXFzLTAwLnR4dCkuDQoNCiAgICBPcHRpb24gMzogRGlzY292ZXJ5IG9m IHNvbWUgZ2VuZXJpYyBQQ0UgY2FwYWJpbGl0aWVzIChjb21wdXRhdGlvbiBkb21haW4sIHNjb3Bl Li4uKSBpcyBkb25lIGJ5IHRoZSBQQ0UgZGlzY292ZXJ5IG1lY2hhbmlzbSBhbmQgZGlzY292ZXJ5 IG9mIGRldGFpbGVkIGNhcGFiaWxpdGllcyAoZS5nLiB0eXBlIG9mIGNvbnN0cmFpbnRzIHN1cHBv cnRlZC4uLikgcmVsaWVzIG9uIHRoZSBQQ0UgY29tbXVuaWNhdGlvbiBwcm90b2NvbC4NCg0KICAg IEluIDEpIHNpbmNlIFBDQyBrbm93cyBhbGwgUENFIGNhcGFiaWxpdGllcywgaXQgaXMgdGhlIHJl cG9uc2liaWxpdHkgb2YgdGhlIFBDQyB0byBzZWxlY3QgdGhlIGFwcHJvcHJpYXRlIFBDRSBmb3Ig YSBwYXJ0aWN1bGFyIHBhdGggY29tcHV0YXRpb24uIFNvLCBubyBjYXBhYmlsaXR5LXJlbGF0ZWQg cmVxdWVzdCBwYXJhbWV0ZXJzIGFyZSBuZWVkZWQgaW4gdGhlIGNvbW11bmljYXRpb24gcHJvdG9j b2wsIHNpbmNlIHRoZSBQQ0MgYWxyZWF5IGtub3dzIHdoYXQgaXMgZXhwZWN0ZWQgZnJvbSB0aGUg UENFLg0KDQogICAgSW4gMykgUENDIGtub3dzIGNlcnRhaW4gYmFzaWMgY2FwYWJpbGl0aWVzLCBi dXQgZm9yIHRoZSBjYXBhYmlsaXRpZXMgdGhhdCBpdCBpcyB1bmF3YXJlIG9mLCBpdCBtYXkgcmVx dWVzdCBzcGVjaWZpYyBwYXJhbWV0ZXJzIGluIHRoZSBjb21tdW5pY2F0aW9uIHByb3RvY29sIHdo ZW4gYSBwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3QgaXMgbWFkZSB0byB0aGUgUENFLiBJZiB0aGUg UENFIGlzIG5vdCBjYXBhYmxlIG9mIHRoZSByZXF1ZXN0ZWQgcGFyYW10ZXJzLCB0aGVuIGFwcHJv cHJpYXRlIGZhaWx1cmUgaXMgcmVwb3J0ZWQuDQoNCiAgICBOb3RlIHRoYXQgdGhpcyBkb2VzIG5v dCB0YWtlIGludG8gYWNjb3VudCBkaXNjb3Zlcnkgb2YgUENFIGxvY2F0aW9uLCB0aGF0IGNhbiBi ZSBkb25lIGVpdGhlciBzdGF0aWNhbGx5IG9yIGR5bmFtaWNhbGx5IHRocm91Z2ggZnVuY3Rpb25h bGl0eSBpbiB0aGUgUENFIGRpc2NvdmVyeSBtZWNoYW5pc20gKGhlcmUgdGhlIFBDRSBjb21tdW5p Y2F0aW9uIHByb3RvY29sIGNhbm5vdCBoZWxwKS4gIA0KDQogICAgTm90ZSBhbHNvIHRoYXQgUENF IGNhcGFiaWxpdGllcyBjb3VsZCBvZiBjb3Vyc2UgYmUgY29uZmlndXJlZCBzdGF0aWNhbGx5IGJ1 dCB0aGlzIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkaXNjdXNzaW9uIGZvY3VzZWQgb24g ZHluYW1pYyBjYXBhYmlsaXR5IGRpc2NvdmVyeS4NCg0KICAgIFdHIGZlZWRiYWNrIG9uIHRoaXMg dG9waWMgd291bGQgYmUgaGlnaGx5IGRlc2lyZWQuIA0KICAgIFBsZWFzZSBnaXZlIHVzIHlvdXIg Y29tbWVudHMgYW5kIHByZWZlcmVuY2VzIHJlZ2FyZGluZyB0aGVzZSB0aHJlZSBvcHRpb25zLiAN Cg0KICAgIEpMIA0KDQoNCg0KDQoNCg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0K ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg UGNlIG1haWxpbmcgbGlzdA0KICAgIFBjZUBsaXN0cy5pZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0KDQo= --Boundary_(ID_Q8E2RV9Dw+tfw5z49lt8lw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8 U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZP TlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj5IaSBKTDwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+TmV2ZXIgbWlu ZCB0aGUgbGF0ZW5lc3M6LSlJIHNob3VsZCB0aGFuayANCnlvdSBmb3IgeW91ciByZXBseS48L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyIgc2l6ZT0yPlRoZSBwcmltYXJ5IGJlbmVmaXQgb2YgbXkgYWR2aWNlICwgSSB0aGluaywgDQpp cyB0aGF0IGl0IGNhbiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 IiBzaXplPTI+cmVkdWNlIHRoZSBQQ0NzJ3MgbWFpbnRhaW5pbmcgdGFzaywgDQplc3BlY2lhbGx5 IHdoZW4gbWFueSBQQ0VzIGV4aXQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3IiBzaXplPTI+YW5kIHRoZSBjYXBhYmlsaXRpZXMgb3IgcG9saWN5IG9mIFBDRXMgbWF5 IA0KdmFyeS5JbiBzb21lIGVudmlyb25tZW50LDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciIHNpemU9Mj5tb3N0Jm5ic3A7UENDcyBtYXliZSBoYXZlIG5vIG9yIHZl cnkgZmV3IA0KcmVxdWVzdCB0byBQQ0UsIHNob3VsZCB0aGVzZSBQQ0NzPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPm1haW50YWluIGFsbCZuYnNwO2Nh cGFiaWxpdGllcyBvZiBhbGwgUENFcyANCj9UaGlzIGtpbmQmbmJzcDtvZiBtYWludGFpbmluZyB3 aWxsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPmNv bnN1bWUgYSBsb3Qgb2YgcmVzb3VyY2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyIgc2l6ZT0yPkJ5IHRoZSB3YXksIDxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiAN CnNpemU9Mj5hY2NvcmRpbmcgPC9GT05UPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+ dG8gbXkgYWR2aWNlLCA8L0ZPTlQ+UENFIA0KZGlzY292ZXJ5IG1lY2hhbmlzbSBpcyA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+bm90IG9ubHkgYXBw bGllZCZuYnNwOzwvRk9OVD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+dG8gUEND LCBidXQgYWxzbyB0byBQQ0UgdG8gZmluZCB0aGUgb3RoZXIgUENFJ3MgDQo8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+Y2FwYWJpbGl0aWVzLCA8L0ZP TlQ+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPnRoZSBkaWZmZXJlbmNlIGlzIHRo YXQgUENFIGZpbmRzIGdlbmVyaWMgYW5kIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyIgc2l6ZT0yPmRldGFpbGVkIGNhcGFiaWxpdGllcyA8L0ZPTlQ+PEZPTlQg DQpmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPmJ1dCBQQ0MgZmluZCBvbmx5IGdlbmVyaWMgY2Fw YWJpbGl0aWVzLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+UmVnYXJkcyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+Wmhhbmc8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAw MCAycHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4OyBQQURESU5H LUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0 ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQog IDxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAz MDc7OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSBocmVmPSJtYWlsdG86 amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29tLmNvbSIgDQogIHRpdGxlPWplYW5sb3Vpcy5s ZXJvdXhAZnJhbmNldGVsZWNvbS5jb20+TEUgUk9VWCBKZWFuLUxvdWlzIFJELUNPUkUtTEFOPC9B PiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48 Qj5Ubzo8L0I+IDxBIGhyZWY9Im1haWx0bzp6aGFuZ3JlbmhhaUBodWF3ZWkuY29tIiANCiAgdGl0 bGU9emhhbmdyZW5oYWlAaHVhd2VpLmNvbT5aaGFuZyBSZW5oYWk8L0E+IDwvRElWPg0KICA8RElW IHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8QSBocmVmPSJt YWlsdG86cGNlQGlldGYub3JnIiANCiAgdGl0bGU9cGNlQGlldGYub3JnPnBjZUBpZXRmLm9yZzwv QT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5T ZW50OjwvQj4gVGh1cnNkYXksIE1heSAwNSwgMjAwNSAyOjAzIEFNPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUkUgOiBbUGNl XSBXRyBmZWVkYmFjayByZXF1aXJlZCBvbiANCiAgUENFIENhcGFiaWxpdHkgRGlzY292ZXJ5PC9E SVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTY5NTM1NDMxNy0wNDA1 MjAwNT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPkhpIA0KICBaaGFuZyw8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTY5NTM1NDMxNy0wNDA1MjAw NT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTY5NTM1NDMxNy0wNDA1MjAwNT48Rk9O VCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgDQogIHNpemU9Mj5Tb3JyeSBmb3IgdGhpcyZuYnNw O2RlbGF5ZWQgYW5zd2VyLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9 Njk1MzU0MzE3LTA0MDUyMDA1PjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+ V2hhdCANCiAgeW91IHByb3Bvc2UmbmJzcDtpcyZuYnNwO2ludGVyZXN0aW5nLCZuYnNwO2I8L0ZP TlQ+PC9TUEFOPjxTUEFOIA0KICBjbGFzcz02OTUzNTQzMTctMDQwNTIwMDU+PEZPTlQgY29sb3I9 IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj51dCBob3cgYSANCiAgUENFJm5ic3A7d291bGQmbmJz cDtrbm93IGRldGFpbGVkJm5ic3A7Y2FwYWJpbGl0aWVzIG9mIG90aGVyIFBDRXM/Jm5ic3A7IA0K ICA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBjb2xvcj0j MDAwMGZmPjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gDQogIGNsYXNzPTY5NTM1NDMxNy0wNDA1MjAw NT5Ob3RlIHRoYXQgaW4gc29tZSBhcHBsaWNhdGlvbnMgbGlrZSBpbnRlci1hcmVhIFRFIHlvdSAN CiAgbWF5IGVuZCB1cCB3aXRoIGEgbGFyZ2UgbnVtYmVyIG9mIFBDRXMuPC9TUEFOPjwvRk9OVD48 L0ZPTlQ+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBjb2xvcj0jMDAw MGZmPjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gDQogIGNsYXNzPTY5NTM1NDMxNy0wNDA1MjAwNT5I ZW5jZSZuYnNwO3RoaXMgd291bGQ8L1NQQU4+PFNQQU4gDQogIGNsYXNzPTY5NTM1NDMxNy0wNDA1 MjAwNT48Rk9OVCBzaXplPSswPiZuYnNwO3N0aWxsJm5ic3A7cmVxdWlyZSBhbiANCiAgYXV0b21h dGljJm5ic3A7bWVjaGFuaXNtJm5ic3A7YWxsb3dpbmcgYSBQQ0UmbmJzcDtkaXNjb3ZlcmluZyBk ZXRhaWxlZCANCiAgY2FwYWJpbGl0aWVzIG9mIG90aGVyIFBDRXMsPC9GT05UPjwvU1BBTj48L0ZP TlQ+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgY29sb3I9 IzAwMDBmZj48Rk9OVCBmYWNlPUFyaWFsPjxTUEFOIA0KICBjbGFzcz02OTUzNTQzMTctMDQwNTIw MDU+YW5kIHRoZSBiZW5lZml0IHdvdWxkIElNSE8gYmUgDQogIHJlZHVjZWQuLi48L1NQQU4+PC9G T05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9Njk1MzU0MzE3LTA0 MDUyMDA1PjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9Njk1MzU0MzE3LTA0MDUyMDA1 PjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+QmVzdCANCiAgUmVnYXJkcyw8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTY5NTM1NDMxNy0wNDA1MjAw NT48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTY5NTM1NDMxNy0wNDA1MjAwNT48Rk9O VCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgDQogIHNpemU9Mj5KTDwvRk9OVD48L1NQQU4+PC9E SVY+DQogIDxCTE9DS1FVT1RFIGRpcj1sdHIgDQogIHN0eWxlPSJCT1JERVItTEVGVDogIzAwMDBm ZiAycHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4OyBQQURESU5H LUxFRlQ6IDVweCI+DQogICAgPERJVj48L0RJVj4NCiAgICA8RElWIGFsaWduPWxlZnQgY2xhc3M9 T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0ciBsYW5nPWZyPjxGT05UIGZhY2U9VGFob21hIA0K ICAgIHNpemU9Mj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08QlI+PEI+RGUmbmJzcDs6PC9C PiBaaGFuZyBSZW5oYWkgDQogICAgW21haWx0bzp6aGFuZ3JlbmhhaUBodWF3ZWkuY29tXSA8QlI+ PEI+RW52b3npJm5ic3A7OjwvQj4gc2FtZWRpIDMwIGF2cmlsIA0KICAgIDIwMDUgMTA6MzI8QlI+ PEI+wCZuYnNwOzo8L0I+IExFIFJPVVggSmVhbi1Mb3VpcyANCiAgICBSRC1DT1JFLUxBTjxCUj48 Qj5DYyZuYnNwOzo8L0I+IHBjZUBpZXRmLm9yZzxCUj48Qj5PYmpldCZuYnNwOzo8L0I+IFJlOiAN CiAgICBbUGNlXSBXRyBmZWVkYmFjayByZXF1aXJlZCBvbiBQQ0UgQ2FwYWJpbGl0eSBEaXNjb3Zl cnk8QlI+PEJSPjwvRk9OVD48L0RJVj4NCiAgICA8RElWPkhpLCBKTDwvRElWPg0KICAgIDxESVY+ Jm5ic3A7PC9ESVY+DQogICAgPERJVj5JZiBldmVyeSBQQ0Uga25vdyB3ZWxsIG9mIHRoZSBjYXBh YmlsaXRpZXMgb2Ygb3RoZXIncyBQQ0UsIGJlZm9yZSBQQ0UgDQogICAgcmVqZWN0PEJSPmEgcmVx dWVzdCBiZWNhdXNlIG9mIGl0cyBjb21wdXRhdGlvbiBjYXBhYmlsaXRpZXMgLCBpdCBjYW4gZ2V0 IHRoZSANCiAgICBhcHByb3ByaWF0ZSBvbmUgYW5kIDxCUj5yZXR1cm4gaXQgdG8gUENDLiBpZiBz byAsYXQgYW55IHRpbWUgLHRoZSBQQ0MgbmVlZCANCiAgICBub3QgdG8ga25vdyB0aGUgZGV0YWls ZWQgPEJSPmNhcGFiaWxpdGllcyxrbm93aW5nIG9ubHkgZ2VuZXJpYyBQQ0UgDQogICAgY2FwYWJp bGl0aWVzIGlzIGVub3VnaCBmb3IgUENDLjwvRElWPg0KICAgIDxESVY+Q291bGQgdGhpcyBiZSZu YnNwOyZuYnNwO2Fub3RoZXIgY2hvaXNlPzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQog ICAgPERJVj5UaGFua3MuPC9ESVY+DQogICAgPERJVj5aaGFuZzwvRElWPg0KICAgIDxESVY+Jm5i c3A7PC9ESVY+DQogICAgPERJVj48QlI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8QlI+ RnJvbTogTEUgUk9VWCBKZWFuLUxvdWlzIA0KICAgIFJELUNPUkUtTEFOIDxCUj5UbzogPEEgaHJl Zj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9BPiA8QlI+U2VudDogDQogICAg TW9uZGF5LCBBcHJpbCAxOCwgMjAwNSA1OjAyIFBNPEJSPlN1YmplY3Q6IFtQY2VdIFdHIGZlZWRi YWNrIHJlcXVpcmVkIG9uIFBDRSANCiAgICBDYXBhYmlsaXR5IERpc2NvdmVyeTwvRElWPg0KICAg IDxESVYgYWxpZ249bGVmdD4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxCUj5IaSBhbGwsIDwvRElW Pg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj5UaGVyZSBoYXMgYmVlbiBzZXZlcmFs IGRpc2N1c3Npb25zIHdpdGhpbiB0aGUgUENFIGNvbSBEZXNpZ24gVGVhbSBhbmQgDQogICAgYW1v bmcgUENFIGRpc2NvdmVyeSByZXF1aXJlbWVudHMgY28tYXV0aG9ycywgcmVnYXJkaW5nIGR5bmFt aWMgZGlzY292ZXJ5IG9mIA0KICAgIFBDRSBjYXBhYmlsaXRpZXMuIDwvRElWPg0KICAgIDxESVY+ Jm5ic3A7PC9ESVY+DQogICAgPERJVj5PbmNlIHdlIGFncmVlIHRoYXQgdGhlcmUgaXMgYSBuZWVk IGZvciBkeW5hbWljIFBDRSBjYXBhYmlsaXR5IA0KICAgIGRpc2NvdmVyeSwgdGhlbiBpdCBhcHBl YXJzIHRoYXQgdGhlcmUgYXJlIHRocmVlIG9wdGlvbnM6IDwvRElWPg0KICAgIDxESVY+Jm5ic3A7 PC9ESVY+DQogICAgPERJVj5PcHRpb24gMTogQSBzaW5nbGUgc3BlY2lmaWMgUENFIGRpc2NvdmVy eSBtZWNoYW5pc20gaXMgdXNlZCB0byBkaXNjb3ZlciANCiAgICBhbGwgUENFIGNhcGFiaWxpdGll cyAoYXMgY3VycmVudGx5IHJlcXVpcmVkIGluIHRoZSBQQ0UgZGlzY292ZXJ5IA0KICAgIHJlcXVp cmVtZW50cyBJLUQgPEEgDQogICAgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtbGVyb3V4LXBjZS1kaXNjb3ZlcnktcmVxcy0wMC50eHQiPmh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxlcm91eC1wY2UtZGlzY292ZXJ5LXJlcXMt MDAudHh0PC9BPikuPC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPk9wdGlv biAyOiBBbGwgUENFIGNhcGFiaWxpdGllcyBhcmUgZGlzY292ZXJlZCB0aHJvdWdoIGFkZGVkIA0K ICAgIGZ1bmN0aW9uYWxpdHkgaW4gdGhlIFBDRSBjb21tdW5pY2F0aW9uIHByb3RvY29sICg8QSAN CiAgICBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hc2gt cGNlLWNvbW0tcHJvdG9jb2wtZ2VuLXJlcXMtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1hc2gtcGNlLWNvbW0tcHJvdG9jb2wtZ2VuLXJlcXMtMDAudHh0 PC9BPikuPC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPk9wdGlvbiAzOiBE aXNjb3Zlcnkgb2Ygc29tZSBnZW5lcmljIFBDRSBjYXBhYmlsaXRpZXMgKGNvbXB1dGF0aW9uIA0K ICAgIGRvbWFpbiwgc2NvcGUuLi4pIGlzIGRvbmUgYnkgdGhlIFBDRSBkaXNjb3ZlcnkgbWVjaGFu aXNtIGFuZCBkaXNjb3Zlcnkgb2YgDQogICAgZGV0YWlsZWQgY2FwYWJpbGl0aWVzIChlLmcuIHR5 cGUgb2YgY29uc3RyYWludHMgc3VwcG9ydGVkLi4uKSByZWxpZXMgb24gdGhlIA0KICAgIFBDRSBj b21tdW5pY2F0aW9uIHByb3RvY29sLjwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAg PERJVj5JbiAxKSBzaW5jZSBQQ0Mga25vd3MgYWxsIFBDRSBjYXBhYmlsaXRpZXMsIGl0IGlzIHRo ZSByZXBvbnNpYmlsaXR5IG9mIA0KICAgIHRoZSBQQ0MgdG8gc2VsZWN0IHRoZSBhcHByb3ByaWF0 ZSBQQ0UgZm9yIGEgcGFydGljdWxhciBwYXRoIGNvbXB1dGF0aW9uLiBTbywgDQogICAgbm8gY2Fw YWJpbGl0eS1yZWxhdGVkIHJlcXVlc3QgcGFyYW1ldGVycyBhcmUgbmVlZGVkIGluIHRoZSBjb21t dW5pY2F0aW9uIA0KICAgIHByb3RvY29sLCBzaW5jZSB0aGUgUENDIGFscmVheSBrbm93cyB3aGF0 IGlzIGV4cGVjdGVkIGZyb20gdGhlIFBDRS48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0K ICAgIDxESVY+SW4gMykgUENDIGtub3dzIGNlcnRhaW4gYmFzaWMgY2FwYWJpbGl0aWVzLCBidXQg Zm9yIHRoZSBjYXBhYmlsaXRpZXMgDQogICAgdGhhdCBpdCBpcyB1bmF3YXJlIG9mLCBpdCBtYXkg cmVxdWVzdCBzcGVjaWZpYyBwYXJhbWV0ZXJzIGluIHRoZSANCiAgICBjb21tdW5pY2F0aW9uIHBy b3RvY29sIHdoZW4gYSBwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3QgaXMgbWFkZSB0byB0aGUgUENF LiANCiAgICBJZiB0aGUgUENFIGlzIG5vdCBjYXBhYmxlIG9mIHRoZSByZXF1ZXN0ZWQgcGFyYW10 ZXJzLCB0aGVuIGFwcHJvcHJpYXRlIA0KICAgIGZhaWx1cmUgaXMgcmVwb3J0ZWQuPC9ESVY+DQog ICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPk5vdGUgdGhhdCB0aGlzIGRvZXMgbm90IHRh a2UgaW50byBhY2NvdW50IGRpc2NvdmVyeSBvZiBQQ0UgbG9jYXRpb24sIA0KICAgIHRoYXQgY2Fu IGJlIGRvbmUgZWl0aGVyIHN0YXRpY2FsbHkgb3IgZHluYW1pY2FsbHkgdGhyb3VnaCBmdW5jdGlv bmFsaXR5IGluIA0KICAgIHRoZSBQQ0UgZGlzY292ZXJ5IG1lY2hhbmlzbSAoaGVyZSB0aGUgUENF IGNvbW11bmljYXRpb24gcHJvdG9jb2wgY2Fubm90IA0KICAgIGhlbHApLiZuYnNwOyA8L0RJVj4N CiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Tm90ZSBhbHNvIHRoYXQgUENFIGNhcGFi aWxpdGllcyBjb3VsZCBvZiBjb3Vyc2UgYmUgY29uZmlndXJlZCANCiAgICBzdGF0aWNhbGx5IGJ1 dCB0aGlzIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkaXNjdXNzaW9uIGZvY3VzZWQgb24g DQogICAgZHluYW1pYyBjYXBhYmlsaXR5IGRpc2NvdmVyeS48L0RJVj4NCiAgICA8RElWPiZuYnNw OzwvRElWPg0KICAgIDxESVY+V0cgZmVlZGJhY2sgb24gdGhpcyB0b3BpYyB3b3VsZCBiZSBoaWdo bHkgZGVzaXJlZC4gPEJSPlBsZWFzZSBnaXZlIHVzIA0KICAgIHlvdXIgY29tbWVudHMgYW5kIHBy ZWZlcmVuY2VzIHJlZ2FyZGluZyB0aGVzZSB0aHJlZSBvcHRpb25zLiA8L0RJVj4NCiAgICA8RElW PiZuYnNwOzwvRElWPg0KICAgIDxESVY+SkwgPC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4N CiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4m bmJzcDs8L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEJSPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxC Uj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5QY2Ug bWFpbGluZyANCiAgICBsaXN0PEJSPjxBIGhyZWY9Im1haWx0bzpQY2VAbGlzdHMuaWV0Zi5vcmci PlBjZUBsaXN0cy5pZXRmLm9yZzwvQT48QlI+PEEgDQogICAgaHJlZj0iaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wY2U8L0E+PEJSPjwvRElWPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9C T0RZPjwvSFRNTD4NCg== --Boundary_(ID_Q8E2RV9Dw+tfw5z49lt8lw)-- --===============0445239956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0445239956==-- From pce-bounces@lists.ietf.org Thu May 12 18:20:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWM2f-0000U3-BX; Thu, 12 May 2005 18:20:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWM2d-0000Tv-3A for pce@megatron.ietf.org; Thu, 12 May 2005 18:20:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15358 for ; Thu, 12 May 2005 18:20:24 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWMIQ-0007tW-7C for pce@ietf.org; Thu, 12 May 2005 18:36:47 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 12 May 2005 18:35:20 -0400 X-IronPort-AV: i="3.93,101,1115006400"; d="scan'208"; a="49108628:sNHT26914924" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4CMKAnM013922; Thu, 12 May 2005 18:20:14 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 18:20:12 -0400 Received: from [192.168.1.101] ([10.86.242.61]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 18:20:11 -0400 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 12 May 2005 18:20:23 -0400 To: ALABS Ash Gerald R ((Jerry)) , LE ROUX Jean-Louis RD-CORE-LAN X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 12 May 2005 22:20:11.0334 (UTC) FILETIME=[C3239660:01C55740] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: [Pce] New Working Group document: draft-ash-pce-comm-protocol-gen-reqs-01.txt -> draft-ietf-pce-comm-protocol-gen-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Thanks to the DT for the hard work to produce this ID and having incorporated the various comments received so far. Thanks to re-publish as a PCE WG with updated date, name (+ changes to pass idnits script). Then, thanks to address any potential remaining comments. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon May 16 15:42:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlUI-0007ox-IB; Mon, 16 May 2005 15:42:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlUD-0007oD-V4; Mon, 16 May 2005 15:42:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00455; Mon, 16 May 2005 15:42:44 -0400 (EDT) Message-Id: <200505161942.PAA00455@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 16 May 2005 15:42:43 -0400 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --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 : PCE Communication Protocol Generic Requirements Author(s) : J. Ash, et al. Filename : draft-ietf-pce-comm-protocol-gen-reqs-00.txt Pages : 15 Date : 2005-5-16 Constraint-based path computation is a fundamental building block for traffic engineering systems such as multiprotocol label switching (MPLS) and generalized multiprotocol label switching (GMPLS) networks. Path computation in large, multi-domain or multi-layer networks is highly complex and may require special computational components and cooperation between the different network domains. There are multiple components in the Path Computation Element (PCE)- based path computation model, including PCE discovery and the PCE communication protocol. The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to PCEs. This document specifies generic requirements for a communication protocol between PCCs and PCEs, and between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-comm-protocol-gen-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-16152107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-comm-protocol-gen-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-16152107.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue May 17 05:25:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXyKa-0002vl-3G; Tue, 17 May 2005 05:25:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXyKY-0002vf-Cq for pce@megatron.ietf.org; Tue, 17 May 2005 05:25:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27167 for ; Tue, 17 May 2005 05:25:35 -0400 (EDT) Received: from oceanus.uk.clara.net ([80.168.70.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXybE-0001Hi-GE for pce@ietf.org; Tue, 17 May 2005 05:42:55 -0400 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1DXyKT-000AAD-Si; Tue, 17 May 2005 10:25:33 +0100 From: "Adrian Farrel" To: pce@ietf.org Date: Tue, 17 May 2005 10:25:32 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.205.25 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: sob@harvard.edu Subject: [Pce] Proposed response liaison to ITU-T Study Group 15 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org All, We owe a response to the liaison received in April from the ITU-T SG15. I propose the following. Please send your comments ASAP. Thanks, Adrian === To: Hing-Kam Lam, Rapporteur Q14/15 Malcolm Betts, Rapporteur Q12/15 Jerry Shrimpton, Rapporteur Q6/15 From: Adrian Farrel and JP Vasseur, co-chairs IETF PCE working group Cc: Alex Zinin and JP Vasseur, IETF Routing Area Directors Subject: Response Liaison Statement on the PCE Working group For: Action Deadline: July 30th 2005 The IETF's PCE Working Group would like to thank Questions 6, 12 and 14 of ITU-T Study Group 15 for their response liaison on the PCE working group. We welcome the prospect of cooperation between our organisations on this subject. We note your reference to Recommendation G.8080 and observe that there is, indeed, mention of the 'Route Table Query interface' that is used to allow a Signaling Controller to resolve an 'unresolved portion of the route.' Nevertheless, our reading of G.8080 is that the 'Route Table Query interface' exists between the Signaling Controller and the Routing Controller. If this is the case, it does not match the architectural model that we are proposing within the PCE working group. That is, we are making a distinction between the distribution and maintenance of TE routing information by the Routing Controller, and the computation of paths as performed by the Path Computation Element. Thus, in the PCE architecture, there may be a physical separation between the Routing Controller responsible for the routing-plane management of a transport entity, and the PCE responsible for satisfying Path Computation Requests issued by the Signaling Controller responsible for the signaling-plane management of the transport entity. This means that we are implying a functional separation between the items listed at the head of section 7.3.2 of G.8080 where such a separation is not possible within the ASON architecture as currently stated. If we have misunderstood the architecture as stated in G.8080 we would appreciate clarification from you. In any case, we would welcome your review and comments on our architecture draft which can be found at http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-00.txt Question 6 asked a specific question about the objective metrics referred to in the PCE charter... > Q.6/15 (Characteristics of optical systems for terrestrial transport > networks) noted that your charter contains the following item: > "- Definition of objective metrics to evaluate various criteria such as > the measurement of path quality, response time, robustness and scalability > of path computation models." > > Could you please clarify the meaning of "path quality" in the above > definition? If this includes optical monitoring aspects, please be aware > that ITU-T Q.6/15 has developed a Recommendation, G.697, Optical > monitoring for DWDM systems which may be of interest to the PCE working > group. This Recommendation is currently in force. Path quality in this context is intended to describe what is sometimes termed the 'optimality' of the path ('route' in G.8080 terminology). Measures of path quality reflect the ability of a PCE model to deliver a path that satisfies the constraints specified by the requesting client. One such quality might be 'shortest path', and it should be clear that once Routing Areas or Layered Networks are in use, different computation models will have different abilities to compute shortest paths. Thus, there is no intention to measure the active quality of the 'path' within the data plane: This is out side the scope of the PCE working group. Note that there is also no intention to measure the effectiveness of the algorithms in use, but rather the likely ability of a particular interaction between PCEs to produce an adequate path. Your liaison goes on to ask a further question about the intentions of the PCE working group with respect to optical path quality. > In addition, we would appreciate a better understanding of whether the PCE > working group will study mechanisms by which optical path quality can be > calculated or only mechanisms for communicating the results of such > calculations. We assume that here, too, you are refering the quality parameters of an established optical trail, and not to the quality of the computed path as expressed above. The PCE working group is limited to the architectural models for computation of paths ('routes') through networks, and will not examine the measurement of optical characteristics. Note, however, that path computation as applied to GMPLS systems falls within the scope of the PCE working group. It is likely that future GMPLS control planes will require to compute paths bearing in mind optical constraints such as (but not limited to) wavelength continuity, dispersion characteristics, etc. In these cases, it will possibly be necessary for some optical characteristic information to be gathered from the data plane, and distributed within the routing plane. Nevertheless, these two functions will remain outside the scope of the PCE working group. Anyone interested in discussing the work of the PCE working group further is invited to join the PCE mailing list. Details can be found at http://www.ietf.org/html.charters/pce-charter.html Best regards, Adrian Farrel and JP Vasseur _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue May 17 11:15:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY3nZ-0001QU-68; Tue, 17 May 2005 11:15:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY3nV-0001QP-FI for pce@megatron.ietf.org; Tue, 17 May 2005 11:15:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05184 for ; Tue, 17 May 2005 11:15:50 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DY44F-0004la-PI for pce@ietf.org; Tue, 17 May 2005 11:33:13 -0400 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1116342941!686314!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.69] Received: (qmail 15788 invoked from network); 17 May 2005 15:15:41 -0000 Received: from almso1.att.com (HELO almso1.proxy.att.com) (192.128.167.69) by server-3.tower-121.messagelabs.com with SMTP; 17 May 2005 15:15:41 -0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso1.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j4HFEhpO010021 for ; Tue, 17 May 2005 11:15:40 -0400 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh5i.attrh.att.com (7.2.052) id 428773740004ECF4; Tue, 17 May 2005 11:15:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Proposed response liaison to ITU-T Study Group 15 Date: Tue, 17 May 2005 10:15:39 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF09ABDB28@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Pce] Proposed response liaison to ITU-T Study Group 15 Thread-Index: AcVawpd3IeU5dlzFSwWQ9pXoxi4uHgALoQvA From: "Brungard, Deborah A, ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: quoted-printable Cc: sob@harvard.edu X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Looks good Adrian. Just a minor suggestion of wording in the third paragraph, "is not possible within the ASON architecture" -> "is not recognized within the..". As you know, the SG15 meeting is on-going. If you send it by the end of this week (cc'd to the Rapporteurs), if it does not make the agenda, it will at least get visibility at the meeting. On the paragraph referring to future GMPLS control plane work, you may want to include reference to initial work by the ipo group and the completion of RFC4054 as this is of interest to Q6/15. Regards, Deborah -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, May 17, 2005 5:26 AM To: pce@ietf.org Cc: sob@harvard.edu Subject: [Pce] Proposed response liaison to ITU-T Study Group 15 All,=20 We owe a response to the liaison received in April from the ITU-T SG15.=20 I propose the following. Please send your comments ASAP.=20 Thanks, Adrian =3D=3D=3D To: Hing-Kam Lam, Rapporteur Q14/15 Malcolm Betts, Rapporteur Q12/15 Jerry Shrimpton, Rapporteur Q6/15 From: Adrian Farrel and JP Vasseur, co-chairs IETF PCE working group Cc: Alex Zinin and JP Vasseur, IETF Routing Area Directors Subject: Response Liaison Statement on the PCE Working group For: Action Deadline: July 30th 2005=20 The IETF's PCE Working Group would like to thank Questions 6, 12 and 14 of=20 ITU-T Study Group 15 for their response liaison on the PCE working group. We=20 welcome the prospect of cooperation between our organisations on this=20 subject.=20 We note your reference to Recommendation G.8080 and observe that there is,=20 indeed, mention of the 'Route Table Query interface' that is used to allow a=20 Signaling Controller to resolve an 'unresolved portion of the route.'=20 Nevertheless, our reading of G.8080 is that the 'Route Table Query=20 interface' exists between the Signaling Controller and the Routing=20 Controller. If this is the case, it does not match the architectural model=20 that we are proposing within the PCE working group. That is, we are making a=20 distinction between the distribution and maintenance of TE routing=20 information by the Routing Controller, and the computation of paths as=20 performed by the Path Computation Element. Thus, in the PCE architecture,=20 there may be a physical separation between the Routing Controller=20 responsible for the routing-plane management of a transport entity, and the=20 PCE responsible for satisfying Path Computation Requests issued by the=20 Signaling Controller responsible for the signaling-plane management of the=20 transport entity. This means that we are implying a functional separation=20 between the items listed at the head of section 7.3.2 of G.8080 where such a=20 separation is not possible within the ASON architecture as currently stated.=20 If we have misunderstood the architecture as stated in G.8080 we would=20 appreciate clarification from you.=20 In any case, we would welcome your review and comments on our architecture=20 draft which can be found at=20 http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-00.txt=20 Question 6 asked a specific question about the objective metrics referred to=20 in the PCE charter...=20 > Q.6/15 (Characteristics of optical systems for terrestrial transport > networks) noted that your charter contains the following item: > "- Definition of objective metrics to evaluate various criteria such as > the measurement of path quality, response time, robustness and scalability > of path computation models."=20 >=20 > Could you please clarify the meaning of "path quality" in the above > definition? If this includes optical monitoring aspects, please be aware > that ITU-T Q.6/15 has developed a Recommendation, G.697, Optical > monitoring for DWDM systems which may be of interest to the PCE working > group. This Recommendation is currently in force. Path quality in this context is intended to describe what is sometimes=20 termed the 'optimality' of the path ('route' in G.8080 terminology).=20 Measures of path quality reflect the ability of a PCE model to deliver a path that satisfies the constraints specified by the requesting client. One=20 such quality might be 'shortest path', and it should be clear that once=20 Routing Areas or Layered Networks are in use, different computation models=20 will have different abilities to compute shortest paths.=20 Thus, there is no intention to measure the active quality of the 'path'=20 within the data plane: This is out side the scope of the PCE working group.=20 Note that there is also no intention to measure the effectiveness of the algorithms in use, but rather the likely ability of a particular interaction=20 between PCEs to produce an adequate path.=20 Your liaison goes on to ask a further question about the intentions of the=20 PCE working group with respect to optical path quality.=20 > In addition, we would appreciate a better understanding of whether the PCE > working group will study mechanisms by which optical path quality can be > calculated or only mechanisms for communicating the results of such > calculations. We assume that here, too, you are refering the quality parameters of an=20 established optical trail, and not to the quality of the computed path as=20 expressed above. The PCE working group is limited to the architectural=20 models for computation of paths ('routes') through networks, and will not=20 examine the measurement of optical characteristics.=20 Note, however, that path computation as applied to GMPLS systems falls=20 within the scope of the PCE working group. It is likely that future GMPLS=20 control planes will require to compute paths bearing in mind optical=20 constraints such as (but not limited to) wavelength continuity, dispersion=20 characteristics, etc. In these cases, it will possibly be necessary for some=20 optical characteristic information to be gathered from the data plane, and=20 distributed within the routing plane. Nevertheless, these two functions will=20 remain outside the scope of the PCE working group.=20 Anyone interested in discussing the work of the PCE working group further is=20 invited to join the PCE mailing list. Details can be found at=20 http://www.ietf.org/html.charters/pce-charter.html=20 Best regards, Adrian Farrel and JP Vasseur=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue May 17 12:46:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5Cu-0006Tb-Au; Tue, 17 May 2005 12:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5Cs-0006TV-IN for pce@megatron.ietf.org; Tue, 17 May 2005 12:46:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14184 for ; Tue, 17 May 2005 12:46:06 -0400 (EDT) Received: from mail123.messagelabs.com ([85.158.136.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DY5Tc-0001Nm-8D for pce@ietf.org; Tue, 17 May 2005 13:03:30 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-11.tower-123.messagelabs.com!1116348356!1014658!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.134.71] Received: (qmail 20145 invoked from network); 17 May 2005 16:45:56 -0000 Received: from kcmso2.att.com (HELO kcmso2.proxy.att.com) (192.128.134.71) by server-11.tower-123.messagelabs.com with SMTP; 17 May 2005 16:45:56 -0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j4HGh108017604 for ; Tue, 17 May 2005 11:45:55 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.2.052) id 4287737400055C27; Tue, 17 May 2005 12:45:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Proposed response liaison to ITU-T Study Group 15 Date: Tue, 17 May 2005 11:45:54 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE5C1@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Proposed response liaison to ITU-T Study Group 15 Thread-Index: AcVawpevoE7nlk4wTheNrpJipknPVQAO4skw From: "Ash, Gerald R \(Jerry\), ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: sob@harvard.edu X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Adrian, The liaison looks good. Regarding: > > Q.6/15 (Characteristics of optical systems for terrestrial transport > > networks) noted that your charter contains the following item: > > "- Definition of objective metrics to evaluate various criteria such > > as the measurement of path quality, response time, robustness and=20 > > scalability of path computation models."=20 > >=20 > > Could you please clarify the meaning of "path quality" in the above > > definition? If this includes optical monitoring aspects, please be > > aware that ITU-T Q.6/15 has developed a Recommendation, G.697, > > Optical monitoring for DWDM systems which may be of interest to the > > PCE working group. This Recommendation is currently in force. =20 > Path quality in this context is intended to describe what is=20 > sometimes termed the 'optimality' of the path ('route' in G.8080 > terminology). Measures of path quality reflect the ability of a PCE > model to deliver a path that satisfies the constraints specified by > the requesting client. One such quality might be 'shortest path', > and it should be clear that once Routing Areas or Layered Networks > are in use, different computation models will have different > abilities to compute shortest paths.=20 >=20 > Thus, there is no intention to measure the active quality of=20 > the 'path' within the data plane: This is *outside* the scope of > the PCE working group.=20 Agreed. > Note that there is also no intention to measure the effectiveness > of the algorithms in use, but rather the likely ability of a=20 > particular interaction between PCEs to produce an adequate path. I'm not sure what this sentence means. There is an intention to control the effectiveness of the algorithms, as stated in Section 6.1.1 of http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-00.txt: "The path request message MUST support the ability to prefer/customize various path computation objective functions, policies and optimization criteria. For example, a PCC may be aware of and would like to choose from among various objective functions that a PCE may offer, and the PCE communication protocol SHOULD allow this to be specified per path computation request." Perhaps the comment could be rephrased and/or clarified to express what is done rather than what isn't done. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue May 17 16:33:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY8lB-0002G9-RC; Tue, 17 May 2005 16:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY8l7-0002C4-UO for pce@megatron.ietf.org; Tue, 17 May 2005 16:33:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15590 for ; Tue, 17 May 2005 16:33:42 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY8xo-0008Q6-0L for pce@ietf.org; Tue, 17 May 2005 16:46:53 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 17 May 2005 16:29:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4HKSunc000419 for ; Tue, 17 May 2005 16:29:18 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 16:29:17 -0400 Received: from [161.44.83.195] ([161.44.83.195]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 16:29:17 -0400 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <1a2064e640c73ab57ae7f0859fc8dac6@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: pce@ietf.org From: JP Vasseur Date: Tue, 17 May 2005 16:29:31 -0400 X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 17 May 2005 20:29:17.0690 (UTC) FILETIME=[1952D5A0:01C55B1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Another Milestone X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Dear WG, Just to mention that we just hit another WG Milestone: http://www.ietf.org/html.charters/pce-charter.html JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 19 03:25:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYfPm-0004jP-Un; Thu, 19 May 2005 03:25:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYfPl-0004ij-EO for pce@megatron.ietf.org; Thu, 19 May 2005 03:25:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29253 for ; Thu, 19 May 2005 03:25:51 -0400 (EDT) Received: from oceanus.uk.clara.net ([80.168.70.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYfgr-0008LR-Ry for pce@ietf.org; Thu, 19 May 2005 03:43:34 -0400 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1DYfPc-0004jD-2f; Thu, 19 May 2005 08:25:44 +0100 From: "Adrian Farrel" To: pce@ietf.org Date: Thu, 19 May 2005 08:25:43 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.205.50 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Updated proposed response liaison to ITU-T Study Group 15 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Thanks for comments on and off the list. Here is an update to the proposal. Final comments soon, please. Thanks, Adrian ==== To: Hing-Kam Lam, Rapporteur Q14/15 Malcolm Betts, Rapporteur Q12/15 Jerry Shrimpton, Rapporteur Q6/15 From: Adrian Farrel and JP Vasseur, co-chairs IETF PCE working group Cc: Alex Zinin and JP Vasseur, IETF Routing Area Directors Subject: Response Liaison Statement on the PCE Working group For: Action Deadline: July 30th 2005 The IETF's PCE Working Group would like to thank Questions 6, 12 and 14 of ITU-T Study Group 15 for their response liaison on the PCE working group. We welcome the prospect of cooperation between our organisations on this subject. We note your reference to Recommendation G.8080 and observe that there is, indeed, mention of the 'Route Table Query interface' that is used to allow a Signaling Controller to resolve an 'unresolved portion of the route.' Nevertheless, our reading of G.8080 is that the 'Route Table Query interface' exists between the Signaling Controller and the Routing Controller. If this is the case, it does not match the architectural model that we are proposing within the PCE working group. That is, we are making a distinction between the distribution and maintenance of TE routing information by the Routing Controller, and the computation of paths as performed by the Path Computation Element. Thus, in the PCE architecture, there may be a physical separation between the Routing Controller responsible for the routing-plane management of a transport entity (that is the RC entity responsible for announcing local topology information generated by the NE), and the PCE responsible for satisfying Path Computation Requests issued by the Signaling Controller responsible for the signaling-plane management of the transport entity. This means that we are implying a functional separation between the items listed at the head of section 7.3.2 of G.8080 where such a separation is not recognized within the ASON architecture as currently stated. If we have misunderstood the architecture as stated in G.8080 we would appreciate clarification from you. In any case, we would welcome your review and comments on our architecture draft which can be found at http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-00.txt Question 6 asked a specific question about the objective metrics referred to in the PCE charter... > Q.6/15 (Characteristics of optical systems for terrestrial transport > networks) noted that your charter contains the following item: > "- Definition of objective metrics to evaluate various criteria such as > the measurement of path quality, response time, robustness and scalability > of path computation models." > > Could you please clarify the meaning of "path quality" in the above > definition? If this includes optical monitoring aspects, please be aware > that ITU-T Q.6/15 has developed a Recommendation, G.697, Optical > monitoring for DWDM systems which may be of interest to the PCE working > group. This Recommendation is currently in force. Path quality in this context is intended to describe what is sometimes termed the 'optimality' of the path ('route' in G.8080 terminology). Measures of path quality reflect the ability of a PCE model to deliver a path that satisfies the constraints specified by the requesting client. One such quality might be 'shortest path', and it should be clear that once Routing Areas or Layered Networks are in use, different computation models will have different abilities to compute shortest paths. Thus, there is no intention to measure the active quality of the 'path' within the data plane: This is out side the scope of the PCE working group. Note that there is also no intention to measure the effectiveness of the algorithms in use (although there is a clear requirement to control the effectiveness according to the requirements of the requester), but rather to measure the likely ability of a particular interaction between PCEs to produce an adequate path. Your liaison goes on to ask a further question about the intentions of the PCE working group with respect to optical path quality. > In addition, we would appreciate a better understanding of whether the PCE > working group will study mechanisms by which optical path quality can be > calculated or only mechanisms for communicating the results of such > calculations. We assume that here, too, you are refering the quality parameters of an established optical trail, and not to the quality of the computed path as expressed above. The PCE working group is limited to the architectural models for computation of paths ('routes') through networks, and will not examine the measurement of optical characteristics. Note, however, that path computation as applied to GMPLS systems falls within the scope of the PCE working group. It is likely that future GMPLS control planes will require to compute paths bearing in mind optical constraints such as (but not limited to) wavelength continuity, dispersion characteristics, etc. In these cases, it will possibly be necessary for some optical characteristic information to be gathered from the data plane, and distributed within the routing plane. These two functions will remain outside the scope of the PCE working group, but may be the responsiblity of other IETF working groups. In this regard, Quesiton 6 may be interested in a new RFC that has been published: RFC 4054 is titled "Impairments and Other Constraints on Optical Layer Routing" and can be found at http://www.ietf.org/rfc/rfc4054.txt Anyone interested in discussing the work of the PCE working group further is invited to join the PCE mailing list. Details can be found at http://www.ietf.org/html.charters/pce-charter.html Best regards, Adrian Farrel and JP Vasseur _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun May 22 07:41:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZopN-0002pS-HF; Sun, 22 May 2005 07:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZogz-0001eW-Cb for pce@megatron.ietf.org; Sun, 22 May 2005 07:32:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07572; Sun, 22 May 2005 07:32:22 -0400 (EDT) Received: from oceanus.uk.clara.net ([80.168.70.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZoyi-0006cD-E7; Sun, 22 May 2005 07:50:44 -0400 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1DZogn-0001QZ-Cw; Sun, 22 May 2005 12:32:13 +0100 From: "Adrian Farrel" To: hklam@lucent.com, betts01@nortel.com, shrimpton@worldnet.att.net Date: Sun, 22 May 2005 12:32:13 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.204.73 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 22 May 2005 07:41:04 -0400 Cc: fenner@research.att.com, Greg.Jones@itu.int, pce@ietf.org, statements@ietf.org, kireeti@juniper.net, sob@harvard.edu Subject: [Pce] Response Liaison Statement on the PCE Working group X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org To: Hing-Kam Lam, Rapporteur Q14/15 Malcolm Betts, Rapporteur Q12/15 Jerry Shrimpton, Rapporteur Q6/15 From: Adrian Farrel and JP Vasseur, co-chairs IETF PCE working group Cc: Alex Zinin and JP Vasseur, IETF Routing Area Directors Subject: Response Liaison Statement on the PCE Working group For: Action Deadline: July 30th 2005 The IETF's PCE Working Group would like to thank Questions 6, 12 and 14 of ITU-T Study Group 15 for their response liaison on the PCE working group. We welcome the prospect of cooperation between our organisations on this subject. Although this liaison may be too late for consideration in your current meeting, we hope that it may be circulated for information, perhaps as a WD, and considered more fully at later meetings. We note your reference to Recommendation G.8080 and observe that there is, indeed, mention of the 'Route Table Query interface' that is used to allow a Signaling Controller to resolve an 'unresolved portion of the route.' Nevertheless, our reading of G.8080 is that the 'Route Table Query interface' exists between the Signaling Controller and the Routing Controller. If this is the case, it does not match the architectural model that we are proposing within the PCE working group. That is, we are making a distinction between the distribution and maintenance of TE routing information by the Routing Controller, and the computation of paths as performed by the Path Computation Element. Thus, in the PCE architecture, there may be a physical separation between the Routing Controller responsible for the routing-plane management of a transport entity (that is the RC entity responsible for announcing local topology information generated by the NE), and the PCE responsible for satisfying Path Computation Requests issued by the Signaling Controller responsible for the signaling-plane management of the transport entity. This means that we are implying a functional separation between the items listed at the head of section 7.3.2 of G.8080 where such a separation is not recognized within the ASON architecture as currently stated. If we have misunderstood the architecture as stated in G.8080 we would appreciate clarification from you. In any case, we would welcome your review and comments on our architecture draft which can be found at http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-00.txt Question 6 asked a specific question about the objective metrics referred to in the PCE charter... > Q.6/15 (Characteristics of optical systems for terrestrial transport > networks) noted that your charter contains the following item: > "- Definition of objective metrics to evaluate various criteria such > as the measurement of path quality, response time, robustness and > scalability of path computation models." > > Could you please clarify the meaning of "path quality" in the above > definition? If this includes optical monitoring aspects, please be > aware that ITU-T Q.6/15 has developed a Recommendation, G.697, > Optical monitoring for DWDM systems which may be of interest to the > PCE working group. This Recommendation is currently in force. Path quality in this context is intended to describe what is sometimes termed the 'optimality' of the path ('route' in G.8080 terminology). Measures of path quality reflect the ability of a PCE model to deliver a path that satisfies the constraints specified by the requesting client. One such quality might be 'shortest path', and it should be clear that once Routing Areas or Layered Networks are in use, different computation models will have different abilities to compute shortest paths. Thus, there is no intention to measure the active quality of the 'path' within the data plane: This is out side the scope of the PCE working group. Note that there is also no intention to measure the effectiveness of the algorithms in use (although there is a clear requirement to control the effectiveness according to the requirements of the requester), but rather to measure the likely ability of a particular interaction between PCEs to produce an adequate path. Your liaison goes on to ask a further question about the intentions of the PCE working group with respect to optical path quality. > In addition, we would appreciate a better understanding of whether > the PCE working group will study mechanisms by which optical path > quality can be calculated or only mechanisms for communicating the > results of such calculations. We assume that here, too, you are refering the quality parameters of an established optical trail, and not to the quality of the computed path as expressed above. The PCE working group is limited to the architectural models for computation of paths ('routes') through networks, and will not examine the measurement of optical characteristics. Note, however, that path computation as applied to GMPLS systems falls within the scope of the PCE working group. It is likely that future GMPLS control planes will require to compute paths bearing in mind optical constraints such as (but not limited to) wavelength continuity, dispersion characteristics, etc. In these cases, it will possibly be necessary for some optical characteristic information to be gathered from the data plane, and distributed within the routing plane. These two functions will remain outside the scope of the PCE working group, but may be the responsiblity of other IETF working groups. In this regard, Quesiton 6 may be interested in a new RFC that has been published: RFC 4054 is titled "Impairments and Other Constraints on Optical Layer Routing" and can be found at http://www.ietf.org/rfc/rfc4054.txt Anyone interested in discussing the work of the PCE working group further is invited to join the PCE mailing list. Details can be found at http://www.ietf.org/html.charters/pce-charter.html Best regards, Adrian Farrel and JP Vasseur _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 26 11:42:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKUs-0001IO-8E; Thu, 26 May 2005 11:42:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKUp-0001GQ-UW for pce@megatron.ietf.org; Thu, 26 May 2005 11:42:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07260 for ; Thu, 26 May 2005 11:42:05 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbKnR-0003uO-Ag for pce@ietf.org; Thu, 26 May 2005 12:01:22 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 26 May 2005 11:41:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4QFfM5O003571; Thu, 26 May 2005 11:41:52 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 11:41:51 -0400 Received: from [192.168.1.102] ([10.86.242.40]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 11:41:50 -0400 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <108556c6a5673f958b5796db23c5bcac@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 26 May 2005 11:42:05 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 26 May 2005 15:41:51.0012 (UTC) FILETIME=[6F385E40:01C56209] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] WG feed-backs on PCEP X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Dear WG, A new ID has recently been posted (http://www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-00.txt) proposing a new PCE communication protocol. There are several aspects for which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to get your feed-backs (see section 6). Comments are also very welcome on the other parts of the ID of course. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 26 15:23:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbNxO-0005qU-SG; Thu, 26 May 2005 15:23:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbNxM-0005qM-Ez for pce@megatron.ietf.org; Thu, 26 May 2005 15:23:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23961 for ; Thu, 26 May 2005 15:23:46 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbOFz-0000ph-Aw for pce@ietf.org; Thu, 26 May 2005 15:43:05 -0400 Received: from ib (vpn15.atlanta.movaz.com [172.18.0.15]) by jera.movaz.com (Postfix) with SMTP id 503BF1672; Thu, 26 May 2005 15:23:35 -0400 (EDT) Message-ID: <004f01c56228$6a1f0980$6501a8c0@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" , References: <108556c6a5673f958b5796db23c5bcac@cisco.com> Subject: Re: [Pce] WG feed-backs on PCEP Date: Thu, 26 May 2005 15:23:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, I think that the draft is certainly a very good starting point. I have several comments. 1. Section 8.7 L (Link diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following REQUEST-ID objects MUST not have any link in common. N (Node diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following REQUEST-ID objects MUST not have any node in common. S (SRLG diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following REQUEST-ID objects MUST not share any SRLG (Shared Risk Link Group). I think a good idea would be to add one more flag: B (Best diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following REQUEST-ID objects MUST be best disjoint (have minimal number of SRLGs, nodes and links in common) . 2. Section 10.1 R bit: when the R bit of the REQUEST-ID object is set in a PCReq message, this indicates that the path computation request relates to the reoptimization of an existing TE LSP. In this case, the PCC MUST provide the complete or partial path by including an ERO object in the PCReq message so as to avoid double bandwidth counting. The ERO must be formed of strict hops only. It is possible that a PCC requires a path computation for MB4B modification of e2e or segment protected service. In order to avoid double bandwidth counting this would require specifying not one but several EROs (representing current working and all recovery LSPs), because newly computed paths can share resources with each of the existing paths. I think a good idea is to specify for such "sharables" a single special ERO that includes an unordered list of links that new path(s) is/are allowed to share resources with (similar to XRO) On more general note: 3. It looks like that the protocol is designed only for Shortest Path First computations. What if a PCC does not want a shortest path, rather, say, minimal delay path with a constraint on the path cost? How a PCC can specify different (possibly many) optimization criteria(s)? 4. How the protocol is expendable for incorporating new constraints? For instance, in some near future we will introduce Interface Adaptation Capabilities Descriptor TE link sub-TLV (necessary for multi-layer path computations). How path computation could be constrained to honor this information? I think it would a good idea to bind a constraint type with TE link sub-TLV type in an abstracted way, so that at least link level constraints could be easily added to the protocol 5. How a PCC can request computation of paths for several LSPs so that they could share backup resources? 6. How a PCC can request computation of paths for one or more services to be diverse (link-, node-, SRLG-, best-) from paths taken by existing LSPs (note that the latter may be explicitly provisioned rather than computed)? 7. Why the authors think that reusing of RSVP objects is a good idea? For instance, RSVP SESSION_ATTRIBUTES object has a field "Session Name". Do we really need it in the path computation request? Why not to introduce instead, say, a PATH_ATTRIBUTES object that will include only parameters (e.g. priorities) and flags (e.g. colors) that are needed for path computation? That's it for now, Igor ----- Original Message ----- From: "JP Vasseur" To: Sent: Thursday, May 26, 2005 11:42 AM Subject: [Pce] WG feed-backs on PCEP > Dear WG, > > A new ID has recently been posted > (http://www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-00.txt) > proposing a new PCE communication protocol. There are several aspects > for which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to > get your feed-backs (see section 6). Comments are also very welcome on > the other parts of the ID of course. > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 26 16:40:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbP9Z-00084j-KL; Thu, 26 May 2005 16:40:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbP9X-00084e-SB for pce@megatron.ietf.org; Thu, 26 May 2005 16:40:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10361 for ; Thu, 26 May 2005 16:40:25 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbPSC-00062x-Id for pce@ietf.org; Thu, 26 May 2005 16:59:45 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 26 May 2005 13:40:18 -0700 X-IronPort-AV: i="3.93,140,1115017200"; d="scan'208"; a="270151581:sNHT188909644" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4QKdala011030; Thu, 26 May 2005 16:40:14 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 16:40:04 -0400 Received: from [192.168.1.102] ([10.86.242.20]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 16:40:03 -0400 In-Reply-To: <004f01c56228$6a1f0980$6501a8c0@movaz.com> References: <108556c6a5673f958b5796db23c5bcac@cisco.com> <004f01c56228$6a1f0980$6501a8c0@movaz.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2086ac66157e2863b7836013c357bbb4@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] WG feed-backs on PCEP Date: Thu, 26 May 2005 16:40:18 -0400 To: "Igor Bryskin" X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 26 May 2005 20:40:03.0956 (UTC) FILETIME=[183EF340:01C56233] X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Igor, On May 26, 2005, at 3:23 PM, Igor Bryskin wrote: > Hi, > > > > I think that the draft is certainly a very good starting point. > > > > I have several comments. > thanks for these useful comments, see below > > > 1. Section 8.7 > > > > L (Link diverse) bit: when set, this indicates that the computed > paths corresponding to the requests specified by the following > REQUEST-ID objects MUST not have any link in common. N > (Node > diverse) bit: when set, this indicates that the computed paths > corresponding to the requests specified by the following > REQUEST-ID > objects MUST not have any node in common. S (SRLG > diverse) > bit: when set, this indicates that the computed paths > corresponding > to the requests specified by the following REQUEST-ID objects > MUST > not share any SRLG (Shared Risk Link Group). I think a good idea > would > be to add one more flag: > > > > B (Best diverse) bit: when set, this indicates that the computed > paths corresponding to the requests specified by the following > REQUEST-ID objects MUST be best disjoint (have minimal number of SRLGs, > nodes and links in common) . We can support this by mentioning some interest for less-constrained path (and let the PCE uses any relevant algo) but adding such bit would add more flexibility indeed. We could in fact have even more granularity: - minimize the number of network elements with fate sharing - minimize the number of elements in common across all the network elements with fate sharing > > 2. Section 10.1 > > > > R bit: when the R bit of the REQUEST-ID object is set in a PCReq > message, this indicates that the path computation request relates to > the reoptimization of an existing TE LSP. In this case, the PCC MUST > provide the complete or partial path by including an ERO object in > the PCReq message so as to avoid double bandwidth counting. The ERO > must be formed of strict hops only. > > It is possible that a PCC requires a path computation for MB4B > modification > of e2e or segment protected service. In order to avoid double bandwidth > counting this would require specifying not one but several EROs > (representing current working and all recovery LSPs), because newly > computed > paths can share resources with each of the existing paths. I think a > good > idea is to specify for such "sharables" a single special ERO that > includes > an unordered list of links that new path(s) is/are allowed to share > resources with (similar to XRO) > > Good point, thanks. Could easily be done with extension to the CVEC object. > > On more general note: > > > > 3. It looks like that the protocol is designed only > for > Shortest Path First computations. What if a PCC does not want a > shortest > path, rather, say, minimal delay path with a constraint on the path > cost? > How a PCC can specify different (possibly many) optimization > criteria(s)? > This is planned for the next revision: ability to specify the objective function - thanks. > 4. How the protocol is expendable for incorporating > new > constraints? For instance, in some near future we will introduce > Interface > Adaptation Capabilities Descriptor TE link sub-TLV (necessary for > multi-layer path computations). How path computation could be > constrained to > honor this information? I think it would a good idea to bind a > constraint > type with TE link sub-TLV type in an abstracted way, so that at least > link > level constraints could be easily added to the protocol Good comment, thanks. > > 5. How a PCC can request computation of paths for > several > LSPs so that they could share backup resources? > We could easily add a flag to the CVEC object to support 1:N protection. Let see if the WG thinks that this is a requirement ? May be listed as a requirement in the context of future application-specific ID. > 6. How a PCC can request computation of paths for > one or > more services to be diverse (link-, node-, SRLG-, best-) from paths > taken by > existing LSPs (note that the latter may be explicitly provisioned > rather > than computed)? > Same as above. > 7. Why the authors think that reusing of RSVP > objects is > a good idea? For instance, RSVP SESSION_ATTRIBUTES object has a field > "Session Name". Do we really need it in the path computation request? > Why > not to introduce instead, say, a PATH_ATTRIBUTES object that will > include > only parameters (e.g. priorities) and flags (e.g. colors) that are > needed > for path computation? > Ah I was expecting this comment ;-) Well, PCEP is in that respect really flexible. Just allow to reuse *some* RSVP objects when appropriate. In that particular context we could w/o any problem specify a new object minus this field but it really does not hurt to carry it, thus we just reuse this object. Conversely, in some other contexts, for instance the source and destination addresses, it is really more optimal to define a new object (END-POINTS) with two fields rather than using the SENDER-TEMPLATE and SESSION objects of course. Thanks for your comments. Any comment on the section 6 ? Cheers. JP. > > > That's it for now, > > > > Igor > > > > > > ----- Original Message ----- > > From: "JP Vasseur" > > To: > > Sent: Thursday, May 26, 2005 11:42 AM > > Subject: [Pce] WG feed-backs on PCEP > > > >> Dear WG, >> >> A new ID has recently been posted >> (http://www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-00.txt) >> proposing a new PCE communication protocol. There are several aspects >> for which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to >> get your feed-backs (see section 6). Comments are also very welcome on >> the other parts of the ID of course. >> >> Thanks. >> >> JP. >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri May 27 09:09:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeaZ-0002NW-V6; Fri, 27 May 2005 09:09:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeaY-0002NP-2Q for pce@megatron.ietf.org; Fri, 27 May 2005 09:09:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08839 for ; Fri, 27 May 2005 09:09:20 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbetL-0002Wa-0V for pce@ietf.org; Fri, 27 May 2005 09:28:48 -0400 Received: from ib (vpn12.atlanta.movaz.com [172.18.0.12]) by jera.movaz.com (Postfix) with SMTP id 909061733; Fri, 27 May 2005 09:09:06 -0400 (EDT) Message-ID: <003601c562bd$441bf0f0$6501a8c0@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" References: <108556c6a5673f958b5796db23c5bcac@cisco.com> <004f01c56228$6a1f0980$6501a8c0@movaz.com> <2086ac66157e2863b7836013c357bbb4@cisco.com> Subject: Re: [Pce] WG feed-backs on PCEP Date: Fri, 27 May 2005 09:09:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JP, > Any comment on the section 6 ? > 6. PCEP Finite State Machine (FSM) PCE Working Group feed-backs will be requested on the following items: - Is there a need for "open" and "close" messages? IB>> Have no strong opinion; - Is there a requirement for PCEP hello message that could be used for faster PCC/PCE liveness detection? (If yes, the hello frequency could be negotiated upon PCEP connection setup (via open messages)IB>> Have no strong opinion; - Is there a requirement for detailed capability discovery upon PCEP connection set up? IB>> Detailed capability discovery is necessary, however, IMHO it should be a part of separate (PCE discovery) protocolrather than PCEP.I believe that a PCE should advertise its presence and basic capability bits, and it should be a responsibility of PCC to establish a capability discovery session with the PCE and obtain (as well as subscribe to notifications on changes in future)all necessary detail information about PCE capabilities, resources, etcHave a great weekend,Igor _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri May 27 18:59:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbnnp-0002Ss-Dj; Fri, 27 May 2005 18:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbnno-0002Sl-CM for pce@megatron.ietf.org; Fri, 27 May 2005 18:59:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12703 for ; Fri, 27 May 2005 18:59:37 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbo6h-0004tY-A2 for pce@ietf.org; Fri, 27 May 2005 19:19:11 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 27 May 2005 15:59:30 -0700 X-IronPort-AV: i="3.93,147,1115017200"; d="scan'208"; a="639264362:sNHT29658404" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4RMwrmK007088 for ; Fri, 27 May 2005 15:59:28 -0700 (PDT) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 15:59:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] WG feed-backs on PCEP Date: Fri, 27 May 2005 15:59:27 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E2BC378@xmb-sjc-234.amer.cisco.com> Thread-Topic: [Pce] WG feed-backs on PCEP Thread-Index: AcViChUUpsQoEz59TVet8yfzdpMAzwA891sg From: "Dean Cheng \(dcheng\)" To: "Jean Philippe Vasseur \(jvasseur\)" , X-OriginalArrivalTime: 27 May 2005 22:59:28.0005 (UTC) FILETIME=[BC054B50:01C5630F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP et al., My opinions on the items in the Section 6 are as follows: > - Is there a need for "open" and "close" messages? I don't think this is necessary, with reasons include: 1) It does not seem serve anything useful, but complicates the protocol a bit unnecessarily. 2) The PCEP runs on the top of TCP, there is already an equivalent=20 function for both "open" and "close", although a TCP session may carry a single or multiple PCEP sessions.=20 3) Each PCEP request has its own request ID along with a FSM that has been defined clearly. The PCReq actually serves the "open" function and the "close" function is implied by the response from the PCE (whatever its is). > - Is there a requirement for PCEP hello message that could be used > for faster PCC/PCE liveness detection? (If yes, the hello > frequency could be negotiated upon PCEP connection setup (via > open messages) I don't think this is necessary. Since the PCEP runs on the top of TCP and=20 the transport layer protocol should take care of the liveness detection, and any improvement if needed, instead of protocols run above that. Another possible solution is (if concerned), the multi-hop BFD may be used here, between the PCE and PCC. =20 > - Is there a requirement for detailed capability discovery upon PCEP > connection set up?=20 I think the PCE discovery protocol should be used for passing information of PCE capability. The PCEP should contain enough code points to carry detailed capability for specific query/response, but in general is not encouraged to=20 be used for general discovery purpose. Thanks Dean=20 >-----Original Message----- >From: pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] On Behalf Of Jean Philippe=20 >Vasseur (jvasseur) >Sent: Thursday, May 26, 2005 8:42 AM >To: pce@ietf.org >Subject: [Pce] WG feed-backs on PCEP > >Dear WG, > >A new ID has recently been posted >(http://www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-00.txt) >proposing a new PCE communication protocol. There are several=20 >aspects for which Jean-Louis, Eiji, Alia, Arthi and myself=20 >would be happy to get your feed-backs (see section 6).=20 >Comments are also very welcome on the other parts of the ID of course. > >Thanks. > >JP. > >_______________________________________________ >Pce mailing list >Pce@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat May 28 22:35:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcDe3-00066F-H7; Sat, 28 May 2005 22:35:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcDe2-00066A-0D for pce@megatron.ietf.org; Sat, 28 May 2005 22:35:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20445 for ; Sat, 28 May 2005 22:35:15 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcDx9-0005ME-NH for pce@ietf.org; Sat, 28 May 2005 22:55:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 28 May 2005 22:35:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4T2Z64u000808; Sat, 28 May 2005 22:35:06 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 28 May 2005 22:35:06 -0400 Received: from [192.168.1.101] ([10.86.242.102]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 28 May 2005 22:35:05 -0400 In-Reply-To: <003601c562bd$441bf0f0$6501a8c0@movaz.com> References: <108556c6a5673f958b5796db23c5bcac@cisco.com> <004f01c56228$6a1f0980$6501a8c0@movaz.com> <2086ac66157e2863b7836013c357bbb4@cisco.com> <003601c562bd$441bf0f0$6501a8c0@movaz.com> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] WG feed-backs on PCEP Date: Sat, 28 May 2005 22:35:20 -0400 To: Igor Bryskin , pce@ietf.org X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 29 May 2005 02:35:05.0961 (UTC) FILETIME=[060E7590:01C563F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Igor, Thanks for your feed-backs. Opinions form others ? JP. On May 27, 2005, at 9:09 AM, Igor Bryskin wrote: > JP, > > >> Any comment on the section 6 ? >> >> > > > 6. PCEP Finite State Machine (FSM) > > PCE Working Group feed-backs will be requested on the following > items: > - Is there a need for "open" and "close" messages? IB>> Have no > strong opinion; > - Is there a requirement for PCEP hello message that could > be used > for faster PCC/PCE liveness detection? (If yes, the hello > frequency could be negotiated upon PCEP connection setup (via > open messages)IB>> Have no strong opinion; > - Is there a requirement for detailed capability discovery > upon PCEP > connection set up? IB>> Detailed capability discovery is > necessary, > however, IMHO it should be a part of separate (PCE discovery) > protocolrather > than PCEP.I believe that a PCE should advertise its presence and basic > capability bits, and it should be a responsibility of PCC to > establish a > capability discovery session with the PCE and obtain (as well as > subscribe > to notifications on changes in future)all necessary detail > information about > PCE capabilities, resources, etcHave a great weekend,Igor > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue May 31 04:54:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd2WI-0005jS-A6; Tue, 31 May 2005 04:54:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd2WG-0005c8-0c for pce@megatron.ietf.org; Tue, 31 May 2005 04:54:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18506 for ; Tue, 31 May 2005 04:54:38 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd2pk-0005Ob-IL for pce@ietf.org; Tue, 31 May 2005 05:14:54 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHC008BAJJN00@szxga01-in.huawei.com> for pce@ietf.org; Tue, 31 May 2005 16:57:23 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHC001VIJFI65@szxga01-in.huawei.com> for pce@ietf.org; Tue, 31 May 2005 16:57:23 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IHC0095DI0J6D@szxml01-in.huawei.com>; Tue, 31 May 2005 16:24:19 +0800 (CST) Date: Tue, 31 May 2005 15:53:33 +0800 From: Zhang Renhai Subject: Re: [Pce] WG feed-backs on PCEP To: JP Vasseur Message-id: <001501c565b5$e1f5de80$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <108556c6a5673f958b5796db23c5bcac@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7BIT Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, JP Sorry for the late reply. What is used to identify the PCEs, IP address? it should be better to give each PCE a sole ID, should a PCE have more than one interfaces connected to the network. In section 8.1, why OS, PR are defined to be two bits, according the usage, one bit is enough, are there some other thoughts on these definition? Section 9 only mentions the correlated request from the same LSR, but the request from different LSR may also be considered correlated, for example, the same source may be allocated by different PCEs at the same time to different PCCs. About section 6: hello message: this can be optional and can be decided by PCC when PCC requesting a computation, for example, an object can be defined that inclueds the interval and timeout value and inserted into the PCReq message, thus the hello message can be relative to PCReq message, if so, the hello message will have more meaning, for example, it can tell PCC how long the request will be served, this is especially useful when the PCReq is sent to multiple PCE. I think it is worst that PCE send the hello messages to all PCCs. detailed capability discovery: Before this is decided, all possible capabilities of PCE should be estimated, maybe this will be clear after this estimation.However, I have had some comments on this issue: PCEs learn of each other's detailed capabilitis if the discovery protocol can be used in PCE-PCE discovery, PCCs learn of generic capabilitis, this will facilitate PCCs to discovery PCEs. When the PCC's first request fails due to the bad selection of PCE based on the generic capability, the PCE determines the right PCE according to the request and the acknowledge of other PCEs' capabilities, and also can communicate the detailed capabilities of the right PCE though PCEP to the PCC. Regard, Zhang ----- Original Message ----- From: "JP Vasseur" To: Sent: Thursday, May 26, 2005 11:42 PM Subject: [Pce] WG feed-backs on PCEP > Dear WG, > > A new ID has recently been posted > (http://www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-00.txt) > proposing a new PCE communication protocol. There are several aspects > for which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to > get your feed-backs (see section 6). Comments are also very welcome on > the other parts of the ID of course. > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce