From pce-bounces@lists.ietf.org Wed Jun 01 14:20:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXp9-0000bS-C4; Wed, 01 Jun 2005 14:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXp7-0000bD-5J for pce@megatron.ietf.org; Wed, 01 Jun 2005 14:20:13 -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 OAA11932 for ; Wed, 1 Jun 2005 14:20: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 1DdY8z-0001y7-12 for pce@ietf.org; Wed, 01 Jun 2005 14:40:45 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 20:20:03 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE : [Pce] WG feed-backs on PCEP Date: Wed, 1 Jun 2005 20:20:02 +0200 Message-ID: Thread-Topic: [Pce] WG feed-backs on PCEP Thread-Index: AcVlvsdxd6Jx+GmVSPaF1A5aPiAouwBBaMAA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Zhang Renhai" , "JP Vasseur" X-OriginalArrivalTime: 01 Jun 2005 18:20:03.0776 (UTC) FILETIME=[87D3B400:01C566D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable 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 Zhang Thanks a lot for these useful comments. Please find below some inlined comments. Regards, JL >-----Message d'origine----- >De : pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] De la part de Zhang Renhai >Envoy=E9 : mardi 31 mai 2005 09:54 >=C0 : JP Vasseur >Cc : pce@ietf.org >Objet : Re: [Pce] WG feed-backs on PCEP > > >Hi, JP > Sorry for the late reply. > > What is used to identify the PCEs, IP address? it should be=20 >better to give each PCE a sole ID, should a PCE have more than=20 >one interfaces connected to the network. Right actually the PCE is identified by an IP address. For instance in case of a composite PCE, this could typically be a = loop-back address that is always reachable. We will clarify this point in next revision. > >In section 8.1, why OS, PR are defined to be two bits,=20 >according the usage, one bit is enough, are there some other=20 >thoughts on these definition? You are right, currently one bit would be enough.=20 We defined OS and PR fields with two bits to have flexibility for = further usages. > > Section 9 only mentions the correlated request from the same LSR, but=20 >the request from different LSR may also be considered=20 >correlated,=20 Such correlation of request sent by distinct PCCs would actually require = quite complex procedures...=20 And there is currently no specific requirement defined for such = function. Note that this first protocol version has been specified based on = generic requirements defined in the PCE communication requirement draft. = Our main objective here is to have a base spec and then work on = application specific pieces in separate documents. The multi-PCC request correlation procedure you mention, would have to = be addressed later, in a separate document, if it appears that there are = PCE applications requiring such feature. >for example, the same source may be allocated by=20 >different PCEs at the same time to different PCCs. > >About section 6: >hello message: this can be optional and can be decided by PCC=20 >when PCC requesting a computation, for example, an object can=20 >be defined that=20 >inclueds the interval and timeout value and inserted into the=20 >PCReq message, thus the hello message can be relative to PCReq=20 >message,=20 >if so, the hello message will have more meaning, for=20 >example, it can tell PCC how long the request will be served,=20 >this is especially useful when the PCReq is sent to multiple PCE.=20 Actually hello message exchange would just be a heart beat to check = PCC-PCE connectivity. Hence hello messages should not be relative to a = particular PCReq. There would be no real gain, and this wouldn't not = scale by the way... Actually the functionality you mention is rather a notification, and = this would be better achieved using the PCNtf message (For instance, we = could define one or more optional TLVs of the NOTIFICATION object for = that purpose). >I think it is worst that PCE send the hello messages to all PCCs. If you mean that it must be possible to activate/deactivate hello = message exchange on a per PCC-PCE communication basis, then I agree with = you.=20 Note that the impact of such hello sessions would depend on the number = of PCCs a PCE would communicate with, and on hello refresh intervals. For instance I don't see any issue if a PCE maintains a hello session = with 50 PCCs, with a 5 seconds hello refresh interval. > >detailed capability discovery: >Before this is decided, all possible capabilities of PCE=20 >should be estimated, maybe this will be clear after this=20 >estimation. I Agree. Note that some capabilities are already listed in = draft-leroux-pce-discovery-reqs-00.txt, that will be updated soon. >However, I have had some comments on this issue:=20 >PCEs learn of each other's detailed capabilitis if=20 >the discovery protocol can be used in PCE-PCE discovery, PCCs=20 >learn of generic capabilitis, this will facilitate PCCs to=20 >discovery PCEs. When the PCC's first request fails due to the=20 >bad selection of PCE based on the generic=20 >capability, the PCE determines the right PCE according to the=20 >request and the acknowledge of other PCEs' capabilities, and=20 >also can communicate the detailed capabilities of the right=20 >PCE though PCEP to the PCC. Yes this is an option, the PCE discovery mechanism could be used only = for discovery of some basic PCE capabilities, and PCEP would be used to = discover detailed capabilities. Again thanks a lot Zhang for these useful comments Regards, JL > >Regard, >Zhang > =20 >----- Original Message -----=20 >From: "JP Vasseur" >To: >Sent: Thursday, May 26, 2005 11:42 PM >Subject: [Pce] WG feed-backs on PCEP > > >> Dear WG, >>=20 >> A new ID has recently been posted >> (http://www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-00.txt)=20 >> proposing a new PCE communication protocol. There are=20 >several aspects=20 >> for which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to=20 >> get your feed-backs (see section 6). Comments are also very=20 >welcome on=20 >> the other parts of the ID of course. >>=20 >> Thanks. >>=20 >> JP. >>=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 > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 06 15:11:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfN0H-0003i8-Sy; Mon, 06 Jun 2005 15:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfN0G-0003hz-Bn for pce@megatron.ietf.org; Mon, 06 Jun 2005 15:11:16 -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 PAA29942 for ; Mon, 6 Jun 2005 15:11:14 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfNL8-0000it-2d for pce@ietf.org; Mon, 06 Jun 2005 15:32:52 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-131.messagelabs.com!1118085063!1918718!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.69] Received: (qmail 27518 invoked from network); 6 Jun 2005 19:11:03 -0000 Received: from kcmso1.att.com (HELO kcmso1.proxy.att.com) (192.128.133.69) by server-10.tower-131.messagelabs.com with SMTP; 6 Jun 2005 19:11:03 -0000 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by kcmso1.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j56J9ZKn021242 for ; Mon, 6 Jun 2005 14:11:03 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 4290ADDF00273A1E; Mon, 6 Jun 2005 15:11:02 -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] WG feed-backs on PCEP Date: Mon, 6 Jun 2005 14:11:02 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE605@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] WG feed-backs on PCEP Thread-Index: AcViCeoqQ4m2MjdSRw6stThOPM/lXQIugKFg From: "Ash, Gerald R \(Jerry\), ALABS" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 JP, All, Here are a few comments on the PCEP I-D. General comments: 1. Nice job, good technical solution, quite complete for a first draft. 2. So far we only have PCE Communication Protocol Generic Requirements http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-00.txt, although we expect application-specific requirements as specified in Section 6.1.9 of that document. How do we know that the proposed PCEP satisfies the application-specific requirements when we have no such requirements at this point? Don't we need some of the application-specific requirements first, such as: - intra-area path computation - inter-area path computation - inter-AS intra provider and inter-AS inter-provider path computation? 3. You list requirements that are satisfied in Section 5. It would be good to identify in general how the proposed PCEP satisfies all the requirements in http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-00.txt. In particular, it is not entirely clear how/where the following requirements are addressed in the PCEP I-D: 6.1.4, 6.1.6 --> 6.1.10, 6.2.1 --> 6.2.3, 6.3.3. 4. You mention that PCEP is extensible, but it isn't clear how this extensibility would be accomplished. For example, in Section 7.2, RE 'format of a PCReq message', how do we extend the list of attributes in case other attributes in the PCReq message need to be added in the future? Same comment on PCRep message in Section 7.3, etc. Specific comments: 1. Section 5, last line: 'regular PCE' and 'PCE itself acting as a PCC' are not terms used in [PCE-ARCH]. For instance, the latter is defined as a 'composite PCE' in [PCE-ARCH]. It would be best to use terminology consistent with [PCE-ARCH]. 2. Section 6: I agree with Dean Cheng that open, close, and hello are not needed, and that detailed capability discovery is needed upon PCEP connection setup. 3. Section 8.2, RE 'P (Partial)': We define 'explicit PCE path' and 'strict/loose PCE path' in [PCE-ARCH], rather than 'Partial'. Again, consistent terminology would be good. 4. Section 8.4: Is 'Bandwidth' the only traffic descriptor allowed? What if other descriptors (e.g., token bucket) are desired, how are these going to be included if needed in the future? 5. Section 8.5: What if 'path jitter', 'path bit error rate', and other path QoS parameters, in addition to 'path delay', are desired? How are these going to be included if needed in the future? 6. Section 8.7, line 1: 'Section 8' --> 'Section 9' 7. Section 8.8, RE 'An implementation may decide to cancel such notification if the PCC is in down state for a specific period. A RECOMMENDED value for such delay is 1 hour.' What is the 1-hour recommendation based on, sounds pretty arbitrary? 8. Section 16.2: Why are [PCE-ARCH] and [PCE-GEN-COM-REQ] informative references, shouldn't these be normative references? Thanks, Regards, Jerry -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of JP Vasseur Sent: Thursday, May 26, 2005 11:42 AM To: pce@ietf.org Subject: [Pce] WG feed-backs on PCEP Dear WG, A new ID has recently been posted=20 (http://www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-00.txt)=20 proposing a new PCE communication protocol. There are several aspects=20 for which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to=20 get your feed-backs (see section 6). Comments are also very welcome on=20 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 Wed Jun 08 11:07:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg297-0006yp-G7; Wed, 08 Jun 2005 11:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg294-0006yf-DN for pce@megatron.ietf.org; Wed, 08 Jun 2005 11:07:07 -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 LAA07550 for ; Wed, 8 Jun 2005 11:07:04 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg2UK-0006Z0-3E for pce@ietf.org; Wed, 08 Jun 2005 11:29:06 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2005 08:06:55 -0700 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 j58F675W001617; Wed, 8 Jun 2005 11:06:53 -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); Wed, 8 Jun 2005 11:06:34 -0400 Received: from [192.168.1.101] ([10.86.240.45]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Jun 2005 11:06:32 -0400 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA060CE605@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA060CE605@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: From: JP Vasseur Subject: Re: [Pce] WG feed-backs on PCEP Date: Wed, 8 Jun 2005 11:06:44 -0400 To: "Ash, Gerald R \(Jerry\), ALABS" X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 08 Jun 2005 15:06:32.0905 (UTC) FILETIME=[A819A390:01C56C3B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec 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="===============0055893344==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0055893344== Content-Type: multipart/alternative; boundary=Apple-Mail-18-349567435 --Apple-Mail-18-349567435 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Jerry, First of all thanks for your comments. See in line, On Jun 6, 2005, at 3:11 PM, Ash, Gerald R ((Jerry)), ALABS wrote: > JP, All, > > Here are a few comments on the PCEP I-D. > > General comments: > > 1. Nice job, good technical solution, quite complete for a first > draft. Thanks. > 2. So far we only have PCE Communication Protocol Generic Requirements > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-00.txt, although we expect application-specific requirements as > specified in Section 6.1.9 of that document. How do we know that the > proposed PCEP satisfies the application-specific requirements when we > have no such requirements at this point? Don't we need some of the > application-specific requirements first, such as: > - intra-area path computation > - inter-area path computation > - inter-AS intra provider and inter-AS inter-provider path > computation? Well as with any protocol, we will first start with the basics and extend it to meet further requirements. This is why we made PCEP as extensible as possible by offering the ability to quite easily add messages and objects in the future without compromising the protocol infrastructure. The aim of this first version is to cover the protocol basics and extensions might be added in the future to meet application-specific requirements. > 3. You list requirements that are satisfied in Section 5. It would be > good to identify in general how the proposed PCEP satisfies all the > requirements in > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol- > gen-req > s-00.txt. "The PCE Working Group has produced a set of requirements for the PCE communication protocols ([PCE-COM-GEN-REQ]) which served as input to the design of the PCEP protocol " > In particular, it is not entirely clear how/where the > following requirements are addressed in the PCEP I-D: 6.1.4, You're absolutely right and a detailed "Security" section must be added to the PCEP draft. Will be done in the next revision. > 6.1.6 --> > 6.1.10, 6.2.1 --> 6.2.3, 6.3.3. I think that there are various requirements that are satisfied. Trying to analyze them one by one is a good idea. To avoid a quite long email, may I suggest to have separate emails (one per item) ? > 4. You mention that PCEP is extensible, but it isn't clear how this > extensibility would be accomplished. For example, in Section 7.2, RE > 'format of a PCReq message', how do we extend the list of > attributes in > case other attributes in the PCReq message need to be added in the > future? Same comment on PCRep message in Section 7.3, etc. > That really depends on the attribute ... could be as simple as a new flag in the REQUEST-ID object or require an entirely new object carried in both the PCReq and PCRep messages. > Specific comments: > > 1. Section 5, last line: 'regular PCE' and 'PCE itself acting as a > PCC' > are not terms used in [PCE-ARCH]. For instance, the latter is defined > as a 'composite PCE' in [PCE-ARCH]. It would be best to use > terminology > consistent with [PCE-ARCH]. Good point ! Will fix that. > 2. Section 6: I agree with Dean Cheng that open, close, and hello are > not needed, and that detailed capability discovery is needed upon PCEP > connection setup. ok thanks for the feed-back. > 3. Section 8.2, RE 'P (Partial)': We define 'explicit PCE path' and > 'strict/loose PCE path' in [PCE-ARCH], rather than 'Partial'. Again, > consistent terminology would be good. Also agree. > 4. Section 8.4: Is 'Bandwidth' the only traffic descriptor allowed? > What if other descriptors (e.g., token bucket) are desired, how are > these going to be included if needed in the future? As simple as new objects. I think that we will likely see new such object in the future, but let's start with the required minimum. > 5. Section 8.5: What if 'path jitter', 'path bit error rate', and > other > path QoS parameters, in addition to 'path delay', are desired? How > are > these going to be included if needed in the future? Well we may either decide to: - Have a single object with all such attributes - Have multiple object This will be discussed once such requirements will be known. > 6. Section 8.7, line 1: 'Section 8' --> 'Section 9' Thanks. > 7. Section 8.8, RE 'An implementation may decide to cancel such > notification if the PCC is in down state for a specific period. A > RECOMMENDED value for such delay is 1 hour.' What is the 1-hour > recommendation based on, sounds pretty arbitrary? Yes indeed ... from the time the ID potentially moves forward we should have implementations providing a better idea of the suggested value. > 8. Section 16.2: Why are [PCE-ARCH] and [PCE-GEN-COM-REQ] informative > references, shouldn't these be normative references? > Thanks. JP. > Thanks, > Regards, > Jerry > > -----Original Message----- > From: pce-bounces@lists.ietf.org [mailto:pce- > bounces@lists.ietf.org] On > Behalf Of JP Vasseur > Sent: Thursday, May 26, 2005 11: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 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. > --Apple-Mail-18-349567435 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jerry,

First of all thanks for = your comments. See in line,

On Jun 6, 2005, = at 3:11 PM, Ash, Gerald R ((Jerry)), ALABS wrote:

JP, All,

Here are a few comments on the = PCEP I-D.

General comments:

1. Nice job, = good technical solution, quite complete for a first = draft.

Thanks.

2. So far we only have PCE = Communication Protocol Generic Requirements
s-00.txt, although we expect = application-specific requirements as
specified in = Section 6.1.9 of that document.=A0 = How do we know that the
proposed PCEP = satisfies the application-specific requirements when we
have no such requirements at this point?=A0 Don't we need some of = the
application-specific = requirements first, such as:
- intra-area = path computation
- inter-area path = computation
- inter-AS intra provider and = inter-AS inter-provider path computation?

Well as with any protocol, = we will first start with the basics and extend it to meet further = requirements. This is why we made PCEP as extensible as possible by = offering the ability to quite easily add messages and objects in the = future without compromising the protocol infrastructure. The aim of this = first version is to cover the protocol basics and extensions might be = added in the future to meet application-specific = requirements.

3. You = list requirements that are satisfied in Section 5.=A0 It would be
good to identify in general how the proposed PCEP = satisfies all the
requirements in
s-00.txt.=A0

"The = PCE Working Group has produced a set of requirements for the PCE = communication protocols ([PCE-COM-GEN-REQ]) which served as input to the = design of the PCEP protocol "

In particular, it is not = entirely clear how/where the
following = requirements are addressed in the PCEP I-D: = 6.1.4,

You're absolutely right and = a detailed "Security" section must be added to the PCEP draft. Will be = done in the next revision.

6.1.6 -->
6.1.10, 6.2.1 = --> 6.2.3, 6.3.3.

I think that there are = various requirements that are satisfied. Trying to analyze them one by = one is a good idea. To avoid a quite long email, may I suggest to have = separate emails (one per item) ?

4. You mention that PCEP is extensible, but it isn't = clear how this
extensibility would be = accomplished.=A0 For = example, in Section 7.2, RE
'format of a = PCReq message', how do we extend the list of attributes in
case other attributes in the PCReq message need to = be added in the
future?=A0 Same comment on PCRep message = in Section 7.3, etc.
That really depends on the = attribute ... could be as simple as a new flag in the REQUEST-ID object = or require an entirely new object carried in both the PCReq and PCRep = messages.

Specific = comments:

1. Section 5, last line: 'regular PCE' and 'PCE = itself acting as a PCC'
are not terms = used in [PCE-ARCH].=A0 For = instance, the latter is defined
as a = 'composite PCE' in [PCE-ARCH].=A0 = It would be best to use terminology
Good point ! Will fix = that.

2. Section 6: = I agree with Dean Cheng that open, close, and hello are
not needed, and that detailed capability discovery = is needed upon PCEP
connection = setup.

ok thanks for the = feed-back.

3. = Section 8.2, RE 'P (Partial)':=A0 = We define 'explicit PCE path' and
=A0 Again,
consistent terminology would be = good.

Also = agree.

4. Section = 8.4: Is 'Bandwidth' the only traffic descriptor allowed?
What if other descriptors (e.g., token bucket) are = desired, how are
these going to be included if = needed in the future?

As simple as new objects. I = think that we will likely see new such object in the future, but let's = start with the required minimum.=A0

5. Section 8.5: What if 'path = jitter', 'path bit error rate', and other
path QoS = parameters, in addition to 'path delay', are desired?=A0 How are
these going to be included if needed in the = future?

Well we may either decide = to:
- Have a single object with all such = attributes
- Have multiple object

This will be discussed once = such requirements will be known.

6. Section 8.7, line 1: 'Section 8' --> 'Section = 9'

Thanks.

7. Section 8.8, RE 'An = implementation may decide to cancel such
RECOMMENDED value for such delay is 1 = hour.'=A0 What is the = 1-hour
recommendation based on, sounds = pretty arbitrary?

Yes indeed ... from the = time the ID potentially moves forward we should have implementations = providing a better idea of the suggested value.

8. Section 16.2: Why are = [PCE-ARCH] and [PCE-GEN-COM-REQ] informative
references, shouldn't these be normative = references?
Thanks.

JP.

Thanks,
Jerry

From: = pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.o= rg] On
Behalf Of JP Vasseur
Sent: Thursday, May 26, 2005 11:42 AM
Subject: [Pce] WG feed-backs on PCEP

Dear = WG,

A new ID has recently been posted=A0
proposing a new PCE communication protocol. There = are several aspects=A0
for = which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to=A0
get your = feed-backs (see section 6). Comments are also very welcome on=A0
the = other parts of the ID of course.

Thanks.


= --Apple-Mail-18-349567435-- --===============0055893344== 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 --===============0055893344==-- From pce-bounces@lists.ietf.org Thu Jun 09 08:17:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLyf-0007up-Ah; Thu, 09 Jun 2005 08:17:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLye-0007uk-9F for pce@megatron.ietf.org; Thu, 09 Jun 2005 08:17:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21045 for ; Thu, 9 Jun 2005 08:17:39 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgMK4-0007fh-Lh for pce@ietf.org; Thu, 09 Jun 2005 08:39:51 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 Jun 2005 08:17:29 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j59CFXNO021711; Thu, 9 Jun 2005 08:15:51 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Jun 2005 08:15:44 -0400 Received: from [192.168.1.101] ([10.86.240.142]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Jun 2005 08:15:43 -0400 Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 9 Jun 2005 08:15:54 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 09 Jun 2005 12:15:43.0902 (UTC) FILETIME=[F5A1A3E0:01C56CEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Requirements for Inter-Area MPLS Traffic Engineering: RFC4105 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 wanted to let you know that "Requirements for Inter-Area MPLS Traffic Engineering" has been published as RFC4105. Section 7 of this RFC contains several detailed requirements that could be used to define the PCE-based inter-area TE LSP path computation. Some of you mentioned to Adrian and myself that they were willing to produce a PCE-based inter-area requirement ID. Thanks to take RFC4105 into account. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jun 10 07:32:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dghk9-0004wD-TQ; Fri, 10 Jun 2005 07:32:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dghk9-0004w7-2P for pce@megatron.ietf.org; Fri, 10 Jun 2005 07:32:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09765 for ; Fri, 10 Jun 2005 07:32:07 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgi5n-0002GD-GW for pce@ietf.org; Fri, 10 Jun 2005 07:54:32 -0400 Received: from du-069-0125.access.clara.net ([217.158.132.125] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1Dghjy-000HHc-I1 for pce@ietf.org; Fri, 10 Jun 2005 12:31:59 +0100 Message-ID: <060601c56db0$552b2610$72849ed9@Puppy> From: "Adrian Farrel" To: Date: Fri, 10 Jun 2005 12:22:44 +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: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Fw: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France 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 For your information ----- Original Message ----- From: To: Sent: Friday, June 10, 2005 5:00 AM Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France > > There are two (2) Internet-Draft cutoff dates for the 63rd > IETF Meeting in Paris, France: > > July 11th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > July 11th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Tuesday, > July 5th at 9:00 AM ET. > > July 18th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, July 18th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, August 1st at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or > revised Internet-Draft after their respective cutoff deadlines, then > your document will be retained and posted when Internet-Draft > processing resumes. You will no longer be required to resubmit the > document. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 63rd IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_63.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 13 22:04:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di0nK-0008Dt-3h; Mon, 13 Jun 2005 22:04:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di0nJ-0008D3-17 for pce@megatron.ietf.org; Mon, 13 Jun 2005 22:04:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00848 for ; Mon, 13 Jun 2005 22:04:46 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di19f-0002wC-Ut for pce@ietf.org; Mon, 13 Jun 2005 22:27:57 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0II100ETMXZZ4Q@szxga02-in.huawei.com> for pce@ietf.org; Tue, 14 Jun 2005 10:09:35 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0II1007USXVY99@szxga02-in.huawei.com> for pce@ietf.org; Tue, 14 Jun 2005 10:09:35 +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 <0II10085PY31NC@szxml01-in.huawei.com> for pce@ietf.org; Tue, 14 Jun 2005 10:11:26 +0800 (CST) Date: Tue, 14 Jun 2005 09:40:13 +0800 From: Zhang Renhai To: pce@ietf.org Message-id: <002501c57082$04f8c9c0$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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Pce] Please comment draft-zhang-pce-comm-app-model-00 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="===============1970756787==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1970756787== Content-type: multipart/alternative; boundary="Boundary_(ID_iSvaLAHvBZQr2HrS/m4fIQ)" This is a multi-part message in MIME format. --Boundary_(ID_iSvaLAHvBZQr2HrS/m4fIQ) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Dear WG, A new ID has just been finished and posted (http://www.ietf.org/internet-drafts/draft-zhang-pce-comm-app-model-00.txt), which proposed a application model. Thinking of the satuation where the network resources are reserved and released frequently, for instance, VoIP environment,this draft give a mechanisms on this respect, mostly on resolving race conditions and on computation load balancing. It's 10 pages long. Comments are very welcome. Thanks and Regards. Rh Zhang --Boundary_(ID_iSvaLAHvBZQr2HrS/m4fIQ) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Dear WG,

A new ID has just been finished and posted
(http://www.ietf.org/internet-drafts/draft-zhang-pce-comm-app-model-00.txt),
which proposed a application model. Thinking of the satuation where the 
network resources are reserved and released frequently, for instance, VoIP
environment,this draft give a mechanisms on this respect, mostly on resolving
race conditions and on computation load balancing.
It's 10 pages long. Comments are very welcome.

Thanks and Regards.
Rh Zhang
--Boundary_(ID_iSvaLAHvBZQr2HrS/m4fIQ)-- --===============1970756787== 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 --===============1970756787==-- From pce-bounces@lists.ietf.org Wed Jun 29 08:00:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnbFS-00048N-RX; Wed, 29 Jun 2005 08:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnbFR-00047o-2M for pce@megatron.ietf.org; Wed, 29 Jun 2005 08:00:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09777 for ; Wed, 29 Jun 2005 08:00:56 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnbey-0002Yl-4e for pce@ietf.org; Wed, 29 Jun 2005 08:27:21 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 14:00:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 29 Jun 2005 14:00:47 +0200 Message-ID: Thread-Topic: PCE Disco Reqs v01 Thread-Index: AcV8oi+p+icoF+06TTaS5Za9z0e3zQ== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 29 Jun 2005 12:00:48.0405 (UTC) FILETIME=[3022A450:01C57CA2] X-Spam-Score: 0.9 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Subject: [Pce] PCE Disco Reqs v01 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="===============1220343703==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1220343703== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57CA2.30275099" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57CA2.30275099 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Version 01 of the PCE discovery reqs ID has just been published http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.t xt This version takes into account comments received during Minneapolis session and on the list. Here are the major changes since 00: -Added multi-area network case in the problem statement -Added application scenario (section 4)=20 -Section 5.1 on capability discovery modified as per discussions on the list: -Discovery of PCE location, PCE scopes and domain(s) under control is mandatory -Capability discovery is no longer a MUST The list of capabilities is now out of the scope and should be addressed in a=20 separate document. =20 -Added section 5.6 on extensibility=20 -Added Security section Section 5.5 (Discovery of PCE capacity and congestion) requires WG feedback: -Is there a need for the discovery of PCE capacity in terms of computation power? This static parameter could be used to ensure weighted load balancing of requests in case PCEs do not have the same capacity.=20 -Would it be useful that a PCE report its status as "congested" in case it is too busy? PCCs may then use this dynamic information to prefer a different PCE.=20 Your comments/feedback would be highly welcome, especially on the above point Best Regards, JL ------_=_NextPart_001_01C57CA2.30275099 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PCE Disco Reqs v01

Hi all,

Version 01 of the PCE discovery = reqs ID has just been published
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-= 01.txt

This version takes into account = comments received during Minneapolis session and on the list.

Here are the major changes since = 00:
-Added multi-area network case = in the problem statement
-Added application scenario = (section 4)
-Section 5.1 on capability = discovery modified as per discussions on the list:
        -Discovery of PCE location, PCE scopes and = domain(s) under control is mandatory
        -Capability discovery is no longer a MUST
       The list of capabilities is = now out of the scope and should be addressed in a
       separate document.
      
-Added section 5.6 on = extensibility
-Added Security section

Section 5.5 (Discovery of PCE = capacity and congestion) requires WG feedback:
-Is there a need for the discovery of PCE capacity in terms of = computation power? This static parameter could be used to ensure = weighted load balancing of requests in case PCEs do not have the same = capacity.

-Would it be useful that a PCE = report its status as "congested" in case it is too busy? PCCs = may then use this dynamic information to prefer a different PCE. =

Your comments/feedback would be = highly welcome, especially on the above point

Best Regards,

JL

------_=_NextPart_001_01C57CA2.30275099-- --===============1220343703== 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 --===============1220343703==-- From pce-bounces@lists.ietf.org Wed Jun 29 09:03:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DncEJ-0006i6-La; Wed, 29 Jun 2005 09:03:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DncEH-0006hn-Pr for pce@megatron.ietf.org; Wed, 29 Jun 2005 09:03:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15969 for ; Wed, 29 Jun 2005 09:03:48 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dncdj-0005V6-2J for pce@ietf.org; Wed, 29 Jun 2005 09:30:15 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1120050210!2677142!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.166.71] Received: (qmail 17436 invoked from network); 29 Jun 2005 13:03:30 -0000 Received: from almso2.att.com (HELO almso2.proxy.att.com) (192.128.166.71) by server-6.tower-120.messagelabs.com with SMTP; 29 Jun 2005 13:03:30 -0000 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by almso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j5TD22HM026431 for ; Wed, 29 Jun 2005 09:03:30 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 42BED27600132B06; Wed, 29 Jun 2005 09:03:30 -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] PCE Disco Reqs v01 Date: Wed, 29 Jun 2005 08:03:29 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA8FCC@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcV8oi+p+icoF+06TTaS5Za9z0e3zQACDc5Q From: "Ash, Gerald R \(Jerry\), ALABS" To: "LE ROUX Jean-Louis RD-CORE-LAN" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 JL, > -Would it be useful that a PCE report its status as "congested" > in case it is too busy? PCCs may then use this dynamic > information to prefer a different PCE.=20 Yes, it would be useful. Also, this is a requirement in http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-00.txt (see Sections 6.1.3 and 6.1.6). Thanks, Regards, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jun 29 09:23:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DncX1-0004XP-Va; Wed, 29 Jun 2005 09:23:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DncX0-0004XH-HS for pce@megatron.ietf.org; Wed, 29 Jun 2005 09:23:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17973 for ; Wed, 29 Jun 2005 09:23: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 1DncwY-0006X5-Bs for pce@ietf.org; Wed, 29 Jun 2005 09:49:35 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 15:23:05 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE : [Pce] PCE Disco Reqs v01 Date: Wed, 29 Jun 2005 15:23:04 +0200 Message-ID: Thread-Topic: [Pce] PCE Disco Reqs v01 Thread-Index: AcV8oi+p+icoF+06TTaS5Za9z0e3zQACDc5QAABiZbA= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Ash, Gerald R \(Jerry\), ALABS" , X-OriginalArrivalTime: 29 Jun 2005 13:23:05.0054 (UTC) FILETIME=[AE9B7FE0:01C57CAD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Jerry, Yes, I know that this is also a requirement for the PCC-PCE com proto = :-) Actually here we are wondering if it would be useful to also rely on the = dynamic PCE discovery mechanism to disclose PCE congestion status?=20 It may be useful that a PCC be aware of the PCE status even in the = absence of a PCC-PCE communication session, this could avoid PCC-PCE = communication setup failure... Regards, JL >-----Message d'origine----- >De : Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 >Envoy=E9 : mercredi 29 juin 2005 15:03 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org >Cc : Ash, Gerald R (Jerry), ALABS >Objet : RE: [Pce] PCE Disco Reqs v01 > > >Hi JL, > >> -Would it be useful that a PCE report its status as "congested" in=20 >> case it is too busy? PCCs may then use this dynamic information to=20 >> prefer a different PCE. > >Yes, it would be useful. Also, this is a requirement in=20 >http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protoco l-gen-req s-00.txt (see Sections 6.1.3 and 6.1.6). Thanks, Regards, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jun 30 09:53:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzTb-0002Wb-IJ; Thu, 30 Jun 2005 09:53:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzTa-0002Uf-LG for pce@megatron.ietf.org; Thu, 30 Jun 2005 09:53:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13085 for ; Thu, 30 Jun 2005 09:53:08 -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 1DnztL-0002cZ-Jx for pce@ietf.org; Thu, 30 Jun 2005 10:19:48 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 30 Jun 2005 06:53:00 -0700 X-IronPort-AV: i="3.93,245,1115017200"; d="scan'208,217"; a="646518509:sNHT40418408" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5UDqvvQ006944 for ; Thu, 30 Jun 2005 06:52:57 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 06:52:47 -0700 Received: from [10.71.5.30] ([10.21.145.249]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 06:52:47 -0700 Mime-Version: 1.0 (Apple Message framework v730) To: pce@ietf.org Message-Id: <4163C072-5C4F-4007-927A-CF14657FDB5A@cisco.com> From: JP Vasseur Date: Thu, 30 Jun 2005 09:53:09 -0400 X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 30 Jun 2005 13:52:47.0770 (UTC) FILETIME=[FF9A1FA0:01C57D7A] X-Spam-Score: 0.7 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG document ? 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="===============1794858799==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1794858799== Content-Type: multipart/alternative; boundary=Apple-Mail-1-98468963 --Apple-Mail-1-98468963 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear WG, draft-leroux-discovery-reqs has just been re-published, addressing several of comments received during the last meeting and on the list (very few remaining open items). Could you provide us your feed-back on adopting draft-leroux- discovery-reqs-01.txt as a WG document ? JP and Adrian. --Apple-Mail-1-98468963 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit

Dear WG,

draft-leroux-discovery-reqs has just been re-published, addressing several of comments received during the last meeting and on the list (very few remaining open items).

Could you provide us your feed-back on adopting draft-leroux-discovery-reqs-01.txt as a WG document ?

JP and Adrian.

--Apple-Mail-1-98468963-- --===============1794858799== 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 --===============1794858799==-- From pce-bounces@lists.ietf.org Thu Jun 30 09:58:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzYU-0003Wx-NV; Thu, 30 Jun 2005 09:58:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzYS-0003Vt-GC for pce@megatron.ietf.org; Thu, 30 Jun 2005 09:58:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13517 for ; Thu, 30 Jun 2005 09:58:10 -0400 (EDT) Received: from relais-inet.francetelecom.com ([212.234.67.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnzyD-0006MB-0z for pce@ietf.org; Thu, 30 Jun 2005 10:24:50 -0400 Received: from prive-Rline3.com ([192.168.1.32] [192.168.1.32]) by Rline3.francetelecom.com with ESMTP for pce@ietf.org; Thu, 30 Jun 2005 15:57:45 +0200 Received: from smtp7.smtpft.francetelecom.fr ([193.249.139.219] [193.249.139.219]) by Rline3.francetelecom.com with ESMTP for pce@ietf.org; Thu, 30 Jun 2005 15:57:44 +0200 Received: from FTTOVPYQRE9ODJ ([10.134.121.146]) by smtp7.smtpft.francetelecom.fr (Netscape Messaging Server 4.15) with SMTP id IIWHG900.AJM; Thu, 30 Jun 2005 15:57:45 +0200 From: "JACQUENET C ROSI/DRLD/ITP" To: "'JP Vasseur'" , Subject: RE: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WGdocument ? Date: Thu, 30 Jun 2005 15:57:43 +0200 Message-Id: <00e901c57d7b$b08fca30$9279860a@rennes.francetelecom.fr> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: <4163C072-5C4F-4007-927A-CF14657FDB5A@cisco.com> Importance: Normal X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: JACQUENET C ROSI/DRLD/ITP List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1203462678==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org C'est un message de format MIME en plusieurs parties. --===============1203462678== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EA_01C57D8C.74189A30" C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_00EA_01C57D8C.74189A30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I'm in favor of adopting this draft as a pce WG document. Cheers, Christian. -----Message d'origine----- De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org]De = la part de JP Vasseur Envoye : jeudi 30 juin 2005 15:53 A : pce@ietf.org Objet : [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as = WGdocument ? Dear WG, draft-leroux-discovery-reqs has just been re-published, addressing = several of comments received during the last meeting and on the list = (very few remaining open items). Could you provide us your feed-back on adopting = draft-leroux-discovery-reqs-01.txt as a WG document ? JP and Adrian. ------=_NextPart_000_00EA_01C57D8C.74189A30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
I'm in favor of adopting this draft as a pce WG=20 document.
 
Cheers,
 
Christian.
-----Message d'origine-----
De :=20 pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org]De la = part=20 de JP Vasseur
Envoyé : jeudi 30 juin 2005=20 15:53
À : pce@ietf.org
Objet : = [Pce] Adoption of=20 draft-leroux-pce-discovery-reqs-01.txt as WGdocument = ?

Dear = WG,

draft-leroux-discovery-reqs has just = been=20 re-published, addressing several of comments received during the last = meeting=20 and on the list (very few remaining open items).

Could you provide us your feed-back = on=20 adopting draft-leroux-discovery-reqs-01.txt as a WG document ?

JP and = Adrian.

------=_NextPart_000_00EA_01C57D8C.74189A30-- --===============1203462678== 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 --===============1203462678==-- From pce-bounces@lists.ietf.org Thu Jun 30 11:28:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0yB-0003dl-Kt; Thu, 30 Jun 2005 11:28:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0y8-0003Z7-13 for pce@megatron.ietf.org; Thu, 30 Jun 2005 11:28:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23948 for ; Thu, 30 Jun 2005 11:28:45 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do1Nu-0004cN-LZ for pce@ietf.org; Thu, 30 Jun 2005 11:55:27 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j5UFRPtB012903; Thu, 30 Jun 2005 11:27:25 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04394; Thu, 30 Jun 2005 11:27:24 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Jun 2005 11:27:24 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885C86@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'JP Vasseur'" Subject: RE: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as W G document ? Date: Thu, 30 Jun 2005 11:27:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.7 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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="===============0577122789==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0577122789== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57D88.35EE65CC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C57D88.35EE65CC Content-Type: text/plain; charset="iso-8859-1" JP, I believe this draft needs more work - particularly in the area of establishing "security requirements" (as opposed to simple inclusion of a security section) - before it is ready to be adopted as a WG document. Implicit in the PCE concept is the inherently undefined nature of the trust model that may apply in any given deployment. Consequently it MUST be a requirement that any PCE discovery mechanism explicitly supports a specific set of trust models and that the complete set of possible solutions (assuming the _possibility_ that one solution may not satisfy all requirements) supports every reasonable combination of security trust models. It is imperative that this is established as a "requirement" of PCE discovery solutions because this requirement will have a very definite effect on choices the WG might make right away in seeking a solution. For example, assuming that we need to support a model where we assume that it is possible for a foreign agency to mimic a valid PCE, this assumption will severely limit the approaches that might be used - as long as it is also a requirement to avoid approaches that require extensive manual configuration. To further illustrate this example, this requirement would make a choice of discovery based on broadcast/multicast announcement mechanisms much less workable - possibly directing us more toward an authenticated directory service approach. To accept this document as a WG document without first nailing down the specific security requirements that we want to apply would potentially send the wrong message to the authors, the WG, the Internet community and - possibly - the IESG. It is far more important to ensure that the work has started in the right direction than it is to drive the work to conform more closely to a time table. -- Eric -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org]On Behalf Of JP Vasseur Sent: Thursday, June 30, 2005 9:53 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG document ? Dear WG, draft-leroux-discovery-reqs has just been re-published, addressing several of comments received during the last meeting and on the list (very few remaining open items). Could you provide us your feed-back on adopting draft-leroux-discovery-reqs-01.txt as a WG document ? JP and Adrian. ------_=_NextPart_001_01C57D88.35EE65CC Content-Type: text/html; charset="iso-8859-1"
JP,
 
    I believe this draft needs more work - particularly in the area of establishing
"security requirements" (as opposed to simple inclusion of a security section)
- before it is ready to be adopted as a WG document.
 
    Implicit in the PCE concept is the inherently undefined nature of the trust
model that may apply in any given deployment. Consequently it MUST be a
requirement that any PCE discovery mechanism explicitly supports a specific
set of trust models and that the complete set of possible solutions (assuming
the _possibility_ that one solution may not satisfy all requirements) supports
every reasonable combination of security trust models.
 
    It is imperative that this is established as a "requirement" of PCE discovery
solutions because this requirement will have a very definite effect on choices
the WG might make right away in seeking a solution.
 
    For example, assuming that we need to support a model where we assume
that it is possible for a foreign agency to mimic a valid PCE, this assumption
will severely limit the approaches that might be used - as long as it is also a
requirement to avoid approaches that require extensive manual configuration.
 
    To further illustrate this example, this requirement would make a choice of
discovery based on broadcast/multicast announcement mechanisms much
less workable - possibly directing us more toward an authenticated directory
service approach.
 
    To accept this document as a WG document without first nailing down the
specific security requirements that we want to apply would potentially send
the wrong message to the authors, the WG, the Internet community and -
possibly - the IESG.
 
    It is far more important to ensure that the work has started in the right
direction than it is to drive the work to conform more closely to a time table.
 
--
Eric
-----Original Message-----
From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org]On Behalf Of JP Vasseur
Sent: Thursday, June 30, 2005 9:53 AM
To: pce@ietf.org
Subject: [Pce] Adoption of draft-leroux-pce-discovery-reqs-01.txt as WG document ?

Dear WG,

draft-leroux-discovery-reqs has just been re-published, addressing several of comments received during the last meeting and on the list (very few remaining open items).

Could you provide us your feed-back on adopting draft-leroux-discovery-reqs-01.txt as a WG document ?

JP and Adrian.

------_=_NextPart_001_01C57D88.35EE65CC-- --===============0577122789== 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 --===============0577122789==--