From pce-bounces@lists.ietf.org Thu Mar 01 14:14:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMqj3-0007yT-6e; Thu, 01 Mar 2007 14:14:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMqj2-0007tZ-Iw for pce@ietf.org; Thu, 01 Mar 2007 14:14:00 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMqiz-0003dm-TP for pce@ietf.org; Thu, 01 Mar 2007 14:14:00 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 20:13:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG Date: Thu, 1 Mar 2007 20:13:39 +0100 Message-ID: In-Reply-To: <082b01c755a9$5dc27ed0$0d01a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG Thread-Index: AcdVqbsCDFY8XNsfSDmUKalXm8vpAwGhdhYA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , X-OriginalArrivalTime: 01 Mar 2007 19:13:56.0489 (UTC) FILETIME=[C2390F90:01C75C35] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 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: , Errors-To: pce-bounces@lists.ietf.org Hi Les, Thanks for these comments. Please see inline, > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Envoy=E9 : mercredi 21 f=E9vrier 2007 11:53 > =C0 : pce@ietf.org > Objet : [Pce] Comments on=20 > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG >=20 > ----- Original Message ----- >=20 > From: "Les Ginsberg (ginsberg)" > To: "Adrian Farrel" ; > Cc: "Jean Philippe Vasseur (jvasseur)" > Sent: Monday, February 19, 2007 6:56 PM > Subject: RE: [Isis-wg] PCE working group last call >=20 > ondraft-ietf-pce-disco-proto-isis-02.txt >=20 >=20 > Section 1 >=20 > ABR: IGP Area Border Router (L1L2 router). >=20 > LES: Use "L2 capable router" instead - or eliminate the=20 > definition since as Mike points out it is not used in the document. OK, to be eliminated >=20 > Examples of domains include IGP areas and Autonomous Systems. >=20 > LES: area and domain are not the same - though a domain may=20 > have only one area. I would omit this sentence. In the PCE context the defintion of a domain is as follows (as per RFC = 4655): "A domain is any collection of network elements within a common sphere = of address management or path computation responsibility. Examples of = domains include IGP areas, Autonomous Systems (ASes), and multiple ASes = within a Service Provider network. Domains of path computation = responsibility may also exist as sub-domains of areas or ASes." Is that OK if we refer to [RFC4655] and indicate that this definition = applies to a PCE context? >=20 > Section 3.1.1 >=20 > inter-area, inter-AS, inter-layer\205 >=20 > LES: Remove Formatting character \205 OK >=20 > Section 3.2 >=20 > The flooding scope for PCE information advertised through IS-IS can > be limited to one or more IS-IS areas the PCE belongs to, or can be >=20 > LES: Flooding can only be area or domain scoped flooding.=20 > There is no defined method to restrict flooding to some=20 > subset of the areas in a domain. Right. We are going to rephrase as follows: The flooding scope for PCE information advertised through IS-IS can be a = single L1 area, a L1 area and the L2 sub-domain (when the PCE is a L1L2 = node), or the entire IS-IS domain (S bit set in the Router Capability = TLV).=20 Does that make sense? >=20 > extended across the entire IS-IS routing domain. > Note that some PCEs may belong to multiple areas, in which case the > flooding scope may comprise these areas. This could be the=20 > case for a >=20 > L1L2 router for instance advertising its PCE information within the > L2 area and/or a subset of its attached L1 area(s). >=20 > LES: There is no such thing as an L2 area. There is the L2=20 > sub-domain, which consists of all L2 routers in a domain. OK, we are going to remove the above paragraph >=20 > Section 4.1. The IS-IS PCED TLV >=20 > LES: This is a sub-TLV. As Mike has pointed out, it is=20 > important to use that terminology consistently throughout the=20 > document. OK >=20 > The format of the IS-IS PCED TLV and its sub-TLVs is the=20 > identical to >=20 >=20 > LES: s/the identical/identical OK >=20 > At the end of Section 4.1 it might be helpful to add: >=20 > "The following sub-sections describe the sub-TLVs which may=20 > be carried within the PCED sub-TLV." OK >=20 > Section 4.1.3 >=20 > Two DOMAIN sub-TLVs are defined >=20 > Sub-TLV type Length Name > 1 Variable Area ID sub-TLV > 2 4 AS number sub-TLV >=20 > LES: These codepoints are not mentioned in the IANA section. OK, to be added. >=20 > Section 4.1.3.1 >=20 > VALUE: This comprises a variable length IS-IS area ID. This is the >=20 > combination of an Initial Domain Part (IDP) and High Order > part of the Domain Specific part (HO-DSP) >=20 > LES: Rather than invent a term (HO-DSP) which ISO 10589 does=20 > not use, say "this is the area address as defined in [ISO]".=20 OK > Which causes me to mention that you have no reference to ISO=20 > 10589 in the references section, a most serious breach of=20 > etiquette indeed!! OK, to be added >=20 > Section 4.1.4 >=20 > LES: The domain/area sub-TLVs (nested level 3) which are defined in > 4.1.3 appear to be "reused" here. This should be explicitly=20 > stated as the scope of the sub-TLV codepoint for domain/area=20 > sub-TLVs is the parent sub-TLV (PCE-domain or=20 > PCE-NEIG-DOMAIN) and therefore the codepoints cannot be=20 > assumed to be the same - it MUST be explicitly stated. OK >=20 > Section 5 >=20 > defined in [IS-IS-CAP]. A such, elements of procedures are=20 > inherited >=20 >=20 > LES: s/A such/As such OK >=20 > domain, itMUST be carried within an IS-IS CAPABILITY TLV=20 > having the S >=20 >=20 > LES: s/itMUST/it MUST OK >=20 > A PCE MUST originate a new IS-IS LSP whenever the content >=20 > LES: There is a generic issue here. As a PCE is not a router=20 > running the IS-IS protocol, it cannot generate any LSPs. :-)=20 > Therefore you cannot say (as you do in multiple places) "a=20 > PCE originates a new IS-IS LSP". You are right the PCE is a functional block. But it is often assimilated = to the node hosting the PCE function, which is an IS-IS node in this = draft. Is that OK if we say "An IS-IS node acting as PCE MUST originate"... > Similarly, you say: >=20 > A PCC MUST be > able to detect that the PCED TLV has been removed from an=20 > IS-IS LSP. >=20 > As a PCC is also not equivalent to a router running the IS-IS=20 > protocol, perhaps you want to say "A PCC MUST be informed..."=20 Let say "An IS-IS node acting as PCC..." ? > - although I tend to think that all of the communication=20 > between the applications (PCE and > PCC) and the IS-IS protocol instance is out of scope for this=20 > document. Yes it is out of the scope. >=20 > The PCE address, i.e. the address indicated within the PCE ADDRESS > sub-TLV, MUST be distributed as part of IS-IS routing; >=20 > LES: I am not sure what you mean here. Do you mean that there=20 > MUST be a host route advertisement for the PCE address(es)?=20 > Or do you simply mean that the PCE address(es) must be=20 > reachable via some prefix(es) advertised by IS-IS? If the=20 > latter, then please change the wording. As written it=20 > suggests there is a special advertisement required. Yes this is the latter, we are going to rephrase as suggested. >=20 > Section 8 >=20 > IS-IS provides no mechanism for protecting the privacy of LSAs, and >=20 > LES: I don't know what you are trying to say here. Do you mean TLVs? > Certainly not LSAs! Yes TLVs :-) >=20 >=20 > in particular the privacy PCE discovery information. >=20 > LES: s/privacy/privacy of OK Again, thanks a lot for these comments.=20 Once the last call is completed, we are going to submit a new revision = that accounts for all these comments. Best Regards, JL >=20 > Les >=20 >=20 > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Wednesday, February 14, 2007 9:36 AM > > To: isis-wg@ietf.org > > Cc: Jean Philippe Vasseur (jvasseur) > > Subject: [Isis-wg] PCE working group last call=20 > ondraft-ietf-pce-disco-=20 > > proto-isis-02.txt > > > > Hi, > > > > The PCE working group is holding a last call on > > > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto > -isis-02.t > xt > > > > Since this I-D proposes protocol extensions to ISIS we=20 > would like the > ISIS > > working group to participate in this last call, and we have > accordingly > > made > > the last call period three weeks in order to give you plenty of time > to > > respond. > > > > The last call will end at 12 noon GMT on Thursday 8th March. > > > > Please send your comments to the PCE mailing list if you are > subscribed. > > Otherwise, please channel your comments through the PCE=20 > working group=20 > > chairs (adrian@olddog.co.uk and jvasseur@cisco.com) > > > > Background reading is: > > RFC4655 - The PCE Architecture > > RFC4674 - Requirements for Path Computation Element (PCE) Discovery > > (These are the requirements that this I-D is > addressing) > > > > > > Thanks, > > Adrian > > > > > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 01 14:49:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMrHG-0002a5-1e; Thu, 01 Mar 2007 14:49:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMrHF-0002Yx-Ar for pce@ietf.org; Thu, 01 Mar 2007 14:49:21 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMrHB-0001Mo-RA for pce@ietf.org; Thu, 01 Mar 2007 14:49:21 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 20:48:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2007 20:48:53 +0100 Message-ID: In-Reply-To: <04b401c750f2$432319b0$0d01a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments on draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG Thread-Index: AcdQ9GI+c99qgvstR7+om7JHEHjxDQLQVytw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , , X-OriginalArrivalTime: 01 Mar 2007 19:48:50.0270 (UTC) FILETIME=[A236AFE0:01C75C3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: Subject: [Pce] RE: Review comments on draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG 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: , Errors-To: pce-bounces@lists.ietf.org Hi Mike, Thanks for these comments. Please see inline, > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel > Envoy=E9 : jeudi 15 f=E9vrier 2007 12:10 > =C0 : ccamp@ops.ietf.org > Objet : Review comments on=20 > draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG >=20 >=20 > ----- Original Message ----- > From: "mike shand" > To: "Adrian Farrel" > Cc: ; "'Jean Philippe Vasseur'" > Sent: Thursday, February 15, 2007 10:47 AM > Subject: Re: [Isis-wg] PCE working group last call on=20 > draft-ietf-pce-disco-proto-isis-02.txt >=20 >=20 > > Adrian, JP, > > > > > > A few comments below, mostly typos. > > > > Mike > > > > > > General comment... sometimes the document refers to octets and=20 > > sometimes to bytes. It would be preferable to use a=20 > consistent term throughout. OK > > > > > > > > Abstract > > > > > > along with some of information that can be used for PCE=20 > selection. > > > > > > some of THE information > > > > or > > > > some information OK > > > > 1. Terminology > > > > ABR is not a commonly used term in the context of IS-IS and doesn't=20 > > appear to be referenced in the document. OK > > > > domain. This definition is different from that commonly used for=20 > > IS-IS. Is there a reason for the difference? The document refers to=20 > > IS-IS routing domains. Is it intended that a domain is=20 > different from a routing domain? This is a domain as defined in the PCE architecture spec (RFC4655) "A domain is any collection of network elements within a common sphere = of address management or path computation responsibility. Examples of = domains include IGP areas, Autonomous Systems (ASes), and multiple ASes = within a Service Provider network. Domains of path computation = responsibility may also exist as sub-domains of areas or ASes." We are going to clarify. We can use the term "Path Computation Domain" = to be more specific. > > > > > > top of page 5 > > > > > > This document does not define any new IS-IS elements of procedure. > > The procedures defined in [IS-IS-CAP] should be used. > > > > > > should that be ... MUST be used? OK, MUST be used > > > > 3.2 flooding scope > > > > > > be limited to one or more IS-IS areas the PCE belongs to,=20 > or can be > > > > one or more IS-IS areas to which the PCE belongs > > > > would be better > > > > > > 4.1. The IS-IS PCED TLV > > > > In the introduction this is referred to (correctly) as a=20 > sub-TLV, but=20 > > here and in subsequent text it is referred to as a TLV. This is=20 > > confusing to say the least. OK, to be changed to sub-TLV > > > > > > The format of the IS-IS PCED TLV and its sub-TLVs is the=20 > identical to > > > > is identical to OK > > > > > > > > 4.1.6. The CONGESTION sub-TLV > > > > > > The CONGESTION sub-TLV is used to indicate a PCE's experiences a > > > > to indicate THAT a PCE experiences > > > > or > > > > to indicate a PCE's experience of a > > > > or > > > > to indicate that a PCE is experiencing a OK > > > > > > VALUE: This comprises a one-byte bit flags indicating the > > > > > > this reads rather strangely > > > > this comprises one byte of bit flags.... OK > > > > > > > > > > 5. Elements of Procedure > > > > > > typo > > > > > > domain, itMUST be carried within an IS-IS CAPABILITY TLV=20 > having the=20 > > S > > > > > > When the PCE function is deactivated on a node, the node MUST > > originate a new IS-IS LSP with no longer any PCED TLV. A=20 > PCC MUST be > > able to detect that the PCED TLV has been removed from=20 > an IS-IS LSP. > > > > > > are we assuming here that all this information will always=20 > fit within=20 > > a single LSP? That is probably reasonable Yes > > > > Are we also assuming that it will always fit within a=20 > single IS-IS CAP=20 > > TLV? That may not be so reasonable. Actually this sounds reasonable 2 * PCE-ADDRESS + PATH-SCOPE + CONGESTION + PCE-CAP-FLAGs (with 32 = flags) =3D 40 bytes. This let 256 - 2 -40 =3D 214 bytes for the PCE-DOMAINS and = PCE-NEIG-DOMAINS, which allows encoding 35 neighbor ASes for instance. Splitting a PCED TLV would add useless complexity. We are going to add this statement : The PCED TLV MUST fit in with a = single ISIS CAP TLV.=20 By the way this restricts the number of PCE domains and neighbor domains = to a reasonable value. Does that make sense? > > > > If it requires two IS-IS CAP TLVS, is there a requirement=20 > that they be=20 > > carried in the same LSP? > > > > > > > > 7.1. IS-IS sub-TLV > > > > Once a registry for the IS-IS Router Capability TLV defined in > > [IS-IS-CAP] will have been assigned, IANA will assign a new > > > > > > "has been assigned" would be better OK > > > > > > > > 9.5. Requirements on Other Protocols and Functional Components > > > > The IS-IS extensions defined in this documents does not imply any > > requirement on other protocols. > > > > do not imply (IS-IS extensions is plural) OK Thanks a lot. Once the last call is completed, we are going to submit a = new revision that accounts for all these comments. Regards, JL >=20 >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 01 15:52:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsGV-00041l-Sx; Thu, 01 Mar 2007 15:52:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsEU-00014f-Rt; Thu, 01 Mar 2007 15:50:35 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMsES-0002ce-FN; Thu, 01 Mar 2007 15:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 636D52AC91; Thu, 1 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMsDy-0002bx-4b; Thu, 01 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-manageability-requirements-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: , 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 : Inclusion of Manageability Sections in PCE Working Group Drafts Author(s) : A. Farrel Filename : draft-ietf-pce-manageability-requirements-01.txt Pages : 11 Date : 2007-3-1 It has often been the case that manageability considerations have been retrofitted to protocols after they have been speicified, standardized, implemented, and deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the recommendation for all new Internet-Drafts in the PCE Working Group to include a "Manageability Considerations" section, and gives guidance on what that section should contain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-manageability-requirements-01.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-manageability-requirements-01.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-manageability-requirements-01.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: <2007-3-1102245.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-manageability-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-manageability-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-1102245.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 Fri Mar 02 10:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN9Z4-0002zu-47; Fri, 02 Mar 2007 10:20:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN9Z3-0002z8-42 for pce@ietf.org; Fri, 02 Mar 2007 10:20:57 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN9Z0-00037J-Gv for pce@ietf.org; Fri, 02 Mar 2007 10:20:57 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l22FL0E6002925 for ; Fri, 2 Mar 2007 16:21:00 +0100 In-Reply-To: To: pce@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Fri, 2 Mar 2007 16:20:51 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/02/2007 16:20:52, Serialize complete at 03/02/2007 16:20:52 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Subject: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.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: , Errors-To: pce-bounces@lists.ietf.org a simple question the document repeats twice that it critical to monitor the state of the PC chain (see below) i try to understand reasoning - can authors clarify ? for perf.mon ? is the PCC going to tack perfs of PC servers ? for troubleshooting ? but for which trouble ? (this said, i am also concerned by the fact that if each PCC for each path across a set of PCEs starts to generate such state monitoring then for sure servers may experience overload) due to limited visibility ? why is this requiring "state monitoring" ? ---> in brief, i still believe a serious problem statement shall be brought up before jumping in the specification of objects (the bits of the wire) thanks, -d. -- "In PCE-based environments, it is critical to monitor the state of the path computation chain that can be used for performance monitoring and troubleshooting purposes. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in order to monitor the path computation chain and gather various performance metrics. As discussed in [RFC4655], a TE LSP may be computed by one PCE (referred to as single PCE path computation) or several PCEs (referred to as multiple PCE path computation). In the former case, the PCC may be able to use IGP extensions to check the liveness of the PCE (see [I-D.ietf-pce-disco-proto-ospf] and [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive messages. In contrast, when multiple PCEs are involved in the path computation chain an example of which is the BRPC procedure defined in [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the first PCE involved in the path computation chain. Thus, it is critical to define mechanisms in order to monitor the state of the path computation chain." -- Internet-Drafts@ietf.org 01/03/2007 21:50 Please respond to internet-drafts To: i-d-announce@ietf.org cc: Subject: I-D ACTION:draft-vasseur-pce-monitoring-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A set of monitoring tools for Path Computation Element based Architecture Author(s) : J. Le Roux, J. Vasseur Filename : draft-vasseur-pce-monitoring-02.txt Pages : 18 Date : 2007-3-1 A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). In PCE-based environments it is thus critical to monitor the state of the path computation chain that can be used for performance monitoring and troubleshooting purposes. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce-monitoring-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Mar 02 11:05:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAFU-0005Wp-2O; Fri, 02 Mar 2007 11:04:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAFS-0005WY-TK for pce@ietf.org; Fri, 02 Mar 2007 11:04:46 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNAFJ-0002yu-34 for pce@ietf.org; Fri, 02 Mar 2007 11:04:46 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2007 11:04:38 -0500 X-IronPort-AV: i="4.14,243,1170651600"; d="scan'208"; a="53923789:sNHT58186708" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l22G4aVk009674; Fri, 2 Mar 2007 11:04:36 -0500 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 l22G4aOE024464; Fri, 2 Mar 2007 11:04:36 -0500 (EST) 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.1830); Fri, 2 Mar 2007 11:03:49 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 11:03:48 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt Date: Fri, 2 Mar 2007 11:03:45 -0500 To: Dimitri.Papadimitriou@alcatel-lucent.be X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 02 Mar 2007 16:03:49.0135 (UTC) FILETIME=[5D52B9F0:01C75CE4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6793; t=1172851476; x=1173715476; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Re=3A=20I-D=20ACTION=3Adraft-vasseur-pce-moni toring-02.txt |Sender:=20 |To:=20Dimitri.Papadimitriou@alcatel-lucent.be; bh=GKLNTCHyApxK1y6VNAsN/IwFYXcpA0oLgbOQCiSO0xA=; b=n61hRftDkt2ibaxDOB3sCdA/3zt2ShuFqOcVIwghhCXVSe1MJL1ydpphcGqBfJiYrQMsQjMa u2FMDX2JRkg6DXKewIk0ryo4TNQI9f4iXxVvXQBkRY22631nXB4wDrpu; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > a simple question > > > the document repeats twice that it critical to monitor the state of > the PC chain (see below) > Yes indeed. > > i try to understand reasoning - can authors clarify ? > > for perf.mon ? is the PCC going to tack perfs of PC servers ? > > for troubleshooting ? but for which trouble ? I think that the motivation is fairly simple here ... You may want to monitor various aspects. For example, you may want to measure the path computation response time. That might be for performance monitoring or troubleshooting because a PCC experience very long response time. The motivation sounds extremely obvious: PCE OAM. As for any other system, the user may want to monitor the performance for network design, troubleshooting, ... > (this said, i am also > concerned by the fact that if each PCC for each path across a set of > PCEs starts to generate such state monitoring then for sure servers > may experience overload) Ah no ... this is an implementation issue on the PCE if you've such issue. Furthermore, if you experience an issue, would you prefer to ignore it or to be able to locate it ? > > due to limited visibility ? why is this requiring "state monitoring" ? > > > ---> in brief, i still believe a serious problem statement shall be > brought up before jumping in the specification of objects (the bits > of the wire) > > Hope this clarifies but the motivations are indeed quite straightforward. Thanks. JP. > thanks, > -d. > -- > > "In PCE-based environments, it is critical to monitor the state of the > path computation chain that can be used for performance monitoring > and troubleshooting purposes. This document specifies > procedures and > extensions to the Path Computation Element Protocol (PCEP) > ([I-D.ietf-pce-pcep]) in order to monitor the path computation > chain > and gather various performance metrics. > > As discussed in [RFC4655], a TE LSP may be computed by one PCE > (referred to as single PCE path computation) or several PCEs > (referred to as multiple PCE path computation). In the former > case, > the PCC may be able to use IGP extensions to check the liveness of > the PCE (see [I-D.ietf-pce-disco-proto-ospf] and > [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive messages. > In contrast, when multiple PCEs are involved in the path > computation > chain an example of which is the BRPC procedure defined in > [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the > first > PCE involved in the path computation chain. Thus, it is > critical to > define mechanisms in order to monitor the state of the path > computation chain." > > -- > > > > > > Internet-Drafts@ietf.org > 01/03/2007 21:50 > Please respond to internet-drafts > > To: i-d-announce@ietf.org > cc: > Subject: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A set of monitoring > tools for Path Computation Element based Architecture > Author(s) : J. Le Roux, J. Vasseur > Filename : > draft-vasseur-pce-monitoring-02.txt > Pages : 18 > Date : 2007-3-1 > > A Path Computation Element (PCE) based architecture has been > specified for the computation of Traffic Engineering (TE) Label > Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) networks in the context of single or > multiple domains (where a domain is referred to as a collection of > network elements within a common sphere of address management or > path > computational responsibility such as IGP areas and Autonomous > Systems). In PCE-based environments it is thus critical to monitor > the state of the path computation chain that can be used for > performance monitoring and troubleshooting purposes. This document > specifies procedures and extensions to the Path Computation Element > Protocol (PCEP) in order to gather such information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vasseur-pce- > monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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. > ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- > monitoring-02.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > _______________________________________________ > 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 Mar 02 11:17:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNARP-00068N-Ei; Fri, 02 Mar 2007 11:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNARN-00067e-LV for pce@ietf.org; Fri, 02 Mar 2007 11:17:05 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNARJ-0004Mu-FG for pce@ietf.org; Fri, 02 Mar 2007 11:17:05 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JEA00CKJA4KL9@usaga01-in.huawei.com> for pce@ietf.org; Fri, 02 Mar 2007 08:07:32 -0800 (PST) Received: from Lee736821 ([10.124.12.86]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JEA00FUSA4GQM@usaga01-in.huawei.com> for pce@ietf.org; Fri, 02 Mar 2007 08:07:32 -0800 (PST) Date: Fri, 02 Mar 2007 10:07:28 -0600 From: Young Lee Subject: [Pce] draft-lee-global-concurrent-optimization-02.txt To: pce@ietf.org Message-id: <000001c75ce4$e01686a0$560c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acdc5N9om49Fsw5dRLiZuzHUiL5dOg== X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae 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: , Content-Type: multipart/mixed; boundary="===============0679047355==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0679047355== Content-type: multipart/alternative; boundary="Boundary_(ID_vkh+doVwP/1HpygOUC2l/w)" This is a multi-part message in MIME format. --Boundary_(ID_vkh+doVwP/1HpygOUC2l/w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, We have posted a new revision (02) of PCE Global Concurrent Optimization (GCO) draft. Major changes have been made to be consistent with a new draft on objective functions (OF): pce-leroux-pce-of-00.txt. We'd appreciate WG comments and feedback. http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimiza tion-02.txt Regards, Young ----Original Message ------- * To: i-d-announce at ietf.org * Subject: I-D ACTION:draft-lee-pce-global-concurrent-optimization-02.txt * From: Internet-Drafts at ietf.org * Date: Thu, 01 Mar 2007 18:50:02 -0500 * Cc: * List-archive: * List-help: * List-id: i-d-announce.ietf.org * List-post: * List-subscribe: , * List-unsubscribe: , * Reply-to: internet-drafts at ietf.org _____ size=2 width="100%" align=center> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-lee-pce-global-concurrent-optimization-02.txt Pages : 30 Date : 2007-3-1 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A Global Concurrent Optimization is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all LSPs. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent path computation application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimiza tion-02.txt --Boundary_(ID_vkh+doVwP/1HpygOUC2l/w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

We have posted a new revision (02) of PCE Global Concurrent Optimization (GCO) draft.  Major changes have been made to be consistent with a new draft on objective functions (OF): pce-leroux-pce-of-00.txt.

 

We’d appreciate WG comments and feedback.

 

http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-02.txt

 

Regards,

 

Young

 

----Original Message -------

size=2 width="100%" align=center> 
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 
 
               Title                        : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization
               Author(s)                : Y. Lee, et al.
               Filename                : draft-lee-pce-global-concurrent-optimization-02.txt
               Pages                    : 30
               Date                       : 2007-3-1
               
The Path Computation Element (PCE) is a network component,
   application, or node that is capable of performing path computations
   at the request of Path Computation Clients (PCCs).  The PCE is
   applied in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
   determine the routes of Label Switched Paths (LSPs) through the
   network.  The Path Computation Element Communication Protocol (PCEP)
   is specified for communications between PCCs and PCEs, and between
   cooperating PCEs.
 
   When computing or re-optimizing the routes of a set of LSPs through a
   network it may be advantageous to perform bulk path computations in
   order to avoid blocking problems and to achieve more optimal network-
   wide solutions.  Such bulk optimization is termed Global Concurrent
   Optimization (GCO).  A Global Concurrent Optimization is able to
   simultaneously consider the entire topology of the network and the
   complete set of existing LSPs, and their respective constraints, and
   look to optimize or re-optimize the entire network to satisfy all
   constraints for all LSPs.
 
   This document provides application-specific requirements and the PCEP
   extensions in support of a global concurrent path computation
   application.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-02.txt

 

--Boundary_(ID_vkh+doVwP/1HpygOUC2l/w)-- --===============0679047355== 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 --===============0679047355==-- From pce-bounces@lists.ietf.org Fri Mar 02 11:50:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAxT-0003mz-Fr; Fri, 02 Mar 2007 11:50:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAxS-0003mp-HF for pce@ietf.org; Fri, 02 Mar 2007 11:50:14 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNAxR-0000oo-Oi for pce@ietf.org; Fri, 02 Mar 2007 11:50:14 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l22GoFYE029111; Fri, 2 Mar 2007 17:50:16 +0100 In-Reply-To: To: JP Vasseur Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Fri, 2 Mar 2007 17:50:08 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/02/2007 17:50:08, Serialize complete at 03/02/2007 17:50:08 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 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: , Errors-To: pce-bounces@lists.ietf.org hi j-p see in-line JP Vasseur 02/03/2007 17:03 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: pce@ietf.org Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt Hi Dimitri, On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > a simple question > > > the document repeats twice that it critical to monitor the state of > the PC chain (see below) > Yes indeed. > > i try to understand reasoning - can authors clarify ? > > for perf.mon ? is the PCC going to tack perfs of PC servers ? > > for troubleshooting ? but for which trouble ? I think that the motivation is fairly simple here ... You may want to monitor various aspects. For example, you may want to measure the path computation response time. That might be for performance monitoring or troubleshooting because a PCC experience very long response time. The motivation sounds extremely obvious: PCE OAM. As for any other system, the user may want to monitor the performance for network design, troubleshooting, ... [dp] PC response time, but how are you going to ensure that running conditions are identical at time t[n-1], t[n], t[n+1] ? in fact the question is the relevance of repeating a given request when the run conditions can be completely different > (this said, i am also > concerned by the fact that if each PCC for each path across a set of > PCEs starts to generate such state monitoring then for sure servers > may experience overload) Ah no ... this is an implementation issue on the PCE if you've such issue. [dp] i disagree, if one builds a PCE to sustain x PC demands per unit of time, but PCE gets now confronted to the fact that a number X of clients, X >> x, are permanently polling the server (remember that the PC server can be memoryless) for monitoring all the previously computed path, the running conditions are completely different, in fact the performance of your system degrades over time (i know a well known operating system that shows the same property ;-( => the PCE OAM mechanism implies a completely mode of operation that influence the capacity of the system Furthermore, if you experience an issue, would you prefer to ignore it or to be able to locate it ? [dp] use my local computation capability rely on "external domain" to solve an local problem may be > due to limited visibility ? why is this requiring "state monitoring" ? > > > ---> in brief, i still believe a serious problem statement shall be > brought up before jumping in the specification of objects (the bits > of the wire) > > Hope this clarifies but the motivations are indeed quite straightforward. [dp] unfortunately, i am not convinced about the usefulness of this mechanism and the problem is that if it would harmless then i would not have any issue but it is not Thanks. JP. > thanks, > -d. > -- > > "In PCE-based environments, it is critical to monitor the state of the > path computation chain that can be used for performance monitoring > and troubleshooting purposes. This document specifies > procedures and > extensions to the Path Computation Element Protocol (PCEP) > ([I-D.ietf-pce-pcep]) in order to monitor the path computation > chain > and gather various performance metrics. > > As discussed in [RFC4655], a TE LSP may be computed by one PCE > (referred to as single PCE path computation) or several PCEs > (referred to as multiple PCE path computation). In the former > case, > the PCC may be able to use IGP extensions to check the liveness of > the PCE (see [I-D.ietf-pce-disco-proto-ospf] and > [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive messages. > In contrast, when multiple PCEs are involved in the path > computation > chain an example of which is the BRPC procedure defined in > [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the > first > PCE involved in the path computation chain. Thus, it is > critical to > define mechanisms in order to monitor the state of the path > computation chain." > > -- > > > > > > Internet-Drafts@ietf.org > 01/03/2007 21:50 > Please respond to internet-drafts > > To: i-d-announce@ietf.org > cc: > Subject: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A set of monitoring > tools for Path Computation Element based Architecture > Author(s) : J. Le Roux, J. Vasseur > Filename : > draft-vasseur-pce-monitoring-02.txt > Pages : 18 > Date : 2007-3-1 > > A Path Computation Element (PCE) based architecture has been > specified for the computation of Traffic Engineering (TE) Label > Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) networks in the context of single or > multiple domains (where a domain is referred to as a collection of > network elements within a common sphere of address management or > path > computational responsibility such as IGP areas and Autonomous > Systems). In PCE-based environments it is thus critical to monitor > the state of the path computation chain that can be used for > performance monitoring and troubleshooting purposes. This document > specifies procedures and extensions to the Path Computation Element > Protocol (PCEP) in order to gather such information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vasseur-pce- > monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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. > ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- > monitoring-02.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > _______________________________________________ > 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 Mar 02 15:51:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEiH-0001ZC-Tj; Fri, 02 Mar 2007 15:50:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEhZ-0000T2-Js; Fri, 02 Mar 2007 15:50:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNEhY-0001Rd-Ce; Fri, 02 Mar 2007 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id DCAFC329ED; Fri, 2 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HNEhX-0002Yf-O0; Fri, 02 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 02 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-brpc-04.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: , 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 : A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-brpc-04.txt Pages : 18 Date : 2007-3-2 The ability to compute shortest constrained Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constrained paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-04.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-brpc-04.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-brpc-04.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: <2007-3-2140358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-brpc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-brpc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-2140358.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 Fri Mar 02 16:46:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFZk-0004GP-Cs; Fri, 02 Mar 2007 16:46:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEiW-0001yJ-JZ; Fri, 02 Mar 2007 15:51:04 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HNEiV-0003Rm-Gl; Fri, 02 Mar 2007 15:51:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id ED45C176CB; Fri, 2 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HNEhX-0002YZ-MW; Fri, 02 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 02 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-policy-enabled-path-comp-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: , 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 : Policy-Enabled Path Computation Framework Author(s) : I. Bryskin, et al. Filename : draft-ietf-pce-policy-enabled-path-comp-01.txt Pages : 33 Date : 2007-3-2 The PCE architecture [RFC4655] introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE Architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-policy-enabled-path-comp-01.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-policy-enabled-path-comp-01.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-policy-enabled-path-comp-01.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: <2007-3-2140007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-policy-enabled-path-comp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-policy-enabled-path-comp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-2140007.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 Fri Mar 02 17:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGAF-0004In-Vt; Fri, 02 Mar 2007 17:23:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGAE-0004Hs-4S for pce@ietf.org; Fri, 02 Mar 2007 17:23:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNGAB-0002v4-I8 for pce@ietf.org; Fri, 02 Mar 2007 17:23:46 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2007 14:23:44 -0800 X-IronPort-AV: i="4.14,244,1170662400"; d="scan'208,217"; a="396115196:sNHT111592820" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l22MNgk5014391 for ; Fri, 2 Mar 2007 14:23:42 -0800 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 l22MNXOC022064 for ; Fri, 2 Mar 2007 17:23:42 -0500 (EST) 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.1830); Fri, 2 Mar 2007 17:23:35 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 17:23:34 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <7027A09C-B524-41DA-B42A-DD49458D9790@cisco.com> References: From: JP Vasseur Subject: Fwd: [Pce] I-D ACTION:draft-ietf-pce-brpc-04.txt Date: Fri, 2 Mar 2007 17:23:32 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 02 Mar 2007 22:23:35.0011 (UTC) FILETIME=[6AC37B30:01C75D19] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20346; t=1172874222; x=1173738222; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[Pce]=20I-D=20ACTION=3Adraft-ietf-pce-brpc-04.txt=20 |Sender:=20; bh=CLfnAge9wkJAlbAGxNLea2Y8TbmawkLlyBnR2gX+c5g=; b=kcM1Uv0Qgbl82yc5tHdCmotKUujrif3wHbBnP2NirQ9bZKNiDVDB7fZ4sJ956nDIFeTBWRNY uxwYDY9UDYSOemUcnydLenDMmmR7WX2v3KLiEDYL5cxsbgCjLGXGLpmY; Authentication-Results: sj-dkim-5; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb 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: , Content-Type: multipart/mixed; boundary="===============1465033320==" Errors-To: pce-bounces@lists.ietf.org --===============1465033320== Content-Type: multipart/alternative; boundary=Apple-Mail-298--853999525 --Apple-Mail-298--853999525 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Main changes compared to rev-03: * New Manageability section in line with draft-ietf-pce-manageability- requirements * Security section has been fleshed out * Edits Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 2, 2007 3:50:03 PM EST > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D ACTION:draft-ietf-pce-brpc-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working > Group of the IETF. > > Title : A Backward Recursive PCE-based Computation (BRPC) > procedure to compute shortest inter-domain Traffic Engineering > Label Switched Paths > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-pce-brpc-04.txt > Pages : 18 > Date : 2007-3-2 > > The ability to compute shortest constrained Traffic Engineering (TE) > Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) networks across multiple domains > (where > a domain is referred to as a collection of network elements > within a > common sphere of address management or path computational > responsibility such as IGP areas and Autonomous Systems) has been > identified as a key requirement . This document specifies a > procedure relying on the use of multiple Path Computation Elements > (PCEs) in order to compute such inter-domain shortest constrained > paths along a determined sequence of domains, using a backward > recursive path computation technique while preserving > confidentiality > across domains, which is sometimes required when domains are > managed > by different Service Providers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-04.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-brpc-04.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-brpc-04.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. > Content-Type: text/plain > Content-ID: <2007-3-2140358.I-D@ietf.org> > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-298--853999525 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Main changes compared to = rev-03:
* New Manageability section in line with = draft-ietf-pce-manageability-requirements
* Security section = has been fleshed out
* Edits

Thanks.

JP.

Begin = forwarded message:

Date: March 2, 2007 3:50:03 PM = EST
To: i-d-announce@ietf.org
Subject: = [Pce] I-D ACTION:draft-ietf-pce-brpc-04.txt=A0

A New = Internet-Draft is available from the on-line Internet-Drafts=A0
This draft is a work item of the = Path Computation Element Working Group of the IETF.

= Title = = : A Backward Recursive PCE-based Computation (BRPC) procedure to = compute shortest inter-domain Traffic Engineering Label Switched = Paths
Author(s) : J. = Vasseur, et al.
Filename : = draft-ietf-pce-brpc-04.txt
= Pages = = : 18
Date : 2007-3-2


The ability = to compute shortest constrained Traffic Engineering (TE)
=A0=A0 = Label Switched Paths (LSPs) in Multiprotocol Label Switching = (MPLS)
=A0=A0 and Generalized MPLS = (GMPLS) networks across multiple domains (where
=A0=A0 = a domain is referred to as a collection of network elements = within a
=A0=A0 common sphere of address = management or path computational
=A0=A0 responsibility such as IGP = areas and Autonomous Systems) has been
=A0=A0 identified as a key = requirement .=A0 This = document specifies a
=A0=A0 procedure relying on the = use of multiple Path Computation Elements
=A0=A0 (PCEs) in order to compute = such inter-domain shortest constrained
=A0=A0 paths along a determined = sequence of domains, using a backward
=A0=A0 recursive path computation = technique while preserving confidentiality
=A0=A0 across domains, which is = sometimes required when domains are managed
=A0=A0 by different Service = Providers.

A URL for this Internet-Draft is:

To = remove yourself from the I-D Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-ietf-pce-brpc-04.txt".

A list of Internet-Drafts = directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-pce-brpc-04.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 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
Content-Type: = text/plain

=

= --Apple-Mail-298--853999525-- --===============1465033320== 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 --===============1465033320==-- From pce-bounces@lists.ietf.org Fri Mar 02 17:28:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGF5-0006mu-E4; Fri, 02 Mar 2007 17:28:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGF4-0006ma-0C for pce@ietf.org; Fri, 02 Mar 2007 17:28:46 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNGF2-0003o1-Or for pce@ietf.org; Fri, 02 Mar 2007 17:28:45 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2007 17:28:19 -0500 X-IronPort-AV: i="4.14,244,1170651600"; d="scan'208"; a="53949025:sNHT74618269114" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l22MSFbn021267 for ; Fri, 2 Mar 2007 17:28:15 -0500 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 l22MSFVT017005 for ; Fri, 2 Mar 2007 17:28:15 -0500 (EST) 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.1830); Fri, 2 Mar 2007 17:28:14 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 17:28:14 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <34AA8CEA-CB65-4A17-BC4E-F90487343CF4@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Fri, 2 Mar 2007 17:28:12 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 02 Mar 2007 22:28:14.0709 (UTC) FILETIME=[117A0250:01C75D1A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=365; t=1172874495; x=1173738495; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20PCEP=20Codepoints |Sender:=20 |To:=20pce@ietf.org; bh=NgEaGp94xtqrhfHW2iZm5hzxujrZyOFcoMJeVQ+Outk=; b=myTDcGw8gARDb4vjOWfEWCSSYafj3Cg1jEj7VAjWg4Qwi0ztPCjNjaFLixRoqKZgLNQug+T7 JaeCWl1QqsvlIzb5mLV557saCCgeQWWz4cHZi98Xi5qKWaDZ+3gJ3c9B; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Pce] PCEP Codepoints 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: , Errors-To: pce-bounces@lists.ietf.org Hi, As you know, Adrian generously offered to maintain the temporary PCEP registry of codepoints at http://www.olddog.co.uk/pce.htm until IANA takes over. Since there are several IDs defining new PCEP messages and objects, if you have such IDs, could you please send me the code-points so that we could update it accordingly ? Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Mar 02 17:44:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGUR-0005Pd-Ej; Fri, 02 Mar 2007 17:44:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGUP-0005Ma-FD for pce@ietf.org; Fri, 02 Mar 2007 17:44:37 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNGUN-0006XK-6k for pce@ietf.org; Fri, 02 Mar 2007 17:44:37 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2007 17:44:35 -0500 X-IronPort-AV: i="4.14,244,1170651600"; d="scan'208"; a="53949580:sNHT40755604" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l22MiYPm024474 for ; Fri, 2 Mar 2007 17:44:34 -0500 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 l22Mi9Vr019787 for ; Fri, 2 Mar 2007 17:44:34 -0500 (EST) 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.1830); Fri, 2 Mar 2007 17:44:31 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 17:44:31 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DBC6F4E-1BB6-4E82-876F-368B4D811FBA@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Fri, 2 Mar 2007 17:44:27 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 02 Mar 2007 22:44:31.0344 (UTC) FILETIME=[5798AF00:01C75D1C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=181; t=1172875475; x=1173739475; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20Draft=20WG=20Meeting=20Agenda |Sender:=20 |To:=20pce@ietf.org; bh=ajwNYOYyXzQDxhex5YuRcISSenXs0XrWraITWvJ9fJ0=; b=OG8q2aej7FG/q8PIfruRDfGgm0tdZ3tbOokZiIjDaJe9SXZn3LzwSazuYckOexsucA84jrcH VDeiUUoWt84V22HLq7/4P09weOqZw1wKXAI5zOu+ES3J/GPJvWnObuO1; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Pce] Fwd: Draft WG Meeting Agenda 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: , Errors-To: pce-bounces@lists.ietf.org > > Dear WG, > > The draft agenda has been posted: http://www3.ietf.org/proceedings/ > 07mar/agenda/pce.txt > > Let us know if you have any comment. > > Thanks. > > JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Mar 02 18:37:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNHJd-0000Xz-8j; Fri, 02 Mar 2007 18:37:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFL7-0000U2-CP for pce@ietf.org; Fri, 02 Mar 2007 16:30:57 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNF7E-0004qS-G1 for pce@ietf.org; Fri, 02 Mar 2007 16:16:39 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 02 Mar 2007 13:16:35 -0800 X-IronPort-AV: i="4.14,244,1170662400"; d="scan'208"; a="363825415:sNHT43618992" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l22LGZa7024741 for ; Fri, 2 Mar 2007 16:16:35 -0500 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 l22LGTVf000296 for ; Fri, 2 Mar 2007 16:16:35 -0500 (EST) 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.1830); Fri, 2 Mar 2007 16:16:34 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 16:16:34 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Fri, 2 Mar 2007 16:16:31 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 02 Mar 2007 21:16:34.0475 (UTC) FILETIME=[0E565FB0:01C75D10] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=162; t=1172870195; x=1173734195; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Draft=20WG=20Meeting=20Agenda |Sender:=20 |To:=20pce@ietf.org; bh=vl8RMzK9/2nwOabqKkRRJptE8zw/l3H27bMsm7mDhhQ=; b=UZgMMiv02LY+lwYykY0jeeIxQWZASyPWpim4wZy70+kRvmpu/MhYb/Fukfw7/NZLbaHkB7q7 CNSAU68tpXzUzlq0cD8WZVq4y6A0jO2F8WUM86Iz5jmIlfOKcBTWA4bo; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Pce] Draft WG Meeting Agenda 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: , Errors-To: pce-bounces@lists.ietf.org Dear WG, The draft agenda has been posted: http://www3.ietf.org/proceedings/ 07mar/agenda/pce.txt Let us know if you have any comment. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Mar 02 20:02:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNIcy-0002KW-LN; Fri, 02 Mar 2007 20:01:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNIcJ-0002Az-LB for pce@ietf.org; Fri, 02 Mar 2007 20:00:55 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HNIcE-0000uB-BE for pce@ietf.org; Fri, 02 Mar 2007 20:00:55 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-146.messagelabs.com!1172883645!2498198!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9630 invoked from network); 3 Mar 2007 01:00:45 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-146.messagelabs.com with SMTP; 3 Mar 2007 01:00:45 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2310fjF013073; Fri, 2 Mar 2007 20:00:41 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2310aYW013053; Fri, 2 Mar 2007 20:00:39 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] draft-leroux-pce-of-00.txt Date: Fri, 2 Mar 2007 18:53:31 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC827B@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] draft-leroux-pce-of-00.txt Thread-Index: AcdbVwERm/G70y43SzGrppgaWl9PcQBztA2Q References: From: "ASH, GERALD R, ATTLABS" To: "LE ROUX Jean-Louis RD-CORE-LAN" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Errors-To: pce-bounces@lists.ietf.org Hi JL, Looks like a good start. =20 Looking through the IANA section, I don't see registration of the objective functions (OFs) required in Section 5.1.17 of http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt: " The PCECP MUST support at least the following "unsynchronized" functions: - Minimum cost path with respect to a specified metric (shortest path) - Least loaded path - Maximum available bandwidth path Also, the PCECP MUST support at least the following "synchronized" objective functions: - Minimize aggregate bandwidth consumption on all links - Maximize the residual bandwidth on the most loaded link - Minimize the cumulative cost of a set of diverse paths" Shouldn't these standard OFs and their parameters be registered from the start? It would also be useful to illustrate how each of these OFs are encoded, perhaps in an illustrative appendix. How can new OFs be specified, i.e., how will extensibility of OFs and their parameters be accommodated? Thanks, Regards, Jerry ________________________________ From: LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@orange-ftgroup.com]=20 Sent: Wednesday, February 28, 2007 11:39 AM To: pce@ietf.org Subject: [Pce] draft-leroux-pce-of-00.txt=20 Hi all,=20 This new draft defines PCED and PCEP extensions for the encoding of objective functions.=20 We are waiting for WG feedback/comments.=20 http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt. Regards,=20 JL _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Mar 04 20:56:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO2QX-0000hJ-W5; Sun, 04 Mar 2007 20:55:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO2QX-0000hE-63 for pce@ietf.org; Sun, 04 Mar 2007 20:55:49 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO2QV-0000u4-Qg for pce@ietf.org; Sun, 04 Mar 2007 20:55:49 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 04 Mar 2007 17:55:47 -0800 X-IronPort-AV: i="4.14,247,1170662400"; d="scan'208,217"; a="363919760:sNHT75951596" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l251tkOU001221; Sun, 4 Mar 2007 20:55:46 -0500 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 l251tdZV012372; Mon, 5 Mar 2007 01:55:48 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Mar 2007 20:55:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Mar 2007 20:55:37 -0500 Message-ID: <06CA4D9493AD874B8222AD078A7AD0A202997B1F@xmb-rtp-205.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CLASSTYPE object for PCE Thread-Index: AcdeyV5WltfmUPtnREmgTD28t8MpXw== From: "Siva Sivabalan \(msiva\)" To: X-OriginalArrivalTime: 05 Mar 2007 01:55:38.0309 (UTC) FILETIME=[5F442F50:01C75EC9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1999; t=1173059746; x=1173923746; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=msiva@cisco.com; z=From:=20=22Siva=20Sivabalan=20\(msiva\)=22=20 |Subject:=20CLASSTYPE=20object=20for=20PCE |Sender:=20 |To:=20; bh=/+Z583szfc/aCHhuCs0ZJC7Kxqrtjn1Z4NYuh7FIcZk=; b=tY2PySVSpshXiBhjbol/TolUmJPeMNfKEiUN74orxTVc0xl4W9tspofzbbJ+mrAjpkrQghkL UR0wKmb01ZBhEwsT6/eZnTOza4K7bDXYTO4FMEhqty4As8zYZ3Om1doB; Authentication-Results: rtp-dkim-2; header.From=msiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: "Jon Parker \(jdparker\)" , "Sami Boutros \(sboutros\)" Subject: [Pce] CLASSTYPE object for PCE 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="===============1044775571==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1044775571== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75EC9.5EFAB5E7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75EC9.5EFAB5E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have posted a short draft (http://www.ietf.org/internet-drafts/draft-sivabalan-pce-dste-00.txt ) to introduce a new object for PCEP protocol. This object carries the class type of the TE LSP (whose path is to be computed via PCE) in the PCE request message. Your comments are appreciated. Thanks, Authors ------_=_NextPart_001_01C75EC9.5EFAB5E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have = posted a short=20 draft (http://www.ietf.org/internet-drafts/draft-sivabalan-pce-dste-00.= txt) to = introduce a=20 new object for PCEP protocol. This object carries the class type of the = TE LSP=20 (whose path is to be computed via PCE) in the PCE request=20 message.

Your = comments are=20 appreciated.

Thanks,

Authors

------_=_NextPart_001_01C75EC9.5EFAB5E7-- --===============1044775571== 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 --===============1044775571==-- From pce-bounces@lists.ietf.org Mon Mar 05 15:55:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKDA-0006Hx-D9; Mon, 05 Mar 2007 15:55:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK9P-0001jh-P4; Mon, 05 Mar 2007 15:51:19 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOK9H-0000VN-PB; Mon, 05 Mar 2007 15:51:19 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1B47C26ED2; Mon, 5 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8B-0005h9-Vi; Mon, 05 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-frwk-03.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: , 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 : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-ietf-pce-inter-layer-frwk-03.txt Pages : 1 Date : 2007-3-5 A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-03.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-inter-layer-frwk-03.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-inter-layer-frwk-03.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: <2007-3-5135224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-inter-layer-frwk-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-frwk-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5135224.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 Mon Mar 05 15:56:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKE3-0007n4-Hb; Mon, 05 Mar 2007 15:56:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK9Z-0001zt-45; Mon, 05 Mar 2007 15:51:29 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOK9Y-0000Ix-DI; Mon, 05 Mar 2007 15:51:28 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 089CA177F8; Mon, 5 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8B-0005gl-Ov; Mon, 05 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-07.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: , 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 : Path Computation Element (PCE) communication Protocol (PCEP) Author(s) : J. Le Roux, J. Vasseur Filename : draft-ietf-pce-pcep-07.txt Pages : 69 Date : 2007-3-5 This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. The PCEP protocol is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.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-pcep-07.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-pcep-07.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: <2007-3-5133004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcep-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcep-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5133004.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 Mon Mar 05 17:11:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLOT-0007pz-AT; Mon, 05 Mar 2007 17:10:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK9J-0001ZZ-1X; Mon, 05 Mar 2007 15:51:13 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOK8t-0000R0-NE; Mon, 05 Mar 2007 15:51:13 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 21320329D0; Mon, 5 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8C-0005hC-0F; Mon, 05 Mar 2007 15:50:04 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Mar 2007 15:50:04 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-req-04.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: , 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 : PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering Author(s) : E. Oki Filename : draft-ietf-pce-inter-layer-req-04.txt Pages : 9 Date : 2007-3-5 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-04.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-inter-layer-req-04.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-inter-layer-req-04.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: <2007-3-5135412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-inter-layer-req-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-req-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5135412.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 Mon Mar 05 17:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLUI-0003mh-JG; Mon, 05 Mar 2007 17:16:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKGk-0003dO-7S for pce@ietf.org; Mon, 05 Mar 2007 15:58:57 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOKFw-0001oQ-9O for pce@ietf.org; Mon, 05 Mar 2007 15:58:54 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Mar 2007 15:58:03 -0500 X-IronPort-AV: i="4.14,251,1170651600"; d="scan'208,217"; a="114962853:sNHT112410208" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l25Kw3nN005150 for ; Mon, 5 Mar 2007 15:58:03 -0500 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 l25KvrZp026660 for ; Mon, 5 Mar 2007 20:58:03 GMT 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.1830); Mon, 5 Mar 2007 15:57:47 -0500 Received: from [161.44.113.202] ([161.44.113.202]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 15:57:47 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <49B90233-EE9F-4F6C-8A68-44A2F2F618B2@cisco.com> References: From: JP Vasseur Subject: Fwd: [Pce] I-D ACTION:draft-ietf-pce-pcep-07.txt Date: Mon, 5 Mar 2007 15:57:45 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 05 Mar 2007 20:57:47.0413 (UTC) FILETIME=[EDCB9C50:01C75F68] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=24314; t=1173128283; x=1173992283; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[Pce]=20I-D=20ACTION=3Adraft-ietf-pce-pcep-07.txt=20 |Sender:=20 |To:=20pce@ietf.org; bh=4T94oCP6rRJr8MAHG1OkgBu77kOYLRtux2qwSylT+LA=; b=E1350qtxziJ5OKa2dZkxkqXvdxdTkmCyBPR4zkJ0q12R6jg9gYae5o+9pfGlCi3TbGrKB3yT LFVO25VpngZmfuyFPwBy6tM43t7At0HPD+mCB2VV4Vsqs8s4TD4HMA4S; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d 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: , Content-Type: multipart/mixed; boundary="===============1173179311==" Errors-To: pce-bounces@lists.ietf.org --===============1173179311== Content-Type: multipart/alternative; boundary=Apple-Mail-15--599946127 --Apple-Mail-15--599946127 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, Here are the changes made in rev-07: 1) Edits 2) Version field of the OPEN Object has been aligned with the version field of the PCEP common header message (both 3 bits) 3) Text Removed: * If a new PCEP session is established while the PCE is in congested state, the PCE MUST immediately send a PCNtf with Notification-type=2, Notification-value=1 along with the optional CONGESTION-DURATION TLV. 4) OpenWait value=1mn (amount of time a PCEP peer will wait to receive an OPEN) 5) Addition: Error-Type=3 or Error-Type=4: if a PCEP message is received that carries a PCEP object (with the P flag set) not recognized by the PCE or recognized but not supported, then the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=3 and 4 respectively). In addition, the PCC MAY include in the PCErr message the unknown object. The corresponding path computation request MUST be cancelled by the PCE without further notification. 6) Few Editorial updates in the FSM 7) Remove of PCErr Error-type=9 (DeadTimer): we just send the Close message with value=2 8) New Manageability section Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 5, 2007 3:50:03 PM EST > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working > Group of the IETF. > > Title : Path Computation Element (PCE) communication Protocol (PCEP) > Author(s) : J. Le Roux, J. Vasseur > Filename : draft-ietf-pce-pcep-07.txt > Pages : 69 > Date : 2007-3-5 > > This document specifies the Path Computation Element communication > Protocol (PCEP) for communications between a Path Computation > Client > (PCC) and a Path Computation Element (PCE), or between two PCEs. > Such interactions include path computation requests and path > computation replies as well as notifications of specific states > related to the use of a PCE in the context of Multiprotocol Label > Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. The > PCEP protocol is designed to be flexible and extensible so as to > easily allow for the addition of further messages and objects, > should > further requirements be expressed in the future. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.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-pcep-07.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-pcep-07.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. > Content-Type: text/plain > Content-ID: <2007-3-5133004.I-D@ietf.org> > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-15--599946127 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Dear = WG,=A0

Here are the changes made in rev-07:

1) = Edits
2) Version field of the OPEN = Object has been aligned with the version field of the PCEP common header = message (both 3 bits)
3) Text Removed:
*=A0 If a new PCEP session is established while the = PCE is in
=A0 =A0 =A0 =A0=A0 congested = state, the PCE MUST immediately send a PCNtf with
=A0 =A0 =A0 =A0=A0 Notification-type=3D2, = Notification-value=3D1 along with the
=A0 =A0 = =A0 =A0=A0 optional CONGESTION-DURATION TLV.
4) OpenWait value=3D1mn (amount of time a PCEP peer = will wait to receive an OPEN)
5) = Addition:
=A0 =A0Error-Type=3D3 or = Error-Type=3D4: if a PCEP message is received that
=A0=A0 carries a PCEP object (with the P flag set) = not recognized by the PCE
=A0=A0 or = recognized but not supported, then the PCE MUST send a PCErr
=A0=A0 message with a PCEP-ERROR object = (Error-Type=3D3 and 4 respectively).
=A0=A0 In = addition, the PCC MAY include in the PCErr message the = unknown
=A0=A0 object.=A0 The = corresponding path computation request MUST be cancelled
=A0=A0 by the PCE without further = notification.
6) Few Editorial updates in the = FSM
7) Remove of PCErr Error-type=3D9 = (DeadTimer): we just send the Close message with value=3D2
8) New Manageability section


JP.


Begin forwarded = message:

Date: March 5, 2007 3:50:03 PM = EST
To: i-d-announce@ietf.org
Subject: = [Pce] I-D ACTION:draft-ietf-pce-pcep-07.txt=A0

A New = Internet-Draft is available from the on-line Internet-Drafts=A0
This draft is a work item of the = Path Computation Element Working Group of the IETF.

= Title = = : Path Computation Element (PCE) communication Protocol = (PCEP)
Author(s) : J. Le = Roux, J. Vasseur
Filename : = draft-ietf-pce-pcep-07.txt
= Pages = = : 69
Date : 2007-3-5


This document = specifies the Path Computation Element communication
=A0=A0 = Protocol (PCEP) for communications between a Path Computation = Client
=A0=A0 (PCC) and a Path = Computation Element (PCE), or between two PCEs.
=A0=A0 = Such interactions include path computation requests and = path
=A0=A0 computation replies as = well as notifications of specific states
=A0=A0 related to the use of a = PCE in the context of Multiprotocol Label
=A0=A0 Switching (MPLS) and = Generalized (GMPLS) Traffic Engineering.=A0 The
=A0=A0 = PCEP protocol is designed to be flexible and extensible so as = to
=A0=A0 = easily allow for the addition of further messages and objects, = should
=A0=A0 further requirements be = expressed in the future.

A URL for this Internet-Draft = is:

To = remove yourself from the I-D Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-ietf-pce-pcep-07.txt".

A list of Internet-Drafts = directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-pce-pcep-07.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 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
Content-Type: = text/plain


= --Apple-Mail-15--599946127-- --===============1173179311== 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 --===============1173179311==-- From pce-bounces@lists.ietf.org Mon Mar 05 17:30:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLhC-0004sB-Vs; Mon, 05 Mar 2007 17:30:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKrR-0005gd-Vh for pce@ietf.org; Mon, 05 Mar 2007 16:36:50 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOKrM-0002Z2-Ul for pce@ietf.org; Mon, 05 Mar 2007 16:36:49 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 05 Mar 2007 13:36:44 -0800 X-IronPort-AV: i="4.14,251,1170662400"; d="scan'208"; a="118164452:sNHT56527668" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l25Lah86025762; Mon, 5 Mar 2007 16:36:43 -0500 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 l25LaZaF019937; Mon, 5 Mar 2007 21:36:41 GMT 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.1830); Mon, 5 Mar 2007 16:36:30 -0500 Received: from [161.44.113.202] ([161.44.113.202]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 16:36:29 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <114099D7-D38E-41EF-8F85-55DA474B4A0A@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt Date: Mon, 5 Mar 2007 16:36:27 -0500 To: Dimitri.Papadimitriou@alcatel-lucent.be X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 05 Mar 2007 21:36:29.0639 (UTC) FILETIME=[55F32D70:01C75F6E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9586; t=1173130603; x=1173994603; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Re=3A=20I-D=20ACTION=3Adraft-vasseur-pce-moni toring-02.txt |Sender:=20 |To:=20Dimitri.Papadimitriou@alcatel-lucent.be; bh=rZlPmNrO/R+o45ovLJFJTEglMbJ2wGWBavnwQm11qpI=; b=CumF/2lG3CyQ2RhR3OAW7bADwClrOyXzKq5oyKTRsykbnqHbVgJrTnj3m23ZlduUqH1l3gRl i1pZK6V6e5lrmX56eQY7+NEui4d06rmU43sggfYFmQW/WcYmvYAlraDZ; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e 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: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, On Mar 2, 2007, at 11:50 AM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > hi j-p > > see in-line > > > > > JP Vasseur > 02/03/2007 17:03 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: pce@ietf.org > Subject: Re: [Pce] Re: I-D > ACTION:draft-vasseur-pce-monitoring-02.txt > > > Hi Dimitri, > > On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel-lucent.be > wrote: > >> a simple question >> >> >> the document repeats twice that it critical to monitor the state of >> the PC chain (see below) >> > > Yes indeed. > >> >> i try to understand reasoning - can authors clarify ? >> >> for perf.mon ? is the PCC going to tack perfs of PC servers ? >> >> for troubleshooting ? but for which trouble ? > > I think that the motivation is fairly simple here ... You may want to > monitor various aspects. > For example, you may want to measure the path computation response > time. That might be > for performance monitoring or troubleshooting because a PCC > experience very long response > time. The motivation sounds extremely obvious: PCE OAM. As for any > other system, the user > may want to monitor the performance for network design, > troubleshooting, ... > > [dp] PC response time, but how are you going to ensure that running > conditions are identical at time t[n-1], t[n], t[n+1] ? in fact the > question is the relevance of repeating a given request when the run > conditions can be completely different You may not be able to capture a transient issue but this is similar to the issue of a packet experiencing a transient congestion: you do a traceroute and when the packet is processed the issue might have disappeared. Still, it is useful to have the tool the determine a bootleneck that sustains. Furthermore you get the average/max and potentially other metrics of interest that relate to a past event. > >> (this said, i am also >> concerned by the fact that if each PCC for each path across a set of >> PCEs starts to generate such state monitoring then for sure servers >> may experience overload) > > Ah no ... this is an implementation issue on the PCE if you've such > issue. > > [dp] i disagree, if one builds a PCE to sustain x PC demands per unit > of time, but PCE gets now confronted to the fact that a number X of > clients, X >> x, are permanently polling the server (remember that > the PC server can be memoryless) for monitoring all the previously > computed path, the running conditions are completely different, in > fact the performance of your system degrades over time (i know a well > known operating system that shows the same property ;-( Not sure what you refer to. But let me re-explain: Indeed the PCC may start to send many such monitoring requests but here is my first point: you PCC must make sure to act diligently here. Using the same analogy as before you could send thousands of ping to a congested host ... bad idea of course. Moreover your PCE scheduler should smartly handle various requests types. It it gets congested there are many ways to avoid more congestion and thus to impact the actual path computation requests because of monitoring requests. > > => the PCE OAM mechanism implies a completely mode of operation that > influence the capacity of the system > > Furthermore, if you experience an issue, would you prefer to ignore > it or to be able to locate it ? > > [dp] use my local computation capability rely on "external domain" > to solve an local problem may be ? > > >> due to limited visibility ? why is this requiring "state >> monitoring" ? >> >> >> ---> in brief, i still believe a serious problem statement shall be >> brought up before jumping in the specification of objects (the bits >> of the wire) >> >> > > Hope this clarifies but the motivations are indeed quite > straightforward. > > [dp] unfortunately, i am not convinced about the usefulness of this > mechanism and the problem is that if it would harmless then i would > not have any issue but it is not > Hope that I shed some light. Thanks. JP. > Thanks. > > JP. > >> thanks, >> -d. >> -- >> >> "In PCE-based environments, it is critical to monitor the state of >> the >> path computation chain that can be used for performance monitoring >> and troubleshooting purposes. This document specifies >> procedures and >> extensions to the Path Computation Element Protocol (PCEP) >> ([I-D.ietf-pce-pcep]) in order to monitor the path computation >> chain >> and gather various performance metrics. >> >> As discussed in [RFC4655], a TE LSP may be computed by one PCE >> (referred to as single PCE path computation) or several PCEs >> (referred to as multiple PCE path computation). In the former >> case, >> the PCC may be able to use IGP extensions to check the liveness of >> the PCE (see [I-D.ietf-pce-disco-proto-ospf] and >> [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive messages. >> In contrast, when multiple PCEs are involved in the path >> computation >> chain an example of which is the BRPC procedure defined in >> [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the >> first >> PCE involved in the path computation chain. Thus, it is >> critical to >> define mechanisms in order to monitor the state of the path >> computation chain." >> >> -- >> >> >> >> >> >> Internet-Drafts@ietf.org >> 01/03/2007 21:50 >> Please respond to internet-drafts >> >> To: i-d-announce@ietf.org >> cc: >> Subject: I-D ACTION:draft-vasseur-pce- >> monitoring-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : A set of >> monitoring >> tools for Path Computation Element based Architecture >> Author(s) : J. Le Roux, J. Vasseur >> Filename : >> draft-vasseur-pce-monitoring-02.txt >> Pages : 18 >> Date : 2007-3-1 >> >> A Path Computation Element (PCE) based architecture has been >> specified for the computation of Traffic Engineering (TE) Label >> Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and >> Generalized MPLS (GMPLS) networks in the context of single or >> multiple domains (where a domain is referred to as a collection of >> network elements within a common sphere of address management or >> path >> computational responsibility such as IGP areas and Autonomous >> Systems). In PCE-based environments it is thus critical to >> monitor >> the state of the path computation chain that can be used for >> performance monitoring and troubleshooting purposes. This >> document >> specifies procedures and extensions to the Path Computation >> Element >> Protocol (PCEP) in order to gather such information. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-vasseur-pce- >> monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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. >> ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- >> monitoring-02.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> >> >> _______________________________________________ >> 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 Mar 06 04:53:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOWMV-0004Vc-Dk; Tue, 06 Mar 2007 04:53:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLPv-0008MX-5X for pce@ietf.org; Mon, 05 Mar 2007 17:12:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOLPs-0004m5-Pa for pce@ietf.org; Mon, 05 Mar 2007 17:12:27 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 05 Mar 2007 14:12:25 -0800 X-IronPort-AV: i="4.14,251,1170662400"; d="scan'208"; a="397147864:sNHT68267628" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l25MCOPt013460; Mon, 5 Mar 2007 14:12:24 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l25MCMe1007268; Mon, 5 Mar 2007 22:12:22 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 14:12:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG Date: Mon, 5 Mar 2007 14:12:18 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG Thread-Index: AcdVqbsCDFY8XNsfSDmUKalXm8vpAwGhdhYAANBXXUA= From: "Les Ginsberg \(ginsberg\)" To: "LE ROUX Jean-Louis RD-CORE-LAN" , , X-OriginalArrivalTime: 05 Mar 2007 22:12:19.0713 (UTC) FILETIME=[577E6F10:01C75F73] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11084; t=1173132744; x=1173996744; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ginsberg@cisco.com; z=From:=20=22Les=20Ginsberg=20\(ginsberg\)=22=20 |Subject:=20RE=3A=20[Pce]=20Comments=20on=20draft-ietf-pce-disco-proto-is is-02.txt=20from=20ISISWG |Sender:=20; bh=9zo/1XYGaKc/Qhl5mwkhkxUe16ZW+feEqvs4k4rB9Iw=; b=mqolE6kb8TWitJ2CUR2gCnzdEl0swZthZSNVuDh7ZvHhYy3NL4ajCdlJiygKeham9dJeAGkj OXdYU1MH/tYiiQJmVygCJfwqFECikwxbTM/ev+P1kuFp4p60hFHXxW/O; Authentication-Results: sj-dkim-3; header.From=ginsberg@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 X-Mailman-Approved-At: Tue, 06 Mar 2007 04:53:38 -0500 Cc: Chris Hopps , David Ward , "Mike Shand \(mshand\)" 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: , Errors-To: pce-bounces@lists.ietf.org Jean-Louis - Sorry for the delayed response. Comments inline. > -----Original Message----- > From: LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@orange- > ftgroup.com] > Sent: Thursday, March 01, 2007 11:14 AM > To: adrian@olddog.co.uk; pce@ietf.org; Les Ginsberg (ginsberg) > Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt = from > ISISWG >=20 > Hi Les, >=20 > Thanks for these comments. >=20 > Please see inline, >=20 > > -----Message d'origine----- > > De : Adrian Farrel [mailto:adrian@olddog.co.uk] > > Envoy=E9 : mercredi 21 f=E9vrier 2007 11:53 > > =C0 : pce@ietf.org > > Objet : [Pce] Comments on > > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG > > > > ----- Original Message ----- > > > > From: "Les Ginsberg (ginsberg)" > > To: "Adrian Farrel" ; > > Cc: "Jean Philippe Vasseur (jvasseur)" > > Sent: Monday, February 19, 2007 6:56 PM > > Subject: RE: [Isis-wg] PCE working group last call > > > > ondraft-ietf-pce-disco-proto-isis-02.txt > > > > > > Section 1 > > > > ABR: IGP Area Border Router (L1L2 router). > > > > LES: Use "L2 capable router" instead - or eliminate the > > definition since as Mike points out it is not used in the document. >=20 > OK, to be eliminated >=20 > > > > Examples of domains include IGP areas and Autonomous Systems. > > > > LES: area and domain are not the same - though a domain may > > have only one area. I would omit this sentence. >=20 > In the PCE context the defintion of a domain is as follows (as per RFC > 4655): >=20 > "A domain is any collection of network elements within a common sphere = of > address management or path computation responsibility. Examples of > domains include IGP areas, Autonomous Systems (ASes), and multiple = ASes > within a Service Provider network. Domains of path computation > responsibility may also exist as sub-domains of areas or ASes." >=20 > Is that OK if we refer to [RFC4655] and indicate that this definition > applies to a PCE context? I think in an IS-IS specific document this is going to get confusing - = as area and domain have a very specific meaning. So I think you need to = define this as "PCE-domain", reference RFC4655, and make clear that this = should be distinguished from a domain as defined by ISO 10589 - and use = "PCE_domain" in all the appriopriate places in the document. >=20 >=20 > > > > Section 3.1.1 > > > > inter-area, inter-AS, inter-layer\205 > > > > LES: Remove Formatting character \205 >=20 > OK >=20 > > > > Section 3.2 > > > > The flooding scope for PCE information advertised through IS-IS = can > > be limited to one or more IS-IS areas the PCE belongs to, or can = be > > > > LES: Flooding can only be area or domain scoped flooding. > > There is no defined method to restrict flooding to some > > subset of the areas in a domain. >=20 > Right. We are going to rephrase as follows: >=20 > The flooding scope for PCE information advertised through IS-IS can be = a > single L1 area, a L1 area and the L2 sub-domain (when the PCE is a = L1L2 > node), or the entire IS-IS domain (S bit set in the Router Capability > TLV). The three options are: 1)Single L1 area (only available at Level-1 - S bit clear) 2)L2 sub-domain (only available at Level-2 when S bit is clear) 3)Entire routing domain (S bit set) You cannot do a combination of #1 and #2 as your statement suggests. >=20 > Does that make sense? >=20 > > > > extended across the entire IS-IS routing domain. > > Note that some PCEs may belong to multiple areas, in which case = the > > flooding scope may comprise these areas. This could be the > > case for a > > > > L1L2 router for instance advertising its PCE information within = the > > L2 area and/or a subset of its attached L1 area(s). > > > > LES: There is no such thing as an L2 area. There is the L2 > > sub-domain, which consists of all L2 routers in a domain. >=20 > OK, we are going to remove the above paragraph >=20 > > > > Section 4.1. The IS-IS PCED TLV > > > > LES: This is a sub-TLV. As Mike has pointed out, it is > > important to use that terminology consistently throughout the > > document. >=20 > OK >=20 > > > > The format of the IS-IS PCED TLV and its sub-TLVs is the > > identical to > > > > > > LES: s/the identical/identical >=20 > OK >=20 > > > > At the end of Section 4.1 it might be helpful to add: > > > > "The following sub-sections describe the sub-TLVs which may > > be carried within the PCED sub-TLV." >=20 > OK >=20 > > > > Section 4.1.3 > > > > Two DOMAIN sub-TLVs are defined > > > > Sub-TLV type Length Name > > 1 Variable Area ID sub-TLV > > 2 4 AS number sub-TLV > > > > LES: These codepoints are not mentioned in the IANA section. >=20 > OK, to be added. >=20 > > > > Section 4.1.3.1 > > > > VALUE: This comprises a variable length IS-IS area ID. This is = the > > > > combination of an Initial Domain Part (IDP) and High Order > > part of the Domain Specific part (HO-DSP) > > > > LES: Rather than invent a term (HO-DSP) which ISO 10589 does > > not use, say "this is the area address as defined in [ISO]". >=20 > OK >=20 > > Which causes me to mention that you have no reference to ISO > > 10589 in the references section, a most serious breach of > > etiquette indeed!! >=20 > OK, to be added >=20 > > > > Section 4.1.4 > > > > LES: The domain/area sub-TLVs (nested level 3) which are defined in > > 4.1.3 appear to be "reused" here. This should be explicitly > > stated as the scope of the sub-TLV codepoint for domain/area > > sub-TLVs is the parent sub-TLV (PCE-domain or > > PCE-NEIG-DOMAIN) and therefore the codepoints cannot be > > assumed to be the same - it MUST be explicitly stated. >=20 > OK >=20 > > > > Section 5 > > > > defined in [IS-IS-CAP]. A such, elements of procedures are > > inherited > > > > > > LES: s/A such/As such >=20 > OK >=20 > > > > domain, itMUST be carried within an IS-IS CAPABILITY TLV > > having the S > > > > > > LES: s/itMUST/it MUST >=20 > OK >=20 > > > > A PCE MUST originate a new IS-IS LSP whenever the content > > > > LES: There is a generic issue here. As a PCE is not a router > > running the IS-IS protocol, it cannot generate any LSPs. :-) > > Therefore you cannot say (as you do in multiple places) "a > > PCE originates a new IS-IS LSP". >=20 > You are right the PCE is a functional block. But it is often = assimilated > to the node hosting the PCE function, which is an IS-IS node in this > draft. > Is that OK if we say "An IS-IS node acting as PCE MUST originate"... But it is also possible to have a PCE which is NOT running on a node = which is acting as an IS-IS router. In that case the PCE information is = passed to the IS-IS node in some manner which is beyond the scope of = this document and IS-IS still advertises the information, but as the IP = address of the PCE is NOT an address of the IS-IS router it is wrong to = say the IS-IS is "acting as a PCE". IS-IS is simply advertising PCE = information which has been provided to it. It does not act as a PCE in = any way. >=20 > > Similarly, you say: > > > > A PCC MUST be > > able to detect that the PCED TLV has been removed from an > > IS-IS LSP. > > > > As a PCC is also not equivalent to a router running the IS-IS > > protocol, perhaps you want to say "A PCC MUST be informed..." >=20 > Let say "An IS-IS node acting as PCC..." ? Please see my previous comment. >=20 > > - although I tend to think that all of the communication > > between the applications (PCE and > > PCC) and the IS-IS protocol instance is out of scope for this > > document. >=20 > Yes it is out of the scope. So, you could just remove the language entirely. Les >=20 >=20 >=20 > > > > The PCE address, i.e. the address indicated within the PCE = ADDRESS > > sub-TLV, MUST be distributed as part of IS-IS routing; > > > > LES: I am not sure what you mean here. Do you mean that there > > MUST be a host route advertisement for the PCE address(es)? > > Or do you simply mean that the PCE address(es) must be > > reachable via some prefix(es) advertised by IS-IS? If the > > latter, then please change the wording. As written it > > suggests there is a special advertisement required. >=20 > Yes this is the latter, we are going to rephrase as suggested. >=20 > > > > Section 8 > > > > IS-IS provides no mechanism for protecting the privacy of LSAs, = and > > > > LES: I don't know what you are trying to say here. Do you mean TLVs? > > Certainly not LSAs! >=20 > Yes TLVs :-) >=20 > > > > > > in particular the privacy PCE discovery information. > > > > LES: s/privacy/privacy of >=20 > OK >=20 > Again, thanks a lot for these comments. > Once the last call is completed, we are going to submit a new revision > that accounts for all these comments. >=20 > Best Regards, >=20 > JL >=20 > > > > Les > > > > > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > Sent: Wednesday, February 14, 2007 9:36 AM > > > To: isis-wg@ietf.org > > > Cc: Jean Philippe Vasseur (jvasseur) > > > Subject: [Isis-wg] PCE working group last call > > ondraft-ietf-pce-disco- > > > proto-isis-02.txt > > > > > > Hi, > > > > > > The PCE working group is holding a last call on > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto > > -isis-02.t > > xt > > > > > > Since this I-D proposes protocol extensions to ISIS we > > would like the > > ISIS > > > working group to participate in this last call, and we have > > accordingly > > > made > > > the last call period three weeks in order to give you plenty of = time > > to > > > respond. > > > > > > The last call will end at 12 noon GMT on Thursday 8th March. > > > > > > Please send your comments to the PCE mailing list if you are > > subscribed. > > > Otherwise, please channel your comments through the PCE > > working group > > > chairs (adrian@olddog.co.uk and jvasseur@cisco.com) > > > > > > Background reading is: > > > RFC4655 - The PCE Architecture > > > RFC4674 - Requirements for Path Computation Element (PCE) = Discovery > > > (These are the requirements that this I-D is > > addressing) > > > > > > > > > Thanks, > > > Adrian > > > > > > > > > > > > _______________________________________________ > > > Isis-wg mailing list > > > Isis-wg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > > > > _______________________________________________ > > 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 Mar 06 12:37:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOdb1-0008EF-Jz; Tue, 06 Mar 2007 12:37:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOdb0-000896-1h for pce@lists.ietf.org; Tue, 06 Mar 2007 12:37:06 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOday-0001Os-HB for pce@lists.ietf.org; Tue, 06 Mar 2007 12:37:06 -0500 Received: (qmail invoked by alias); 06 Mar 2007 17:37:03 -0000 Received: from host48.natpool.mwn.de (EHLO r049048.osh.swh.mhn.de) [138.246.7.48] by mail.gmx.net (mp017) with SMTP; 06 Mar 2007 18:37:03 +0100 X-Authenticated: #19887475 X-Provags-ID: V01U2FsdGVkX1/CCY5b6lDCiU7tShysC0keIoK4FFwjX86wnVqHCJ b3O2BnbwQt8rvq From: Dennis Aristow <_den@gmx.de> To: pce@lists.ietf.org Date: Tue, 6 Mar 2007 18:37:01 +0100 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703061837.02525._den@gmx.de> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Pce] contradiction in section 10 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: , Errors-To: pce-bounces@lists.ietf.org In section 10. where the Idle-State is descripted: ... In Idle state, PCEP resources are allocated (memory, potential process, ...) but no PCEP messages are accepted from any PCEP peer. ... Upon receiving a TCP connection on the well-known PCEP TCP port, if the PCE is in congested state, the PCE MUST immediately send a PCErr with Notification-type=2, Notification-value=1 along with the optional CONGESTION-DURATION TLV (see Section 7.13). ... These 2 pieces of text seems to be in contradiction with each other. How it must be possible to send an PCNtf message if there are no PCEP session established? _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 07 04:04:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOs3q-00043f-U3; Wed, 07 Mar 2007 04:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOj9i-0006vq-5U for pce@ietf.org; Tue, 06 Mar 2007 18:33:18 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOj9E-0006gO-Mh for pce@ietf.org; Tue, 06 Mar 2007 18:32:49 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 00:32:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG Date: Wed, 7 Mar 2007 00:32:23 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG Thread-Index: Acdfzdp4rAoESyYGRgGoIS9nDt957AATZRFgAAn4jHA= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Les Ginsberg \(ginsberg\)" , "Mike Shand \(mshand\)" X-OriginalArrivalTime: 06 Mar 2007 23:32:20.0422 (UTC) FILETIME=[AF5A3E60:01C76047] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a3b79fd9d7bf2ef1762376a62c51ec4 Cc: Chris Hopps , pce@ietf.org, David Ward 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: , Errors-To: pce-bounces@lists.ietf.org Hi Les,=20 > -----Message d'origine----- > De : Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]=20 > Envoy=E9 : mardi 6 mars 2007 19:28 > =C0 : Mike Shand (mshand) > Cc : LE ROUX Jean-Louis RD-CORE-LAN; zzx-adrian@olddog.co.uk;=20 > pce@ietf.org; David Ward; Chris Hopps > Objet : RE: [Pce] Comments on=20 > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG >=20 >=20 >=20 > > -----Original Message----- > > From: Mike Shand (mshand) > > Sent: Tuesday, March 06, 2007 12:40 AM > > To: Les Ginsberg (ginsberg) > > Cc: LE ROUX Jean-Louis RD-CORE-LAN; adrian@olddog.co.uk;=20 > pce@ietf.org;=20 > > David Ward; Chris Hopps > > Subject: RE: [Pce] Comments on=20 > draft-ietf-pce-disco-proto-isis-02.txt=20 > > from ISISWG > >=20 > > I agree with Les' responses. My only concern is the issue=20 > of whether=20 > > or not a PCE is an IS-IS router or not. I assume that it=20 > usually is,=20 > > but need not be. The text doesn't seem to work for the case=20 > where it=20 > > is not. Is the assumption that in this case some IS-IS router will=20 > > APPEAR to be a PCE, but the actual PCE will be located=20 > elsewhere and=20 > > some undefined communication method used between the two. In that=20 > > case, to all intents and purposes the IS-IS router *is* a=20 > PCE, in just=20 > > the same way that you could (if you were so minded) have an IS-IS=20 > > router whose SPF processing was handed off to some other piece of=20 > > hardware located elsewhere in the network. > >=20 > > I guess the question I am asking is; can you tell by looking at the=20 > > bits on the wire whether the PCE function is collocated=20 > with an IS-IS=20 > > router or not? > >=20 > > If you can tell (and hence distinguish the case where it is not),=20 > > then draft needs to describe this. If you can't tell, then I guess=20 > > there is no issue. >=20 > I think I am slightly less forgiving with the language in the=20 > draft than Mike. >=20 > Quoting RFC 4655 >=20 > "A Path Computation Element (PCE) is an entity that is capable of > computing a network path or route based on a network graph, and of > applying computational constraints during the computation. The PCE > entity is an application that can be located within a=20 > network node or > component, on an out-of-network server, etc." >=20 > I don't think it matters whether the PCE happens to be=20 > co-located on a router running an IS-IS instance or not - the=20 > key point is that a PCE (as well as PCC) is NOT an instance=20 > of the IS-IS protocol. It therefore is simply wrong to say -=20 > as you do in Section 5: >=20 > "A PCE MUST originate a new IS-IS LSP..."=20 >=20 > And it is also wrong to say as you do later in the same section > =20 > "When the PCE function is deactivated on a node, the node=20 > MUST originate a new IS-IS..." >=20 > I don't think this should be very controversial - just avoid=20 > language which suggests that because IS-IS happens to be=20 > advertising information on behalf of a PCE application that=20 > it is the PCE application which is actually responsible for=20 > actions which are clearly the responsibility of the IS-IS instance. >=20 > For example, for the latter case you might say something like: >=20 > "When the PCE function is deactivated the information=20 > associated with this PCE which is currently being advertised=20 > in IS-IS LSPs MUST be withdrawn." OK, I get your point, so what about: An IS-IS router MUST originate a new IS-IS LSP whenever there is a = change in a PCED TLV=20 associated with a PCE it advertises. =20 When a PCE is deactivated, the IS-IS Router advertising this PCE MUST = =20 originate a new IS-IS LSP that does no longer include the = corresponding PCED TLV.=20 Regards, JL >=20 > (Just a suggestion) >=20 > Les >=20 >=20 > >=20 > >=20 > > Mike > >=20 > >=20 > >=20 > > Mike > >=20 > > At 22:12 05/03/2007, Les Ginsberg \(ginsberg\) wrote: > >=20 > > >Jean-Louis - > > > > > >Sorry for the delayed response. > > >Comments inline. > > > > > > > -----Original Message----- > > > > From: LE ROUX Jean-Louis RD-CORE-LAN=20 > > > > [mailto:jeanlouis.leroux@orange- ftgroup.com] > > > > Sent: Thursday, March 01, 2007 11:14 AM > > > > To: adrian@olddog.co.uk; pce@ietf.org; Les Ginsberg (ginsberg) > > > > Subject: RE: [Pce] Comments on=20 > > > > draft-ietf-pce-disco-proto-isis-02.txt > > from > > > > ISISWG > > > > > > > > Hi Les, > > > > > > > > Thanks for these comments. > > > > > > > > Please see inline, > > > > > > > > > -----Message d'origine----- > > > > > De : Adrian Farrel [mailto:adrian@olddog.co.uk] Envoy=E9 :=20 > > > > > mercredi 21 f=E9vrier 2007 11:53 =C0 : pce@ietf.org Objet : = [Pce]=20 > > > > > Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Les Ginsberg (ginsberg)" > > > > > To: "Adrian Farrel" ; > > > > > Cc: "Jean Philippe Vasseur (jvasseur)" > > > > > Sent: Monday, February 19, 2007 6:56 PM > > > > > Subject: RE: [Isis-wg] PCE working group last call > > > > > > > > > > ondraft-ietf-pce-disco-proto-isis-02.txt > > > > > > > > > > > > > > > Section 1 > > > > > > > > > > ABR: IGP Area Border Router (L1L2 router). > > > > > > > > > > LES: Use "L2 capable router" instead - or eliminate the=20 > > > > > definition since as Mike points out it is not used in=20 > the document. > > > > > > > > OK, to be eliminated > > > > > > > > > > > > > > Examples of domains include IGP areas and=20 > Autonomous Systems. > > > > > > > > > > LES: area and domain are not the same - though a=20 > domain may have=20 > > > > > only one area. I would omit this sentence. > > > > > > > > In the PCE context the defintion of a domain is as=20 > follows (as per=20 > > > > RFC > > > > 4655): > > > > > > > > "A domain is any collection of network elements within a common=20 > > > > sphere > > of > > > > address management or path computation responsibility. =20 > Examples=20 > > > > of domains include IGP areas, Autonomous Systems (ASes), and=20 > > > > multiple > > ASes > > > > within a Service Provider network. Domains of path computation=20 > > > > responsibility may also exist as sub-domains of areas or ASes." > > > > > > > > Is that OK if we refer to [RFC4655] and indicate that this=20 > > > > definition applies to a PCE context? > > > > > >I think in an IS-IS specific document this is going to get=20 > confusing=20 > > >- as area and domain have a very specific meaning. So I think you=20 > > >need to define this as "PCE-domain", reference RFC4655, and make=20 > > >clear that this should be distinguished from a domain as=20 > defined by=20 > > >ISO 10589 - and use "PCE_domain" in all the appriopriate places in=20 > > >the document. > >=20 > > I agree. > >=20 > >=20 > > > > > > > > > > > > > > > > > > Section 3.1.1 > > > > > > > > > > inter-area, inter-AS, inter-layer\205 > > > > > > > > > > LES: Remove Formatting character \205 > > > > > > > > OK > > > > > > > > > > > > > > Section 3.2 > > > > > > > > > > The flooding scope for PCE information advertised through=20 > > > > > IS-IS > > can > > > > > be limited to one or more IS-IS areas the PCE=20 > belongs to, or=20 > > > > > can > > be > > > > > > > > > > LES: Flooding can only be area or domain scoped flooding. > > > > > There is no defined method to restrict flooding to=20 > some subset=20 > > > > > of the areas in a domain. > > > > > > > > Right. We are going to rephrase as follows: > > > > > > > > The flooding scope for PCE information advertised through IS-IS=20 > > > > can be > > a > > > > single L1 area, a L1 area and the L2 sub-domain (when=20 > the PCE is a > > L1L2 > > > > node), or the entire IS-IS domain (S bit set in the Router=20 > > > > Capability TLV). > > > > > >The three options are: > > > > > >1)Single L1 area (only available at Level-1 - S bit clear) > > >2)L2 sub-domain (only available at Level-2 when S bit is clear)=20 > > >3)Entire routing domain (S bit set) > > > > > >You cannot do a combination of #1 and #2 as your statement=20 > suggests. > >=20 > > Les is of course correct. > >=20 > >=20 > >=20 > > > > > > > > Does that make sense? > > > > > > > > > > > > > > extended across the entire IS-IS routing domain. > > > > > Note that some PCEs may belong to multiple areas, in which=20 > > > > > case > > the > > > > > flooding scope may comprise these areas. This could be the=20 > > > > > case for a > > > > > > > > > > L1L2 router for instance advertising its PCE information=20 > > > > > within > > the > > > > > L2 area and/or a subset of its attached L1 area(s). > > > > > > > > > > LES: There is no such thing as an L2 area. There is the L2=20 > > > > > sub-domain, which consists of all L2 routers in a domain. > > > > > > > > OK, we are going to remove the above paragraph > > > > > > > > > > > > > > Section 4.1. The IS-IS PCED TLV > > > > > > > > > > LES: This is a sub-TLV. As Mike has pointed out, it=20 > is important=20 > > > > > to use that terminology consistently throughout the document. > > > > > > > > OK > > > > > > > > > > > > > > The format of the IS-IS PCED TLV and its sub-TLVs is the=20 > > > > > identical to > > > > > > > > > > > > > > > LES: s/the identical/identical > > > > > > > > OK > > > > > > > > > > > > > > At the end of Section 4.1 it might be helpful to add: > > > > > > > > > > "The following sub-sections describe the sub-TLVs=20 > which may be=20 > > > > > carried within the PCED sub-TLV." > > > > > > > > OK > > > > > > > > > > > > > > Section 4.1.3 > > > > > > > > > > Two DOMAIN sub-TLVs are defined > > > > > > > > > > Sub-TLV type Length Name > > > > > 1 Variable Area ID sub-TLV > > > > > 2 4 AS number sub-TLV > > > > > > > > > > LES: These codepoints are not mentioned in the IANA section. > > > > > > > > OK, to be added. > > > > > > > > > > > > > > Section 4.1.3.1 > > > > > > > > > > VALUE: This comprises a variable length IS-IS area=20 > ID. This=20 > > > > > is > > the > > > > > > > > > > combination of an Initial Domain Part (IDP)=20 > and High Order > > > > > part of the Domain Specific part (HO-DSP) > > > > > > > > > > LES: Rather than invent a term (HO-DSP) which ISO=20 > 10589 does not=20 > > > > > use, say "this is the area address as defined in [ISO]". > > > > > > > > OK > > > > > > > > > Which causes me to mention that you have no reference to ISO > > > > > 10589 in the references section, a most serious breach of=20 > > > > > etiquette indeed!! > > > > > > > > OK, to be added > > > > > > > > > > > > > > Section 4.1.4 > > > > > > > > > > LES: The domain/area sub-TLVs (nested level 3) which=20 > are defined=20 > > > > > in > > > > > 4.1.3 appear to be "reused" here. This should be explicitly=20 > > > > > stated as the scope of the sub-TLV codepoint for domain/area=20 > > > > > sub-TLVs is the parent sub-TLV (PCE-domain or > > > > > PCE-NEIG-DOMAIN) and therefore the codepoints cannot=20 > be assumed=20 > > > > > to be the same - it MUST be explicitly stated. > > > > > > > > OK > > > > > > > > > > > > > > Section 5 > > > > > > > > > > defined in [IS-IS-CAP]. A such, elements of procedures are=20 > > > > > inherited > > > > > > > > > > > > > > > LES: s/A such/As such > > > > > > > > OK > > > > > > > > > > > > > > domain, itMUST be carried within an IS-IS CAPABILITY TLV=20 > > > > > having the S > > > > > > > > > > > > > > > LES: s/itMUST/it MUST > > > > > > > > OK > > > > > > > > > > > > > > A PCE MUST originate a new IS-IS LSP whenever the content > > > > > > > > > > LES: There is a generic issue here. As a PCE is not a router=20 > > > > > running the IS-IS protocol, it cannot generate any LSPs. :-)=20 > > > > > Therefore you cannot say (as you do in multiple=20 > places) "a PCE=20 > > > > > originates a new IS-IS LSP". > > > > > > > > You are right the PCE is a functional block. But it is often > > assimilated > > > > to the node hosting the PCE function, which is an IS-IS node in=20 > > > > this draft. > > > > Is that OK if we say "An IS-IS node acting as PCE MUST=20 > originate"... > > > > > >But it is also possible to have a PCE which is NOT running=20 > on a node=20 > > >which is acting as an IS-IS router. In that case the PCE=20 > information=20 > > >is passed to the IS-IS node in some manner which is beyond=20 > the scope=20 > > >of this document and IS-IS still advertises the=20 > information, but as=20 > > >the IP address of the PCE is NOT an address of the IS-IS=20 > router it is=20 > > >wrong to say the IS-IS is "acting as a PCE". IS-IS is simply=20 > > >advertising PCE information which has been provided to it. > > >It does not act as a PCE in any way. > > > > > > > > > > > > Similarly, you say: > > > > > > > > > > A PCC MUST be > > > > > able to detect that the PCED TLV has been removed from an=20 > > > > > IS-IS LSP. > > > > > > > > > > As a PCC is also not equivalent to a router running the IS-IS=20 > > > > > protocol, perhaps you want to say "A PCC MUST be informed..." > > > > > > > > Let say "An IS-IS node acting as PCC..." ? > > > > > >Please see my previous comment. > > > > > > > > > > > > - although I tend to think that all of the=20 > communication between=20 > > > > > the applications (PCE and > > > > > PCC) and the IS-IS protocol instance is out of scope for this=20 > > > > > document. > > > > > > > > Yes it is out of the scope. > > > > > >So, you could just remove the language entirely. > > > > > > Les > > > > > > > > > > > > > > > > > > > > > > > > > The PCE address, i.e. the address indicated within the PCE > > ADDRESS > > > > > sub-TLV, MUST be distributed as part of IS-IS routing; > > > > > > > > > > LES: I am not sure what you mean here. Do you mean that there=20 > > > > > MUST be a host route advertisement for the PCE address(es)? > > > > > Or do you simply mean that the PCE address(es) must=20 > be reachable=20 > > > > > via some prefix(es) advertised by IS-IS? If the latter, then=20 > > > > > please change the wording. As written it suggests there is a=20 > > > > > special advertisement required. > > > > > > > > Yes this is the latter, we are going to rephrase as suggested. > > > > > > > > > > > > > > Section 8 > > > > > > > > > > IS-IS provides no mechanism for protecting the privacy of=20 > > > > > LSAs, > > and > > > > > > > > > > LES: I don't know what you are trying to say here. Do=20 > you mean TLVs? > > > > > Certainly not LSAs! > > > > > > > > Yes TLVs :-) > > > > > > > > > > > > > > > > > > > in particular the privacy PCE discovery information. > > > > > > > > > > LES: s/privacy/privacy of > > > > > > > > OK > > > > > > > > Again, thanks a lot for these comments. > > > > Once the last call is completed, we are going to submit a new=20 > > > > revision that accounts for all these comments. > > > > > > > > Best Regards, > > > > > > > > JL > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > > > Sent: Wednesday, February 14, 2007 9:36 AM > > > > > > To: isis-wg@ietf.org > > > > > > Cc: Jean Philippe Vasseur (jvasseur) > > > > > > Subject: [Isis-wg] PCE working group last call > > > > > ondraft-ietf-pce-disco- > > > > > > proto-isis-02.txt > > > > > > > > > > > > Hi, > > > > > > > > > > > > The PCE working group is holding a last call on > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto > > > > > -isis-02.t > > > > > xt > > > > > > > > > > > > Since this I-D proposes protocol extensions to ISIS we > > > > > would like the > > > > > ISIS > > > > > > working group to participate in this last call, and we have > > > > > accordingly > > > > > > made > > > > > > the last call period three weeks in order to give=20 > you plenty=20 > > > > > > of > > time > > > > > to > > > > > > respond. > > > > > > > > > > > > The last call will end at 12 noon GMT on Thursday 8th March. > > > > > > > > > > > > Please send your comments to the PCE mailing list if you are > > > > > subscribed. > > > > > > Otherwise, please channel your comments through the PCE > > > > > working group > > > > > > chairs (adrian@olddog.co.uk and jvasseur@cisco.com) > > > > > > > > > > > > Background reading is: > > > > > > RFC4655 - The PCE Architecture > > > > > > RFC4674 - Requirements for Path Computation Element (PCE) > > Discovery > > > > > > (These are the requirements that=20 > this I-D is > > > > > addressing) > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Adrian > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Isis-wg mailing list > > > > > > Isis-wg@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pce mailing list > > > > > Pce@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 07 04:04:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOs4p-000705-2a; Wed, 07 Mar 2007 04:04:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOjPx-0003fQ-7u for pce@ietf.org; Tue, 06 Mar 2007 18:50:05 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOjPv-0000pL-QD for pce@ietf.org; Tue, 06 Mar 2007 18:50:05 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 00:49:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] draft-leroux-pce-of-00.txt Date: Wed, 7 Mar 2007 00:49:42 +0100 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC827B@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] draft-leroux-pce-of-00.txt Thread-Index: AcdbVwERm/G70y43SzGrppgaWl9PcQBztA2QAMiArrA= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "ASH, GERALD R, ATTLABS" , X-OriginalArrivalTime: 06 Mar 2007 23:49:38.0623 (UTC) FILETIME=[1A2B24F0:01C7604A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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: , Errors-To: pce-bounces@lists.ietf.org Hi Jerry, Thanks for the feedback and comments. Please see inline,=20 > -----Message d'origine----- > De : ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > Envoy=E9 : samedi 3 mars 2007 01:54 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org > Cc : ASH, GERALD R, ATTLABS > Objet : RE: [Pce] draft-leroux-pce-of-00.txt=20 >=20 > Hi JL, >=20 > Looks like a good start. =20 >=20 > Looking through the IANA section, I don't see registration of=20 > the objective functions (OFs) required in Section 5.1.17 of > http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt: >=20 > " The PCECP MUST support at least the following "unsynchronized" > functions: >=20 > - Minimum cost path with respect to a specified metric > (shortest path) > - Least loaded path > - Maximum available bandwidth path >=20 > Also, the PCECP MUST support at least the following "synchronized" > objective functions: >=20 > - Minimize aggregate bandwidth consumption on all links > - Maximize the residual bandwidth on the most loaded link > - Minimize the cumulative cost of a set of diverse paths" >=20 > Shouldn't these standard OFs and their parameters be=20 > registered from the start? Actually we prefer to keep this draft generic, and define specific = objective functions in other documents. For instance = draft-lee-pce-global-concurrent-optimization-02.txt requests for three = code points within the OF registry. >=20 > It would also be useful to illustrate how each of these OFs=20 > are encoded, perhaps in an illustrative appendix. >=20 > How can new OFs be specified,=20 >i.e., how will extensibility of=20 > OFs and their parameters be accommodated? The OF is identified by a 16 bit code point. A document that defines a new OF will request IANA for a code point = within the OF code point registry. We will clarify in next revision. Regards,=20 JL >=20 > Thanks, > Regards, > Jerry >=20 > ________________________________ >=20 > From: LE ROUX Jean-Louis RD-CORE-LAN > [mailto:jeanlouis.leroux@orange-ftgroup.com] > Sent: Wednesday, February 28, 2007 11:39 AM > To: pce@ietf.org > Subject: [Pce] draft-leroux-pce-of-00.txt=20 >=20 > Hi all,=20 >=20 > This new draft defines PCED and PCEP extensions for the=20 > encoding of objective functions.=20 > We are waiting for WG feedback/comments.=20 >=20 > http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt. >=20 > Regards,=20 >=20 > JL >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 07 04:05:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOs53-0007RJ-3i; Wed, 07 Mar 2007 04:05:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOiyU-0004M4-4N for pce@ietf.org; Tue, 06 Mar 2007 18:21:42 -0500 Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOiyR-0006NF-NT for pce@ietf.org; Tue, 06 Mar 2007 18:21:41 -0500 Received: from sfs2.rdh.ecl.ntt.co.jp (IDENT:mirapoint@sfs2.rdh.ecl.ntt.co.jp [129.60.39.117]) by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NLc3f009173 for ; Wed, 7 Mar 2007 08:21:38 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by sfs2.rdh.ecl.ntt.co.jp (MOS 3.8.3-GA) with ESMTP id ABY84461; Wed, 7 Mar 2007 08:21:38 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id F237720AE2C for ; Wed, 7 Mar 2007 08:21:37 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id A799E20AE2B for ; Wed, 7 Mar 2007 08:21:37 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NLbx8004860 for ; Wed, 7 Mar 2007 08:21:37 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NLaMs026655 for ; Wed, 7 Mar 2007 08:21:37 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NLaQh026652 for ; Wed, 7 Mar 2007 08:21:36 +0900 (JST) Received: from [129.60.144.165] ([129.60.144.165]) by imb.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NLVcn005678 for ; Wed, 7 Mar 2007 08:21:34 +0900 (JST) Date: Wed, 07 Mar 2007 08:21:35 +0900 From: Eiji Oki To: pce@ietf.org In-Reply-To: References: Message-Id: <20070307081438.84C3.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Junkmail: UCE(10) X-Junkmail-Status: score=10/10, host=sfs2.rdh.ecl.ntt.co.jp X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090207.45EDF782.001B,ss=1,fgs=0, ip=129.60.5.69, so=2006-12-09 10:45:40, dmn=5.2.125/2007-01-26 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [Pce] Re: I-D ACTION:draft-ietf-pce-inter-layer-req-04.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: , Errors-To: pce-bounces@lists.ietf.org Hi all, A new version of the inter-layer PCC-PCE communication requirements has been published below. Main changes are: - Section 5.1.3 was modified. - Section 5.1.4 was added. Any comments and suggestions are highly appreciated. Thank you. Eiji On Mon, 05 Mar 2007 15:50:04 -0500 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group of the IETF. > > Title : PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering > Author(s) : E. Oki > Filename : draft-ietf-pce-inter-layer-req-04.txt > Pages : 9 > Date : 2007-3-5 > > The Path Computation Element (PCE) provides functions of path > computation in support of traffic engineering in Multi-Protocol > Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > MPLS and GMPLS networks may be constructed from layered service > networks. It is advantageous for overall network efficiency to > provide end-to-end traffic engineering across multiple network > layers. PCE is a candidate solution for such requirements. > > Generic requirements for a communication protocol between Path > Computation Clients (PCCs) and PCEs are presented in "PCE > Communication Protocol Generic Requirements". This document > complements the generic requirements and presents a detailed set of > PCC-PCE communication protocol requirements for inter-layer traffic > engineering. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-04.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-inter-layer-req-04.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-inter-layer-req-04.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. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 07 04:05:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOs55-0007Zf-5m; Wed, 07 Mar 2007 04:05:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOjUO-0005BH-RZ for pce@ietf.org; Tue, 06 Mar 2007 18:54:40 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOiy3-0005WF-Pi for pce@ietf.org; Tue, 06 Mar 2007 18:21:18 -0500 Received: from sfs2.rdh.ecl.ntt.co.jp (IDENT:mirapoint@sfs2.rdh.ecl.ntt.co.jp [129.60.39.117]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NIwG7025225 for ; Wed, 7 Mar 2007 08:21:14 +0900 (JST) Received: from mfs4.rdh.ecl.ntt.co.jp (mfs4.rdh.ecl.ntt.co.jp [129.60.39.113]) by sfs2.rdh.ecl.ntt.co.jp (MOS 3.8.3-GA) with ESMTP id ABY84370; Wed, 7 Mar 2007 08:21:14 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs4.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NLDhv017953 for ; Wed, 7 Mar 2007 08:21:13 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NLDGV004726 for ; Wed, 7 Mar 2007 08:21:13 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NLDts026500 for ; Wed, 7 Mar 2007 08:21:13 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NLCDp026497 for ; Wed, 7 Mar 2007 08:21:12 +0900 (JST) Received: from [129.60.144.165] ([129.60.144.165]) by imb.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l26NL7KZ005666 for ; Wed, 7 Mar 2007 08:21:10 +0900 (JST) Date: Wed, 07 Mar 2007 08:21:11 +0900 From: Eiji Oki To: pce@ietf.org Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-frwk-03.txt In-Reply-To: References: Message-Id: <20070307081416.84C0.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Junkmail: UCE(10) X-Junkmail-Status: score=10/10, host=sfs2.rdh.ecl.ntt.co.jp X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A09020A.45EDF769.00A5,ss=1,fgs=0, ip=129.60.5.69, so=2006-12-09 10:45:40, dmn=5.2.125/2007-01-26 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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: , Errors-To: pce-bounces@lists.ietf.org Hi all, A new version of the PCE-based inter-layer framework draft has been published below. Main changes are: - We modified sections 5 and 6 to clarify the communications between PCE and VNTM. - I added section 6.5 (Separation of Layer Management). - Other changes are to move the text around for clarity. Any comments and suggestions are highly appreciated. Thank you. Eiji On Mon, 05 Mar 2007 15:50:03 -0500 Internet-Drafts@ietf.org wrote: > 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 : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering > Author(s) : E. Oki, et al. > Filename : draft-ietf-pce-inter-layer-frwk-03.txt > Pages : 1 > Date : 2007-3-5 > > A network may comprise multiple layers. It is important to globally > optimize network resource utilization, taking into account all > layers, rather than optimizing resource utilization at each layer > independently. This allows better network efficiency to be achieved > through a process that we call inter-layer traffic engineering. The > Path Computation Element (PCE) can be a powerful tool to achieve > inter-layer traffic engineering. > > This document describes a framework for applying the PCE-based > architecture to inter-layer Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) traffic engineering. It provides > suggestions for the deployment of PCE in support of multi-layer > networks. This document also describes network models where PCE > performs inter-layer traffic engineering, and the relationship > between PCE and a functional component called the Virtual Network > Topology Manager (VNTM). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-03.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-inter-layer-frwk-03.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-inter-layer-frwk-03.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. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 07 04:07:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOs7S-0003Xf-Cj; Wed, 07 Mar 2007 04:07:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOiyH-0005Rq-Mg for pce@ietf.org; Tue, 06 Mar 2007 18:21:29 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOiZZ-0003NU-5E for pce@ietf.org; Tue, 06 Mar 2007 17:55:59 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 23:55:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG Date: Tue, 6 Mar 2007 23:55:29 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG Thread-Index: AcdVqbsCDFY8XNsfSDmUKalXm8vpAwGhdhYAANBXXUAAM3pGwA== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Les Ginsberg \(ginsberg\)" , , X-OriginalArrivalTime: 06 Mar 2007 22:55:27.0206 (UTC) FILETIME=[882C4860:01C76042] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: Chris Hopps , David Ward , "Mike Shand \(mshand\)" 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: , Errors-To: pce-bounces@lists.ietf.org Hi Les, Please see inline,=20 > -----Message d'origine----- > De : Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]=20 > Envoy=E9 : lundi 5 mars 2007 23:12 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; zzx-adrian@olddog.co.uk;=20 > pce@ietf.org > Cc : Mike Shand (mshand); David Ward; Chris Hopps > Objet : RE: [Pce] Comments on=20 > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG >=20 >=20 > Jean-Louis - >=20 > Sorry for the delayed response. > Comments inline. >=20 > > -----Original Message----- > > From: LE ROUX Jean-Louis RD-CORE-LAN=20 > [mailto:jeanlouis.leroux@orange-=20 > > ftgroup.com] > > Sent: Thursday, March 01, 2007 11:14 AM > > To: adrian@olddog.co.uk; pce@ietf.org; Les Ginsberg (ginsberg) > > Subject: RE: [Pce] Comments on=20 > draft-ietf-pce-disco-proto-isis-02.txt=20 > > from ISISWG > >=20 > > Hi Les, > >=20 > > Thanks for these comments. > >=20 > > Please see inline, > >=20 > > > -----Message d'origine----- > > > De : Adrian Farrel [mailto:adrian@olddog.co.uk] Envoy=E9 :=20 > mercredi 21=20 > > > f=E9vrier 2007 11:53 =C0 : pce@ietf.org Objet : [Pce] Comments on=20 > > > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG > > > > > > ----- Original Message ----- > > > > > > From: "Les Ginsberg (ginsberg)" > > > To: "Adrian Farrel" ; > > > Cc: "Jean Philippe Vasseur (jvasseur)" > > > Sent: Monday, February 19, 2007 6:56 PM > > > Subject: RE: [Isis-wg] PCE working group last call > > > > > > ondraft-ietf-pce-disco-proto-isis-02.txt > > > > > > > > > Section 1 > > > > > > ABR: IGP Area Border Router (L1L2 router). > > > > > > LES: Use "L2 capable router" instead - or eliminate the=20 > definition=20 > > > since as Mike points out it is not used in the document. > >=20 > > OK, to be eliminated > >=20 > > > > > > Examples of domains include IGP areas and=20 > Autonomous Systems. > > > > > > LES: area and domain are not the same - though a domain may have=20 > > > only one area. I would omit this sentence. > >=20 > > In the PCE context the defintion of a domain is as follows=20 > (as per RFC > > 4655): > >=20 > > "A domain is any collection of network elements within a=20 > common sphere=20 > > of address management or path computation responsibility. =20 > Examples of=20 > > domains include IGP areas, Autonomous Systems (ASes), and multiple=20 > > ASes within a Service Provider network. Domains of path=20 > computation=20 > > responsibility may also exist as sub-domains of areas or ASes." > >=20 > > Is that OK if we refer to [RFC4655] and indicate that this=20 > definition=20 > > applies to a PCE context? >=20 > I think in an IS-IS specific document this is going to get=20 > confusing - as area and domain have a very specific meaning.=20 > So I think you need to define this as "PCE-domain", reference=20 > RFC4655, and make clear that this should be distinguished=20 > from a domain as defined by ISO 10589 - and use "PCE_domain"=20 > in all the appriopriate places in the document. what about the term "Path Computation Domain"? >=20 > >=20 > >=20 > > > > > > Section 3.1.1 > > > > > > inter-area, inter-AS, inter-layer\205 > > > > > > LES: Remove Formatting character \205 > >=20 > > OK > >=20 > > > > > > Section 3.2 > > > > > > The flooding scope for PCE information advertised=20 > through IS-IS can > > > be limited to one or more IS-IS areas the PCE belongs=20 > to, or can=20 > > > be > > > > > > LES: Flooding can only be area or domain scoped flooding. > > > There is no defined method to restrict flooding to some subset of=20 > > > the areas in a domain. > >=20 > > Right. We are going to rephrase as follows: > >=20 > > The flooding scope for PCE information advertised through=20 > IS-IS can be=20 > > a single L1 area, a L1 area and the L2 sub-domain (when the=20 > PCE is a=20 > > L1L2 node), or the entire IS-IS domain (S bit set in the Router=20 > > Capability TLV). >=20 > The three options are: >=20 > 1)Single L1 area (only available at Level-1 - S bit clear) > 2)L2 sub-domain (only available at Level-2 when S bit is=20 > clear) 3)Entire routing domain (S bit set) >=20 > You cannot do a combination of #1 and #2 as your statement suggests. Actually a L1L2 node may include a PCED TLV in a Router Cap TLV with the = S bit cleared, both in its L1 and L2 LSPs. We are going to clarify this = point. >=20 > >=20 > > Does that make sense? > >=20 > > > > > > extended across the entire IS-IS routing domain. > > > Note that some PCEs may belong to multiple areas, in=20 > which case the > > > flooding scope may comprise these areas. This could be=20 > the case=20 > > > for a > > > > > > L1L2 router for instance advertising its PCE=20 > information within the > > > L2 area and/or a subset of its attached L1 area(s). > > > > > > LES: There is no such thing as an L2 area. There is the L2=20 > > > sub-domain, which consists of all L2 routers in a domain. > >=20 > > OK, we are going to remove the above paragraph > >=20 > > > > > > Section 4.1. The IS-IS PCED TLV > > > > > > LES: This is a sub-TLV. As Mike has pointed out, it is=20 > important to=20 > > > use that terminology consistently throughout the document. > >=20 > > OK > >=20 > > > > > > The format of the IS-IS PCED TLV and its sub-TLVs is the=20 > > > identical to > > > > > > > > > LES: s/the identical/identical > >=20 > > OK > >=20 > > > > > > At the end of Section 4.1 it might be helpful to add: > > > > > > "The following sub-sections describe the sub-TLVs which may be=20 > > > carried within the PCED sub-TLV." > >=20 > > OK > >=20 > > > > > > Section 4.1.3 > > > > > > Two DOMAIN sub-TLVs are defined > > > > > > Sub-TLV type Length Name > > > 1 Variable Area ID sub-TLV > > > 2 4 AS number sub-TLV > > > > > > LES: These codepoints are not mentioned in the IANA section. > >=20 > > OK, to be added. > >=20 > > > > > > Section 4.1.3.1 > > > > > > VALUE: This comprises a variable length IS-IS area ID. This is=20 > > > the > > > > > > combination of an Initial Domain Part (IDP) and=20 > High Order > > > part of the Domain Specific part (HO-DSP) > > > > > > LES: Rather than invent a term (HO-DSP) which ISO 10589 does not=20 > > > use, say "this is the area address as defined in [ISO]". > >=20 > > OK > >=20 > > > Which causes me to mention that you have no reference to ISO > > > 10589 in the references section, a most serious breach of=20 > etiquette=20 > > > indeed!! > >=20 > > OK, to be added > >=20 > > > > > > Section 4.1.4 > > > > > > LES: The domain/area sub-TLVs (nested level 3) which are=20 > defined in > > > 4.1.3 appear to be "reused" here. This should be=20 > explicitly stated=20 > > > as the scope of the sub-TLV codepoint for domain/area sub-TLVs is=20 > > > the parent sub-TLV (PCE-domain or > > > PCE-NEIG-DOMAIN) and therefore the codepoints cannot be=20 > assumed to=20 > > > be the same - it MUST be explicitly stated. > >=20 > > OK > >=20 > > > > > > Section 5 > > > > > > defined in [IS-IS-CAP]. A such, elements of procedures are=20 > > > inherited > > > > > > > > > LES: s/A such/As such > >=20 > > OK > >=20 > > > > > > domain, itMUST be carried within an IS-IS CAPABILITY=20 > TLV having=20 > > > the S > > > > > > > > > LES: s/itMUST/it MUST > >=20 > > OK > >=20 > > > > > > A PCE MUST originate a new IS-IS LSP whenever the content > > > > > > LES: There is a generic issue here. As a PCE is not a=20 > router running=20 > > > the IS-IS protocol, it cannot generate any LSPs. :-)=20 > Therefore you=20 > > > cannot say (as you do in multiple places) "a PCE originates a new=20 > > > IS-IS LSP". > >=20 > > You are right the PCE is a functional block. But it is often=20 > > assimilated to the node hosting the PCE function, which is an IS-IS=20 > > node in this draft. > > Is that OK if we say "An IS-IS node acting as PCE MUST originate"... >=20 > But it is also possible to have a PCE which is NOT running on=20 > a node which is acting as an IS-IS router. In that case the=20 > PCE information is passed to the IS-IS node in some manner=20 > which is beyond the scope of this document and IS-IS still=20 > advertises the information, but as the IP address of the PCE=20 > is NOT an address of the IS-IS router it is wrong to say the=20 > IS-IS is "acting as a PCE". IS-IS is simply advertising PCE=20 > information which has been provided to it. It does not act as=20 > a PCE in any way. OK, I see, so what about "An IS-IS router MUST originate a new IS-IS LSP = whenever the content of any of the PCED TLV changes"? >=20 > >=20 > > > Similarly, you say: > > > > > > A PCC MUST be > > > able to detect that the PCED TLV has been removed from=20 > an IS-IS=20 > > > LSP. > > > > > > As a PCC is also not equivalent to a router running the IS-IS=20 > > > protocol, perhaps you want to say "A PCC MUST be informed..." > >=20 > > Let say "An IS-IS node acting as PCC..." ? >=20 > Please see my previous comment. What about "An IS-IS router MUST be able to detect..."? >=20 > >=20 > > > - although I tend to think that all of the communication=20 > between the=20 > > > applications (PCE and > > > PCC) and the IS-IS protocol instance is out of scope for this=20 > > > document. > >=20 > > Yes it is out of the scope. >=20 > So, you could just remove the language entirely. Would it be OK if we only refer to "IS-IS routers"? Best Regards, JL >=20 > Les >=20 > >=20 > >=20 > >=20 > > > > > > The PCE address, i.e. the address indicated within the=20 > PCE ADDRESS > > > sub-TLV, MUST be distributed as part of IS-IS routing; > > > > > > LES: I am not sure what you mean here. Do you mean that=20 > there MUST=20 > > > be a host route advertisement for the PCE address(es)? > > > Or do you simply mean that the PCE address(es) must be=20 > reachable via=20 > > > some prefix(es) advertised by IS-IS? If the latter, then please=20 > > > change the wording. As written it suggests there is a special=20 > > > advertisement required. > >=20 > > Yes this is the latter, we are going to rephrase as suggested. > >=20 > > > > > > Section 8 > > > > > > IS-IS provides no mechanism for protecting the privacy of LSAs,=20 > > > and > > > > > > LES: I don't know what you are trying to say here. Do you=20 > mean TLVs? > > > Certainly not LSAs! > >=20 > > Yes TLVs :-) > >=20 > > > > > > > > > in particular the privacy PCE discovery information. > > > > > > LES: s/privacy/privacy of > >=20 > > OK > >=20 > > Again, thanks a lot for these comments. > > Once the last call is completed, we are going to submit a=20 > new revision=20 > > that accounts for all these comments. > >=20 > > Best Regards, > >=20 > > JL > >=20 > > > > > > Les > > > > > > > > > > -----Original Message----- > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > Sent: Wednesday, February 14, 2007 9:36 AM > > > > To: isis-wg@ietf.org > > > > Cc: Jean Philippe Vasseur (jvasseur) > > > > Subject: [Isis-wg] PCE working group last call > > > ondraft-ietf-pce-disco- > > > > proto-isis-02.txt > > > > > > > > Hi, > > > > > > > > The PCE working group is holding a last call on > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto > > > -isis-02.t > > > xt > > > > > > > > Since this I-D proposes protocol extensions to ISIS we > > > would like the > > > ISIS > > > > working group to participate in this last call, and we have > > > accordingly > > > > made > > > > the last call period three weeks in order to give you plenty of=20 > > > > time > > > to > > > > respond. > > > > > > > > The last call will end at 12 noon GMT on Thursday 8th March. > > > > > > > > Please send your comments to the PCE mailing list if you are > > > subscribed. > > > > Otherwise, please channel your comments through the PCE > > > working group > > > > chairs (adrian@olddog.co.uk and jvasseur@cisco.com) > > > > > > > > Background reading is: > > > > RFC4655 - The PCE Architecture > > > > RFC4674 - Requirements for Path Computation Element=20 > (PCE) Discovery > > > > (These are the requirements that this I-D is > > > addressing) > > > > > > > > > > > > Thanks, > > > > Adrian > > > > > > > > > > > > > > > > _______________________________________________ > > > > Isis-wg mailing list > > > > Isis-wg@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 07 04:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOs7d-0003m0-Qu; Wed, 07 Mar 2007 04:07:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOknq-0005sW-Ac for pce@ietf.org; Tue, 06 Mar 2007 20:18:50 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOknp-0006Je-1L for pce@ietf.org; Tue, 06 Mar 2007 20:18:50 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 50B7247DDEF for ; Tue, 6 Mar 2007 17:18:48 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09358-07 for ; Tue, 6 Mar 2007 17:18:48 -0800 (PST) Received: from [155.53.44.200] (malaga.redback.com [155.53.44.200]) by prattle.redback.com (Postfix) with ESMTP id 1B8E047DDEB for ; Tue, 6 Mar 2007 17:18:48 -0800 (PST) Message-ID: <45EE12F8.9040902@redback.com> Date: Tue, 06 Mar 2007 17:18:48 -0800 From: Wenhu Lu User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: pce@ietf.org Subject: Re: [Pce] draft-leroux-pce-of-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Errors-To: pce-bounces@lists.ietf.org Hi Jean-Louis, It came to my attention that the acronym PCEP was used throughout this draft whereas the acronym PCECP was used in drafts such as this one - _PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (26301 bytes)._ Are these two acronyms going to converge at some time? Regards, -wenhu LE ROUX Jean-Louis RD-CORE-LAN wrote: > > Hi all, > > This new draft defines PCED and PCEP extensions for the encoding of > objective functions. > We are waiting for WG feedback/comments. > > _http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt_ > > Regards, > > JL > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Wed Mar 07 04:12:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsC2-0003ep-Lw; Wed, 07 Mar 2007 04:12:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOqk2-0004qw-25 for pce@ietf.org; Wed, 07 Mar 2007 02:39:18 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOqk0-00010Y-VO for pce@ietf.org; Wed, 07 Mar 2007 02:39:18 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 08:39:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG Date: Wed, 7 Mar 2007 08:38:53 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG Thread-Index: Acdfzdp4rAoESyYGRgGoIS9nDt957AATZRFgAAn4jHAAAbGoMAAQRjNA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Les Ginsberg \(ginsberg\)" , "Mike Shand \(mshand\)" X-OriginalArrivalTime: 07 Mar 2007 07:39:11.0088 (UTC) FILETIME=[B2442700:01C7608B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d3308915082aec5bdcb405956a0eb0ae Cc: Chris Hopps , pce@ietf.org, David Ward 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: , Errors-To: pce-bounces@lists.ietf.org Hi Les=20 > This is better, but I really think it is unnecessary. > IS-IS is advertising information that the PCE application=20 > provides. Clearly if that information changes, IS-IS must=20 > update the relevant LSP(s). I don't know why we have to say=20 > that - what else could IS-IS possibly do? Advertise something=20 > other than what PCE provides? >=20 > As the manner in which the information is transferred between=20 > the PCE application and an IS-IS instance is out of scope for=20 > this spec I don't see what discussing this adds.=20 >=20 > Consider RFC 3784. In that case IS-IS is advertising=20 > information on behalf of TE. I don't think you will find any=20 > language logically equivalent to what you are proposing in=20 > 3784 - it's just not needed. OK, so we are going to remove these aspects. Best Regards, JL > -----Message d'origine----- > De : Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]=20 > Envoy=E9 : mercredi 7 mars 2007 00:57 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Mike Shand (mshand) > Cc : zzx-adrian@olddog.co.uk; pce@ietf.org; David Ward; Chris Hopps > Objet : RE: [Pce] Comments on=20 > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG >=20 >=20 >=20 > > -----Original Message----- > > From: LE ROUX Jean-Louis RD-CORE-LAN=20 > [mailto:jeanlouis.leroux@orange-=20 > > ftgroup.com] > > Sent: Tuesday, March 06, 2007 3:32 PM > > To: Les Ginsberg (ginsberg); Mike Shand (mshand) > > Cc: adrian@olddog.co.uk; pce@ietf.org; David Ward; Chris Hopps > > Subject: RE: [Pce] Comments on=20 > draft-ietf-pce-disco-proto-isis-02.txt=20 > > from ISISWG > >=20 > > Hi Les, > >=20 > > > -----Message d'origine----- > > > De : Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Envoy=E9 = :=20 > > > mardi 6 mars 2007 19:28 =C0 : Mike Shand (mshand) Cc : LE ROUX=20 > > > Jean-Louis RD-CORE-LAN; zzx-adrian@olddog.co.uk;=20 > pce@ietf.org; David=20 > > > Ward; Chris Hopps Objet : RE: [Pce] Comments on=20 > > > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG > > > > > > > > > > > > > -----Original Message----- > > > > From: Mike Shand (mshand) > > > > Sent: Tuesday, March 06, 2007 12:40 AM > > > > To: Les Ginsberg (ginsberg) > > > > Cc: LE ROUX Jean-Louis RD-CORE-LAN; adrian@olddog.co.uk; > > > pce@ietf.org; > > > > David Ward; Chris Hopps > > > > Subject: RE: [Pce] Comments on > > > draft-ietf-pce-disco-proto-isis-02.txt > > > > from ISISWG > > > > > > > > I agree with Les' responses. My only concern is the issue > > > of whether > > > > or not a PCE is an IS-IS router or not. I assume that it > > > usually is, > > > > but need not be. The text doesn't seem to work for the case > > > where it > > > > is not. Is the assumption that in this case some IS-IS=20 > router will > > > > APPEAR to be a PCE, but the actual PCE will be located > > > elsewhere and > > > > some undefined communication method used between the=20 > two. In that > > > > case, to all intents and purposes the IS-IS router *is* a > > > PCE, in just > > > > the same way that you could (if you were so minded)=20 > have an IS-IS > > > > router whose SPF processing was handed off to some=20 > other piece of > > > > hardware located elsewhere in the network. > > > > > > > > I guess the question I am asking is; can you tell by=20 > looking at the > > > > bits on the wire whether the PCE function is collocated > > > with an IS-IS > > > > router or not? > > > > > > > > If you can tell (and hence distinguish the case where=20 > it is not), > > > > then draft needs to describe this. If you can't tell,=20 > then I guess > > > > there is no issue. > > > > > > I think I am slightly less forgiving with the language in the > > > draft than Mike. > > > > > > Quoting RFC 4655 > > > > > > "A Path Computation Element (PCE) is an entity that is capable of > > > computing a network path or route based on a network=20 > graph, and of > > > applying computational constraints during the=20 > computation. The PCE > > > entity is an application that can be located within a > > > network node or > > > component, on an out-of-network server, etc." > > > > > > I don't think it matters whether the PCE happens to be > > > co-located on a router running an IS-IS instance or not - the > > > key point is that a PCE (as well as PCC) is NOT an instance > > > of the IS-IS protocol. It therefore is simply wrong to say - > > > as you do in Section 5: > > > > > > "A PCE MUST originate a new IS-IS LSP..." > > > > > > And it is also wrong to say as you do later in the same section > > > > > > "When the PCE function is deactivated on a node, the node > > > MUST originate a new IS-IS..." > > > > > > I don't think this should be very controversial - just avoid > > > language which suggests that because IS-IS happens to be > > > advertising information on behalf of a PCE application that > > > it is the PCE application which is actually responsible for > > > actions which are clearly the responsibility of the IS-IS=20 > instance. > > > > > > For example, for the latter case you might say something like: > > > > > > "When the PCE function is deactivated the information > > > associated with this PCE which is currently being advertised > > > in IS-IS LSPs MUST be withdrawn." > >=20 > > OK, I get your point, so what about: > >=20 > > An IS-IS router MUST originate a new IS-IS LSP whenever=20 > there is a > > change in a PCED TLV > > associated with a PCE it advertises. > >=20 > > When a PCE is deactivated, the IS-IS Router advertising=20 > this PCE MUST > > originate a new IS-IS LSP that does no longer include=20 > the corresponding > > PCED TLV. >=20 > This is better, but I really think it is unnecessary. > IS-IS is advertising information that the PCE application=20 > provides. Clearly if that information changes, IS-IS must=20 > update the relevant LSP(s). I don't know why we have to say=20 > that - what else could IS-IS possibly do? Advertise something=20 > other than what PCE provides? >=20 > As the manner in which the information is transferred between=20 > the PCE application and an IS-IS instance is out of scope for=20 > this spec I don't see what discussing this adds.=20 >=20 > Consider RFC 3784. In that case IS-IS is advertising=20 > information on behalf of TE. I don't think you will find any=20 > language logically equivalent to what you are proposing in=20 > 3784 - it's just not needed. >=20 > Les >=20 > >=20 > > Regards, > >=20 > > JL > >=20 > > > > > > (Just a suggestion) > > > > > > Les > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > Mike > > > > > > > > At 22:12 05/03/2007, Les Ginsberg \(ginsberg\) wrote: > > > > > > > > >Jean-Louis - > > > > > > > > > >Sorry for the delayed response. > > > > >Comments inline. > > > > > > > > > > > -----Original Message----- > > > > > > From: LE ROUX Jean-Louis RD-CORE-LAN > > > > > > [mailto:jeanlouis.leroux@orange- ftgroup.com] > > > > > > Sent: Thursday, March 01, 2007 11:14 AM > > > > > > To: adrian@olddog.co.uk; pce@ietf.org; Les Ginsberg=20 > (ginsberg) > > > > > > Subject: RE: [Pce] Comments on > > > > > > draft-ietf-pce-disco-proto-isis-02.txt > > > > from > > > > > > ISISWG > > > > > > > > > > > > Hi Les, > > > > > > > > > > > > Thanks for these comments. > > > > > > > > > > > > Please see inline, > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De : Adrian Farrel [mailto:adrian@olddog.co.uk] Envoy=E9 : > > > > > > > mercredi 21 f=E9vrier 2007 11:53 =C0 : pce@ietf.org=20 > Objet : [Pce] > > > > > > > Comments on=20 > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Les Ginsberg (ginsberg)" > > > > > > > To: "Adrian Farrel" ;=20 > > > > > > > > Cc: "Jean Philippe Vasseur (jvasseur)"=20 > > > > > > > > Sent: Monday, February 19, 2007 6:56 PM > > > > > > > Subject: RE: [Isis-wg] PCE working group last call > > > > > > > > > > > > > > ondraft-ietf-pce-disco-proto-isis-02.txt > > > > > > > > > > > > > > > > > > > > > Section 1 > > > > > > > > > > > > > > ABR: IGP Area Border Router (L1L2 router). > > > > > > > > > > > > > > LES: Use "L2 capable router" instead - or eliminate the > > > > > > > definition since as Mike points out it is not used in > > > the document. > > > > > > > > > > > > OK, to be eliminated > > > > > > > > > > > > > > > > > > > > Examples of domains include IGP areas and > > > Autonomous Systems. > > > > > > > > > > > > > > LES: area and domain are not the same - though a > > > domain may have > > > > > > > only one area. I would omit this sentence. > > > > > > > > > > > > In the PCE context the defintion of a domain is as > > > follows (as per > > > > > > RFC > > > > > > 4655): > > > > > > > > > > > > "A domain is any collection of network elements=20 > within a common > > > > > > sphere > > > > of > > > > > > address management or path computation responsibility. > > > Examples > > > > > > of domains include IGP areas, Autonomous Systems (ASes), and > > > > > > multiple > > > > ASes > > > > > > within a Service Provider network. Domains of path=20 > computation > > > > > > responsibility may also exist as sub-domains of=20 > areas or ASes." > > > > > > > > > > > > Is that OK if we refer to [RFC4655] and indicate that this > > > > > > definition applies to a PCE context? > > > > > > > > > >I think in an IS-IS specific document this is going to get > > > confusing > > > > >- as area and domain have a very specific meaning. So=20 > I think you > > > > >need to define this as "PCE-domain", reference=20 > RFC4655, and make > > > > >clear that this should be distinguished from a domain as > > > defined by > > > > >ISO 10589 - and use "PCE_domain" in all the=20 > appriopriate places in > > > > >the document. > > > > > > > > I agree. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Section 3.1.1 > > > > > > > > > > > > > > inter-area, inter-AS, inter-layer\205 > > > > > > > > > > > > > > LES: Remove Formatting character \205 > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > > Section 3.2 > > > > > > > > > > > > > > The flooding scope for PCE information=20 > advertised through > > > > > > > IS-IS > > > > can > > > > > > > be limited to one or more IS-IS areas the PCE > > > belongs to, or > > > > > > > can > > > > be > > > > > > > > > > > > > > LES: Flooding can only be area or domain scoped flooding. > > > > > > > There is no defined method to restrict flooding to > > > some subset > > > > > > > of the areas in a domain. > > > > > > > > > > > > Right. We are going to rephrase as follows: > > > > > > > > > > > > The flooding scope for PCE information advertised=20 > through IS-IS > > > > > > can be > > > > a > > > > > > single L1 area, a L1 area and the L2 sub-domain (when > > > the PCE is a > > > > L1L2 > > > > > > node), or the entire IS-IS domain (S bit set in the Router > > > > > > Capability TLV). > > > > > > > > > >The three options are: > > > > > > > > > >1)Single L1 area (only available at Level-1 - S bit clear) > > > > >2)L2 sub-domain (only available at Level-2 when S bit is clear) > > > > >3)Entire routing domain (S bit set) > > > > > > > > > >You cannot do a combination of #1 and #2 as your statement > > > suggests. > > > > > > > > Les is of course correct. > > > > > > > > > > > > > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > extended across the entire IS-IS routing domain. > > > > > > > Note that some PCEs may belong to multiple=20 > areas, in which > > > > > > > case > > > > the > > > > > > > flooding scope may comprise these areas. This=20 > could be the > > > > > > > case for a > > > > > > > > > > > > > > L1L2 router for instance advertising its PCE=20 > information > > > > > > > within > > > > the > > > > > > > L2 area and/or a subset of its attached L1 area(s). > > > > > > > > > > > > > > LES: There is no such thing as an L2 area. There is the L2 > > > > > > > sub-domain, which consists of all L2 routers in a domain. > > > > > > > > > > > > OK, we are going to remove the above paragraph > > > > > > > > > > > > > > > > > > > > Section 4.1. The IS-IS PCED TLV > > > > > > > > > > > > > > LES: This is a sub-TLV. As Mike has pointed out, it > > > is important > > > > > > > to use that terminology consistently throughout=20 > the document. > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > > The format of the IS-IS PCED TLV and its=20 > sub-TLVs is the > > > > > > > identical to > > > > > > > > > > > > > > > > > > > > > LES: s/the identical/identical > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > > At the end of Section 4.1 it might be helpful to add: > > > > > > > > > > > > > > "The following sub-sections describe the sub-TLVs > > > which may be > > > > > > > carried within the PCED sub-TLV." > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > > Section 4.1.3 > > > > > > > > > > > > > > Two DOMAIN sub-TLVs are defined > > > > > > > > > > > > > > Sub-TLV type Length Name > > > > > > > 1 Variable Area ID sub-TLV > > > > > > > 2 4 AS number sub-TLV > > > > > > > > > > > > > > LES: These codepoints are not mentioned in the=20 > IANA section. > > > > > > > > > > > > OK, to be added. > > > > > > > > > > > > > > > > > > > > Section 4.1.3.1 > > > > > > > > > > > > > > VALUE: This comprises a variable length IS-IS area > > > ID. This > > > > > > > is > > > > the > > > > > > > > > > > > > > combination of an Initial Domain Part (IDP) > > > and High Order > > > > > > > part of the Domain Specific part (HO-DSP) > > > > > > > > > > > > > > LES: Rather than invent a term (HO-DSP) which ISO > > > 10589 does not > > > > > > > use, say "this is the area address as defined in [ISO]". > > > > > > > > > > > > OK > > > > > > > > > > > > > Which causes me to mention that you have no=20 > reference to ISO > > > > > > > 10589 in the references section, a most serious breach of > > > > > > > etiquette indeed!! > > > > > > > > > > > > OK, to be added > > > > > > > > > > > > > > > > > > > > Section 4.1.4 > > > > > > > > > > > > > > LES: The domain/area sub-TLVs (nested level 3) which > > > are defined > > > > > > > in > > > > > > > 4.1.3 appear to be "reused" here. This should be=20 > explicitly > > > > > > > stated as the scope of the sub-TLV codepoint for=20 > domain/area > > > > > > > sub-TLVs is the parent sub-TLV (PCE-domain or > > > > > > > PCE-NEIG-DOMAIN) and therefore the codepoints cannot > > > be assumed > > > > > > > to be the same - it MUST be explicitly stated. > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > > Section 5 > > > > > > > > > > > > > > defined in [IS-IS-CAP]. A such, elements of=20 > procedures are > > > > > > > inherited > > > > > > > > > > > > > > > > > > > > > LES: s/A such/As such > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > > domain, itMUST be carried within an IS-IS=20 > CAPABILITY TLV > > > > > > > having the S > > > > > > > > > > > > > > > > > > > > > LES: s/itMUST/it MUST > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > > A PCE MUST originate a new IS-IS LSP whenever=20 > the content > > > > > > > > > > > > > > LES: There is a generic issue here. As a PCE is=20 > not a router > > > > > > > running the IS-IS protocol, it cannot generate=20 > any LSPs. :-) > > > > > > > Therefore you cannot say (as you do in multiple > > > places) "a PCE > > > > > > > originates a new IS-IS LSP". > > > > > > > > > > > > You are right the PCE is a functional block. But it is often > > > > assimilated > > > > > > to the node hosting the PCE function, which is an=20 > IS-IS node in > > > > > > this draft. > > > > > > Is that OK if we say "An IS-IS node acting as PCE MUST > > > originate"... > > > > > > > > > >But it is also possible to have a PCE which is NOT running > > > on a node > > > > >which is acting as an IS-IS router. In that case the PCE > > > information > > > > >is passed to the IS-IS node in some manner which is beyond > > > the scope > > > > >of this document and IS-IS still advertises the > > > information, but as > > > > >the IP address of the PCE is NOT an address of the IS-IS > > > router it is > > > > >wrong to say the IS-IS is "acting as a PCE". IS-IS is simply > > > > >advertising PCE information which has been provided to it. > > > > >It does not act as a PCE in any way. > > > > > > > > > > > > > > > > > > Similarly, you say: > > > > > > > > > > > > > > A PCC MUST be > > > > > > > able to detect that the PCED TLV has been=20 > removed from an > > > > > > > IS-IS LSP. > > > > > > > > > > > > > > As a PCC is also not equivalent to a router=20 > running the IS-IS > > > > > > > protocol, perhaps you want to say "A PCC MUST be=20 > informed..." > > > > > > > > > > > > Let say "An IS-IS node acting as PCC..." ? > > > > > > > > > >Please see my previous comment. > > > > > > > > > > > > > > > > > > - although I tend to think that all of the > > > communication between > > > > > > > the applications (PCE and > > > > > > > PCC) and the IS-IS protocol instance is out of=20 > scope for this > > > > > > > document. > > > > > > > > > > > > Yes it is out of the scope. > > > > > > > > > >So, you could just remove the language entirely. > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The PCE address, i.e. the address indicated=20 > within the PCE > > > > ADDRESS > > > > > > > sub-TLV, MUST be distributed as part of IS-IS routing; > > > > > > > > > > > > > > LES: I am not sure what you mean here. Do you=20 > mean that there > > > > > > > MUST be a host route advertisement for the PCE=20 > address(es)? > > > > > > > Or do you simply mean that the PCE address(es) must > > > be reachable > > > > > > > via some prefix(es) advertised by IS-IS? If the=20 > latter, then > > > > > > > please change the wording. As written it suggests=20 > there is a > > > > > > > special advertisement required. > > > > > > > > > > > > Yes this is the latter, we are going to rephrase as=20 > suggested. > > > > > > > > > > > > > > > > > > > > Section 8 > > > > > > > > > > > > > > IS-IS provides no mechanism for protecting the=20 > privacy of > > > > > > > LSAs, > > > > and > > > > > > > > > > > > > > LES: I don't know what you are trying to say here. Do > > > you mean TLVs? > > > > > > > Certainly not LSAs! > > > > > > > > > > > > Yes TLVs :-) > > > > > > > > > > > > > > > > > > > > > > > > > > > in particular the privacy PCE discovery information. > > > > > > > > > > > > > > LES: s/privacy/privacy of > > > > > > > > > > > > OK > > > > > > > > > > > > Again, thanks a lot for these comments. > > > > > > Once the last call is completed, we are going to=20 > submit a new > > > > > > revision that accounts for all these comments. > > > > > > > > > > > > Best Regards, > > > > > > > > > > > > JL > > > > > > > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > > > > > Sent: Wednesday, February 14, 2007 9:36 AM > > > > > > > > To: isis-wg@ietf.org > > > > > > > > Cc: Jean Philippe Vasseur (jvasseur) > > > > > > > > Subject: [Isis-wg] PCE working group last call > > > > > > > ondraft-ietf-pce-disco- > > > > > > > > proto-isis-02.txt > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > The PCE working group is holding a last call on > > > > > > > > > > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto > > > > > > > -isis-02.t > > > > > > > xt > > > > > > > > > > > > > > > > Since this I-D proposes protocol extensions to ISIS we > > > > > > > would like the > > > > > > > ISIS > > > > > > > > working group to participate in this last call,=20 > and we have > > > > > > > accordingly > > > > > > > > made > > > > > > > > the last call period three weeks in order to give > > > you plenty > > > > > > > > of > > > > time > > > > > > > to > > > > > > > > respond. > > > > > > > > > > > > > > > > The last call will end at 12 noon GMT on=20 > Thursday 8th March. > > > > > > > > > > > > > > > > Please send your comments to the PCE mailing=20 > list if you are > > > > > > > subscribed. > > > > > > > > Otherwise, please channel your comments through the PCE > > > > > > > working group > > > > > > > > chairs (adrian@olddog.co.uk and jvasseur@cisco.com) > > > > > > > > > > > > > > > > Background reading is: > > > > > > > > RFC4655 - The PCE Architecture > > > > > > > > RFC4674 - Requirements for Path Computation=20 > Element (PCE) > > > > Discovery > > > > > > > > (These are the requirements that > > > this I-D is > > > > > > > addressing) > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Adrian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Isis-wg mailing list > > > > > > > > Isis-wg@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pce mailing list > > > > > > > Pce@lists.ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > > > > > > > > > > > > > > > >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 07 06:08:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOu0c-0004s8-Nr; Wed, 07 Mar 2007 06:08:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOu0b-0004nm-Vu for pce@ietf.org; Wed, 07 Mar 2007 06:08:38 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOu0I-0004UJ-JZ for pce@ietf.org; Wed, 07 Mar 2007 06:08:37 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 12:08:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] draft-leroux-pce-of-00.txt Date: Wed, 7 Mar 2007 12:08:16 +0100 Message-ID: In-Reply-To: <45EE12F8.9040902@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] draft-leroux-pce-of-00.txt Thread-Index: AcdgmBjW58dZB2ffS6CmPKeGX85zeQADaAjw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Wenhu Lu" , X-OriginalArrivalTime: 07 Mar 2007 11:08:16.0720 (UTC) FILETIME=[E80BAD00:01C760A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: , Errors-To: pce-bounces@lists.ietf.org Hi Wenhu The acronym PCECP is a generic term that refers to any protocol for = communication between PCC and PCE. It does not refer to a specific = protocol. This term has been used in requirement documents. PCEP refers to a specific PCECP protocol, this is the protocol defined = by the PCE WG.=20 Does that clarify? Regards, JL > -----Message d'origine----- > De : Wenhu Lu [mailto:luw@redback.com]=20 > Envoy=E9 : mercredi 7 mars 2007 02:19 > =C0 : pce@ietf.org > Objet : Re: [Pce] draft-leroux-pce-of-00.txt >=20 > Hi Jean-Louis, >=20 > It came to my attention that the acronym PCEP was used=20 > throughout this draft whereas the acronym PCECP was used in=20 > drafts such as this one - >=20 > _PCE Communication Protocol (PCECP) Specific Requirements for=20 > Inter-Area Multi Protocol Label Switching (MPLS) and=20 > Generalized MPLS (GMPLS) Traffic Engineering=20 > > (26301 bytes)._ >=20 > Are these two acronyms going to converge at some time? >=20 > Regards, > -wenhu >=20 >=20 >=20 > LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > > Hi all, > > > > This new draft defines PCED and PCEP extensions for the encoding of=20 > > objective functions. > > We are waiting for WG feedback/comments. > > > > _http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt_ > > > > Regards, > > > > JL > > > > > >=20 > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > =20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 07 08:54:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOwap-0008LE-9c; Wed, 07 Mar 2007 08:54:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOwan-0008L2-E1 for pce@ietf.org; Wed, 07 Mar 2007 08:54:09 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOwal-0000Hl-PP for pce@ietf.org; Wed, 07 Mar 2007 08:54:09 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 07 Mar 2007 05:54:06 -0800 X-IronPort-AV: i="4.14,258,1170662400"; d="scan'208,217"; a="364441588:sNHT86132696" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l27Ds6eW005901; Wed, 7 Mar 2007 08:54:06 -0500 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 l27Ds0Zv001445; Wed, 7 Mar 2007 13:54:04 GMT 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.1830); Wed, 7 Mar 2007 08:53:59 -0500 Received: from [161.44.113.141] ([161.44.113.141]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 08:53:59 -0500 In-Reply-To: <45EE12F8.9040902@redback.com> References: <45EE12F8.9040902@redback.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <82DA0B86-6482-430B-959A-8342B5C5E0E4@cisco.com> From: JP Vasseur Subject: Re: [Pce] draft-leroux-pce-of-00.txt Date: Wed, 7 Mar 2007 08:53:57 -0500 To: Wenhu Lu X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Mar 2007 13:53:59.0220 (UTC) FILETIME=[0E3CC740:01C760C0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8783; t=1173275646; x=1174139646; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20draft-leroux-pce-of-00.txt |Sender:=20 |To:=20Wenhu=20Lu=20; bh=aEr55CJ+Ly8t8cCh4yRSEfVjwn6qQUuhj20V9oC0SF8=; b=QGqX/r3pbk6I9NIpkm+g2ptAbtss7SKRswptlt5z6d9akDG+3hcd2eUsGlnnujo8f4b9ZMCe UE3m9W8FFiTtBDEtIGnNFOZXEdXliTpsWnKDMA/1zF+QYiRwVmP1DSLM; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e 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="===============1175620338==" Errors-To: pce-bounces@lists.ietf.org --===============1175620338== Content-Type: multipart/alternative; boundary=Apple-Mail-10--452574051 --Apple-Mail-10--452574051 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Mar 6, 2007, at 8:18 PM, Wenhu Lu wrote: > Hi Jean-Louis, > > It came to my attention that the acronym PCEP was used throughout > this draft > whereas the acronym PCECP was used in drafts such as this one - > > _PCE Communication Protocol (PCECP) Specific Requirements for Inter- > Area Multi Protocol Label Switching (MPLS) and Generalized MPLS > (GMPLS) Traffic Engineering draft-ietf-pce-pcecp-interarea-reqs-05.txt> (26301 bytes)._ > > Are these two acronyms going to converge at some time? > The term PCECP is used in the requirement drafts because they refer to requirements for a PCE Communication Protocol: PCEP is the protocol that has been defined. Hope this clarifies. JP. > Regards, > -wenhu > > > > LE ROUX Jean-Louis RD-CORE-LAN wrote: >> >> Hi all, >> >> This new draft defines PCED and PCEP extensions for the encoding >> of objective functions. >> We are waiting for WG feedback/comments. >> >> _http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt_ >> >> Regards, >> >> JL >> >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> 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 --Apple-Mail-10--452574051 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

On Mar 6, = 2007, at 8:18 PM, Wenhu Lu wrote:

Hi Jean-Louis,

It came to my attention that the = acronym PCEP was used throughout this draft
whereas = the acronym PCECP was used in drafts such as this one -

_PCE = Communication Protocol (PCECP) Specific Requirements for Inter-Area = Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) = Traffic Engineering <http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-int= erarea-reqs-05.txt> (26301 bytes)._

Are these two = acronyms going to converge at some time?


The term PCECP is used in the requirement = drafts because they refer to requirements for a PCE Communication = Protocol: PCEP is the protocol that has been = defined.

Hope this = clarifies.

JP.=A0

Regards,



LE ROUX = Jean-Louis RD-CORE-LAN wrote:

Hi = all,

This new draft defines PCED and PCEP extensions for = the encoding of objective functions.
We are = waiting for WG feedback/comments.



JL


Pce mailing list

=A0=A0



Pce mailing list
=

= --Apple-Mail-10--452574051-- --===============1175620338== 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 --===============1175620338==-- From pce-bounces@lists.ietf.org Wed Mar 07 15:51:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP36Y-0002yy-De; Wed, 07 Mar 2007 15:51:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35P-0001OM-2E; Wed, 07 Mar 2007 15:50:11 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP35M-0001QX-0H; Wed, 07 Mar 2007 15:50:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 81C0C32AD9; Wed, 7 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35H-00031s-CS; Wed, 07 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-tc-mib-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: , 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 : Definitions of Textual Conventions for Path Computation Element Author(s) : E. Stephan Filename : draft-ietf-pce-tc-mib-01.txt Pages : 8 Date : 2007-3-7 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-tc-mib-01.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-tc-mib-01.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-tc-mib-01.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: <2007-3-7141607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-tc-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-tc-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7141607.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 Wed Mar 07 20:37:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7Yu-0003IY-SF; Wed, 07 Mar 2007 20:36:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7Yt-0003GA-N0 for pce@ietf.org; Wed, 07 Mar 2007 20:36:55 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP7Ys-0006jN-8n for pce@ietf.org; Wed, 07 Mar 2007 20:36:55 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BD90F46890E; Wed, 7 Mar 2007 17:36:53 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15870-05; Wed, 7 Mar 2007 17:36:53 -0800 (PST) Received: from [155.53.44.200] (malaga.redback.com [155.53.44.200]) by prattle.redback.com (Postfix) with ESMTP id A60D546890C; Wed, 7 Mar 2007 17:36:53 -0800 (PST) Message-ID: <45EF68B5.3030501@redback.com> Date: Wed, 07 Mar 2007 17:36:53 -0800 From: Wenhu Lu User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] draft-leroux-pce-of-00.txt References: <45EE12F8.9040902@redback.com> <82DA0B86-6482-430B-959A-8342B5C5E0E4@cisco.com> In-Reply-To: <82DA0B86-6482-430B-959A-8342B5C5E0E4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: , Errors-To: pce-bounces@lists.ietf.org JP Vasseur wrote: > Hi, > > On Mar 6, 2007, at 8:18 PM, Wenhu Lu wrote: > >> Hi Jean-Louis, >> >> It came to my attention that the acronym PCEP was used throughout >> this draft >> whereas the acronym PCECP was used in drafts such as this one - >> >> _PCE Communication Protocol (PCECP) Specific Requirements for >> Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS >> (GMPLS) Traffic Engineering >> >> (26301 bytes)._ >> >> Are these two acronyms going to converge at some time? >> > > The term PCECP is used in the requirement drafts because they refer to > requirements for *a* PCE Communication Protocol: PCEP is the protocol > that has been defined. > > Hope this clarifies. Thank you JP, point taken. I'm a little bit concerned about the symmetries of PCED and PCEP. It's not as easy in relating "Communication" to PCEP as "Discovery" to PCED. Maybe I missed something. Regards, -wenhu > > JP. > >> Regards, >> -wenhu >> >> >> >> LE ROUX Jean-Louis RD-CORE-LAN wrote: >>> >>> Hi all, >>> >>> This new draft defines PCED and PCEP extensions for the encoding of >>> objective functions. >>> We are waiting for WG feedback/comments. >>> >>> _http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt_ >>> >>> Regards, >>> >>> JL >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 Thu Mar 08 12:00:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPLyn-0000QI-5d; Thu, 08 Mar 2007 12:00:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPLyX-00080X-Qu for pce@ietf.org; Thu, 08 Mar 2007 12:00:22 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPLyR-0004aY-B1 for pce@ietf.org; Thu, 08 Mar 2007 12:00:21 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1HPLyQ-0000iR-Ga for pce@ietf.org; Thu, 08 Mar 2007 17:00:14 +0000 Received: from your029b8cecfe ([217.158.132.244] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 17:00:13 +0000 Message-ID: <184501c761a3$39f32cb0$22849ed9@your029b8cecfe> From: "Adrian Farrel" To: References: <03ec01c75075$d7e31e10$0d01a8c0@your029b8cecfe> Date: Thu, 8 Mar 2007 16:59:58 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 08 Mar 2007 17:00:13.0680 (UTC) FILETIME=[3D25CF00:01C761A3] X-Originating-Heisenberg-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [Pce] Working Group Last Call on Discovery Protocols Ended 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: , Errors-To: pce-bounces@lists.ietf.org Hi, The working group last call on these I-Ds has ended. Several comments were received from the IS-IS working group, and I believe some small updates are required as a result. Authors, please prepare an updated version of the IS-IS I-D and, if necessary, apply any corresponding changes to the OSPF I-D. Although the Secretariat is not taking draft submissions at the moment, we can post your new versions on the Alternate PCE page so that people can look at them and you can send mail to the list to say what you have changed. Then we will be ready to move forward immediately after Prague. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, February 14, 2007 5:35 PM Subject: [Pce] Working Group Last Call on Discovery Protocols > Hi, > > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-02.txt > > The authors have updated these drafts to accommodate my review comments, > and > I am happy that they are now ready for working group last call. > > We need to give the OSPF and ISIS working groups the chance to comment, so > I > am going to make this a three week last call, but please send your > comments > to the mailing list as soon as you can. > > The last call will end at 12 noon GMT on Thursday 8th March. > > Thanks, > Adrian > > > > _______________________________________________ > 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 Mar 08 14:09:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNzQ-0000hX-4D; Thu, 08 Mar 2007 14:09:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNzO-0000hJ-Sx for pce@ietf.org; Thu, 08 Mar 2007 14:09:22 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPNzN-0004kG-C3 for pce@ietf.org; Thu, 08 Mar 2007 14:09:22 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 20:08:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Working Group Last Call on Discovery Protocols Ended Date: Thu, 8 Mar 2007 20:08:53 +0100 Message-ID: In-Reply-To: <184501c761a3$39f32cb0$22849ed9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Working Group Last Call on Discovery Protocols Ended Thread-Index: Acdho3jr/nJqVoPoS9ijIsWJ+DhtBgAEZTbg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 08 Mar 2007 19:08:55.0038 (UTC) FILETIME=[376F89E0:01C761B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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: , Errors-To: pce-bounces@lists.ietf.org Hi Adrian, > Although the Secretariat is not taking draft submissions at=20 > the moment, we >=20 > can post your new versions on the Alternate PCE page so that=20 > people can look >=20 > at them and you can send mail to the list to say what you=20 > have changed. Then >=20 > we will be ready to move forward immediately after Prague. OK we will do that Thanks JL =20 > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Envoy=E9 : jeudi 8 mars 2007 18:00 > =C0 : pce@ietf.org > Objet : [Pce] Working Group Last Call on Discovery Protocols Ended >=20 > Attention, votre correspondant continue de vous =E9crire =E0=20 > votre ancienne adresse en @orange-ft.com, qui va =EAtre=20 > d=E9sactiv=E9e d=E9but avril. Veuillez lui demander de mettre =E0=20 > jour son carnet d'adresses avec votre nouvelle adresse en=20 > @orange-ftgroup.com. >=20 > Caution : your correspondent is still writing to your=20 > orange-ft.com address, which will be disabled beginning of=20 > April. Please ask him/her to update his/her address book to=20 > orange-ftgroup.com .................................................. >=20 > Hi, >=20 > The working group last call on these I-Ds has ended. >=20 > Several comments were received from the IS-IS working group,=20 > and I believe >=20 > some small updates are required as a result. >=20 > Authors, please prepare an updated version of the IS-IS I-D and, if >=20 > necessary, apply any corresponding changes to the OSPF I-D. >=20 > Although the Secretariat is not taking draft submissions at=20 > the moment, we >=20 > can post your new versions on the Alternate PCE page so that=20 > people can look >=20 > at them and you can send mail to the list to say what you=20 > have changed. Then >=20 > we will be ready to move forward immediately after Prague. >=20 > Thanks, > Adrian > ----- Original Message ----- >=20 > From: "Adrian Farrel" > To: > Sent: Wednesday, February 14, 2007 5:35 PM > Subject: [Pce] Working Group Last Call on Discovery Protocols >=20 >=20 > > Hi, > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-02 > > .txt=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-02 > > .txt > > > > The authors have updated these drafts to accommodate my review=20 > > comments, >=20 > > and > > I am happy that they are now ready for working group last call. > > > > We need to give the OSPF and ISIS working groups the chance to=20 > > comment, so >=20 > > I > > am going to make this a three week last call, but please send your >=20 > > comments > > to the mailing list as soon as you can. > > > > The last call will end at 12 noon GMT on Thursday 8th March. > > > > Thanks, > > Adrian > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 08 14:54:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPOgk-0001ae-Tx; Thu, 08 Mar 2007 14:54:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPOgk-0001aZ-75 for pce@ietf.org; Thu, 08 Mar 2007 14:54:10 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPOgg-0004mS-Md for pce@ietf.org; Thu, 08 Mar 2007 14:54:10 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2007 11:54:06 -0800 X-IronPort-AV: i="4.14,264,1170662400"; d="scan'208"; a="398857315:sNHT47824616" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l28Js5fD027439; Thu, 8 Mar 2007 11:54:05 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l28JrPxx007022; Thu, 8 Mar 2007 19:54:05 GMT 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.1830); Thu, 8 Mar 2007 14:53:52 -0500 Received: from [161.44.113.82] ([161.44.113.82]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 14:53:52 -0500 In-Reply-To: <45EF68B5.3030501@redback.com> References: <45EE12F8.9040902@redback.com> <82DA0B86-6482-430B-959A-8342B5C5E0E4@cisco.com> <45EF68B5.3030501@redback.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31A3D4FE-19C9-4A4B-82E2-D20B258B354E@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] draft-leroux-pce-of-00.txt Date: Thu, 8 Mar 2007 14:53:49 -0500 To: Wenhu Lu X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Mar 2007 19:53:52.0236 (UTC) FILETIME=[7F174AC0:01C761BB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2054; t=1173383645; x=1174247645; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20draft-leroux-pce-of-00.txt |Sender:=20; bh=bRVSCnpaxTRcaV00ebFbTWRzfqneAGhrodBEJaxkbJ4=; b=H+rHMxF+xt0c8xe0IMVKerSmw0u6ZiZe+k77uZT1NysOMKsItKzsFjBeOdyJvXk6JZhPYkgF ziI9FDgRDlkSG5LMTgZNPK8qKIi68SUxOslpLtsm9HgvITeiJq2lWJYJ; Authentication-Results: sj-dkim-5; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Errors-To: pce-bounces@lists.ietf.org On Mar 7, 2007, at 8:36 PM, Wenhu Lu wrote: > JP Vasseur wrote: >> Hi, >> >> On Mar 6, 2007, at 8:18 PM, Wenhu Lu wrote: >> >>> Hi Jean-Louis, >>> >>> It came to my attention that the acronym PCEP was used throughout >>> this draft >>> whereas the acronym PCECP was used in drafts such as this one - >>> >>> _PCE Communication Protocol (PCECP) Specific Requirements for >>> Inter-Area Multi Protocol Label Switching (MPLS) and Generalized >>> MPLS (GMPLS) Traffic Engineering >> drafts/draft-ietf-pce-pcecp-interarea-reqs-05.txt> (26301 bytes)._ >>> >>> Are these two acronyms going to converge at some time? >>> >> >> The term PCECP is used in the requirement drafts because they >> refer to requirements for *a* PCE Communication Protocol: PCEP is >> the protocol that has been defined. >> >> Hope this clarifies. > Thank you JP, point taken. > I'm a little bit concerned about the symmetries of PCED and PCEP. > It's not as easy in relating "Communication" to PCEP as "Discovery" > to PCED. > Maybe I missed something. > Not sure to see what you're concerned about ? JP. > Regards, > -wenhu >> >> JP. >>> Regards, >>> -wenhu >>> >>> >>> >>> LE ROUX Jean-Louis RD-CORE-LAN wrote: >>>> >>>> Hi all, >>>> >>>> This new draft defines PCED and PCEP extensions for the encoding >>>> of objective functions. >>>> We are waiting for WG feedback/comments. >>>> >>>> _http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt_ >>>> >>>> Regards, >>>> >>>> JL >>>> >>>> >>>> ------------------------------------------------------------------- >>>> ----- >>>> >>>> _______________________________________________ >>>> 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 Thu Mar 08 15:50:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZ5-0006yT-Td; Thu, 08 Mar 2007 15:50:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPYp-0006lu-CO; Thu, 08 Mar 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPYp-0007ah-10; Thu, 08 Mar 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id F3B553298A; Thu, 8 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYo-0007Fg-SP; Thu, 08 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disc-mib-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: , 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 : Definitions of Managed Objects for Path Computation Element Discovery Author(s) : E. Stephan Filename : draft-ietf-pce-disc-mib-01.txt Pages : 24 Date : 2007-3-8 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing Path Computation Elements Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disc-mib-01.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-disc-mib-01.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-disc-mib-01.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: <2007-3-8113241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disc-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disc-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8113241.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 Fri Mar 09 04:27:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbN5-00028B-W5; Fri, 09 Mar 2007 04:26:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPWmr-0006Y2-VF for pce@ietf.org; Thu, 08 Mar 2007 23:33:01 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPWmo-0000tD-ED for pce@ietf.org; Thu, 08 Mar 2007 23:33:01 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1173414776!23215100!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 7507 invoked from network); 9 Mar 2007 04:32:56 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-9.tower-120.messagelabs.com with SMTP; 9 Mar 2007 04:32:56 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l294WujW022656; Thu, 8 Mar 2007 23:32:56 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l294Wm7I022633; Thu, 8 Mar 2007 23:32:51 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] draft-leroux-pce-of-00.txt Date: Thu, 8 Mar 2007 22:28:27 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82C5@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] draft-leroux-pce-of-00.txt Thread-Index: AcdbVwERm/G70y43SzGrppgaWl9PcQBztA2QAMiArrAAbnR58A== References: <9473683187ADC049A855ED2DA739ABCA0DDC827B@KCCLUST06EVS1.ugd.att.com> From: "ASH, GERALD R, ATTLABS" To: "LE ROUX Jean-Louis RD-CORE-LAN" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Errors-To: pce-bounces@lists.ietf.org Hi JL, > -----Original Message----- > From: LE ROUX Jean-Louis RD-CORE-LAN=20 > [mailto:jeanlouis.leroux@orange-ftgroup.com]=20 > Sent: Tuesday, March 06, 2007 6:50 PM > To: ASH, GERALD R, ATTLABS; pce@ietf.org > Subject: RE: [Pce] draft-leroux-pce-of-00.txt=20 >=20 > Hi Jerry, >=20 > Thanks for the feedback and comments. >=20 > Please see inline,=20 >=20 > > -----Message d'origine----- > > De : ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > > Envoy=E9 : samedi 3 mars 2007 01:54 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org > > Cc : ASH, GERALD R, ATTLABS > > Objet : RE: [Pce] draft-leroux-pce-of-00.txt=20 > >=20 > > Hi JL, > >=20 > > Looks like a good start. =20 > >=20 > > Looking through the IANA section, I don't see registration of=20 > > the objective functions (OFs) required in Section 5.1.17 of > > http://www.rfc-editor.org/rfc/rfc4657.txt: > >=20 > > " The PCECP MUST support at least the following "unsynchronized" > > functions: > >=20 > > - Minimum cost path with respect to a specified metric > > (shortest path) > > - Least loaded path > > - Maximum available bandwidth path > >=20 > > Also, the PCECP MUST support at least the following=20 > > "synchronized" objective functions: > >=20 > > - Minimize aggregate bandwidth consumption on all links > > - Maximize the residual bandwidth on the most loaded link > > - Minimize the cumulative cost of a set of diverse paths" > >=20 > > Shouldn't these standard OFs and their parameters be=20 > > registered from the start? >=20 > Actually we prefer to keep this draft generic, and define=20 > specific objective functions in other documents. For instance=20 > draft-lee-pce-global-concurrent-optimization-02.txt requests=20 > for three code points within the OF registry. I guess I have the same question. Which PCEP document(s) will specify = the missing 6 objective functions, listed above, as required in Section = 5.1.17 of the PCECP Generic Requirements (RFC 4657)? I don't think = these should be specified in 'other' (unnamed) documents, they should = appear in the main PCEP specification document = http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt, or = perhaps in draft-leroux-pce-of-00.txt. Thanks, Regards, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 14 13:55:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXgH-0000I3-6l; Wed, 14 Mar 2007 13:54:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXgE-0000GZ-9h for pce@ietf.org; Wed, 14 Mar 2007 13:54:30 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRXdY-000056-IQ for pce@ietf.org; Wed, 14 Mar 2007 13:51:46 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 18:51:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] draft-leroux-pce-of-00.txt Date: Wed, 14 Mar 2007 18:51:36 +0100 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82C5@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] draft-leroux-pce-of-00.txt Thread-Index: AcdbVwERm/G70y43SzGrppgaWl9PcQBztA2QAMiArrAAbnR58AEJVQNA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "ASH, GERALD R, ATTLABS" , X-OriginalArrivalTime: 14 Mar 2007 17:51:09.0352 (UTC) FILETIME=[58F2DA80:01C76661] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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: , Errors-To: pce-bounces@lists.ietf.org Hi Jerry,=20 > -----Message d'origine----- > De : ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > Envoy=E9 : vendredi 9 mars 2007 05:28 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org > Objet : RE: [Pce] draft-leroux-pce-of-00.txt=20 >=20 > Hi JL, >=20 > > -----Original Message----- > > From: LE ROUX Jean-Louis RD-CORE-LAN > > [mailto:jeanlouis.leroux@orange-ftgroup.com] > > Sent: Tuesday, March 06, 2007 6:50 PM > > To: ASH, GERALD R, ATTLABS; pce@ietf.org > > Subject: RE: [Pce] draft-leroux-pce-of-00.txt > >=20 > > Hi Jerry, > >=20 > > Thanks for the feedback and comments. > >=20 > > Please see inline, > >=20 > > > -----Message d'origine----- > > > De : ASH, GERALD R, ATTLABS [mailto:gash@att.com] Envoy=E9=20 > : samedi 3=20 > > > mars 2007 01:54 =C0 : LE ROUX Jean-Louis RD-CORE-LAN;=20 > pce@ietf.org Cc=20 > > > : ASH, GERALD R, ATTLABS Objet : RE: [Pce]=20 > > > draft-leroux-pce-of-00.txt > > >=20 > > > Hi JL, > > >=20 > > > Looks like a good start. =20 > > >=20 > > > Looking through the IANA section, I don't see registration of the=20 > > > objective functions (OFs) required in Section 5.1.17 of > > > http://www.rfc-editor.org/rfc/rfc4657.txt: > > >=20 > > > " The PCECP MUST support at least the following "unsynchronized" > > > functions: > > >=20 > > > - Minimum cost path with respect to a specified metric > > > (shortest path) > > > - Least loaded path > > > - Maximum available bandwidth path > > >=20 > > > Also, the PCECP MUST support at least the following=20 > > > "synchronized" objective functions: > > >=20 > > > - Minimize aggregate bandwidth consumption on all links > > > - Maximize the residual bandwidth on the most loaded link > > > - Minimize the cumulative cost of a set of diverse paths" > > >=20 > > > Shouldn't these standard OFs and their parameters be=20 > registered from=20 > > > the start? > >=20 > > Actually we prefer to keep this draft generic, and define specific=20 > > objective functions in other documents. For instance=20 > > draft-lee-pce-global-concurrent-optimization-02.txt=20 > requests for three=20 > > code points within the OF registry. >=20 > I guess I have the same question. Which PCEP document(s)=20 > will specify the missing 6 objective functions, listed above,=20 > as required in Section 5.1.17 of the PCECP Generic=20 > Requirements (RFC 4657)? Two objective functions listed in 5.1.17 are specified in section 5.1 of draft-lee-pce-global-concurrent-optimization-02.txt. We can add other synchronized objective functions in the next revision = of the gco draft. > I don't think these should be=20 > specified in 'other' (unnamed) documents, they should appear=20 > in the main PCEP specification document=20 > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt Hum, this would create dependancy between the PCEP spec which is stable = and this new OF draft. > , or perhaps in draft-leroux-pce-of-00.txt. We don't really like this option as we want to keep the OF draft = generic. One could write a short draft that would define a set of straightforward = unsynchronized objective functions including those we listed in 4657. Regards, JL >=20 > Thanks, > Regards, > Jerry >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 14 16:17:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZuG-0004Dl-EC; Wed, 14 Mar 2007 16:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZuE-0004Ck-Ud for pce@ietf.org; Wed, 14 Mar 2007 16:17:06 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRZuB-0003mo-I1 for pce@ietf.org; Wed, 14 Mar 2007 16:17:06 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-15.tower-146.messagelabs.com!1173903422!5533429!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23369 invoked from network); 14 Mar 2007 20:17:02 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-15.tower-146.messagelabs.com with SMTP; 14 Mar 2007 20:17:02 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2EKH1wD026300; Wed, 14 Mar 2007 16:17:02 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2EKGkpC026202; Wed, 14 Mar 2007 16:16:58 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] draft-leroux-pce-of-00.txt Date: Wed, 14 Mar 2007 15:16:51 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC82FE@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] draft-leroux-pce-of-00.txt Thread-Index: AcdbVwERm/G70y43SzGrppgaWl9PcQBztA2QAMiArrAAbnR58AEJVQNAABJeg4A= References: <9473683187ADC049A855ED2DA739ABCA0DDC82C5@KCCLUST06EVS1.ugd.att.com> From: "ASH, GERALD R, ATTLABS" To: "LE ROUX Jean-Louis RD-CORE-LAN" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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: , Errors-To: pce-bounces@lists.ietf.org Hi JL,=20 > -----Original Message----- > From: LE ROUX Jean-Louis RD-CORE-LAN=20 > [mailto:jeanlouis.leroux@orange-ftgroup.com]=20 > Sent: Wednesday, March 14, 2007 1:52 PM > To: ASH, GERALD R, ATTLABS; pce@ietf.org > Subject: RE: [Pce] draft-leroux-pce-of-00.txt=20 >=20 > Hi Jerry,=20 >=20 > > -----Message d'origine----- > > De : ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > > Envoy=E9 : vendredi 9 mars 2007 05:28 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org > > Objet : RE: [Pce] draft-leroux-pce-of-00.txt=20 > >=20 > > Hi JL, > >=20 > > > -----Original Message----- > > > From: LE ROUX Jean-Louis RD-CORE-LAN > > > [mailto:jeanlouis.leroux@orange-ftgroup.com] > > > Sent: Tuesday, March 06, 2007 6:50 PM > > > To: ASH, GERALD R, ATTLABS; pce@ietf.org > > > Subject: RE: [Pce] draft-leroux-pce-of-00.txt > > >=20 > > > Hi Jerry, > > >=20 > > > Thanks for the feedback and comments. > > >=20 > > > Please see inline, > > >=20 > > > > -----Message d'origine----- > > > > De : ASH, GERALD R, ATTLABS [mailto:gash@att.com] Envoy=E9=20 > > : > samedi 3=20 > > > > mars 2007 01:54 =C0 : LE ROUX Jean-Louis RD-CORE-LAN;=20 > > > > pce@ietf.org Cc=20 > > > > : ASH, GERALD R, ATTLABS Objet : RE: [Pce]=20 > > > > draft-leroux-pce-of-00.txt > > > >=20 > > > > Hi JL, > > > >=20 > > > > Looks like a good start. =20 > > > >=20 > > > > Looking through the IANA section, I don't see=20 > registration of the=20 > > > > objective functions (OFs) required in Section 5.1.17 of > > > > http://www.rfc-editor.org/rfc/rfc4657.txt: > > > >=20 > > > > " The PCECP MUST support at least the following=20 > > > > "unsynchronized" > > > > functions: > > > >=20 > > > > - Minimum cost path with respect to a specified metric > > > > (shortest path) > > > > - Least loaded path > > > > - Maximum available bandwidth path > > > >=20 > > > > Also, the PCECP MUST support at least the following=20 > > > > "synchronized" objective functions: > > > >=20 > > > > - Minimize aggregate bandwidth consumption on all links > > > > - Maximize the residual bandwidth on the most loaded link > > > > - Minimize the cumulative cost of a set of diverse paths" > > > >=20 > > > > Shouldn't these standard OFs and their parameters be=20 > > > > registered from=20 > > > > the start? > > >=20 > > > Actually we prefer to keep this draft generic, and define=20 > > > specific=20 > > > objective functions in other documents. For instance=20 > > > draft-lee-pce-global-concurrent-optimization-02.txt=20 > > > requests for three=20 > > > code points within the OF registry. > >=20 > > I guess I have the same question. Which PCEP document(s)=20 > > will specify the missing 6 objective functions, listed above,=20 > > as required in Section 5.1.17 of the PCECP Generic=20 > > Requirements (RFC 4657)? >=20 > Two objective functions listed in 5.1.17 are specified in=20 > section 5.1 of > draft-lee-pce-global-concurrent-optimization-02.txt. > We can add other synchronized objective functions in the next=20 > revision of the gco draft. >=20 > > I don't think these should be=20 > > specified in 'other' (unnamed) documents, they should appear=20 > > in the main PCEP specification document=20 > > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt >=20 > Hum, this would create dependency between the PCEP spec which=20 > is stable and this new OF draft. >=20 > > , or perhaps in draft-leroux-pce-of-00.txt. >=20 > We don't really like this option as we want to keep the OF=20 > draft generic. >=20 > One could write a short draft that would define a set of=20 > straightforward unsynchronized objective functions including=20 > those we listed in 4657. IMO an important missing PCECP requirement is identified in = http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt Appendix = A (Compliance with the PCECP Requirement Document): " Here is the list of currently unsatisfied requirements: o Allow to select/prefer from advertised list of standard objective functions/options o Allow to customize objective function/options o Support "unsynchronized" & "synchronized" objective functions" They all deal with the missing 6 objective functions required in RFC = 4657, and are an important omission in PCEP, so far. You say that PCEP is 'stable' so you don't want to add them there? Does = that mean no further changes to PCEP before WGLC? If so, the omission = would be brought up during WGLC as an important gap in PCEP. You don't want them in the OF draft, OK, your call. Finally, once again, I don't think other new drafts (e.g., = draft-lee-pce-global-concurrent-optimization-02.txt) that specify = perhaps *new* PCEP requirements, should be satisfying the original RFC = 4657 PCECP requirements on PCEP. You also say 'We can add other = synchronized objective functions in the next revision of the gco draft.' = I don't think that's the right place to satisfy the PCECP requirements. = And furthermore you say that yet another draft 'would define a set of = straightforward unsynchronized objective functions including those we = listed in 4657.' It doesn't make sense IMO, rather, all 6 of these = objective functions should be specified in the PCEP document. It would be good to have other opinions on this. Thanks, Regards, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 14 18:38:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRc6m-00005r-Cc; Wed, 14 Mar 2007 18:38:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRc6l-0008WD-Gr for pce@ietf.org; Wed, 14 Mar 2007 18:38:11 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRc6j-0003Gv-Vu for pce@ietf.org; Wed, 14 Mar 2007 18:38:11 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 23:37:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] draft-leroux-pce-of-00.txt Date: Wed, 14 Mar 2007 23:37:42 +0100 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC82FE@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] draft-leroux-pce-of-00.txt Thread-Index: AcdbVwERm/G70y43SzGrppgaWl9PcQBztA2QAMiArrAAbnR58AEJVQNAABJeg4AABX8JsA== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "ASH, GERALD R, ATTLABS" , X-OriginalArrivalTime: 14 Mar 2007 22:37:58.0445 (UTC) FILETIME=[6A5E0DD0:01C76689] X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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: , Errors-To: pce-bounces@lists.ietf.org Hi Jerry,=20 > -----Message d'origine----- > De : ASH, GERALD R, ATTLABS [mailto:gash@att.com]=20 > Envoy=E9 : mercredi 14 mars 2007 21:17 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org > Cc : ASH, GERALD R, ATTLABS > Objet : RE: [Pce] draft-leroux-pce-of-00.txt=20 >=20 > Hi JL,=20 >=20 > > -----Original Message----- > > From: LE ROUX Jean-Louis RD-CORE-LAN > > [mailto:jeanlouis.leroux@orange-ftgroup.com] > > Sent: Wednesday, March 14, 2007 1:52 PM > > To: ASH, GERALD R, ATTLABS; pce@ietf.org > > Subject: RE: [Pce] draft-leroux-pce-of-00.txt > >=20 > > Hi Jerry, > >=20 > > > -----Message d'origine----- > > > De : ASH, GERALD R, ATTLABS [mailto:gash@att.com] Envoy=E9=20 > : vendredi=20 > > > 9 mars 2007 05:28 =C0 : LE ROUX Jean-Louis RD-CORE-LAN;=20 > pce@ietf.org=20 > > > Objet : RE: [Pce] draft-leroux-pce-of-00.txt > > >=20 > > > Hi JL, > > >=20 > > > > -----Original Message----- > > > > From: LE ROUX Jean-Louis RD-CORE-LAN=20 > > > > [mailto:jeanlouis.leroux@orange-ftgroup.com] > > > > Sent: Tuesday, March 06, 2007 6:50 PM > > > > To: ASH, GERALD R, ATTLABS; pce@ietf.org > > > > Subject: RE: [Pce] draft-leroux-pce-of-00.txt > > > >=20 > > > > Hi Jerry, > > > >=20 > > > > Thanks for the feedback and comments. > > > >=20 > > > > Please see inline, > > > >=20 > > > > > -----Message d'origine----- > > > > > De : ASH, GERALD R, ATTLABS [mailto:gash@att.com] Envoy=E9 > > > : > samedi 3 > > > > > mars 2007 01:54 =C0 : LE ROUX Jean-Louis RD-CORE-LAN;=20 > pce@ietf.org=20 > > > > > Cc > > > > > : ASH, GERALD R, ATTLABS Objet : RE: [Pce]=20 > > > > > draft-leroux-pce-of-00.txt > > > > >=20 > > > > > Hi JL, > > > > >=20 > > > > > Looks like a good start. =20 > > > > >=20 > > > > > Looking through the IANA section, I don't see > > registration of the > > > > > objective functions (OFs) required in Section 5.1.17 of > > > > > http://www.rfc-editor.org/rfc/rfc4657.txt: > > > > >=20 > > > > > " The PCECP MUST support at least the following=20 > > > > > "unsynchronized" > > > > > functions: > > > > >=20 > > > > > - Minimum cost path with respect to a specified metric > > > > > (shortest path) > > > > > - Least loaded path > > > > > - Maximum available bandwidth path > > > > >=20 > > > > > Also, the PCECP MUST support at least the following=20 > > > > > "synchronized" objective functions: > > > > >=20 > > > > > - Minimize aggregate bandwidth consumption on all links > > > > > - Maximize the residual bandwidth on the most loaded link > > > > > - Minimize the cumulative cost of a set of diverse paths" > > > > >=20 > > > > > Shouldn't these standard OFs and their parameters be=20 > registered=20 > > > > > from the start? > > > >=20 > > > > Actually we prefer to keep this draft generic, and=20 > define specific=20 > > > > objective functions in other documents. For instance=20 > > > > draft-lee-pce-global-concurrent-optimization-02.txt > > > > requests for three > > > > code points within the OF registry. > > >=20 > > > I guess I have the same question. Which PCEP document(s) will=20 > > > specify the missing 6 objective functions, listed above,=20 > as required=20 > > > in Section 5.1.17 of the PCECP Generic Requirements (RFC 4657)? > >=20 > > Two objective functions listed in 5.1.17 are specified in=20 > section 5.1=20 > > of draft-lee-pce-global-concurrent-optimization-02.txt. > > We can add other synchronized objective functions in the=20 > next revision=20 > > of the gco draft. > >=20 > > > I don't think these should be > > > specified in 'other' (unnamed) documents, they should=20 > appear in the=20 > > > main PCEP specification document=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt > >=20 > > Hum, this would create dependency between the PCEP spec which is=20 > > stable and this new OF draft. > >=20 > > > , or perhaps in draft-leroux-pce-of-00.txt. > >=20 > > We don't really like this option as we want to keep the OF draft=20 > > generic. > >=20 > > One could write a short draft that would define a set of=20 > > straightforward unsynchronized objective functions=20 > including those we=20 > > listed in 4657. >=20 > IMO an important missing PCECP requirement is identified in=20 > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt > Appendix A (Compliance with the PCECP Requirement Document): >=20 > " Here is the list of currently unsatisfied requirements: >=20 > o Allow to select/prefer from advertised list of standard=20 > objective > functions/options >=20 > o Allow to customize objective function/options >=20 > o Support "unsynchronized" & "synchronized" objective functions" >=20 > They all deal with the missing 6 objective functions required=20 > in RFC 4657, and are an important omission in PCEP, so far. In montreal we indicated that objective functions would not be covered = in the base PCEP spec.=20 There was no objection. This was recalled in San Diego, again no = objection... >=20 > You say that PCEP is 'stable' so you don't want to add them=20 > there? =20 What I say is that this would create dependancy between PCEP and OF = drafts which is not good. The base PCEP draft should not have any = dependancy with other drafts. > Does that mean no further changes to PCEP before=20 > WGLC?=20 Definitely no! But, again, note that it was agreed that objective functions would not = be covered in the base spec. > If so, the omission would be brought up during WGLC as=20 > an important gap in PCEP. As far as I know in 4657 we don't say that all MUST requirements MUST be = covered in the same document... >=20 > You don't want them in the OF draft, OK, your call. >=20 > Finally, once again, I don't think other new drafts (e.g.,=20 > draft-lee-pce-global-concurrent-optimization-02.txt) that=20 > specify perhaps *new* PCEP requirements, should be satisfying=20 > the original RFC 4657 PCECP requirements on PCEP. =20 Why? Draft-lee specifies two objective functions listed in 4657, where is the = problem? > You also=20 > say 'We can add other synchronized objective functions in the=20 > next revision of the gco draft.' I don't think that's the=20 > right place to satisfy the PCECP requirements. Why?=20 > And=20 > furthermore you say that yet another draft 'would define a=20 > set of straightforward unsynchronized objective functions=20 > including those we listed in 4657.' It doesn't make sense=20 > IMO, rather, all 6 of these objective functions should be=20 > specified in the PCEP document. >=20 > It would be good to have other opinions on this. Regards, JL >=20 > Thanks, > Regards, > Jerry >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 15 17:46:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxlf-0006u5-TA; Thu, 15 Mar 2007 17:45:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxlc-0006q2-BB; Thu, 15 Mar 2007 17:45:48 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRxlc-0006AA-1E; Thu, 15 Mar 2007 17:45:48 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id ED65517684; Thu, 15 Mar 2007 21:45:17 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HRxl7-0003JJ-Nn; Thu, 15 Mar 2007 17:45:17 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 15 Mar 2007 17:45:17 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Internet Architecture Board , pce mailing list , pce chair , RFC Editor Subject: [Pce] Document Action: 'PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering' to Informational RFC 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: , Errors-To: pce-bounces@lists.ietf.org The IESG has approved the following document: - 'PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering ' as an Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-05.txt Technical Summary This document lists a detailed set of requirements for the Path Computation Element Communication Protocol for support of inter- area TE-LSP path computation. This specifically applies to paths that cross multiple areas within a single IGP routing domain. It complements the generic requirements for a PCE Communication Protocol. Working Group Summary no dissent reported. Protocol Quality Ross Callon has reviewed this spec for the IESG. As a requirements document, it inherently isn't implemented, but there is ongoing work to update the PCE Communications Protocol to handle inter-area path computation consistent with these requirements. Note to RFC Editor The email address for Nabil Bitar (in section 11 contributors' addresses) should be nabil.n.bitar@verizon.com. Please replace the second paragraph of section 5 (Manageability Considerations) as follows: Old Text (one paragraph to be removed): A built in diagnostic tool MUST be defined to monitor the performances of a PCE chain, in case of multiple-PCE inter-area path computation. It MUST allow determining the minimum maximum and average response time globally for the chain, and on a per PCE basis. New Text (two paragraphs to be added): It is really important, for diagnostic and troubleshooting reasons, to monitor the availability and performances of each PCE of a PCE chain used for inter-area path computation. Particularly it is really important to identify the PCE(s) responsible for a delayed reply. Hence a mechanism MUST be defined to monitor the performances of a PCE chain. It MUST allow determining the availability of each PCE of the chain as well as its minimum maximum and average response time. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 15 17:55:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxvE-0004hV-SD; Thu, 15 Mar 2007 17:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxvD-0004gm-AS for pce@ietf.org; Thu, 15 Mar 2007 17:55:43 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRxv0-0007cm-9w for pce@ietf.org; Thu, 15 Mar 2007 17:55:43 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-146.messagelabs.com!1173995729!3284366!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14671 invoked from network); 15 Mar 2007 21:55:29 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-146.messagelabs.com with SMTP; 15 Mar 2007 21:55:29 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FLtSbV019905; Thu, 15 Mar 2007 17:55:28 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FLtEa3019828; Thu, 15 Mar 2007 17:55:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] draft-leroux-pce-of-00.txt Date: Thu, 15 Mar 2007 16:55:03 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8308@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] draft-leroux-pce-of-00.txt Thread-Index: AcdbVwERm/G70y43SzGrppgaWl9PcQBztA2QAMiArrAAbnR58AEJVQNAABJeg4AABX8JsAAw+otw References: <9473683187ADC049A855ED2DA739ABCA0DDC82FE@KCCLUST06EVS1.ugd.att.com> From: "ASH, GERALD R, ATTLABS" To: "LE ROUX Jean-Louis RD-CORE-LAN" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: , Errors-To: pce-bounces@lists.ietf.org Hi JL,=20 > > IMO an important missing PCECP requirement is identified in=20 > > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt > > Appendix A (Compliance with the PCECP Requirement Document): > >=20 > > " Here is the list of currently unsatisfied requirements: > >=20 > > o Allow to select/prefer from advertised list of standard=20 > > objective > > functions/options > >=20 > > o Allow to customize objective function/options > >=20 > > o Support "unsynchronized" & "synchronized" objective functions" > >=20 > > They all deal with the missing 6 objective functions required=20 > > in RFC 4657, and are an important omission in PCEP, so far. >=20 >=20 > In montreal we indicated that objective functions would not=20 > be covered in the base PCEP spec.=20 > There was no objection. This was recalled in San Diego, again=20 > no objection... Well that doesn't cast it in concrete, I'll register my objection. Without objective functions, PCE would not be able to do much to optimize path computation. I think it's important for PCEP to include the objective functions required in the PCECP generic requirements in the base PCEP spec. =20 > > You say that PCEP is 'stable' so you don't want to add them=20 > > there? =20 >=20 > What I say is that this would create dependency between PCEP=20 > and OF drafts which is not good. The base PCEP draft should=20 > not have any dependency with other drafts. >=20 > > Does that mean no further changes to PCEP before=20 > > WGLC?=20 >=20 > Definitely no! >=20 > But, again, note that it was agreed that objective functions=20 > would not be covered in the base spec. See above comments. =20 > > I don't think other new drafts (e.g.,=20 > > draft-lee-pce-global-concurrent-optimization-02.txt) that=20 > > specify perhaps *new* PCEP requirements, should be satisfying=20 > > the original RFC 4657 PCECP requirements on PCEP. =20 >=20 > Why? >=20 > Draft-lee specifies two objective functions listed in 4657,=20 > where is the problem? Several. No rationale to put generic PCECP requirements in some other draft besides the base PCEP draft. The draft isn't a WG draft. There isn't any compelling reason to not specify the objective functions in the base PCEP draft. > > You also=20 > > say 'We can add other synchronized objective functions in the=20 > > next revision of the gco draft.' I don't think that's the=20 > > right place to satisfy the PCECP requirements. >=20 > Why?=20 See above comments. Thanks, Regards, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 15 19:28:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRzMH-0002sH-Ig; Thu, 15 Mar 2007 19:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRzMG-0002s6-3D for pce@ietf.org; Thu, 15 Mar 2007 19:27:44 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRzMD-0008Cp-Nb for pce@ietf.org; Thu, 15 Mar 2007 19:27:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2007 19:27:42 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2FNRfLe026454; Thu, 15 Mar 2007 19:27:41 -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 l2FNRdGd011433; Thu, 15 Mar 2007 23:27:39 GMT 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.1830); Thu, 15 Mar 2007 19:27:39 -0400 Received: from [192.168.1.48] ([10.82.243.58]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 19:27:38 -0400 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8308@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA0DDC82FE@KCCLUST06EVS1.ugd.att.com> <9473683187ADC049A855ED2DA739ABCA0DDC8308@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37E3E710-7217-432D-B56C-0C651DAB840D@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] draft-leroux-pce-of-00.txt Date: Fri, 16 Mar 2007 00:27:34 +0100 To: "ASH, GERALD R, ATTLABS" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 15 Mar 2007 23:27:38.0751 (UTC) FILETIME=[852E68F0:01C76759] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3899; t=1174001261; x=1174865261; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20draft-leroux-pce-of-00.txt=20 |Sender:=20 |To:=20=22ASH,=20GERALD=20R,=20ATTLABS=22=20; bh=GRtZXBmRezC2wjLpzGdvJjB7xwckRReGv1dsWKXLC3s=; b=CdzALDDGv4ndqMIx9IIRGB/JGuHvthJMRZIMqcQFHVpLo0xIBLySvt4X+p5WeoQ0ClWAQt+5 NLtp1f3tPdtwQFWrGNNzSZAz/AE+4/Mbv5OA+0xNuqdsD1cRiuJK9NH5; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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: , Errors-To: pce-bounces@lists.ietf.org Hi Jerry, On Mar 15, 2007, at 10:55 PM, ASH, GERALD R, ATTLABS wrote: > Hi JL, > >>> IMO an important missing PCECP requirement is identified in >>> http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-07.txt >>> Appendix A (Compliance with the PCECP Requirement Document): >>> >>> " Here is the list of currently unsatisfied requirements: >>> >>> o Allow to select/prefer from advertised list of standard >>> objective >>> functions/options >>> >>> o Allow to customize objective function/options >>> >>> o Support "unsynchronized" & "synchronized" objective functions" >>> >>> They all deal with the missing 6 objective functions required >>> in RFC 4657, and are an important omission in PCEP, so far. >> Let's try to step back for a minute. 1) PCEP has been designed so as to support the functionalities listed above. RFC 4657 does not mandate to define the objective functions but to allow to select objective functions, ... and that is clearly feasible with the PCEP design. As such I don't see any particular issues. 2) Yes, defining such functions is a good idea, thus the proposed draft, which is not at this point a WG ID indeed. Thanks for helping out on the content of this draft. 3) Whether to add those functions and other features in the base spec has indeed been debated during the last two WG meetings and the agreement was to freeze the current spec in order to stabilize the specification, wait to see implementations, interop reports, ... As you know, we have to draw the line somewhere and if we keep adding feature, the base protocol spec will not stabilize. The PCE being a new path computation concept, it is crucial to first stabilize a set of core features, acquire some experience based on deployments rather than keep adding features. Does that make sense ? Cheers. JP. >> >> In montreal we indicated that objective functions would not >> be covered in the base PCEP spec. >> There was no objection. This was recalled in San Diego, again >> no objection... > > Well that doesn't cast it in concrete, I'll register my objection. > Without objective functions, PCE would not be able to do much to > optimize path computation. I think it's important for PCEP to include > the objective functions required in the PCECP generic requirements in > the base PCEP spec. > >>> You say that PCEP is 'stable' so you don't want to add them >>> there? >> >> What I say is that this would create dependency between PCEP >> and OF drafts which is not good. The base PCEP draft should >> not have any dependency with other drafts. >> >>> Does that mean no further changes to PCEP before >>> WGLC? >> >> Definitely no! >> >> But, again, note that it was agreed that objective functions >> would not be covered in the base spec. > > See above comments. > >>> I don't think other new drafts (e.g., >>> draft-lee-pce-global-concurrent-optimization-02.txt) that >>> specify perhaps *new* PCEP requirements, should be satisfying >>> the original RFC 4657 PCECP requirements on PCEP. >> >> Why? >> >> Draft-lee specifies two objective functions listed in 4657, >> where is the problem? > > Several. No rationale to put generic PCECP requirements in some other > draft besides the base PCEP draft. The draft isn't a WG draft. There > isn't any compelling reason to not specify the objective functions in > the base PCEP draft. > >>> You also >>> say 'We can add other synchronized objective functions in the >>> next revision of the gco draft.' I don't think that's the >>> right place to satisfy the PCECP requirements. >> >> Why? > > See above comments. > > Thanks, > Regards, > Jerry > > _______________________________________________ > 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 Sun Mar 18 15:58:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT1Vu-0008BH-4r; Sun, 18 Mar 2007 15:57:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT1Vs-00089s-KX for pce@ietf.org; Sun, 18 Mar 2007 15:57:56 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT1Vq-0007l6-Ro for pce@ietf.org; Sun, 18 Mar 2007 15:57:56 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 18 Mar 2007 12:57:55 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2IJvswM030780; Sun, 18 Mar 2007 12:57:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2IJvpA8022822; Sun, 18 Mar 2007 19:57:51 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 12:57:51 -0700 Received: from [10.0.0.86] ([10.21.89.79]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 12:57:50 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt Date: Sun, 18 Mar 2007 20:57:43 +0100 To: DOLGANOW Andrew X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 18 Mar 2007 19:57:50.0349 (UTC) FILETIME=[B525F3D0:01C76997] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11307; t=1174247874; x=1175111874; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Re=3A=20I-D=20ACTION=3Adraft-vasseur-pce-moni toring-02.txt |Sender:=20; bh=Z6jx/0bozxANrJ8dJEax6dXPkTqUMmbnwz/KcouRkq4=; b=v991R2hRMK3iKRrOZzZOHkeXBVoLmQwySQAZRKT7SXpWH0aTKGn0hbVvGcddhgd65LZdrjgY C15Iy27zW+SPFj8rSxyLEnDT2WeXQBYCdunN4nnPfZAaXNdNelgLIMRl; Authentication-Results: sj-dkim-8; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b 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: , Errors-To: pce-bounces@lists.ietf.org FYI, look at my reply to this email. More in line, On Mar 18, 2007, at 5:48 PM, DOLGANOW Andrew wrote: > Please see below prefixed with [ad] > >> -----Original Message----- >> From: Dimitri.Papadimitriou@alcatel-lucent.be >> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] >> Sent: Friday, March 02, 2007 11:50 AM >> To: JP Vasseur >> Cc: pce@ietf.org >> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt >> >> hi j-p >> >> see in-line >> >> >> >> >> JP Vasseur >> 02/03/2007 17:03 >> >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >> cc: pce@ietf.org >> Subject: Re: [Pce] Re: I-D >> ACTION:draft-vasseur-pce-monitoring-02.txt >> >> >> Hi Dimitri, >> >> On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel-lucent.be >> wrote: >> >>> a simple question >>> >>> >>> the document repeats twice that it critical to monitor the state of >>> the PC chain (see below) >>> >> >> Yes indeed. >> >>> >>> i try to understand reasoning - can authors clarify ? >>> >>> for perf.mon ? is the PCC going to tack perfs of PC servers ? >>> >>> for troubleshooting ? but for which trouble ? >> >> I think that the motivation is fairly simple here ... You may >> want to monitor various aspects. >> For example, you may want to measure the path computation >> response time. That might be for performance monitoring or >> troubleshooting because a PCC experience very long response >> time. The motivation sounds extremely obvious: PCE OAM. As >> for any other system, the user may want to monitor the >> performance for network design, troubleshooting, ... >> >> [dp] PC response time, but how are you going to ensure that >> running conditions are identical at time t[n-1], t[n], t[n+1] >> ? in fact the question is the relevance of repeating a given >> request when the run conditions can be completely different >> > [ad] Dimitri brings a valid point here. This was discussed in San > Diego, > proposed to be taken to the list and never really answered. In > addition > to the time variable, for performance monitoring to work, we would > need > to ensure that no steps are skipped along the process. The best way I > would say would be to monitor Request/Results from PCC and if required > issue another PC request (which could collect timestamps along the > process). You miss a point here ... of course, you can monitor the overall response time but how do you figure out the time you spent along the PCE chain ? > >>> (this said, i am also >>> concerned by the fact that if each PCC for each path across >> a set of >>> PCEs starts to generate such state monitoring then for sure servers >>> may experience overload) >> >> Ah no ... this is an implementation issue on the PCE if >> you've such issue. >> >> [dp] i disagree, if one builds a PCE to sustain x PC demands >> per unit of time, but PCE gets now confronted to the fact >> that a number X of clients, X >> x, are permanently polling >> the server (remember that the PC server can be memoryless) >> for monitoring all the previously computed path, the running >> conditions are completely different, in fact the performance >> of your system degrades over time (i know a well known >> operating system that shows the same property ;-( >> > > [ad] Agree with Dimitri. Please look at my reply to Dimitri to this point. > More so, PCE may be implemented to give > priority to various messages and limit certain messages (so the > implementation may not help monitoring here as JP is suggesting) and > again you could get different results of a monitoring request than > computational request. Again you make some confusion here: we're not trying to build a way to proritize messages, ... this is already in PCEP. The aim of the this draft is to have OAM. > >> => the PCE OAM mechanism implies a completely mode of >> operation that influence the capacity of the system >> >> Furthermore, if you experience an issue, would you prefer to >> ignore it or to be able to locate it ? >> >> [dp] use my local computation capability rely on "external domain" >> to solve an local problem may be >> >>> due to limited visibility ? why is this requiring "state >> monitoring" ? >>> >>> >>> ---> in brief, i still believe a serious problem statement shall be >>> brought up before jumping in the specification of objects >> (the bits of >>> the wire) >>> >>> >> >> Hope this clarifies but the motivations are indeed quite >> straightforward. >> >> [dp] unfortunately, i am not convinced about the usefulness >> of this mechanism and the problem is that if it would >> harmless then i would not have any issue but it is not >> > [ad] agree with Dimitri, all that is looked after by the monitoring > mechanism can be achieved without that mechanism in place. So if you have a PCE chain PCC----PCE1----PCE2-----Dest How do the determine various perf metric along the chain with the mechanism in place ? > The mechanism > may add to the problem by being badly deployed and with many PCCs > runnning performance monitoring. With scaling and time passing the > mechanism may degrade PCE. This is implementation specific. If you design your system properly, you won't have this problem. Back to your previous point you have different message priority + other mechanisms to avoid this. > We do not want to monitor the monitoring > mechanism? > Sorry but this makes no sense. We're not monitoring the monitoring mechanism at all. JP. >> Thanks. >> >> JP. >> >>> thanks, >>> -d. >>> -- >>> >>> "In PCE-based environments, it is critical to monitor the >> state of the >>> path computation chain that can be used for performance >> monitoring >>> and troubleshooting purposes. This document specifies >> procedures >>> and >>> extensions to the Path Computation Element Protocol (PCEP) >>> ([I-D.ietf-pce-pcep]) in order to monitor the path computation >>> chain >>> and gather various performance metrics. >>> >>> As discussed in [RFC4655], a TE LSP may be computed by one PCE >>> (referred to as single PCE path computation) or several PCEs >>> (referred to as multiple PCE path computation). In the former >>> case, >>> the PCC may be able to use IGP extensions to check the >> liveness of >>> the PCE (see [I-D.ietf-pce-disco-proto-ospf] and >>> [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive >> messages. >>> In contrast, when multiple PCEs are involved in the path >>> computation >>> chain an example of which is the BRPC procedure defined in >>> [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the >>> first >>> PCE involved in the path computation chain. Thus, it is >> critical >>> to >>> define mechanisms in order to monitor the state of the path >>> computation chain." >>> >>> -- >>> >>> >>> >>> >>> >>> Internet-Drafts@ietf.org >>> 01/03/2007 21:50 >>> Please respond to internet-drafts >>> >>> To: i-d-announce@ietf.org >>> cc: >>> Subject: I-D >> ACTION:draft-vasseur-pce-monitoring-02.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : A set of >> monitoring >>> tools for Path Computation Element based Architecture >>> Author(s) : J. Le Roux, J. Vasseur >>> Filename : >>> draft-vasseur-pce-monitoring-02.txt >>> Pages : 18 >>> Date : 2007-3-1 >>> >>> A Path Computation Element (PCE) based architecture has been >>> specified for the computation of Traffic Engineering (TE) Label >>> Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and >>> Generalized MPLS (GMPLS) networks in the context of single or >>> multiple domains (where a domain is referred to as a >> collection of >>> network elements within a common sphere of address management or >>> path computational responsibility such as IGP areas and Autonomous >>> Systems). In PCE-based environments it is thus critical >> to monitor >>> the state of the path computation chain that can be used for >>> performance monitoring and troubleshooting purposes. >> This document >>> specifies procedures and extensions to the Path >> Computation Element >>> Protocol (PCEP) in order to gather such information. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-vasseur-pce- >>> monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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. >>> ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- >>> monitoring-02.txt >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/i-d-announce >>> >>> >>> >>> _______________________________________________ >>> 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 Mar 19 05:47:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTEST-0001Kg-Sg; Mon, 19 Mar 2007 05:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTESS-0001KP-D0 for pce@ietf.org; Mon, 19 Mar 2007 05:47:16 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTESR-000294-4O for pce@ietf.org; Mon, 19 Mar 2007 05:47:16 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 19 Mar 2007 02:47:14 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2J9lEUn015713 for ; Mon, 19 Mar 2007 02:47:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2J9lEEi015686 for ; Mon, 19 Mar 2007 09:47:14 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 02:47:14 -0700 Received: from [130.129.19.82] ([10.21.115.76]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 02:47:13 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain To: pce@ietf.org From: JP Vasseur Date: Mon, 19 Mar 2007 10:47:09 +0100 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Mar 2007 09:47:13.0978 (UTC) FILETIME=[929521A0:01C76A0B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2; t=1174297634; x=1175161634; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Please=20send=20the=20missing=20presentations.=20Thanks.=20JP |Sender:=20; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=H1S7A4eWR1y6n7f+WQdHUKJqij7izTuhMB6lZ6MHs3qqzBkTYtLv/VBnrevSJhi2yP/vEG4B gtZgfCc6qgf/4r80hKdEmB0EQSGB0zQupco+SheHW/bgOQR2IQZGbd9n; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Cc: Subject: [Pce] Please send the missing presentations. Thanks. JP 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: , Errors-To: pce-bounces@lists.ietf.org _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Mar 19 09:17:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHjG-00040a-6a; Mon, 19 Mar 2007 09:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHjE-0003zY-Np for pce@ietf.org; Mon, 19 Mar 2007 09:16:48 -0400 Received: from mgw1.noc.ntt.com ([210.160.15.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTHjB-0003yf-Ow for pce@ietf.org; Mon, 19 Mar 2007 09:16:48 -0400 Received: from mop2.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id l2JDGSME014420 for ; Mon, 19 Mar 2007 22:16:28 +0900 (JST) Received: from mip2.noc.ntt.com (mvi3.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0JF500628JJFCB@ntt.com> for pce@ietf.org; Mon, 19 Mar 2007 22:16:28 +0900 (JST) Date: Mon, 19 Mar 2007 22:16:28 +0900 From: "Yuichi Ikejiri" Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt To: pce@ietf.org Message-id: <00f601c76a28$cd9998e0$93fa320a@araoa.ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 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: , Errors-To: pce-bounces@lists.ietf.org Hi, >From perspective of service provider, this kind of monitoring or diagnostics tool described in this draft is very useful and indespendable in the network where PCE chain is used (like the network devided into multiple IGP areas and ABRs are working as PCEs) . When a PCC doesn't receive any response from a peer PCE, (meaning that a requested path is not established for a while), an operator would try to check not only the peer PCE, but also the PCE chain to see if the PCE chain is working or appropriate, and who does not response the result or takes very long time to do path calculation. We need to have a mechanism to do such check. The chain itself is different depending on the END-POINTS or other contraints, so that this kind of monitoring should be reqeusted with the PCReq message. And also an operator sometimes wants to check only PCE chain itself without any actual path computation and sometimes wants to check the actual processing time at a PCE in the PCE chain with actual path computation. This is just an example of the situation, coming up in my mind, where SPs may use the tools described in this draft. I believe that the example(use case) I mentioned, is covered in the draft by choosing appropriate objects proposed. #if no, please clarify, authors. So, I think that this kind of monitoring tool is needed. Thanks, Yuichi ----- Original Message ----- From: "JP Vasseur" To: "DOLGANOW Andrew" Cc: Sent: Monday, March 19, 2007 4:57 AM Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > FYI, look at my reply to this email. > > More in line, > > On Mar 18, 2007, at 5:48 PM, DOLGANOW Andrew wrote: > > > Please see below prefixed with [ad] > > > >> -----Original Message----- > >> From: Dimitri.Papadimitriou@alcatel-lucent.be > >> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] > >> Sent: Friday, March 02, 2007 11:50 AM > >> To: JP Vasseur > >> Cc: pce@ietf.org > >> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > >> > >> hi j-p > >> > >> see in-line > >> > >> > >> > >> > >> JP Vasseur > >> 02/03/2007 17:03 > >> > >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > >> cc: pce@ietf.org > >> Subject: Re: [Pce] Re: I-D > >> ACTION:draft-vasseur-pce-monitoring-02.txt > >> > >> > >> Hi Dimitri, > >> > >> On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel-lucent.be > >> wrote: > >> > >>> a simple question > >>> > >>> > >>> the document repeats twice that it critical to monitor the state of > >>> the PC chain (see below) > >>> > >> > >> Yes indeed. > >> > >>> > >>> i try to understand reasoning - can authors clarify ? > >>> > >>> for perf.mon ? is the PCC going to tack perfs of PC servers ? > >>> > >>> for troubleshooting ? but for which trouble ? > >> > >> I think that the motivation is fairly simple here ... You may > >> want to monitor various aspects. > >> For example, you may want to measure the path computation > >> response time. That might be for performance monitoring or > >> troubleshooting because a PCC experience very long response > >> time. The motivation sounds extremely obvious: PCE OAM. As > >> for any other system, the user may want to monitor the > >> performance for network design, troubleshooting, ... > >> > >> [dp] PC response time, but how are you going to ensure that > >> running conditions are identical at time t[n-1], t[n], t[n+1] > >> ? in fact the question is the relevance of repeating a given > >> request when the run conditions can be completely different > >> > > [ad] Dimitri brings a valid point here. This was discussed in San > > Diego, > > proposed to be taken to the list and never really answered. In > > addition > > to the time variable, for performance monitoring to work, we would > > need > > to ensure that no steps are skipped along the process. The best way I > > would say would be to monitor Request/Results from PCC and if required > > issue another PC request (which could collect timestamps along the > > process). > > You miss a point here ... of course, you can monitor the overall > response time > but how do you figure out the time you spent along the PCE chain ? > > > > >>> (this said, i am also > >>> concerned by the fact that if each PCC for each path across > >> a set of > >>> PCEs starts to generate such state monitoring then for sure servers > >>> may experience overload) > >> > >> Ah no ... this is an implementation issue on the PCE if > >> you've such issue. > >> > >> [dp] i disagree, if one builds a PCE to sustain x PC demands > >> per unit of time, but PCE gets now confronted to the fact > >> that a number X of clients, X >> x, are permanently polling > >> the server (remember that the PC server can be memoryless) > >> for monitoring all the previously computed path, the running > >> conditions are completely different, in fact the performance > >> of your system degrades over time (i know a well known > >> operating system that shows the same property ;-( > >> > > > > [ad] Agree with Dimitri. > > Please look at my reply to Dimitri to this point. > > > More so, PCE may be implemented to give > > priority to various messages and limit certain messages (so the > > implementation may not help monitoring here as JP is suggesting) and > > again you could get different results of a monitoring request than > > computational request. > > Again you make some confusion here: we're not trying to build a way to > proritize messages, ... this is already in PCEP. The aim of the this > draft is > to have OAM. > > > > >> => the PCE OAM mechanism implies a completely mode of > >> operation that influence the capacity of the system > >> > >> Furthermore, if you experience an issue, would you prefer to > >> ignore it or to be able to locate it ? > >> > >> [dp] use my local computation capability rely on "external domain" > >> to solve an local problem may be > >> > >>> due to limited visibility ? why is this requiring "state > >> monitoring" ? > >>> > >>> > >>> ---> in brief, i still believe a serious problem statement shall be > >>> brought up before jumping in the specification of objects > >> (the bits of > >>> the wire) > >>> > >>> > >> > >> Hope this clarifies but the motivations are indeed quite > >> straightforward. > >> > >> [dp] unfortunately, i am not convinced about the usefulness > >> of this mechanism and the problem is that if it would > >> harmless then i would not have any issue but it is not > >> > > [ad] agree with Dimitri, all that is looked after by the monitoring > > mechanism can be achieved without that mechanism in place. > > So if you have a PCE chain PCC----PCE1----PCE2-----Dest > How do the determine various perf metric along the chain with the > mechanism > in place ? > > > The mechanism > > may add to the problem by being badly deployed and with many PCCs > > runnning performance monitoring. With scaling and time passing the > > mechanism may degrade PCE. > > This is implementation specific. If you design your system properly, > you won't > have this problem. Back to your previous point you have different > message priority > + other mechanisms to avoid this. > > > We do not want to monitor the monitoring > > mechanism? > > > > Sorry but this makes no sense. We're not monitoring the monitoring > mechanism at all. > > JP. > > >> Thanks. > >> > >> JP. > >> > >>> thanks, > >>> -d. > >>> -- > >>> > >>> "In PCE-based environments, it is critical to monitor the > >> state of the > >>> path computation chain that can be used for performance > >> monitoring > >>> and troubleshooting purposes. This document specifies > >> procedures > >>> and > >>> extensions to the Path Computation Element Protocol (PCEP) > >>> ([I-D.ietf-pce-pcep]) in order to monitor the path computation > >>> chain > >>> and gather various performance metrics. > >>> > >>> As discussed in [RFC4655], a TE LSP may be computed by one PCE > >>> (referred to as single PCE path computation) or several PCEs > >>> (referred to as multiple PCE path computation). In the former > >>> case, > >>> the PCC may be able to use IGP extensions to check the > >> liveness of > >>> the PCE (see [I-D.ietf-pce-disco-proto-ospf] and > >>> [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive > >> messages. > >>> In contrast, when multiple PCEs are involved in the path > >>> computation > >>> chain an example of which is the BRPC procedure defined in > >>> [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the > >>> first > >>> PCE involved in the path computation chain. Thus, it is > >> critical > >>> to > >>> define mechanisms in order to monitor the state of the path > >>> computation chain." > >>> > >>> -- > >>> > >>> > >>> > >>> > >>> > >>> Internet-Drafts@ietf.org > >>> 01/03/2007 21:50 > >>> Please respond to internet-drafts > >>> > >>> To: i-d-announce@ietf.org > >>> cc: > >>> Subject: I-D > >> ACTION:draft-vasseur-pce-monitoring-02.txt > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> > >>> > >>> Title : A set of > >> monitoring > >>> tools for Path Computation Element based Architecture > >>> Author(s) : J. Le Roux, J. Vasseur > >>> Filename : > >>> draft-vasseur-pce-monitoring-02.txt > >>> Pages : 18 > >>> Date : 2007-3-1 > >>> > >>> A Path Computation Element (PCE) based architecture has been > >>> specified for the computation of Traffic Engineering (TE) Label > >>> Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and > >>> Generalized MPLS (GMPLS) networks in the context of single or > >>> multiple domains (where a domain is referred to as a > >> collection of > >>> network elements within a common sphere of address management or > >>> path computational responsibility such as IGP areas and Autonomous > >>> Systems). In PCE-based environments it is thus critical > >> to monitor > >>> the state of the path computation chain that can be used for > >>> performance monitoring and troubleshooting purposes. > >> This document > >>> specifies procedures and extensions to the Path > >> Computation Element > >>> Protocol (PCEP) in order to gather such information. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-vasseur-pce- > >>> monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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. > >>> ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- > >>> monitoring-02.txt > >>> _______________________________________________ > >>> I-D-Announce mailing list > >>> I-D-Announce@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/i-d-announce > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Mar 19 10:53:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJEN-0004gF-WA; Mon, 19 Mar 2007 10:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJEN-0004g0-6Y for pce@ietf.org; Mon, 19 Mar 2007 10:53:03 -0400 Received: from smail2.alcatel.fr ([64.208.49.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJEK-0005U2-7W for pce@ietf.org; Mon, 19 Mar 2007 10:53:03 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id l2JEk55V020045; Mon, 19 Mar 2007 15:52:31 +0100 In-Reply-To: <00f601c76a28$cd9998e0$93fa320a@araoa.ntt.com> To: "Yuichi Ikejiri" Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Mon, 19 Mar 2007 15:43:46 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 03/19/2007 15:52:31, Serialize complete at 03/19/2007 15:52:31 Content-Type: text/plain; charset="US-ASCII" X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.2 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e 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: , Errors-To: pce-bounces@lists.ietf.org hello just a question to see whether i understand the point - if the PCC doesn't receive an answer from the PCE after initiating a request how does the PCC knows there is a chain of PCE behind the PCE towards which the request has been initiated - in brief what is the purpose of having a monitoring when the PCE is an on-path techno now, assume that the PCC received an answer from the PCE is there a need keep track of PCE chain liveness ? i have also trouble to understanding the following: "When a PCC doesn't receive any response from a peer PCE, (meaning that a requested path is not established for a while)" PCE do not establish "path" they compute paths thanks, -d. "Yuichi Ikejiri" 19/03/2007 14:16 To: pce@ietf.org cc: Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt Hi, >From perspective of service provider, this kind of monitoring or diagnostics tool described in this draft is very useful and indespendable in the network where PCE chain is used (like the network devided into multiple IGP areas and ABRs are working as PCEs) . When a PCC doesn't receive any response from a peer PCE, (meaning that a requested path is not established for a while), an operator would try to check not only the peer PCE, but also the PCE chain to see if the PCE chain is working or appropriate, and who does not response the result or takes very long time to do path calculation. We need to have a mechanism to do such check. The chain itself is different depending on the END-POINTS or other contraints, so that this kind of monitoring should be reqeusted with the PCReq message. And also an operator sometimes wants to check only PCE chain itself without any actual path computation and sometimes wants to check the actual processing time at a PCE in the PCE chain with actual path computation. This is just an example of the situation, coming up in my mind, where SPs may use the tools described in this draft. I believe that the example(use case) I mentioned, is covered in the draft by choosing appropriate objects proposed. #if no, please clarify, authors. So, I think that this kind of monitoring tool is needed. Thanks, Yuichi ----- Original Message ----- From: "JP Vasseur" To: "DOLGANOW Andrew" Cc: Sent: Monday, March 19, 2007 4:57 AM Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > FYI, look at my reply to this email. > > More in line, > > On Mar 18, 2007, at 5:48 PM, DOLGANOW Andrew wrote: > > > Please see below prefixed with [ad] > > > >> -----Original Message----- > >> From: Dimitri.Papadimitriou@alcatel-lucent.be > >> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] > >> Sent: Friday, March 02, 2007 11:50 AM > >> To: JP Vasseur > >> Cc: pce@ietf.org > >> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > >> > >> hi j-p > >> > >> see in-line > >> > >> > >> > >> > >> JP Vasseur > >> 02/03/2007 17:03 > >> > >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > >> cc: pce@ietf.org > >> Subject: Re: [Pce] Re: I-D > >> ACTION:draft-vasseur-pce-monitoring-02.txt > >> > >> > >> Hi Dimitri, > >> > >> On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel-lucent.be > >> wrote: > >> > >>> a simple question > >>> > >>> > >>> the document repeats twice that it critical to monitor the state of > >>> the PC chain (see below) > >>> > >> > >> Yes indeed. > >> > >>> > >>> i try to understand reasoning - can authors clarify ? > >>> > >>> for perf.mon ? is the PCC going to tack perfs of PC servers ? > >>> > >>> for troubleshooting ? but for which trouble ? > >> > >> I think that the motivation is fairly simple here ... You may > >> want to monitor various aspects. > >> For example, you may want to measure the path computation > >> response time. That might be for performance monitoring or > >> troubleshooting because a PCC experience very long response > >> time. The motivation sounds extremely obvious: PCE OAM. As > >> for any other system, the user may want to monitor the > >> performance for network design, troubleshooting, ... > >> > >> [dp] PC response time, but how are you going to ensure that > >> running conditions are identical at time t[n-1], t[n], t[n+1] > >> ? in fact the question is the relevance of repeating a given > >> request when the run conditions can be completely different > >> > > [ad] Dimitri brings a valid point here. This was discussed in San > > Diego, > > proposed to be taken to the list and never really answered. In > > addition > > to the time variable, for performance monitoring to work, we would > > need > > to ensure that no steps are skipped along the process. The best way I > > would say would be to monitor Request/Results from PCC and if required > > issue another PC request (which could collect timestamps along the > > process). > > You miss a point here ... of course, you can monitor the overall > response time > but how do you figure out the time you spent along the PCE chain ? > > > > >>> (this said, i am also > >>> concerned by the fact that if each PCC for each path across > >> a set of > >>> PCEs starts to generate such state monitoring then for sure servers > >>> may experience overload) > >> > >> Ah no ... this is an implementation issue on the PCE if > >> you've such issue. > >> > >> [dp] i disagree, if one builds a PCE to sustain x PC demands > >> per unit of time, but PCE gets now confronted to the fact > >> that a number X of clients, X >> x, are permanently polling > >> the server (remember that the PC server can be memoryless) > >> for monitoring all the previously computed path, the running > >> conditions are completely different, in fact the performance > >> of your system degrades over time (i know a well known > >> operating system that shows the same property ;-( > >> > > > > [ad] Agree with Dimitri. > > Please look at my reply to Dimitri to this point. > > > More so, PCE may be implemented to give > > priority to various messages and limit certain messages (so the > > implementation may not help monitoring here as JP is suggesting) and > > again you could get different results of a monitoring request than > > computational request. > > Again you make some confusion here: we're not trying to build a way to > proritize messages, ... this is already in PCEP. The aim of the this > draft is > to have OAM. > > > > >> => the PCE OAM mechanism implies a completely mode of > >> operation that influence the capacity of the system > >> > >> Furthermore, if you experience an issue, would you prefer to > >> ignore it or to be able to locate it ? > >> > >> [dp] use my local computation capability rely on "external domain" > >> to solve an local problem may be > >> > >>> due to limited visibility ? why is this requiring "state > >> monitoring" ? > >>> > >>> > >>> ---> in brief, i still believe a serious problem statement shall be > >>> brought up before jumping in the specification of objects > >> (the bits of > >>> the wire) > >>> > >>> > >> > >> Hope this clarifies but the motivations are indeed quite > >> straightforward. > >> > >> [dp] unfortunately, i am not convinced about the usefulness > >> of this mechanism and the problem is that if it would > >> harmless then i would not have any issue but it is not > >> > > [ad] agree with Dimitri, all that is looked after by the monitoring > > mechanism can be achieved without that mechanism in place. > > So if you have a PCE chain PCC----PCE1----PCE2-----Dest > How do the determine various perf metric along the chain with the > mechanism > in place ? > > > The mechanism > > may add to the problem by being badly deployed and with many PCCs > > runnning performance monitoring. With scaling and time passing the > > mechanism may degrade PCE. > > This is implementation specific. If you design your system properly, > you won't > have this problem. Back to your previous point you have different > message priority > + other mechanisms to avoid this. > > > We do not want to monitor the monitoring > > mechanism? > > > > Sorry but this makes no sense. We're not monitoring the monitoring > mechanism at all. > > JP. > > >> Thanks. > >> > >> JP. > >> > >>> thanks, > >>> -d. > >>> -- > >>> > >>> "In PCE-based environments, it is critical to monitor the > >> state of the > >>> path computation chain that can be used for performance > >> monitoring > >>> and troubleshooting purposes. This document specifies > >> procedures > >>> and > >>> extensions to the Path Computation Element Protocol (PCEP) > >>> ([I-D.ietf-pce-pcep]) in order to monitor the path computation > >>> chain > >>> and gather various performance metrics. > >>> > >>> As discussed in [RFC4655], a TE LSP may be computed by one PCE > >>> (referred to as single PCE path computation) or several PCEs > >>> (referred to as multiple PCE path computation). In the former > >>> case, > >>> the PCC may be able to use IGP extensions to check the > >> liveness of > >>> the PCE (see [I-D.ietf-pce-disco-proto-ospf] and > >>> [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive > >> messages. > >>> In contrast, when multiple PCEs are involved in the path > >>> computation > >>> chain an example of which is the BRPC procedure defined in > >>> [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the > >>> first > >>> PCE involved in the path computation chain. Thus, it is > >> critical > >>> to > >>> define mechanisms in order to monitor the state of the path > >>> computation chain." > >>> > >>> -- > >>> > >>> > >>> > >>> > >>> > >>> Internet-Drafts@ietf.org > >>> 01/03/2007 21:50 > >>> Please respond to internet-drafts > >>> > >>> To: i-d-announce@ietf.org > >>> cc: > >>> Subject: I-D > >> ACTION:draft-vasseur-pce-monitoring-02.txt > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> > >>> > >>> Title : A set of > >> monitoring > >>> tools for Path Computation Element based Architecture > >>> Author(s) : J. Le Roux, J. Vasseur > >>> Filename : > >>> draft-vasseur-pce-monitoring-02.txt > >>> Pages : 18 > >>> Date : 2007-3-1 > >>> > >>> A Path Computation Element (PCE) based architecture has been > >>> specified for the computation of Traffic Engineering (TE) Label > >>> Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and > >>> Generalized MPLS (GMPLS) networks in the context of single or > >>> multiple domains (where a domain is referred to as a > >> collection of > >>> network elements within a common sphere of address management or > >>> path computational responsibility such as IGP areas and Autonomous > >>> Systems). In PCE-based environments it is thus critical > >> to monitor > >>> the state of the path computation chain that can be used for > >>> performance monitoring and troubleshooting purposes. > >> This document > >>> specifies procedures and extensions to the Path > >> Computation Element > >>> Protocol (PCEP) in order to gather such information. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-vasseur-pce- > >>> monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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. > >>> ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- > >>> monitoring-02.txt > >>> _______________________________________________ > >>> I-D-Announce mailing list > >>> I-D-Announce@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/i-d-announce > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 _______________________________________________ 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 Mar 19 11:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKCF-0005pA-Bq; Mon, 19 Mar 2007 11:54:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKCD-0005p5-PN for pce@ietf.org; Mon, 19 Mar 2007 11:54:53 -0400 Received: from mgw2.noc.ntt.com ([210.160.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTKCA-0007KD-Lt for pce@ietf.org; Mon, 19 Mar 2007 11:54:53 -0400 Received: from mop3.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id l2JFsbFY008907; Tue, 20 Mar 2007 00:54:38 +0900 (JST) Received: from mip1.noc.ntt.com (mvi3.noc.ntt.com) by mop3.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0JF5005PJQV15N@ntt.com>; Tue, 20 Mar 2007 00:54:37 +0900 (JST) Date: Tue, 20 Mar 2007 00:54:37 +0900 From: "Yuichi Ikejiri" Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt To: Dimitri.Papadimitriou@alcatel-lucent.be Message-id: <002301c76a3e$e59089c0$93fa320a@araoa.ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 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: , Errors-To: pce-bounces@lists.ietf.org Hello, ----- Original Message ----- From: To: "Yuichi Ikejiri" Cc: Sent: Monday, March 19, 2007 11:43 PM Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > hello > > just a question to see whether i understand the point - > > if the PCC doesn't receive an answer from the PCE after > initiating a request how does the PCC knows there is a > chain of PCE behind the PCE towards which the request > has been initiated - in brief what is the purpose of > having a monitoring when the PCE is an on-path techno > > now, assume that the PCC received an answer from the > PCE is there a need keep track of PCE chain liveness ? It depends on the situation, but I think not keep track of the chain so often in the example I described. Just several times to see what is happening in the current chain with the specific path requests. But maybe there is also a case where longer monitoring is needed in periodic manner. Again it depends on the situation where the tool is used, I think. > i have also trouble to understanding the following: > > "When a PCC doesn't receive any response from a peer PCE, (meaning that > a requested path is not established for a while)" > > PCE do not establish "path" they compute paths I know that. I am sorry for the confusion. I just described what an operator actually knows as a result of that the PCC does not receive any path calculation result from the PCE in the actual network operation. But it was not good example, so just ignore the text enclosed in the parenthesis. Thanks, Yuichi > > thanks, > -d. > > > > > "Yuichi Ikejiri" > 19/03/2007 14:16 > > To: pce@ietf.org > cc: > Subject: Re: [Pce] Re: I-D > ACTION:draft-vasseur-pce-monitoring-02.txt > > > Hi, > > >From perspective of service provider, this kind of monitoring or > diagnostics > tool described in this draft is very useful and indespendable in the > network > where PCE chain is used (like the network devided into multiple IGP areas > and ABRs are working as PCEs) . > > When a PCC doesn't receive any response from a peer PCE, (meaning that > a requested path is not established for a while), an operator would try to > check > not only the peer PCE, but also the PCE chain to see if the PCE chain is > working or appropriate, and who does not response the result or takes > very long time to do path calculation. We need to have a mechanism to do > such check. > > The chain itself is different depending on the END-POINTS or other > contraints, > so that this kind of monitoring should be reqeusted with the PCReq > message. > And > also an operator sometimes wants to check only PCE chain itself without > any > actual path > computation and sometimes wants to check the actual processing time at a > PCE > in the PCE chain with actual path computation. > > This is just an example of the situation, coming up in my mind, where SPs > may use > the tools described in this draft. I believe that the example(use case) I > mentioned, > is covered in the draft by choosing appropriate objects proposed. > #if no, please clarify, authors. > > So, I think that this kind of monitoring tool is needed. > > Thanks, > Yuichi > > ----- Original Message ----- > From: "JP Vasseur" > To: "DOLGANOW Andrew" > Cc: > Sent: Monday, March 19, 2007 4:57 AM > Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > > > > FYI, look at my reply to this email. > > > > More in line, > > > > On Mar 18, 2007, at 5:48 PM, DOLGANOW Andrew wrote: > > > > > Please see below prefixed with [ad] > > > > > >> -----Original Message----- > > >> From: Dimitri.Papadimitriou@alcatel-lucent.be > > >> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] > > >> Sent: Friday, March 02, 2007 11:50 AM > > >> To: JP Vasseur > > >> Cc: pce@ietf.org > > >> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > > >> > > >> hi j-p > > >> > > >> see in-line > > >> > > >> > > >> > > >> > > >> JP Vasseur > > >> 02/03/2007 17:03 > > >> > > >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > >> cc: pce@ietf.org > > >> Subject: Re: [Pce] Re: I-D > > >> ACTION:draft-vasseur-pce-monitoring-02.txt > > >> > > >> > > >> Hi Dimitri, > > >> > > >> On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel-lucent.be > > >> wrote: > > >> > > >>> a simple question > > >>> > > >>> > > >>> the document repeats twice that it critical to monitor the state of > > >>> the PC chain (see below) > > >>> > > >> > > >> Yes indeed. > > >> > > >>> > > >>> i try to understand reasoning - can authors clarify ? > > >>> > > >>> for perf.mon ? is the PCC going to tack perfs of PC servers ? > > >>> > > >>> for troubleshooting ? but for which trouble ? > > >> > > >> I think that the motivation is fairly simple here ... You may > > >> want to monitor various aspects. > > >> For example, you may want to measure the path computation > > >> response time. That might be for performance monitoring or > > >> troubleshooting because a PCC experience very long response > > >> time. The motivation sounds extremely obvious: PCE OAM. As > > >> for any other system, the user may want to monitor the > > >> performance for network design, troubleshooting, ... > > >> > > >> [dp] PC response time, but how are you going to ensure that > > >> running conditions are identical at time t[n-1], t[n], t[n+1] > > >> ? in fact the question is the relevance of repeating a given > > >> request when the run conditions can be completely different > > >> > > > [ad] Dimitri brings a valid point here. This was discussed in San > > > Diego, > > > proposed to be taken to the list and never really answered. In > > > addition > > > to the time variable, for performance monitoring to work, we would > > > need > > > to ensure that no steps are skipped along the process. The best way I > > > would say would be to monitor Request/Results from PCC and if required > > > issue another PC request (which could collect timestamps along the > > > process). > > > > You miss a point here ... of course, you can monitor the overall > > response time > > but how do you figure out the time you spent along the PCE chain ? > > > > > > > >>> (this said, i am also > > >>> concerned by the fact that if each PCC for each path across > > >> a set of > > >>> PCEs starts to generate such state monitoring then for sure servers > > >>> may experience overload) > > >> > > >> Ah no ... this is an implementation issue on the PCE if > > >> you've such issue. > > >> > > >> [dp] i disagree, if one builds a PCE to sustain x PC demands > > >> per unit of time, but PCE gets now confronted to the fact > > >> that a number X of clients, X >> x, are permanently polling > > >> the server (remember that the PC server can be memoryless) > > >> for monitoring all the previously computed path, the running > > >> conditions are completely different, in fact the performance > > >> of your system degrades over time (i know a well known > > >> operating system that shows the same property ;-( > > >> > > > > > > [ad] Agree with Dimitri. > > > > Please look at my reply to Dimitri to this point. > > > > > More so, PCE may be implemented to give > > > priority to various messages and limit certain messages (so the > > > implementation may not help monitoring here as JP is suggesting) and > > > again you could get different results of a monitoring request than > > > computational request. > > > > Again you make some confusion here: we're not trying to build a way to > > proritize messages, ... this is already in PCEP. The aim of the this > > draft is > > to have OAM. > > > > > > > >> => the PCE OAM mechanism implies a completely mode of > > >> operation that influence the capacity of the system > > >> > > >> Furthermore, if you experience an issue, would you prefer to > > >> ignore it or to be able to locate it ? > > >> > > >> [dp] use my local computation capability rely on "external domain" > > >> to solve an local problem may be > > >> > > >>> due to limited visibility ? why is this requiring "state > > >> monitoring" ? > > >>> > > >>> > > >>> ---> in brief, i still believe a serious problem statement shall be > > >>> brought up before jumping in the specification of objects > > >> (the bits of > > >>> the wire) > > >>> > > >>> > > >> > > >> Hope this clarifies but the motivations are indeed quite > > >> straightforward. > > >> > > >> [dp] unfortunately, i am not convinced about the usefulness > > >> of this mechanism and the problem is that if it would > > >> harmless then i would not have any issue but it is not > > >> > > > [ad] agree with Dimitri, all that is looked after by the monitoring > > > mechanism can be achieved without that mechanism in place. > > > > So if you have a PCE chain PCC----PCE1----PCE2-----Dest > > How do the determine various perf metric along the chain with the > > mechanism > > in place ? > > > > > The mechanism > > > may add to the problem by being badly deployed and with many PCCs > > > runnning performance monitoring. With scaling and time passing the > > > mechanism may degrade PCE. > > > > This is implementation specific. If you design your system properly, > > you won't > > have this problem. Back to your previous point you have different > > message priority > > + other mechanisms to avoid this. > > > > > We do not want to monitor the monitoring > > > mechanism? > > > > > > > Sorry but this makes no sense. We're not monitoring the monitoring > > mechanism at all. > > > > JP. > > > > >> Thanks. > > >> > > >> JP. > > >> > > >>> thanks, > > >>> -d. > > >>> -- > > >>> > > >>> "In PCE-based environments, it is critical to monitor the > > >> state of the > > >>> path computation chain that can be used for performance > > >> monitoring > > >>> and troubleshooting purposes. This document specifies > > >> procedures > > >>> and > > >>> extensions to the Path Computation Element Protocol (PCEP) > > >>> ([I-D.ietf-pce-pcep]) in order to monitor the path computation > > >>> chain > > >>> and gather various performance metrics. > > >>> > > >>> As discussed in [RFC4655], a TE LSP may be computed by one PCE > > >>> (referred to as single PCE path computation) or several PCEs > > >>> (referred to as multiple PCE path computation). In the former > > >>> case, > > >>> the PCC may be able to use IGP extensions to check the > > >> liveness of > > >>> the PCE (see [I-D.ietf-pce-disco-proto-ospf] and > > >>> [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive > > >> messages. > > >>> In contrast, when multiple PCEs are involved in the path > > >>> computation > > >>> chain an example of which is the BRPC procedure defined in > > >>> [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the > > >>> first > > >>> PCE involved in the path computation chain. Thus, it is > > >> critical > > >>> to > > >>> define mechanisms in order to monitor the state of the path > > >>> computation chain." > > >>> > > >>> -- > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Internet-Drafts@ietf.org > > >>> 01/03/2007 21:50 > > >>> Please respond to internet-drafts > > >>> > > >>> To: i-d-announce@ietf.org > > >>> cc: > > >>> Subject: I-D > > >> ACTION:draft-vasseur-pce-monitoring-02.txt > > >>> > > >>> > > >>> A New Internet-Draft is available from the on-line Internet-Drafts > > >>> directories. > > >>> > > >>> > > >>> Title : A set of > > >> monitoring > > >>> tools for Path Computation Element based Architecture > > >>> Author(s) : J. Le Roux, J. Vasseur > > >>> Filename : > > >>> draft-vasseur-pce-monitoring-02.txt > > >>> Pages : 18 > > >>> Date : 2007-3-1 > > >>> > > >>> A Path Computation Element (PCE) based architecture has been > > >>> specified for the computation of Traffic Engineering (TE) Label > > >>> Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and > > >>> Generalized MPLS (GMPLS) networks in the context of single or > > >>> multiple domains (where a domain is referred to as a > > >> collection of > > >>> network elements within a common sphere of address management or > > >>> path computational responsibility such as IGP areas and Autonomous > > >>> Systems). In PCE-based environments it is thus critical > > >> to monitor > > >>> the state of the path computation chain that can be used for > > >>> performance monitoring and troubleshooting purposes. > > >> This document > > >>> specifies procedures and extensions to the Path > > >> Computation Element > > >>> Protocol (PCEP) in order to gather such information. > > >>> > > >>> A URL for this Internet-Draft is: > > >>> http://www.ietf.org/internet-drafts/draft-vasseur-pce- > > >>> monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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. > > >>> ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- > > >>> monitoring-02.txt > > >>> _______________________________________________ > > >>> I-D-Announce mailing list > > >>> I-D-Announce@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/i-d-announce > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> 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 > > > _______________________________________________ > 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 Mar 20 01:34:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWyZ-0001Sm-AG; Tue, 20 Mar 2007 01:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWyY-0001P1-85 for pce@ietf.org; Tue, 20 Mar 2007 01:33:38 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTWyV-0001wW-92 for pce@ietf.org; Tue, 20 Mar 2007 01:33:38 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 06:33:33 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2K5XWjZ015518; Tue, 20 Mar 2007 06:33:32 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2K5XOlb015335; Tue, 20 Mar 2007 05:33:32 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 06:33:25 +0100 Received: from [10.0.0.86] ([10.21.80.51]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 06:33:22 +0100 In-Reply-To: <00f601c76a28$cd9998e0$93fa320a@araoa.ntt.com> References: <00f601c76a28$cd9998e0$93fa320a@araoa.ntt.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3CE097B4-9C66-453F-A916-1F766389BD2B@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt Date: Tue, 20 Mar 2007 06:17:19 +0100 To: Yuichi Ikejiri X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Mar 2007 05:33:23.0098 (UTC) FILETIME=[46AF07A0:01C76AB1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14662; t=1174368812; x=1175232812; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Re=3A=20I-D=20ACTION=3Adraft-vasseur-pce-moni toring-02.txt |Sender:=20; bh=tIulNymcdi3KbDY1SJw0Ka8Wumbwhl1d6vPVKat8G1Y=; b=pY+Gr5/Ib9zuk/e9Wh4J1kVlE+dTW0IQ2md99VgFXqaozlZdczWAmSTO0PJlIiXZGu2OOKby XYxccnOK+qmnCym0aoBFr0i1sksbF4wrqbxm88j9UfLfHabsrHkK3p8D; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 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: , Errors-To: pce-bounces@lists.ietf.org Hi Yuichi, Thanks for the useful feed-back. See in line. On Mar 19, 2007, at 2:16 PM, Yuichi Ikejiri wrote: > Hi, > >> From perspective of service provider, this kind of monitoring or >> diagnostics > tool described in this draft is very useful and indespendable in > the network > where PCE chain is used (like the network devided into multiple IGP > areas > and ABRs are working as PCEs) . > > When a PCC doesn't receive any response from a peer PCE, From pce-bounces@lists.ietf.org Tue Mar 20 01:34:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWyZ-0001Sm-AG; Tue, 20 Mar 2007 01:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWyY-0001P1-85 for pce@ietf.org; Tue, 20 Mar 2007 01:33:38 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTWyV-0001wW-92 for pce@ietf.org; Tue, 20 Mar 2007 01:33:38 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 06:33:33 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2K5XWjZ015518; Tue, 20 Mar 2007 06:33:32 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2K5XOlb015335; Tue, 20 Mar 2007 05:33:32 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 06:33:25 +0100 Received: from [10.0.0.86] ([10.21.80.51]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 06:33:22 +0100 In-Reply-To: <00f601c76a28$cd9998e0$93fa320a@araoa.ntt.com> References: <00f601c76a28$cd9998e0$93fa320a@araoa.ntt.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3CE097B4-9C66-453F-A916-1F766389BD2B@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt Date: Tue, 20 Mar 2007 06:17:19 +0100 To: Yuichi Ikejiri X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Mar 2007 05:33:23.0098 (UTC) FILETIME=[46AF07A0:01C76AB1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14662; t=1174368812; x=1175232812; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Re=3A=20I-D=20ACTION=3Adraft-vasseur-pce-moni toring-02.txt |Sender:=20; bh=tIulNymcdi3KbDY1SJw0Ka8Wumbwhl1d6vPVKat8G1Y=; b=pY+Gr5/Ib9zuk/e9Wh4J1kVlE+dTW0IQ2md99VgFXqaozlZdczWAmSTO0PJlIiXZGu2OOKby XYxccnOK+qmnCym0aoBFr0i1sksbF4wrqbxm88j9UfLfHabsrHkK3p8D; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 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: , Errors-To: pce-bounces@lists.ietf.org Hi Yuichi, Thanks for the useful feed-back. See in line. On Mar 19, 2007, at 2:16 PM, Yuichi Ikejiri wrote: > Hi, > >> From perspective of service provider, this kind of monitoring or >> diagnostics > tool described in this draft is very useful and indespendable in > the network > where PCE chain is used (like the network devided into multiple IGP > areas > and ABRs are working as PCEs) . > > When a PCC doesn't receive any response from a peer PCE, (meaning that > a requested path is not established for a while), an operator would > try to > check > not only the peer PCE, but also the PCE chain to see if the PCE > chain is > working or appropriate, and who does not response the result or takes > very long time to do path calculation. We need to have a mechanism > to do > such check. > That is indeed for the one main features of this document. > The chain itself is different depending on the END-POINTS or other > contraints, > so that this kind of monitoring should be reqeusted with the PCReq > message. > And > also an operator sometimes wants to check only PCE chain itself > without any > actual path > computation and sometimes wants to check the actual processing time > at a PCE > in the PCE chain with actual path computation. Indeed: this is why we introduced the ability to check the PCE chain in the context of a specific path computation or to retrieve various metrics related to set of path computations performed over a period of time (specific/general). > > This is just an example of the situation, coming up in my mind, > where SPs > may use > the tools described in this draft. I believe that the example(use > case) I > mentioned, > is covered in the draft by choosing appropriate objects proposed. > #if no, please clarify, authors. This is exactly what we propose. > > So, I think that this kind of monitoring tool is needed. > Thanks. JP. > Thanks, > Yuichi > > ----- Original Message ----- > From: "JP Vasseur" > To: "DOLGANOW Andrew" > Cc: > Sent: Monday, March 19, 2007 4:57 AM > Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > > >> FYI, look at my reply to this email. >> >> More in line, >> >> On Mar 18, 2007, at 5:48 PM, DOLGANOW Andrew wrote: >> >>> Please see below prefixed with [ad] >>> >>>> -----Original Message----- >>>> From: Dimitri.Papadimitriou@alcatel-lucent.be >>>> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] >>>> Sent: Friday, March 02, 2007 11:50 AM >>>> To: JP Vasseur >>>> Cc: pce@ietf.org >>>> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce- >>>> monitoring-02.txt >>>> >>>> hi j-p >>>> >>>> see in-line >>>> >>>> >>>> >>>> >>>> JP Vasseur >>>> 02/03/2007 17:03 >>>> >>>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>>> cc: pce@ietf.org >>>> Subject: Re: [Pce] Re: I-D >>>> ACTION:draft-vasseur-pce-monitoring-02.txt >>>> >>>> >>>> Hi Dimitri, >>>> >>>> On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel- >>>> lucent.be >>>> wrote: >>>> >>>>> a simple question >>>>> >>>>> >>>>> the document repeats twice that it critical to monitor the >>>>> state of >>>>> the PC chain (see below) >>>>> >>>> >>>> Yes indeed. >>>> >>>>> >>>>> i try to understand reasoning - can authors clarify ? >>>>> >>>>> for perf.mon ? is the PCC going to tack perfs of PC servers ? >>>>> >>>>> for troubleshooting ? but for which trouble ? >>>> >>>> I think that the motivation is fairly simple here ... You may >>>> want to monitor various aspects. >>>> For example, you may want to measure the path computation >>>> response time. That might be for performance monitoring or >>>> troubleshooting because a PCC experience very long response >>>> time. The motivation sounds extremely obvious: PCE OAM. As >>>> for any other system, the user may want to monitor the >>>> performance for network design, troubleshooting, ... >>>> >>>> [dp] PC response time, but how are you going to ensure that >>>> running conditions are identical at time t[n-1], t[n], t[n+1] >>>> ? in fact the question is the relevance of repeating a given >>>> request when the run conditions can be completely different >>>> >>> [ad] Dimitri brings a valid point here. This was discussed in San >>> Diego, >>> proposed to be taken to the list and never really answered. In >>> addition >>> to the time variable, for performance monitoring to work, we would >>> need >>> to ensure that no steps are skipped along the process. The b(meaning that > a requested path is not established for a while), an operator would > try to > check > not only the peer PCE, but also the PCE chain to see if the PCE > chain is > working or appropriate, and who does not response the result or takes > very long time to do path calculation. We need to have a mechanism > to do > such check. > That is indeed for the one main features of this document. > The chain itself is different depending on the END-POINTS or other > contraints, > so that this kind of monitoring should be reqeusted with the PCReq > message. > And > also an operator sometimes wants to check only PCE chain itself > without any > actual path > computation and sometimes wants to check the actual processing time > at a PCE > in the PCE chain with actual path computation. Indeed: this is why we introduced the ability to check the PCE chain in the context of a specific path computation or to retrieve various metrics related to set of path computations performed over a period of time (specific/general). > > This is just an example of the situation, coming up in my mind, > where SPs > may use > the tools described in this draft. I believe that the example(use > case) I > mentioned, > is covered in the draft by choosing appropriate objects proposed. > #if no, please clarify, authors. This is exactly what we propose. > > So, I think that this kind of monitoring tool is needed. > Thanks. JP. > Thanks, > Yuichi > > ----- Original Message ----- > From: "JP Vasseur" > To: "DOLGANOW Andrew" > Cc: > Sent: Monday, March 19, 2007 4:57 AM > Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > > >> FYI, look at my reply to this email. >> >> More in line, >> >> On Mar 18, 2007, at 5:48 PM, DOLGANOW Andrew wrote: >> >>> Please see below prefixed with [ad] >>> >>>> -----Original Message----- >>>> From: Dimitri.Papadimitriou@alcatel-lucent.be >>>> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] >>>> Sent: Friday, March 02, 2007 11:50 AM >>>> To: JP Vasseur >>>> Cc: pce@ietf.org >>>> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce- >>>> monitoring-02.txt >>>> >>>> hi j-p >>>> >>>> see in-line >>>> >>>> >>>> >>>> >>>> JP Vasseur >>>> 02/03/2007 17:03 >>>> >>>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>>> cc: pce@ietf.org >>>> Subject: Re: [Pce] Re: I-D >>>> ACTION:draft-vasseur-pce-monitoring-02.txt >>>> >>>> >>>> Hi Dimitri, >>>> >>>> On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel- >>>> lucent.be >>>> wrote: >>>> >>>>> a simple question >>>>> >>>>> >>>>> the document repeats twice that it critical to monitor the >>>>> state of >>>>> the PC chain (see below) >>>>> >>>> >>>> Yes indeed. >>>> >>>>> >>>>> i try to understand reasoning - can authors clarify ? >>>>> >>>>> for perf.mon ? is the PCC going to tack perfs of PC servers ? >>>>> >>>>> for troubleshooting ? but for which trouble ? >>>> >>>> I think that the motivation is fairly simple here ... You may >>>> want to monitor various aspects. >>>> For example, you may want to measure the path computation >>>> response time. That might be for performance monitoring or >>>> troubleshooting because a PCC experience very long response >>>> time. The motivation sounds extremely obvious: PCE OAM. As >>>> for any other system, the user may want to monitor the >>>> performance for network design, troubleshooting, ... >>>> >>>> [dp] PC response time, but how are you going to ensure that >>>> running conditions are identical at time t[n-1], t[n], t[n+1] >>>> ? in fact the question is the relevance of repeating a given >>>> request when the run conditions can be completely different >>>> >>> [ad] Dimitri brings a valid point here. This was discussed in San >>> Diego, >>> proposed to be taken to the list and never really answered. In >>> addition >>> to the time variable, for performance monitoring to work, we would >>> need >>> to ensure that no steps are skipped along the process. The best >>> way I >>> would say would be to monitor Request/Results from PCC and if >>> required >>> issue another PC request (which could collect timestamps along the >>> process). >> >> You miss a point here ... of course, you can monitor the overall >> response time >> but how do you figure out the time you spent along the PCE chain ? >> >>> >>>>> (this said, i am also >>>>> concerned by the fact that if each PCC for each path across >>>> a set of >>>>> PCEs starts to generate such state monitoring then for sure >>>>> servers >>>>> may experience overload) >>>> >>>> Ah no ... this is an implementation issue on the PCE if >>>> you've such issue. >>>> >>>> [dp] i disagree, if one builds a PCE to sustain x PC demands >>>> per unit of time, but PCE gets now confronted to the fact >>>> that a number X of clients, X >> x, are permanently polling >>>> the server (remember that the PC server can be memoryless) >>>> for monitoring all the previously computed path, the running >>>> conditions are completely different, in fact the performance >>>> of your system degrades over time (i know a well known >>>> operating system that shows the same property ;-( >>>> >>> >>> [ad] Agree with Dimitri. >> >> Please look at my reply to Dimitri to this point. >> >>> More so, PCE may be implemented to give >>> priority to various messages and limit certain messages (so the >>> implementation may not help monitoring here as JP is suggesting) and >>> again you could get different results of a monitoring request than >>> computational request. >> >> Again you make some confusion here: we're not trying to build a >> way to >> proritize messages, ... this is already in PCEP. The aim of the this >> draft is >> to have OAM. >> >>> >>>> => the PCE OAM mechanism implies a completely mode of >>>> operation that influence the capacity of the system >>>> >>>> Furthermore, if you experience an issue, would you prefer to >>>> ignore it or to be able to locate it ? >>>> >>>> [dp] use my local computation capability rely on "external domain" >>>> to solve an local problem may be >>>> >>>>> due to limited visibility ? why is this requiring "state >>>> monitoring" ? >>>>> >>>>> >>>>> ---> in brief, i still believe a serious problem statement >>>>> shall be >>>>> brought up before jumping in the specification of objects >>>> (the bits of >>>>> the wire) >>>>> >>>>> >>>> >>>> Hope this clarifies but the motivations are indeed quite >>>> straightforward. >>>> >>>> [dp] unfortunately, i am not convinced about the usefulness >>>> of this mechanism and the problem is that if it would >>>> harmless then i would not have any issue but it is not >>>> >>> [ad] agree with Dimitri, all that is looked after by the monitoring >>> mechanism can be achieved without that mechanism in place. >> >> So if you have a PCE chain PCC----PCE1----PCE2-----Dest >> How do the determine various perf metric along the chain with the >> mechanism >> in place ? >> >>> The mechanism >>> may add to the problem by being badly deployed and with many PCCs >>> runnning performance monitoring. With scaling and time passing the >>> mechanism may degrade PCE. >> >> This is implementation specific. If you design your system properly, >> you won't >> have this problem. Back to your previous point you have different >> message priority >> + other mechanisms to avoid this. >> >>> We do not want to monitor the monitoring >>> mechanism? >>> >> >> Sorry but this makes no sense. We're not monitoring the monitoring >> mechanism at all. >> >> JP. >> >>>> Thanks. >>>> >>>> JP. >>>> >>>>> thanks, >>>>> -d. >>>>> -- >>>>> >>>>> "In PCE-based environments, it is critical to monitor the >>>> state of the >>>>> path computation chain that can be used for performance >>>> monitoring >>>>> and troubleshooting purposes. This document specifies >>>> procedures >>>>> and >>>>> extensions to the Path Computation Element Protocol (PCEP) >>>>> ([I-D.ietf-pce-pcep]) in order to monitor the path computation >>>>> chain >>>>> and gather various performance metrics. >>>>> >>>>> As discussed in [RFC4655]est >>> way I >>> would say would be to monitor Request/Results from PCC and if >>> required >>> issue another PC request (which could collect timestamps along the >>> process). >> >> You miss a point here ... of course, you can monitor the overall >> response time >> but how do you figure out the time you spent along the PCE chain ? >> >>> >>>>> (this said, i am also >>>>> concerned by the fact that if each PCC for each path across >>>> a set of >>>>> PCEs starts to generate such state monitoring then for sure >>>>> servers >>>>> may experience overload) >>>> >>>> Ah no ... this is an implementation issue on the PCE if >>>> you've such issue. >>>> >>>> [dp] i disagree, if one builds a PCE to sustain x PC demands >>>> per unit of time, but PCE gets now confronted to the fact >>>> that a number X of clients, X >> x, are permanently polling >>>> the server (remember that the PC server can be memoryless) >>>> for monitoring all the previously computed path, the running >>>> conditions are completely different, in fact the performance >>>> of your system degrades over time (i know a well known >>>> operating system that shows the same property ;-( >>>> >>> >>> [ad] Agree with Dimitri. >> >> Please look at my reply to Dimitri to this point. >> >>> More so, PCE may be implemented to give >>> priority to various messages and limit certain messages (so the >>> implementation may not help monitoring here as JP is suggesting) and >>> again you could get different results of a monitoring request than >>> computational request. >> >> Again you make some confusion here: we're not trying to build a >> way to >> proritize messages, ... this is already in PCEP. The aim of the this >> draft is >> to have OAM. >> >>> >>>> => the PCE OAM mechanism implies a completely mode of >>>> operation that influence the capacity of the system >>>> >>>> Furthermore, if you experience an issue, would you prefer to >>>> ignore it or to be able to locate it ? >>>> >>>> [dp] use my local computation capability rely on "external domain" >>>> to solve an local problem may be >>>> >>>>> due to limited visibility ? why is this requiring "state >>>> monitoring" ? >>>>> >>>>> >>>>> ---> in brief, i still believe a serious problem statement >>>>> shall be >>>>> brought up before jumping in the specification of objects >>>> (the bits of >>>>> the wire) >>>>> >>>>> >>>> >>>> Hope this clarifies but the motivations are indeed quite >>>> straightforward. >>>> >>>> [dp] unfortunately, i am not convinced about the usefulness >>>> of this mechanism and the problem is that if it would >>>> harmless then i would not have any issue but it is not >>>> >>> [ad] agree with Dimitri, all that is looked after by the monitoring >>> mechanism can be achieved without that mechanism in place. >> >> So if you have a PCE chain PCC----PCE1----PCE2-----Dest >> How do the determine various perf metric along the chain with the >> mechanism >> in place ? >> >>> The mechanism >>> may add to the problem by being badly deployed and with many PCCs >>> runnning performance monitoring. With scaling and time passing the >>> mechanism may degrade PCE. >> >> This is implementation specific. If you design your system properly, >> you won't >> have this problem. Back to your previous point you have different >> message priority >> + other mechanisms to avoid this. >> >>> We do not want to monitor the monitoring >>> mechanism? >>> >> >> Sorry but this makes no sense. We're not monitoring the monitoring >> mechanism at all. >> >> JP. >> >>>> Thanks. >>>> >>>> JP. >>>> >>>>> thanks, >>>>> -d. >>>>> -- >>>>> >>>>> "In PCE-based environments, it is critical to monitor the >>>> state of the >>>>> path computation chain that can be used for performance >>>> monitoring >>>>> and troubleshooting purposes. This document specifies >>>> procedures >>>>> and >>>>> extensions to the Path Computation Element Protocol (PCEP) >>>>> ([I-D.ietf-pce-pcep]) in order to monitor the path computation >>>>> chain >>>>> and gather various performance metrics. >>>>> >>>>> As discussed in [RFC4655], a TE LSP may be computed by one PCE >>>>> (referred to as single PCE path computation) or several PCEs >>>>> (referred to as multiple PCE path computation). In the former >>>>> case, >>>>> the PCC may be able to use IGP extensions to check the >>>> liveness of >>>>> the PCE (see [I-D.ietf-pce-disco-proto-ospf] and >>>>> [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive >>>> messages. >>>>> In contrast, when multiple PCEs are involved in the path >>>>> computation >>>>> chain an example of which is the BRPC procedure defined in >>>>> [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the >>>>> first >>>>> PCE involved in the path computation chain. Thus, it is >>>> critical >>>>> to >>>>> define mechanisms in order to monitor the state of the path >>>>> computation chain." >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Internet-Drafts@ietf.org >>>>> 01/03/2007 21:50 >>>>> Please respond to internet-drafts >>>>> >>>>> To: i-d-announce@ietf.org >>>>> cc: >>>>> Subject: I-D >>>> ACTION:draft-vasseur-pce-monitoring-02.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : A set of >>>> monitoring >>>>> tools for Path Computation Element based Architecture >>>>> Author(s) : J. Le Roux, J. Vasseur >>>>> Filename : >>>>> draft-vasseur-pce-monitoring-02.txt >>>>> Pages : 18 >>>>> Date : 2007-3-1 >>>>> >>>>> A Path Computation Element (PCE) based architecture has been >>>>> specified for the computation of Traffic Engineering (TE) Label >>>>> Switched Paths (LSPs) in Multiprotocol Label Switching >>>>> (MPLS) and >>>>> Generalized MPLS (GMPLS) networks in the context of single or >>>>> multiple domains (where a domain is referred to as a >>>> collection of >>>>> network elements within a common sphere of address >>>>> management or >>>>> path computational responsibility such as IGP areas and Autonomous >>>>> Systems). In PCE-based environments it is thus critical >>>> to monitor >>>>> the state of the path computation chain that can be used for >>>>> performance monitoring and troubleshooting purposes. >>>> This document >>>>> specifies procedures and extensions to the Path >>>> Computation Element >>>>> Protocol (PCEP) in order to gather such information. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-vasseur-pce- >>>>> monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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 TE LSP may be computed by one PCE >>>>> (referred to as single PCE path computation) or several PCEs >>>>> (referred to as multiple PCE path computation). In the former >>>>> case, >>>>> the PCC may be able to use IGP extensions to check the >>>> liveness of >>>>> the PCE (see [I-D.ietf-pce-disco-proto-ospf] and >>>>> [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive >>>> messages. >>>>> In contrast, when multiple PCEs are involved in the path >>>>> computation >>>>> chain an example of which is the BRPC procedure defined in >>>>> [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the >>>>> first >>>>> PCE involved in the path computation chain. Thus, it is >>>> critical >>>>> to >>>>> define mechanisms in order to monitor the state of the path >>>>> computation chain." >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Internet-Drafts@ietf.org >>>>> 01/03/2007 21:50 >>>>> Please respond to internet-drafts >>>>> >>>>> To: i-d-announce@ietf.org >>>>> cc: >>>>> Subject: I-D >>>> ACTION:draft-vasseur-pce-monitoring-02.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : A set of >>>> monitoring >>>>> tools for Path Computation Element based Architecture >>>>> Author(s) : J. Le Roux, J. Vasseur >>>>> Filename : >>>>> draft-vasseur-pce-monitoring-02.txt >>>>> Pages : 18 >>>>> Date : 2007-3-1 >>>>> >>>>> A Path Computation Element (PCE) based architecture has been >>>>> specified for the computation of Traffic Engineering (TE) Label >>>>> Switched Paths (LSPs) in Multiprotocol Label Switching >>>>> (MPLS) and >>>>> Generalized MPLS (GMPLS) networks in the context of single or >>>>> multiple domains (where a domain is referred to as a >>>> collection of >>>>> network elements within a common sphere of address >>>>> management or >>>>> path computational responsibility such as IGP areas and Autonomous >>>>> Systems). In PCE-based environments it is thus critical >>>> to monitor >>>>> the state of the path computation chain that can be used for >>>>> performance monitoring and troubleshooting purposes. >>>> This document >>>>> specifies procedures and extensions to the Path >>>> Computation Element >>>>> Protocol (PCEP) in order to gather such information. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-vasseur-pce- >>>>> monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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. >>>>> ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- >>>>> monitoring-02.txt >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > 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 Mar 20 01:34:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWyb-0001W5-IJ; Tue, 20 Mar 2007 01:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWya-0001W0-Db for pce@ietf.org; Tue, 20 Mar 2007 01:33:40 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTWyY-0001wW-Fm for pce@ietf.org; Tue, 20 Mar 2007 01:33:40 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 06:33:34 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2K5XWZX015522; Tue, 20 Mar 2007 06:33:32 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2K5XOlf015335; Tue, 20 Mar 2007 05:33:32 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 06:33:32 +0100 Received: from [10.0.0.86] ([10.21.80.51]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 06:33:29 +0100 In-Reply-To: <002301c76a3e$e59089c0$93fa320a@araoa.ntt.com> References: <002301c76a3e$e59089c0$93fa320a@araoa.ntt.com> Mime-Version: 1.0 (Apple Message framework v752.2) 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] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt Date: Tue, 20 Mar 2007 06:23:04 +0100 To: Yuichi Ikejiri , PAPADIMITRIOU Dimitri X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Mar 2007 05:33:30.0176 (UTC) FILETIME=[4AE70C00:01C76AB1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=17539; t=1174368812; x=1175232812; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce] 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. >>>>> ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- >>>>> monitoring-02.txt >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > 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 Mar 20 01:34:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWyb-0001W5-IJ; Tue, 20 Mar 2007 01:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWya-0001W0-Db for pce@ietf.org; Tue, 20 Mar 2007 01:33:40 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTWyY-0001wW-Fm for pce@ietf.org; Tue, 20 Mar 2007 01:33:40 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 06:33:34 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2K5XWZX015522; Tue, 20 Mar 2007 06:33:32 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2K5XOlf015335; Tue, 20 Mar 2007 05:33:32 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 06:33:32 +0100 Received: from [10.0.0.86] ([10.21.80.51]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 06:33:29 +0100 In-Reply-To: <002301c76a3e$e59089c0$93fa320a@araoa.ntt.com> References: <002301c76a3e$e59089c0$93fa320a@araoa.ntt.com> Mime-Version: 1.0 (Apple Message framework v752.2) 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] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt Date: Tue, 20 Mar 2007 06:23:04 +0100 To: Yuichi Ikejiri , PAPADIMITRIOU Dimitri X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Mar 2007 05:33:30.0176 (UTC) FILETIME=[4AE70C00:01C76AB1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=17539; t=1174368812; x=1175232812; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Re=3A=20I-D=20ACTION=3Adraft-vasseur-pce-moni toring-02.txt |Sender:=20; bh=vYsbrpERqoXGF1pjr48YYn+w2DQorRtKSB9TiIHGFxw=; b=eKlIyniGuy+871GV78N/A2eFQw/GrXap7AZg1A8jWsv0WdjWQKcIzAfh7BegSkhs/s7eGzKk DxVgb+1WnDygAlddRVLXd02SFKN1YK+ioRk7oi3sYLLLTEpiLQUQBCMS; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 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: , Errors-To: pce-bounces@lists.ietf.org Hi, On Mar 19, 2007, at 4:54 PM, Yuichi Ikejiri wrote: > Hello, > > ----- Original Message ----- > From: > To: "Yuichi Ikejiri" > Cc: > Sent: Monday, March 19, 2007 11:43 PM > Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > > >> hello >> >> just a question to see whether i understand the point - >> >> if the PCC doesn't receive an answer from the PCE after >> initiating a request how does the PCC knows there is a >> chain of PCE behind the PCE towards which the request >> has been initiated - in brief what is the purpose of >> having a monitoring when the PCE is an on-path techno >> The PCC does not have to know ! If the PCE chain is limited to a single element the monitoring request will figure this out. >> now, assume that the PCC received an answer from the >> PCE is there a need keep track of PCE chain liveness ? > It depends on the situation, but I think not keep track of the chain > so often in the example I described. Just several times to see > what is happening in the current chain with the specific path > requests. But maybe there is also a case where longer monitoring > is needed in periodic manner. Again it depends on the situation > where the tool is used, I think. You're right. As with many other OAM tools, the goal is not to keep sending probes in the network but to use the tool as needed, which can be automatically or manually triggered in various circumstances. > >> i have also trouble to understanding the following: >> >> "When a PCC doesn't receive any response from a peer PCE, (meaning >> that >> a requested path is not established for a while)" >> >> PCE do not establish "path" they compute paths > I know that. I am sorry for the confusion. I just described what an > operator > actually knows as a result of that the PCC does not receive any path > calculation > result from the PCE in the actual network operation. But it was not > good > example, > so just ignore the text enclosed in the parenthesis. > The example is actually quite good and typical: such OAM tool can be used to determine a potential bottleneck along a PCE chain or should the PCE chain be broken to spot the PCE that does not respond, which may not be possible using the IGP discovery depending on the location of such PCE. Thanks. JP. > Thanks, > Yuichi > >> >> thanks, >> -d. >> >> >> >> >> "Yuichi Ikejiri" >> 19/03/2007 14:16 >> >> To: pce@ietf.org >> cc: >> Subject: Re: [Pce] Re: I-D >> ACTION:draft-vasseur-pce-monitoring-02.txt >> >> >> Hi, >> >>> From perspective of service provider, this kind of monitoring or >> diagnostics >> tool described in this draft is very useful and indespendable in the >> network >> where PCE chain is used (like the network devided into multiple >> IGP areas >> and ABRs are working as PCEs) . >> >> When a PCC doesn't receive any response from a peer PCE, (meaning >> that >> a requested path is not establish=20Re=3A=20I-D=20ACTION=3Adraft-vasseur-pce-moni toring-02.txt |Sender:=20; bh=vYsbrpERqoXGF1pjr48YYn+w2DQorRtKSB9TiIHGFxw=; b=eKlIyniGuy+871GV78N/A2eFQw/GrXap7AZg1A8jWsv0WdjWQKcIzAfh7BegSkhs/s7eGzKk DxVgb+1WnDygAlddRVLXd02SFKN1YK+ioRk7oi3sYLLLTEpiLQUQBCMS; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 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: , Errors-To: pce-bounces@lists.ietf.org Hi, On Mar 19, 2007, at 4:54 PM, Yuichi Ikejiri wrote: > Hello, > > ----- Original Message ----- > From: > To: "Yuichi Ikejiri" > Cc: > Sent: Monday, March 19, 2007 11:43 PM > Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt > > >> hello >> >> just a question to see whether i understand the point - >> >> if the PCC doesn't receive an answer from the PCE after >> initiating a request how does the PCC knows there is a >> chain of PCE behind the PCE towards which the request >> has been initiated - in brief what is the purpose of >> having a monitoring when the PCE is an on-path techno >> The PCC does not have to know ! If the PCE chain is limited to a single element the monitoring request will figure this out. >> now, assume that the PCC received an answer from the >> PCE is there a need keep track of PCE chain liveness ? > It depends on the situation, but I think not keep track of the chain > so often in the example I described. Just several times to see > what is happening in the current chain with the specific path > requests. But maybe there is also a case where longer monitoring > is needed in periodic manner. Again it depends on the situation > where the tool is used, I think. You're right. As with many other OAM tools, the goal is not to keep sending probes in the network but to use the tool as needed, which can be automatically or manually triggered in various circumstances. > >> i have also trouble to understanding the following: >> >> "When a PCC doesn't receive any response from a peer PCE, (meaning >> that >> a requested path is not established for a while)" >> >> PCE do not establish "path" they compute paths > I know that. I am sorry for the confusion. I just described what an > operator > actually knows as a result of that the PCC does not receive any path > calculation > result from the PCE in the actual network operation. But it was not > good > example, > so just ignore the text enclosed in the parenthesis. > The example is actually quite good and typical: such OAM tool can be used to determine a potential bottleneck along a PCE chain or should the PCE chain be broken to spot the PCE that does not respond, which may not be possible using the IGP discovery depending on the location of such PCE. Thanks. JP. > Thanks, > Yuichi > >> >> thanks, >> -d. >> >> >> >> >> "Yuichi Ikejiri" >> 19/03/2007 14:16 >> >> To: pce@ietf.org >> cc: >> Subject: Re: [Pce] Re: I-D >> ACTION:draft-vasseur-pce-monitoring-02.txt >> >> >> Hi, >> >>> From perspective of service provider, this kind of monitoring or >> diagnostics >> tool described in this draft is very useful and indespendable in the >> network >> where PCE chain is used (like the network devided into multiple >> IGP areas >> and ABRs are working as PCEs) . >> >> When a PCC doesn't receive any response from a peer PCE, (meaning >> that >> a requested path is not established for a while), an operator >> would try to >> check >> not only the peer PCE, but also the PCE chain to see if the PCE >> chain is >> working or appropriate, and who does not response the result or takes >> very long time to do path calculation. We need to have a mechanism >> to do >> such check. >> >> The chain itself is different depending on the END-POINTS or other >> contraints, >> so that this kind of monitoring should be reqeusted with the PCReq >> message. >> And >> also an operator sometimes wants to check only PCE chain itself >> without >> any >> actual path >> computation and sometimes wants to check the actual processing >> time at a >> PCE >> in the PCE chain with actual path computation. >> >> This is just an example of the situation, coming up in my mind, >> where SPs >> may use >> the tools described in this draft. I believe that the example(use >> case) I >> mentioned, >> is covered in the draft by choosing appropriate objects proposed. >> #if no, please clarify, authors. >> >> So, I think that this kind of monitoring tool is needed. >> >> Thanks, >> Yuichi >> >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "DOLGANOW Andrew" >> Cc: >> Sent: Monday, March 19, 2007 4:57 AM >> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt >> >> >>> FYI, look at my reply to this email. >>> >>> More in line, >>> >>> On Mar 18, 2007, at 5:48 PM, DOLGANOW Andrew wrote: >>> >>>> Please see below prefixed with [ad] >>>> >>>>> -----Original Message----- >>>>> From: Dimitri.Papadimitriou@alcatel-lucent.be >>>>> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] >>>>> Sent: Friday, March 02, 2007 11:50 AM >>>>> To: JP Vasseur >>>>> Cc: pce@ietf.org >>>>> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce- >>>>> monitoring-02.txt >>>>> >>>>> hi j-p >>>>> >>>>> see in-line >>>>> >>>>> >>>>> >>>>> >>>>> JP Vasseur >>>>> 02/03/2007 17:03 >>>>> >>>>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>>>> cc: pce@ietf.org >>>>> Subject: Re: [Pce] Re: I-D >>>>> ACTION:draft-vasseur-pce-monitoring-02.txt >>>>> >>>>> >>>>> Hi Dimitri, >>>>> >>>>> On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel- >>>>> lucent.be >>>>> wrote: >>>>> >>>>>> a simple question >>>>>> >>>>>> >>>>>> the document repeats twice that it critical to monitor the >>>>>> state of >>>>>> the PC chain (see below) >>>>>> >>>>> >>>>> Yes indeed. >>>>> >>>>>> >>>>>> i try to understand reasoning - can authors clarify ? >>>>>> >>>>>> for perf.mon ? is the PCC going to tack perfs of PC servers ? >>>>>> >>>>>> for troubleshooting ? but for which trouble ? >>>>> >>>>> I think that the motivation is fairly simple here ... You may >>>>> want to monitor various aspects. >>>>> For example, you may want to measure the path computation >>>>> response time. That might be for performance monitoring or >>>>> troubleshooting because a PCC experience very long response >>>>> time. The motivation sounds extremely obvious: PCE OAM. As >>>>> for any other system, the user may want to monitor the >>>>> performance for network design, troubleshooting, ... >>>>> >>>>> [dp] PC response time, but how are you going to ensure that >>>>> running conditions are identical at time t[n-1], t[n], t[n+1] >>>>> ? in fact the question is the relevance of repeating a given >>>>> request when the run conditions can be completely different >>>>> >>>> [ad] Dimitri brings a valid point here. This was discussed in San >>>> Diego, >>>> proposed to be taken to the list and never really answered. In >>>> addition >>>> to the time variable, for performance monitoring to work, we would >>>> need >>>> to ensure that no steps are skipped along the process. The best >>>> way I >>>> would say would be to monitor Request/Results from PCC and if >>>> required >>>> issue another PC request (which could collect timestamps along the >>>> process). >>> >>> You miss a point here ... of course, you can monitor the overall >>> response timed for a while), an operator >> would try to >> check >> not only the peer PCE, but also the PCE chain to see if the PCE >> chain is >> working or appropriate, and who does not response the result or takes >> very long time to do path calculation. We need to have a mechanism >> to do >> such check. >> >> The chain itself is different depending on the END-POINTS or other >> contraints, >> so that this kind of monitoring should be reqeusted with the PCReq >> message. >> And >> also an operator sometimes wants to check only PCE chain itself >> without >> any >> actual path >> computation and sometimes wants to check the actual processing >> time at a >> PCE >> in the PCE chain with actual path computation. >> >> This is just an example of the situation, coming up in my mind, >> where SPs >> may use >> the tools described in this draft. I believe that the example(use >> case) I >> mentioned, >> is covered in the draft by choosing appropriate objects proposed. >> #if no, please clarify, authors. >> >> So, I think that this kind of monitoring tool is needed. >> >> Thanks, >> Yuichi >> >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "DOLGANOW Andrew" >> Cc: >> Sent: Monday, March 19, 2007 4:57 AM >> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt >> >> >>> FYI, look at my reply to this email. >>> >>> More in line, >>> >>> On Mar 18, 2007, at 5:48 PM, DOLGANOW Andrew wrote: >>> >>>> Please see below prefixed with [ad] >>>> >>>>> -----Original Message----- >>>>> From: Dimitri.Papadimitriou@alcatel-lucent.be >>>>> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] >>>>> Sent: Friday, March 02, 2007 11:50 AM >>>>> To: JP Vasseur >>>>> Cc: pce@ietf.org >>>>> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce- >>>>> monitoring-02.txt >>>>> >>>>> hi j-p >>>>> >>>>> see in-line >>>>> >>>>> >>>>> >>>>> >>>>> JP Vasseur >>>>> 02/03/2007 17:03 >>>>> >>>>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>>>> cc: pce@ietf.org >>>>> Subject: Re: [Pce] Re: I-D >>>>> ACTION:draft-vasseur-pce-monitoring-02.txt >>>>> >>>>> >>>>> Hi Dimitri, >>>>> >>>>> On Mar 2, 2007, at 10:20 AM, Dimitri.Papadimitriou@alcatel- >>>>> lucent.be >>>>> wrote: >>>>> >>>>>> a simple question >>>>>> >>>>>> >>>>>> the document repeats twice that it critical to monitor the >>>>>> state of >>>>>> the PC chain (see below) >>>>>> >>>>> >>>>> Yes indeed. >>>>> >>>>>> >>>>>> i try to understand reasoning - can authors clarify ? >>>>>> >>>>>> for perf.mon ? is the PCC going to tack perfs of PC servers ? >>>>>> >>>>>> for troubleshooting ? but for which trouble ? >>>>> >>>>> I think that the motivation is fairly simple here ... You may >>>>> want to monitor various aspects. >>>>> For example, you may want to measure the path computation >>>>> response time. That might be for performance monitoring or >>>>> troubleshooting because a PCC experience very long response >>>>> time. The motivation sounds extremely obvious: PCE OAM. As >>>>> for any other system, the user may want to monitor the >>>>> performance for network design, troubleshooting, ... >>>>> >>>>> [dp] PC response time, but how are you going to ensure that >>>>> running conditions are identical at time t[n-1], t[n], t[n+1] >>>>> ? in fact the question is the relevance of repeating a given >>>>> request when the run conditions can be completely different >>>>> >>>> [ad] Dimitri brings a valid point here. This was discussed in San >>>> Diego, >>>> proposed to be taken to the list and never really answered. In >>>> addition >>>> to the time variable, for performance monitoring to work, we would >>>> need >>>> to ensure that no steps are skipped along the process. The best >>>> way I >>>> would say would be to monitor Request/Results from PCC and if >>>> required >>>> issue another PC request (which could collect timestamps along the >>>> process). >>> >>> You miss a point here ... of course, you can monitor the overall >>> response time >>> but how do you figure out the time you spent along the PCE chain ? >>> >>>> >>>>>> (this said, i am also >>>>>> concerned by the fact that if each PCC for each path across >>>>> a set of >>>>>> PCEs starts to generate such state monitoring then for sure >>>>>> servers >>>>>> may experience overload) >>>>> >>>>> Ah no ... this is an implementation issue on the PCE if >>>>> you've such issue. >>>>> >>>>> [dp] i disagree, if one builds a PCE to sustain x PC demands >>>>> per unit of time, but PCE gets now confronted to the fact >>>>> that a number X of clients, X >> x, are permanently polling >>>>> the server (remember that the PC server can be memoryless) >>>>> for monitoring all the previously computed path, the running >>>>> conditions are completely different, in fact the performance >>>>> of your system degrades over time (i know a well known >>>>> operating system that shows the same property ;-( >>>>> >>>> >>>> [ad] Agree with Dimitri. >>> >>> Please look at my reply to Dimitri to this point. >>> >>>> More so, PCE may be implemented to give >>>> priority to various messages and limit certain messages (so the >>>> implementation may not help monitoring here as JP is suggesting) >>>> and >>>> again you could get different results of a monitoring request than >>>> computational request. >>> >>> Again you make some confusion here: we're not trying to build a >>> way to >>> proritize messages, ... this is already in PCEP. The aim of the this >>> draft is >>> to have OAM. >>> >>>> >>>>> => the PCE OAM mechanism implies a completely mode of >>>>> operation that influence the capacity of the system >>>>> >>>>> Furthermore, if you experience an issue, would you prefer to >>>>> ignore it or to be able to locate it ? >>>>> >>>>> [dp] use my local computation capability rely on "external domain" >>>>> to solve an local problem may be >>>>> >>>>>> due to limited visibility ? why is this requiring "state >>>>> monitoring" ? >>>>>> >>>>>> >>>>>> ---> in brief, i still believe a serious problem statement >>>>>> shall be >>>>>> brought up before jumping in the specification of objects >>>>> (the bits of >>>>>> the wire) >>>>>> >>>>>> >>>>> >>>>> Hope this clarifies but the motivations are indeed quite >>>>> straightforward. >>>>> >>>>> [dp] unfortunately, i am not convinced about the usefulness >>>>> of this mechanism and the problem is that if it would >>>>> harmless then i would not have any issue but it is not >>>>> >>>> [ad] agree with Dimitri, all that is looked after by the monitoring >>>> mechanism can be achieved without that mechanism in place. >>> >>> So if you have a PCE chain PCC----PCE1----PCE2-----Dest >>> How do the determine various perf metric along the chain with the >>> mechanism >>> in place ? >>> >>>> The mechanism >>>> may add to the problem by being badly deployed and with many PCCs >>>> runnning performance monitoring. With scaling and time passing the >>>> mechanism may degrade PCE. >>> >>> This is implementation specific. If you design your system properly, >>> you won't >>> have this problem. Back to your previous point you have different >>> message priority >>> + other mechanisms to avoid this. >>> >>>> We do not want to monitor the monitoring >>>> mechanism? >>>> >>> >>> Sorry but this makes no sense. We're not monitoring the monitoring >>> mechanism at all. >>> >>> JP. >>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>>> thanks, >>>>>> -d. >>>>>> -- >>>>>> >>>>>> "In PCE-based environments, it is critical to monitor the >>>>> state of the >>>>>> path computation chain that can be used for performance >>>>> monitoring >>>>>> and troubleshooting purposes. This document specifies >>>>> procedures >>>>>> and >>>>>> extensions to the Path Computation Element Protocol (PCEP) >>>>>> ([I-D.ietf-pce-pcep]) in order to monitor the path computation >>>>>> chain >>>>>> and gather various performance metrics. >>>>>> >>>>>> As discussed in [RFC4655], a TE LSP may be computed by one PCE >>>>>> (referred to as single PCE path computation) or several PCEs >>>>>> (referred to as multiple e >>> but how do you figure out the time you spent along the PCE chain ? >>> >>>> >>>>>> (this said, i am also >>>>>> concerned by the fact that if each PCC for each path across >>>>> a set of >>>>>> PCEs starts to generate such state monitoring then for sure >>>>>> servers >>>>>> may experience overload) >>>>> >>>>> Ah no ... this is an implementation issue on the PCE if >>>>> you've such issue. >>>>> >>>>> [dp] i disagree, if one builds a PCE to sustain x PC demands >>>>> per unit of time, but PCE gets now confronted to the fact >>>>> that a number X of clients, X >> x, are permanently polling >>>>> the server (remember that the PC server can be memoryless) >>>>> for monitoring all the previously computed path, the running >>>>> conditions are completely different, in fact the performance >>>>> of your system degrades over time (i know a well known >>>>> operating system that shows the same property ;-( >>>>> >>>> >>>> [ad] Agree with Dimitri. >>> >>> Please look at my reply to Dimitri to this point. >>> >>>> More so, PCE may be implemented to give >>>> priority to various messages and limit certain messages (so the >>>> implementation may not help monitoring here as JP is suggesting) >>>> and >>>> again you could get different results of a monitoring request than >>>> computational request. >>> >>> Again you make some confusion here: we're not trying to build a >>> way to >>> proritize messages, ... this is already in PCEP. The aim of the this >>> draft is >>> to have OAM. >>> >>>> >>>>> => the PCE OAM mechanism implies a completely mode of >>>>> operation that influence the capacity of the system >>>>> >>>>> Furthermore, if you experience an issue, would you prefer to >>>>> ignore it or to be able to locate it ? >>>>> >>>>> [dp] use my local computation capability rely on "external domain" >>>>> to solve an local problem may be >>>>> >>>>>> due to limited visibility ? why is this requiring "state >>>>> monitoring" ? >>>>>> >>>>>> >>>>>> ---> in brief, i still believe a serious problem statement >>>>>> shall be >>>>>> brought up before jumping in the specification of objects >>>>> (the bits of >>>>>> the wire) >>>>>> >>>>>> >>>>> >>>>> Hope this clarifies but the motivations are indeed quite >>>>> straightforward. >>>>> >>>>> [dp] unfortunately, i am not convinced about the usefulness >>>>> of this mechanism and the problem is that if it would >>>>> harmless then i would not have any issue but it is not >>>>> >>>> [ad] agree with Dimitri, all that is looked after by the monitoring >>>> mechanism can be achieved without that mechanism in place. >>> >>> So if you have a PCE chain PCC----PCE1----PCE2-----Dest >>> How do the determine various perf metric along the chain with the >>> mechanism >>> in place ? >>> >>>> The mechanism >>>> may add to the problem by being badly deployed and with many PCCs >>>> runnning performance monitoring. With scaling and time passing the >>>> mechanism may degrade PCE. >>> >>> This is implementation specific. If you design your system properly, >>> you won't >>> have this problem. Back to your previous point you have different >>> message priority >>> + other mechanisms to avoid this. >>> >>>> We do not want to monitor the monitoring >>>> mechanism? >>>> >>> >>> Sorry but this makes no sense. We're not monitoring the monitoring >>> mechanism at all. >>> >>> JP. >>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>>> thanks, >>>>>> -d. >>>>>> -- >>>>>> >>>>>> "In PCE-based environments, it is critical to monitor the >>>>> state of the >>>>>> path computation chain that can be used for performance >>>>> monitoring >>>>>> and troubleshooting purposes. This document specifies >>>>> procedures >>>>>> and >>>>>> extensions to the Path Computation Element Protocol (PCEP) >>>>>> ([I-D.ietf-pce-pcep]) in order to monitor the path computation >>>>>> chain >>>>>> and gather various performance metrics. >>>>>> >>>>>> As discussed in [RFC4655], a TE LSP may be computed by one PCE >>>>>> (referred to as single PCE path computation) or several PCEs >>>>>> (referred to as multiple PCE path computation). In the former >>>>>> case, >>>>>> the PCC may be able to use IGP extensions to check the >>>>> liveness of >>>>>> the PCE (see [I-D.ietf-pce-disco-proto-ospf] and >>>>>> [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive >>>>> messages. >>>>>> In contrast, when multiple PCEs are involved in the path >>>>>> computation >>>>>> chain an example of which is the BRPC procedure defined in >>>>>> [I-D.ietf-pce-brpc], the PCC's visibility may be limited to >>>>>> the >>>>>> first >>>>>> PCE involved in the path computation chain. Thus, it is >>>>> critical >>>>>> to >>>>>> define mechanisms in order to monitor the state of the path >>>>>> computation chain." >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Internet-Drafts@ietf.org >>>>>> 01/03/2007 21:50 >>>>>> Please respond to internet-drafts >>>>>> >>>>>> To: i-d-announce@ietf.org >>>>>> cc: >>>>>> Subject: I-D >>>>> ACTION:draft-vasseur-pce-monitoring-02.txt >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet- >>>>>> Drafts >>>>>> directories. >>>>>> >>>>>> >>>>>> Title : A set of >>>>> monitoring >>>>>> tools for Path Computation Element based Architecture >>>>>> Author(s) : J. Le Roux, J. Vasseur >>>>>> Filename : >>>>>> draft-vasseur-pce-monitoring-02.txt >>>>>> Pages : 18 >>>>>> Date : 2007-3-1 >>>>>> >>>>>> A Path Computation Element (PCE) based architecture has been >>>>>> specified for the computation of Traffic Engineering (TE) >>>>>> Label >>>>>> Switched Paths (LSPs) in Multiprotocol Label Switching >>>>>> (MPLS) and >>>>>> Generalized MPLS (GMPLS) networks in the context of single or >>>>>> multiple domains (where a domain is referred to as a >>>>> collection of >>>>>> network elements within a common sphere of address >>>>>> management or >>>>>> path computational responsibility such as IGP areas and >>>>>> Autonomous >>>>>> Systems). In PCE-based environments it is thus critical >>>>> to monitor >>>>>> the state of the path computation chain that can be used for >>>>>> performance monitoring and troubleshooting purposes. >>>>> This document >>>>>> specifies procedures and extensions to the Path >>>>> Computation Element >>>>>> Protocol (PCEP) in order to gather such information. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-vasseur-pce- >>>>>> monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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 >>>>>> PCE path computation). In the former >>>>>> case, >>>>>> the PCC may be able to use IGP extensions to check the >>>>> liveness of >>>>>> the PCE (see [I-D.ietf-pce-disco-proto-ospf] and >>>>>> [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive >>>>> messages. >>>>>> In contrast, when multiple PCEs are involved in the path >>>>>> computation >>>>>> chain an example of which is the BRPC procedure defined in >>>>>> [I-D.ietf-pce-brpc], the PCC's visibility may be limited to >>>>>> the >>>>>> first >>>>>> PCE involved in the path computation chain. Thus, it is >>>>> critical >>>>>> to >>>>>> define mechanisms in order to monitor the state of the path >>>>>> computation chain." >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Internet-Drafts@ietf.org >>>>>> 01/03/2007 21:50 >>>>>> Please respond to internet-drafts >>>>>> >>>>>> To: i-d-announce@ietf.org >>>>>> cc: >>>>>> Subject: I-D >>>>> ACTION:draft-vasseur-pce-monitoring-02.txt >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet- >>>>>> Drafts >>>>>> directories. >>>>>> >>>>>> >>>>>> Title : A set of >>>>> monitoring >>>>>> tools for Path Computation Element based Architecture >>>>>> Author(s) : J. Le Roux, J. Vasseur >>>>>> Filename : >>>>>> draft-vasseur-pce-monitoring-02.txt >>>>>> Pages : 18 >>>>>> Date : 2007-3-1 >>>>>> >>>>>> A Path Computation Element (PCE) based architecture has been >>>>>> specified for the computation of Traffic Engineering (TE) >>>>>> Label >>>>>> Switched Paths (LSPs) in Multiprotocol Label Switching >>>>>> (MPLS) and >>>>>> Generalized MPLS (GMPLS) networks in the context of single or >>>>>> multiple domains (where a domain is referred to as a >>>>> collection of >>>>>> network elements within a common sphere of address >>>>>> management or >>>>>> path computational responsibility such as IGP areas and >>>>>> Autonomous >>>>>> Systems). In PCE-based environments it is thus critical >>>>> to monitor >>>>>> the state of the path computation chain that can be used for >>>>>> performance monitoring and troubleshooting purposes. >>>>> This document >>>>>> specifies procedures and extensions to the Path >>>>> Computation Element >>>>>> Protocol (PCEP) in order to gather such information. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-vasseur-pce- >>>>>> monitoring-02.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-vasseur-pce-monitoring-02.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-vasseur-pce-monitoring-02.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. >>>>>> ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- >>>>>> monitoring-02.txt >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> _______________________________________________ >> 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 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. >>>>>> ftp://anonymous@ftp.ietf.org/internet-drafts/draft-vasseur-pce- >>>>>> monitoring-02.txt >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> _______________________________________________ >> 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 Thu Mar 22 04:33:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIiv-0003L7-U5; Thu, 22 Mar 2007 04:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIiu-0003Kn-Gh for pce@ietf.org; Thu, 22 Mar 2007 04:32:40 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUIis-0005Av-6n for pce@ietf.org; Thu, 22 Mar 2007 04:32:40 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2007 01:32:38 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2M8Wb8I029208 for ; Thu, 22 Mar 2007 01:32:37 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2M8WbZT008607 for ; Thu, 22 Mar 2007 08:32:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 01:32:37 -0700 Received: from [130.129.19.82] ([10.21.100.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 01:32:36 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Thu, 22 Mar 2007 09:32:33 +0100 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Mar 2007 08:32:37.0133 (UTC) FILETIME=[A56A0BD0:01C76C5C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=196; t=1174552357; x=1175416357; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20New=20WG=20ID=3A=20draft-oki-pce-pcep-xro-00.txt=20? |Sender:=20; bh=kfLmgInN5oA2ljMePZEYStXdrhQcu/Ney+6ntRTmXGY=; b=ENMknPX742gYdv0Et5uEggPvB22T7eWEoxVN0mtLlkP3hl0DAeSrHfj0oFUf3qyIYytsZsuM LIuHfQI6OfveWHU2kmVKikxy7Kd5e+r0rpzJa9CIiCWUaxZMPjY4nT6urfwFkgUVp18UfwvHt5 bkltU3S1u5p9lBhHdeLdu40g4=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Pce] New WG ID: draft-oki-pce-pcep-xro-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: , Errors-To: pce-bounces@lists.ietf.org Hi, There was a good support during the PCE WG meeting to adopt draft-oki- pce-pcep-xro-00.txt as a WG document. Are you in favor / opposed adopting the ID as a WG ID ? Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 22 04:38:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIoP-0005m3-6o; Thu, 22 Mar 2007 04:38:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIoN-0005lj-AI for pce@ietf.org; Thu, 22 Mar 2007 04:38:19 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUIoK-0005th-Od for pce@ietf.org; Thu, 22 Mar 2007 04:38:19 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2007 01:38:16 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l2M8cFuV022458 for ; Thu, 22 Mar 2007 01:38:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2M8cFA8012449 for ; Thu, 22 Mar 2007 08:38:16 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 01:38:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? Date: Thu, 22 Mar 2007 01:38:13 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E033EC079@xmb-sjc-234.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? Thread-Index: AcdsXPQsfMwsLSvWQKufa6RXtxsbwwAAG38g References: From: "Dean Cheng \(dcheng\)" To: "Jean Philippe Vasseur \(jvasseur\)" , X-OriginalArrivalTime: 22 Mar 2007 08:38:15.0868 (UTC) FILETIME=[6F50E7C0:01C76C5D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=609; t=1174552696; x=1175416696; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dcheng@cisco.com; z=From:=20=22Dean=20Cheng=20\(dcheng\)=22=20 |Subject:=20RE=3A=20[Pce]=20New=20WG=20ID=3A=20draft-oki-pce-pcep-xro-00. txt=20? |Sender:=20; bh=5/agIxcINs8ckMmVt/WwJNTxRP6W8iT4xzQ/Vadolrs=; b=RCdo210B+bm8ORBNRntd5TFxWDOqB/dOIc1GR6O10Jf2RyAXLc1igC7WbvSshjGJzF+G15KZ H4ohvKrtkdHmVw/ou04uaPjgwaEIPxWMci6X8YGGjtJNSG2dEjVM41ju; Authentication-Results: sj-dkim-6; header.From=dcheng@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: pce-bounces@lists.ietf.org I'm in favor. Dean=20 > -----Original Message----- > From: Jean Philippe Vasseur (jvasseur)=20 > Sent: Thursday, March 22, 2007 1:33 AM > To: pce@ietf.org > Subject: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? >=20 > Hi, >=20 > There was a good support during the PCE WG meeting to adopt=20 > draft-oki- pce-pcep-xro-00.txt as a WG document. >=20 > Are you in favor / opposed adopting the ID as a WG ID ? >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 22 04:41:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIrL-0008UG-AF; Thu, 22 Mar 2007 04:41:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIrJ-0008SQ-Ur for pce@ietf.org; Thu, 22 Mar 2007 04:41:21 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUIr8-0007v4-AO for pce@ietf.org; Thu, 22 Mar 2007 04:41:21 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1174552868!13725363!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 27937 invoked from network); 22 Mar 2007 08:41:09 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-2.tower-120.messagelabs.com with SMTP; 22 Mar 2007 08:41:09 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2M8f8Vo026967; Thu, 22 Mar 2007 04:41:08 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2M8f5L7026954; Thu, 22 Mar 2007 04:41:05 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? Date: Thu, 22 Mar 2007 03:41:05 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8334@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <70BC84B185C3EE448EDB7AB8956D3B0E033EC079@xmb-sjc-234.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? Thread-Index: AcdsXPQsfMwsLSvWQKufa6RXtxsbwwAAG38gAAATMZA= References: <70BC84B185C3EE448EDB7AB8956D3B0E033EC079@xmb-sjc-234.amer.cisco.com> From: "ASH, GERALD R, ATTLABS" To: "Jean Philippe Vasseur \(jvasseur\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 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: , Errors-To: pce-bounces@lists.ietf.org > Are you in favor / opposed adopting the ID as a WG ID? In favor. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 22 04:53:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJ2w-00006m-3T; Thu, 22 Mar 2007 04:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJ2v-00006S-MQ for pce@ietf.org; Thu, 22 Mar 2007 04:53:21 -0400 Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJ2k-0002YF-ET for pce@ietf.org; Thu, 22 Mar 2007 04:53:21 -0400 Received: from sfs2.rdh.ecl.ntt.co.jp (IDENT:mirapoint@sfs2.rdh.ecl.ntt.co.jp [129.60.39.117]) by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2M8oj6j013385; Thu, 22 Mar 2007 17:52:58 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by sfs2.rdh.ecl.ntt.co.jp (MOS 3.8.3-GA) with ESMTP id ADZ03698; Thu, 22 Mar 2007 17:52:58 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 16BF920AE29; Thu, 22 Mar 2007 17:52:58 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id DF1B520AE28; Thu, 22 Mar 2007 17:52:57 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2M8qvEc001447; Thu, 22 Mar 2007 17:52:57 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2M8qvNb001277; Thu, 22 Mar 2007 17:52:57 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2M8quZw001268; Thu, 22 Mar 2007 17:52:56 +0900 (JST) Received: from Panasonic.lab.ntt.co.jp ([129.60.15.201]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l2M8qh71012933; Thu, 22 Mar 2007 17:52:53 +0900 (JST) Message-Id: <6.0.0.20.2.20070322175058.07e0cc40@imf.m.ecl.ntt.co.jp> X-Sender: tt043@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Thu, 22 Mar 2007 17:51:17 +0900 To: JP Vasseur , pce@ietf.org From: Tomonori TAKEDA Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: pce-bounces@lists.ietf.org In favor. Tomonori At 17:32 07/03/22, JP Vasseur wrote: >Hi, > >There was a good support during the PCE WG meeting to adopt draft-oki- pce-pcep-xro-00.txt as a WG document. > >Are you in favor / opposed adopting the ID as a WG ID ? > >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 Mar 22 04:55:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJ5L-0001hb-09; Thu, 22 Mar 2007 04:55:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJ5J-0001fY-Te for pce@ietf.org; Thu, 22 Mar 2007 04:55:49 -0400 Received: from mgw1.noc.ntt.com ([210.160.15.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJ5D-0003Oj-63 for pce@ietf.org; Thu, 22 Mar 2007 04:55:49 -0400 Received: from mop2.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id l2M8tZnT012446; Thu, 22 Mar 2007 17:55:39 +0900 (JST) Received: from mip3.noc.ntt.com (mvi1.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0JFA000DTRGPFE@ntt.com>; Thu, 22 Mar 2007 17:55:38 +0900 (JST) Date: Thu, 22 Mar 2007 17:55:38 +0900 From: "Yuichi Ikejiri" Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: "JP Vasseur" , pce@ietf.org Message-id: <074c01c76c5f$dc82efd0$92fa320a@araoa.ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: pce-bounces@lists.ietf.org In favor. Yuichi ----- Original Message ----- From: "JP Vasseur" To: Sent: Thursday, March 22, 2007 5:32 PM Subject: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? > Hi, > > There was a good support during the PCE WG meeting to adopt draft-oki- > pce-pcep-xro-00.txt as a WG document. > > Are you in favor / opposed adopting the ID as a WG ID ? > > 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 Mar 22 04:58:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJ7g-00075a-6k; Thu, 22 Mar 2007 04:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJ7e-00070j-5v for pce@ietf.org; Thu, 22 Mar 2007 04:58:14 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJ7Z-0003uA-PM for pce@ietf.org; Thu, 22 Mar 2007 04:58:14 -0400 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1HUJ7Y-0007Qb-UZ for pce@ietf.org; Thu, 22 Mar 2007 08:58:08 +0000 Received: from your029b8cecfe ([130.129.19.234] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 08:58:08 +0000 Message-ID: <00d201c76c60$33a59ba0$ea138182@your029b8cecfe> From: "Adrian Farrel" To: Date: Thu, 22 Mar 2007 08:55:36 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 22 Mar 2007 08:58:08.0462 (UTC) FILETIME=[36284EE0:01C76C60] X-Originating-Rutherford-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Pce] Updates to your slides 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: , Errors-To: pce-bounces@lists.ietf.org Some of you (or was it just JP?) used updated slides in the meeting. Can you please mail them to me for upload to the meeting archive. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 22 04:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJ7v-0007DB-HS; Thu, 22 Mar 2007 04:58:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJ7t-0007Cl-DR for pce@ietf.org; Thu, 22 Mar 2007 04:58:29 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJ7p-0003rt-WD for pce@ietf.org; Thu, 22 Mar 2007 04:58:28 -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 <0JFA008YIRA65S@szxga02-in.huawei.com> for pce@ietf.org; Thu, 22 Mar 2007 16:51:42 +0800 (CST) Received: from dan (dhcp-17e6.ietf68.org [130.129.23.230]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JFA00DHSR9WZF@szxga02-in.huawei.com> for pce@ietf.org; Thu, 22 Mar 2007 16:51:42 +0800 (CST) Date: Thu, 22 Mar 2007 16:51:28 +0800 From: Dan Li Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: JP Vasseur , pce@ietf.org Message-id: <01d101c76c5f$4f16dda0$5300000a@dan> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: pce-bounces@lists.ietf.org In favor. Dan Li ----- Original Message ----- From: "JP Vasseur" To: Sent: Thursday, March 22, 2007 4:32 PM Subject: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? > Hi, > > There was a good support during the PCE WG meeting to adopt draft-oki- > pce-pcep-xro-00.txt as a WG document. > > Are you in favor / opposed adopting the ID as a WG ID ? > > 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 Mar 22 05:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJRg-0003HG-5M; Thu, 22 Mar 2007 05:18:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJRf-0003H4-0N for pce@ietf.org; Thu, 22 Mar 2007 05:18:55 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJRd-0000RK-JW for pce@ietf.org; Thu, 22 Mar 2007 05:18:54 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 10:18:19 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? Date: Thu, 22 Mar 2007 10:18:40 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? Thread-Index: AcdsXPUJUdc9JGjcTaKnsRTzoZ76RgABgvWA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , X-OriginalArrivalTime: 22 Mar 2007 09:18:19.0830 (UTC) FILETIME=[08306560:01C76C63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Errors-To: pce-bounces@lists.ietf.org Hi all, I support this draft as WG doc Regards JL =20 >=20 > Hi, >=20 > There was a good support during the PCE WG meeting to adopt draft-oki- >=20 > pce-pcep-xro-00.txt as a WG document. >=20 > Are you in favor / opposed adopting the ID as a WG ID ? >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 22 05:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJRS-0002zT-P6; Thu, 22 Mar 2007 05:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJRR-0002zL-86 for pce@ietf.org; Thu, 22 Mar 2007 05:18:41 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJRP-0000ON-TV for pce@ietf.org; Thu, 22 Mar 2007 05:18:41 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 22 Mar 2007 02:18:39 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2M9Idln002425; Thu, 22 Mar 2007 02:18:39 -0700 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 l2M9IdEi028203; Thu, 22 Mar 2007 09:18:39 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 02:18:38 -0700 Received: from [130.129.19.82] ([10.21.100.249]) by xFrom pce-bounces@lists.ietf.org Thu Mar 22 05:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJRg-0003HG-5M; Thu, 22 Mar 2007 05:18:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJRf-0003H4-0N for pce@ietf.org; Thu, 22 Mar 2007 05:18:55 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJRd-0000RK-JW for pce@ietf.org; Thu, 22 Mar 2007 05:18:54 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 10:18:19 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? Date: Thu, 22 Mar 2007 10:18:40 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? Thread-Index: AcdsXPUJUdc9JGjcTaKnsRTzoZ76RgABgvWA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , X-OriginalArrivalTime: 22 Mar 2007 09:18:19.0830 (UTC) FILETIME=[08306560:01C76C63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Errors-To: pce-bounces@lists.ietf.org Hi all, I support this draft as WG doc Regards JL =20 >=20 > Hi, >=20 > There was a good support during the PCE WG meeting to adopt draft-oki- >=20 > pce-pcep-xro-00.txt as a WG document. >=20 > Are you in favor / opposed adopting the ID as a WG ID ? >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 22 05:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJRS-0002zT-P6; Thu, 22 Mar 2007 05:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJRR-0002zL-86 for pce@ietf.org; Thu, 22 Mar 2007 05:18:41 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJRP-0000ON-TV for pce@ietf.org; Thu, 22 Mar 2007 05:18:41 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 22 Mar 2007 02:18:39 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2M9Idln002425; Thu, 22 Mar 2007 02:18:39 -0700 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 l2M9IdEi028203; Thu, 22 Mar 2007 09:18:39 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 02:18:38 -0700 Received: from [130.129.19.82] ([10.21.100.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 02:18:38 -0700 In-Reply-To: <00d201c76c60$33a59ba0$ea138182@your029b8cecfe> References: <00d201c76c60$33a59ba0$ea138182@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <131F18C9-23C9-4B36-998E-2C7C34A567F7@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Updates to your slides Date: Thu, 22 Mar 2007 10:18:36 +0100 To: Adrian Farrel X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Mar 2007 09:18:38.0539 (UTC) FILETIME=[135729B0:01C76C63] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=387; t=1174555119; x=1175419119; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Updates=20to=20your=20slides |Sender:=20; bh=es4NoVZtng9eOVd6FIOE2pO0dZjV2i0ssCeo5bdGRRg=; b=mXeeZoXZ/guDNyBh26kjWayvDcV7jb36RIPP0vmRohAgpRsuEr4TsS4lvHYqXUsh1Jo3or7q KaHJ+dbAEW2Hykm83kBYpaxSZua3BJOwqiwHrvx3nlpm9PZwdNZm3kRf; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: pce-bounces@lists.ietf.org On Mar 22, 2007, at 9:55 AM, Adrian Farrel wrote: > Some of you (or was it just JP? JL ;-) > ) used updated slides in the meeting. > > Can you please mail them to me for upload to the meeting archive. > > Thanks, > > Adrian > > > _______________________________________________ > 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 fe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 02:18:38 -0700 In-Reply-To: <00d201c76c60$33a59ba0$ea138182@your029b8cecfe> References: <00d201c76c60$33a59ba0$ea138182@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <131F18C9-23C9-4B36-998E-2C7C34A567F7@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Updates to your slides Date: Thu, 22 Mar 2007 10:18:36 +0100 To: Adrian Farrel X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Mar 2007 09:18:38.0539 (UTC) FILETIME=[135729B0:01C76C63] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=387; t=1174555119; x=1175419119; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Updates=20to=20your=20slides |Sender:=20; bh=es4NoVZtng9eOVd6FIOE2pO0dZjV2i0ssCeo5bdGRRg=; b=mXeeZoXZ/guDNyBh26kjWayvDcV7jb36RIPP0vmRohAgpRsuEr4TsS4lvHYqXUsh1Jo3or7q KaHJ+dbAEW2Hykm83kBYpaxSZua3BJOwqiwHrvx3nlpm9PZwdNZm3kRf; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: pce-bounces@lists.ietf.org On Mar 22, 2007, at 9:55 AM, Adrian Farrel wrote: > Some of you (or was it just JP? JL ;-) > ) used updated slides in the meeting. > > Can you please mail them to me for upload to the meeting archive. > > Thanks, > > Adrian > > > _______________________________________________ > 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 Mar 22 05:23:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJWI-000594-TB; Thu, 22 Mar 2007 05:23:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJWH-00058n-4x for pce@ietf.org; Thu, 22 Mar 2007 05:23:41 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJWF-0001L5-QR for pce@ietf.org; Thu, 22 Mar 2007 05:23:41 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2007 10:23:39 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2M9NbIp005396 for ; Thu, 22 Mar 2007 10:23:37 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2M9Nalr023104 for ; Thu, 22 Mar 2007 09:23:37 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 10:23:36 +0100 Received: from [10.61.65.108] ([10.61.65.108]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 10:23:36 +0100 Message-ID: <46024B20.6090308@cisco.com> Date: Thu, 22 Mar 2007 05:23:44 -0400 From: Jon Parker User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2007 09:23:36.0173 (UTC) FILETIME=[C4BE81D0:01C76C63] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=416; t=1174555417; x=1175419417; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdparker@cisco.com; z=From:=20Jon=20Parker=20 |Subject:=20Re=3A=20[Pce]=20New=20WG=20ID=3A=20draft-oki-pce-pcep-xro-00. txt=20? |Sender:=20; bh=siIygxUplYCngmUMqtDiVqvVwhcruNZwqSVx57uGXso=; b=TqAOD9hwMO26bGfDBioXFrGHniYODS9GJUvizZQtX/G8jz/H/ZiQenqRRd7E+StiQq4v+Bn7 EKd6Wy12X6JbS+GsWg+gY9aTjJRlNTzg2RAqNFloLZk7S47kDt6dVErn; Authentication-Results: ams-dkim-1; header.From=jdparker@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: pce-bounces@lists.ietf.org In favor. Jon On 3/22/2007 4:32 AM JP Vasseur wrote: > Hi, > > There was a good support during the PCE WG meeting to adopt > draft-oki-pce-pcep-xro-00.txt as a WG document. > > Are you in favor / opposed adopting the ID as a WG ID ? > > 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 Mar 22 05:26:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJZ4-0006vq-Oe; Thu, 22 Mar 2007 05:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJZ2-0006tq-Gc for pce@ietf.org; Thu, 22 Mar 2007 05:26:32 -0400 Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJZ1-0001qd-6D for pce@ietf.org; Thu, 22 Mar 2007 05:26:32 -0400 Received: from [130.129.21.14] (dhcp-150e.ietf68.org [130.129.21.14]) (authenticated bits=0) by coe.drexel.edu (8.13.6/8.13.4) with ESMTP id l2M9SSmx019509 for ; Thu, 22 Mar 2007 05:28:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Message-Id: <2A8D1ADF-BD4D-4D23-8BDF-6AAD9B51C630@ece.drexel.edu> From: Jaudelice Cavalcante de Oliveira Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? Date: Thu, 22 Mar 2007 05:33:18 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: (0.015) AWL,HTML_MESSAGE X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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: , Content-Type: multipart/mixed; boundary="===============0901984481==" Errors-To: pce-bounces@lists.ietf.org --===============0901984481== Content-Type: multipart/alternative; boundary=Apple-Mail-4-827786182 --Apple-Mail-4-827786182 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed In favor... Jau. > > >> >> Hi, >> >> There was a good support during the PCE WG meeting to adopt draft- >> oki- >> >> pce-pcep-xro-00.txt as a WG document. >> >> Are you in favor / opposed adopting the ID as a WG ID ? >> >> 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 > Jaudelice C. de Oliveira, Assistant Professor ECE Dept., Drexel University 3141 Chestnut St., Bossone 312 Philadelphia, PA 19104 Phone: 215.895.2248 Fax: 215.895.1695 http://www.ece.drexel.edu/faculty/deoliveira/ --Apple-Mail-4-827786182 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
In = favor...

Jau.





There was a good support during the PCE WG meeting = to adopt draft-oki-
pce-pcep-xro-00.txt as a WG = document.

Are you in favor / opposed adopting the ID as a WG = ID ?

Thanks.

JP.

Pce mailing list




Pce mailing list


Jaudelice C. = de Oliveira, Assistant Professor
ECE Dept.,=A0Drexel = University
3141 Chestnut St., Bossone = 312
Philadelphia, PA 19104
Phone: 215.895.2248 Fax: = 215.895.1695

 =

= --Apple-Mail-4-827786182-- --===============0901984481== 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 --===============0901984481==-- From pce-bounces@lists.ietf.org Thu Mar 22 06:00:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJxj-0005bN-5C; Thu, 22 Mar 2007 05:52:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJxh-0005ae-PT for pce@lists.ietf.org; Thu, 22 Mar 2007 05:52:01 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJuT-0007cG-91 for pce@lists.ietf.org; Thu, 22 Mar 2007 05:48:59 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFA001GBTX4WK@usaga01-in.huawei.com> for pce@lists.ietf.org; Thu, 22 Mar 2007 02:48:40 -0700 (PDT) Received: from Lee736821 (dhcp-1414.ietf68.org [130.129.20.20]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFA00HNVTWZF6@usaga01-in.huawei.com> for pce@lists.ietf.org; Thu, 22 Mar 2007 02:48:40 -0700 (PDT) Date: Thu, 22 Mar 2007 03:48:31 -0600 From: Young Lee In-reply-to: To: pce@lists.ietf.org Message-id: <000e01c76c67$40761420$14148182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdsZDSymILm9A/IS16BkRV5PEAfvgAAwIRA X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f Subject: [Pce] RE: Pce Digest, Vol 31, Issue 19 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: , Errors-To: pce-bounces@lists.ietf.org Support. Young -----Original Message----- From: pce-request@lists.ietf.org [mailto:pce-request@lists.ietf.org] Sent: Thursday, March 22, 2007 3:27 AM To: pce@lists.ietf.org Subject: Pce Digest, Vol 31, Issue 19 Send Pce mailing list submissions to pce@lists.ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/pce or, via email, send a message with subject or body 'help' to pce-request@lists.ietf.org You can reach the person managing the list at pce-owner@lists.ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Pce digest..." Today's Topics: 1. New WG ID: draft-oki-pce-pcep-xro-00.txt ? (JP Vasseur) 2. RE: New WG ID: draft-oki-pce-pcep-xro-00.txt ? (Dean Cheng (dcheng)) 3. RE: New WG ID: draft-oki-pce-pcep-xro-00.txt ? (ASH, GERALD R, ATTLABS) 4. Re: New WG ID: draft-oki-pce-pcep-xro-00.txt ? (Tomonori TAKEDA) 5. Re: New WG ID: draft-oki-pce-pcep-xro-00.txt ? (Yuichi Ikejiri) 6. Updates to your slides (Adrian Farrel) 7. Re: New WG ID: draft-oki-pce-pcep-xro-00.txt ? (Dan Li) 8. Re: Updates to your slides (JP Vasseur) 9. RE: New WG ID: draft-oki-pce-pcep-xro-00.txt ? (LE ROUX Jean-Louis RD-CORE-LAN) 10. Re: New WG ID: draft-oki-pce-pcep-xro-00.txt ? (Jon Parker) 11. Re: New WG ID: draft-oki-pce-pcep-xro-00.txt ? (Jaudelice Cavalcante de Oliveira) ---------------------------------------------------------------------- Message: 1 Date: Thu, 22 Mar 2007 09:32:33 +0100 From: JP Vasseur Subject: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: pce@ietf.org Message-ID: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, There was a good support during the PCE WG meeting to adopt draft-oki- pce-pcep-xro-00.txt as a WG document. Are you in favor / opposed adopting the ID as a WG ID ? Thanks. JP. ------------------------------ Message: 2 Date: Thu, 22 Mar 2007 01:38:13 -0700 From: "Dean Cheng \(dcheng\)" Subject: RE: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: "Jean Philippe Vasseur \(jvasseur\)" , Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E033EC079@xmb-sjc-234.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" I'm in favor. Dean > -----Original Message----- > From: Jean Philippe Vasseur (jvasseur) > Sent: Thursday, March 22, 2007 1:33 AM > To: pce@ietf.org > Subject: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? > > Hi, > > There was a good support during the PCE WG meeting to adopt > draft-oki- pce-pcep-xro-00.txt as a WG document. > > Are you in favor / opposed adopting the ID as a WG ID ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > ------------------------------ Message: 3 Date: Thu, 22 Mar 2007 03:41:05 -0500 From: "ASH, GERALD R, ATTLABS" Subject: RE: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: "Jean Philippe Vasseur \(jvasseur\)" , Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8334@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset="US-ASCII" > Are you in favor / opposed adopting the ID as a WG ID? In favor. ------------------------------ Message: 4 Date: Thu, 22 Mar 2007 17:51:17 +0900 From: Tomonori TAKEDA Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: JP Vasseur , pce@ietf.org Message-ID: <6.0.0.20.2.20070322175058.07e0cc40@imf.m.ecl.ntt.co.jp> Content-Type: text/plain; charset="us-ascii"; format=flowed In favor. Tomonori At 17:32 07/03/22, JP Vasseur wrote: >Hi, > >There was a good support during the PCE WG meeting to adopt draft-oki- pce-pcep-xro-00.txt as a WG document. > >Are you in favor / opposed adopting the ID as a WG ID ? > >Thanks. > >JP. > >_______________________________________________ >Pce mailing list >Pce@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/pce > ------------------------------ Message: 5 Date: Thu, 22 Mar 2007 17:55:38 +0900 From: "Yuichi Ikejiri" Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: "JP Vasseur" , pce@ietf.org Message-ID: <074c01c76c5f$dc82efd0$92fa320a@araoa.ntt.com> Content-Type: text/plain; charset=ISO-8859-1 In favor. Yuichi ----- Original Message ----- From: "JP Vasseur" To: Sent: Thursday, March 22, 2007 5:32 PM Subject: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? > Hi, > > There was a good support during the PCE WG meeting to adopt draft-oki- > pce-pcep-xro-00.txt as a WG document. > > Are you in favor / opposed adopting the ID as a WG ID ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce ------------------------------ Message: 6 Date: Thu, 22 Mar 2007 08:55:36 -0000 From: "Adrian Farrel" Subject: [Pce] Updates to your slides To: Message-ID: <00d201c76c60$33a59ba0$ea138182@your029b8cecfe> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Some of you (or was it just JP?) used updated slides in the meeting. Can you please mail them to me for upload to the meeting archive. Thanks, Adrian ------------------------------ Message: 7 Date: Thu, 22 Mar 2007 16:51:28 +0800 From: Dan Li Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: JP Vasseur , pce@ietf.org Message-ID: <01d101c76c5f$4f16dda0$5300000a@dan> Content-Type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response In favor. Dan Li ----- Original Message ----- From: "JP Vasseur" To: Sent: Thursday, March 22, 2007 4:32 PM Subject: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? > Hi, > > There was a good support during the PCE WG meeting to adopt draft-oki- > pce-pcep-xro-00.txt as a WG document. > > Are you in favor / opposed adopting the ID as a WG ID ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce ------------------------------ Message: 8 Date: Thu, 22 Mar 2007 10:18:36 +0100 From: JP Vasseur Subject: Re: [Pce] Updates to your slides To: Adrian Farrel Cc: pce@ietf.org Message-ID: <131F18C9-23C9-4B36-998E-2C7C34A567F7@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 22, 2007, at 9:55 AM, Adrian Farrel wrote: > Some of you (or was it just JP? JL ;-) > ) used updated slides in the meeting. > > Can you please mail them to me for upload to the meeting archive. > > Thanks, > > Adrian > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce ------------------------------ Message: 9 Date: Thu, 22 Mar 2007 10:18:40 +0100 From: "LE ROUX Jean-Louis RD-CORE-LAN" Subject: RE: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: "JP Vasseur" , Message-ID: Content-Type: text/plain; charset="us-ascii" Hi all, I support this draft as WG doc Regards JL > > Hi, > > There was a good support during the PCE WG meeting to adopt draft-oki- > > pce-pcep-xro-00.txt as a WG document. > > Are you in favor / opposed adopting the ID as a WG ID ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > ------------------------------ Message: 10 Date: Thu, 22 Mar 2007 05:23:44 -0400 From: Jon Parker Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: JP Vasseur Cc: pce@ietf.org Message-ID: <46024B20.6090308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed In favor. Jon On 3/22/2007 4:32 AM JP Vasseur wrote: > Hi, > > There was a good support during the PCE WG meeting to adopt > draft-oki-pce-pcep-xro-00.txt as a WG document. > > Are you in favor / opposed adopting the ID as a WG ID ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > ------------------------------ Message: 11 Date: Thu, 22 Mar 2007 05:33:18 -0400 From: Jaudelice Cavalcante de Oliveira Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? To: pce@ietf.org Message-ID: <2A8D1ADF-BD4D-4D23-8BDF-6AAD9B51C630@ece.drexel.edu> Content-Type: text/plain; charset="us-ascii" In favor... Jau. > > >> >> Hi, >> >> There was a good support during the PCE WG meeting to adopt draft- >> oki- >> >> pce-pcep-xro-00.txt as a WG document. >> >> Are you in favor / opposed adopting the ID as a WG ID ? >> >> 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 > Jaudelice C. de Oliveira, Assistant Professor ECE Dept., Drexel University 3141 Chestnut St., Bossone 312 Philadelphia, PA 19104 Phone: 215.895.2248 Fax: 215.895.1695 http://www.ece.drexel.edu/faculty/deoliveira/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/pce/attachments/20070322/d0bbcae8/attachment. html ------------------------------ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce End of Pce Digest, Vol 31, Issue 19 *********************************** _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 22 08:28:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMOt-00007J-Pq; Thu, 22 Mar 2007 08:28:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMOs-0008Vg-UO for pce@ietf.org; Thu, 22 Mar 2007 08:28:14 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUMOr-0001Ff-Hz for pce@ietf.org; Thu, 22 Mar 2007 08:28:14 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 13:27:43 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Mar 2007 13:28:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next steps with draft-leroux-pce-of Thread-Index: AcdsfYljTni9eIHuTuaaoMDNTWlPZw== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 22 Mar 2007 12:27:43.0679 (UTC) FILETIME=[7D9224F0:01C76C7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Subject: [Pce] Next steps with draft-leroux-pce-of 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="===============0386236517==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0386236517== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76C7D.8EA6FD77" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76C7D.8EA6FD77 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Following the presentation and comments around draft-leroux-pce-of,=20 we had a discussion with Adrian JP and Jerry, and agreed to do the following: -Keep the OF in a separate draft (this draft). -Define the six mandatory OF listed in 4657 within this draft. We will submit a revised draft including the 6 objective functions within a couple of weeks. Regards, JL ------_=_NextPart_001_01C76C7D.8EA6FD77 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Next steps with draft-leroux-pce-of

Hi all,

Following the presentation and comments = around draft-leroux-pce-of,
we had a discussion with Adrian JP and = Jerry, and agreed to do the following:

-Keep the OF in a separate draft (this = draft).
-Define the six mandatory OF listed in = 4657 within this draft.

We will submit a revised draft = including the 6 objective functions within a couple of weeks.

Regards,

JL

------_=_NextPart_001_01C76C7D.8EA6FD77-- --===============0386236517== 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 --===============0386236517==-- From pce-bounces@lists.ietf.org Thu Mar 22 19:14:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUWUR-000815-Ku; Thu, 22 Mar 2007 19:14:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUWUQ-00080r-Fa for pce@ietf.org; Thu, 22 Mar 2007 19:14:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUWUN-0004xP-2k for pce@ietf.org; Thu, 22 Mar 2007 19:14:38 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2007 16:14:36 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2MNEYaZ026341 for ; Thu, 22 Mar 2007 16:14:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2MNEKAA005478 for ; Thu, 22 Mar 2007 23:14:34 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 19:14:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? Date: Thu, 22 Mar 2007 19:11:02 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? thread-index: AcdsXPT1GPSty9GFRo2FImrPSXwfSwAelmUg References: From: "Zafar Ali \(zali\)" To: "Jean Philippe Vasseur \(jvasseur\)" , X-OriginalArrivalTime: 22 Mar 2007 23:14:26.0562 (UTC) FILETIME=[D5E43620:01C76CD7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=630; t=1174605274; x=1175469274; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20 |Subject:=20RE=3A=20[Pce]=20New=20WG=20ID=3A=20draft-oki-pce-pcep-xro-00. txt=20? |Sender:=20; bh=eYQfG+UuifslntqR9Ym85OreyxZC4E+B1EmLDgGVEbo=; b=pSpxKl7AwsvZss4NiH4Wgr6VKaUgcnwh6A+/cQFygOu/4XKOU11N6YVMyj+M5x6qSy7lVGIu EuVMquN+yGQ+KtwIol3x+Yjr1BIiywmkZCVpwqHz8Vbasy+yKR+1vR4v; Authentication-Results: sj-dkim-5; header.From=zali@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Errors-To: pce-bounces@lists.ietf.org In favor.=20 Thanks Regards.. Zafar =20 > -----Original Message----- > From: Jean Philippe Vasseur (jvasseur)=20 > Sent: Thursday, March 22, 2007 4:33 AM > To: pce@ietf.org > Subject: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? >=20 > Hi, >=20 > There was a good support during the PCE WG meeting to adopt=20 > draft-oki- pce-pcep-xro-00.txt as a WG document. >=20 > Are you in favor / opposed adopting the ID as a WG ID ? >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Mar 26 07:08:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVn3C-0001s4-FS; Mon, 26 Mar 2007 07:07:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVn3B-0001rs-D3 for pce@ietf.org; Mon, 26 Mar 2007 07:07:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVn36-0007LP-Vh for pce@ietf.org; Mon, 26 Mar 2007 07:07:45 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Mar 2007 07:07:39 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2QB7c2S025757 for ; Mon, 26 Mar 2007 07:07:38 -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 l2QB7clG021186 for ; Mon, 26 Mar 2007 11:07:38 GMT 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.1830); Mon, 26 Mar 2007 07:07:38 -0400 Received: from [10.86.104.180] ([10.86.104.180]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 07:07:38 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: References: <34AA8CEA-CB65-4A17-BC4E-F90487343CF4@cisco.com> From: JP Vasseur Subject: Fwd: [Pce] PCEP Codepoints Date: Fri, 23 Mar 2007 13:58:04 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 Mar 2007 11:07:38.0129 (UTC) FILETIME=[F6E46810:01C76F96] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4992; t=1174907258; x=1175771258; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[Pce]=20PCEP=20Codepoints |Sender:=20 |To:=20pce@ietf.org; bh=A5yNdb2W7LBaHqZQr7r0VWkT64VND2owI0q7ajG1gjw=; b=bOqp4WTY15oX4sA34SZdxoITiKLTd7Up5TO6sRceb90IV07X3J4oJ4/w1fPR+EiJky/smeNR JenlXWhWD5Eb3oYPZhf/fo8D313OpzcD87bvE4vf8uLs+w4ncwf5TYPG; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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: , Content-Type: multipart/mixed; boundary="===============1073748265==" Errors-To: pce-bounces@lists.ietf.org --===============1073748265== Content-Type: multipart/alternative; boundary=Apple-Mail-1-944472444 --Apple-Mail-1-944472444 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: JP Vasseur > Date: March 2, 2007 5:28:12 PM EST > To: pce@ietf.org > Subject: [Pce] PCEP Codepoints > > Hi, > > As you know, Adrian generously offered to maintain the temporary > PCEP registry of codepoints at http://www.olddog.co.uk/pce.htm > until IANA takes over. > > Since there are several IDs defining new PCEP messages and objects, > if you have such IDs, could you please send me the code-points so > that we could update it accordingly ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-1-944472444 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

= --Apple-Mail-1-944472444-- --===============1073748265== 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 --===============1073748265==-- From pce-bounces@lists.ietf.org Tue Mar 27 06:32:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW8yj-0007CX-6x; Tue, 27 Mar 2007 06:32:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW8yh-0007CS-AB for pce@ietf.org; Tue, 27 Mar 2007 06:32:35 -0400 Received: from mgw2.noc.ntt.com ([210.160.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW8yf-0003P7-Nq for pce@ietf.org; Tue, 27 Mar 2007 06:32:35 -0400 Received: from mop3.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id l2RAWGb4007219 for ; Tue, 27 Mar 2007 19:32:18 +0900 (JST) Received: from mip3.noc.ntt.com (mvi1.noc.ntt.com) by mop3.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0JFK005DL59QDZ@ntt.com> for pce@ietf.org; Tue, 27 Mar 2007 19:32:17 +0900 (JST) Date: Tue, 27 Mar 2007 19:32:15 +0900 From: "Kensuke SHINDOME" X-Face: #I"_L&@Qb/[xD^oDn)qcDj|Q4,e?naHQKntl(Z_`\6&8M(/j65Q,}dNKTJ0; )60$/#!$r:L d`@UE=]%'5IXiP#vre~{? Subject: Re: [Pce] New WG ID: draft-oki-pce-pcep-xro-00.txt ? In-reply-to: To: pce@ietf.org Message-id: Organization: Innovative IP Architecture Center, NTT Communications MIME-version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-type: text/plain; charset=US-ASCII User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) LIMIT/1.14.7 (Fujiidera) APEL/10.6 Emacs/21.1 (i386-mingw-nt5.0.2195) MULE/5.0 (SAKAKI) Meadow/2.00pre2 (KIKYOU) References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: pce-bounces@lists.ietf.org In favor. Thanks, At Thu, 22 Mar 2007 09:32:33 +0100, "JP Vasseur" wrote: > > Hi, > > There was a good support during the PCE WG meeting to adopt draft-oki- > pce-pcep-xro-00.txt as a WG document. > > Are you in favor / opposed adopting the ID as a WG ID ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce -- Kensuke Shindome _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Mar 28 04:57:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWTxe-0007W7-Q4; Wed, 28 Mar 2007 04:56:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWTxd-0007VB-Az for pce@ietf.org; Wed, 28 Mar 2007 04:56:53 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee01s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWTxc-00060A-21 for pce@ietf.org; Wed, 28 Mar 2007 04:56:53 -0400 Received: from wpwuee01s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id D91EDF4072 for ; Wed, 28 Mar 2007 10:56:48 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id C32EFF4077 for ; Wed, 28 Mar 2007 10:56:48 +0200 (CEST) Message-ID: <004b01c77116$ebb07de0$15600337@AOFR11476> From: "fabien.verhaeghe" To: Date: Wed, 28 Mar 2007 10:56:05 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Pce] Switching type Constraint in 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: , Content-Type: multipart/mixed; boundary="===============0839097647==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0839097647== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01C77127.AEB3CA30" This is a multi-part message in MIME format. ------=_NextPart_000_0048_01C77127.AEB3CA30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In RFC4657 one of the generic requirement concerns the support of = switching/encoding type constraint for GMPLS. Is there any ongoing work about this item? Thanks Fabien ------=_NextPart_000_0048_01C77127.AEB3CA30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
In RFC4657 one of the generic = requirement concerns=20 the support of switching/encoding type constraint
for GMPLS.
 
Is there any ongoing work about this=20 item?
 
Thanks
Fabien
 
------=_NextPart_000_0048_01C77127.AEB3CA30-- --===============0839097647== 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 --===============0839097647==-- From pce-bounces@lists.ietf.org Wed Mar 28 05:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWUfn-0007RR-LS; Wed, 28 Mar 2007 05:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWUfm-0007RG-KU for pce@ietf.org; Wed, 28 Mar 2007 05:42:30 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWUfk-0000TT-On for pce@ietf.org; Wed, 28 Mar 2007 05:42:30 -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 <0JFL00CEEXCJEK@szxga02-in.huawei.com> for pce@ietf.org; Wed, 28 Mar 2007 17:36:20 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JFL00HXSXCJZZ@szxga02-in.huawei.com> for pce@ietf.org; Wed, 28 Mar 2007 17:36:19 +0800 (CST) Received: from l37133 ([10.70.77.160]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFL0010SXCIJP@szxml03-in.huawei.com> for pce@ietf.org; Wed, 28 Mar 2007 17:36:19 +0800 (CST) Date: Wed, 28 Mar 2007 17:36:18 +0800 From: Dan Li Subject: Re: [Pce] Switching type Constraint in PCEP To: "fabien.verhaeghe" , pce@ietf.org Message-id: <00e601c7711c$89bf3120$a04d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-Priority: 3 X-MSMail-priority: Normal References: <004b01c77116$ebb07de0$15600337@AOFR11476> X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Content-Type: multipart/mixed; boundary="===============1929018586==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1929018586== Content-type: multipart/alternative; boundary="Boundary_(ID_IF/fxn2FRr9pn/v/MVaBbA)" This is a multi-part message in MIME format. --Boundary_(ID_IF/fxn2FRr9pn/v/MVaBbA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Fabien, There is a draft "draft-otani-ccamp-gmpls-cspf-constraints-05.txt" which may relate to this issue. But the switching/encoding type may be considered as an attribute of a TE-link, so I doubt it has something to do with the PCEP. Regards, Dan ----- Original Message ----- From: fabien.verhaeghe To: pce@ietf.org Sent: Wednesday, March 28, 2007 4:56 PM Subject: [Pce] Switching type Constraint in PCEP Hi, In RFC4657 one of the generic requirement concerns the support of switching/encoding type constraint for GMPLS. Is there any ongoing work about this item? Thanks Fabien ------------------------------------------------------------------------------ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --Boundary_(ID_IF/fxn2FRr9pn/v/MVaBbA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Fabien,
 
There is a draft "draft-otani-ccamp-gmpls-cspf-constraints-05.txt" which may relate to this issue. But the switching/encoding type may be considered as an attribute of a TE-link, so I doubt it has something to do with the PCEP.
 
Regards,
 
Dan
 
----- Original Message -----
Sent: Wednesday, March 28, 2007 4:56 PM
Subject: [Pce] Switching type Constraint in PCEP

Hi,
 
In RFC4657 one of the generic requirement concerns the support of switching/encoding type constraint
for GMPLS.
 
Is there any ongoing work about this item?
 
Thanks
Fabien
 

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--Boundary_(ID_IF/fxn2FRr9pn/v/MVaBbA)-- --===============1929018586== 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 --===============1929018586==-- From pce-bounces@lists.ietf.org Wed Mar 28 06:19:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWVEq-000129-Kk; Wed, 28 Mar 2007 06:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWVEp-0000yR-GX for pce@ietf.org; Wed, 28 Mar 2007 06:18:43 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWVEj-0001ud-8c for pce@ietf.org; Wed, 28 Mar 2007 06:18:43 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 12:18:36 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Pce] Switching type Constraint in PCEP Date: Wed, 28 Mar 2007 12:18:33 +0200 Message-ID: In-Reply-To: <00e601c7711c$89bf3120$a04d460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Switching type Constraint in PCEP Thread-Index: AcdxInCY2lVoc5F0R02ZX6o8S5mG7Q== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Dan Li" , "fabien.verhaeghe" , X-OriginalArrivalTime: 28 Mar 2007 10:18:36.0032 (UTC) FILETIME=[72178800:01C77122] X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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: , Content-Type: multipart/mixed; boundary="===============0952916865==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0952916865== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77122.716A43A7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77122.716A43A7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fabien, =20 The switching type/encoding type used to be carried in earlier versions = of PCEP ( GENERALIZED LABEL OBJECT in = http://www.watersprings.org/pub/id/draft-vasseur-pce-pcep-00.txt). We decided to remove it from the base spec as this is application = specific. This will be covered in a separate document (for instance = switching/encoding type could be encoded in a optional TLV of the LSPA = object). =20 Best Regards, =20 JL =20 =20 ________________________________ De : Dan Li [mailto:danli@huawei.com]=20 Envoy=E9 : mercredi 28 mars 2007 11:36 =C0 : fabien.verhaeghe; pce@ietf.org Objet : Re: [Pce] Switching type Constraint in PCEP =09 =09 Hi Fabien, =20 There is a draft "draft-otani-ccamp-gmpls-cspf-constraints-05.txt" = which may relate to this issue. But the switching/encoding type may be = considered as an attribute of a TE-link, so I doubt it has something to = do with the PCEP. =20 Regards, =20 Dan =20 ----- Original Message -----=20 From: fabien.verhaeghe =20 To: pce@ietf.org=20 Sent: Wednesday, March 28, 2007 4:56 PM Subject: [Pce] Switching type Constraint in PCEP Hi, =20 In RFC4657 one of the generic requirement concerns the support of = switching/encoding type constraint for GMPLS. =20 Is there any ongoing work about this item? =20 Thanks Fabien =20 =09 ________________________________ =09 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =09 ------_=_NextPart_001_01C77122.716A43A7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Fabien,
 
The switching type/encoding type used to be = carried in=20 earlier versions of PCEP
( GENERALIZED LABEL OBJECT in http://www.watersprings.org/pub/id/draft-vasseur-pce-pcep-00.txt).
We decided to remove it from the base spec = as this is=20 application specific.
This will be covered in a separate document = (for instance=20 switching/encoding type could be encoded in a optional TLV of the LSPA=20 object).
 
Best Regards,
 
JL
 
 

De : Dan Li = [mailto:danli@huawei.com]=20
Envoy=E9 : mercredi 28 mars 2007 = 11:36
=C0 :=20 fabien.verhaeghe; pce@ietf.org
Objet : Re: [Pce] = Switching type=20 Constraint in PCEP

Hi Fabien,
 
There is a draft = "draft-otani-ccamp-gmpls-cspf-constraints-05.txt" which=20 may relate to this issue. But the switching/encoding type may be = considered as=20 an attribute of a TE-link, so I doubt it = has something to do=20 with the PCEP.
 
Regards,
 
Dan
 
----- Original Message = -----
From: fabien.verhaeghe =
Sent: Wednesday, = March 28, 2007 4:56=20 PM
Subject: [Pce] = Switching type Constraint in=20 PCEP

Hi,
 
In RFC4657 one of the generic = requirement=20 concerns the support of switching/encoding type = constraint
for GMPLS.
 
Is there any ongoing work about = this=20 item?
 
Thanks
Fabien
 

_______________________________________________
Pce = mailing=20 list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce
------_=_NextPart_001_01C77122.716A43A7-- --===============0952916865== 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 --===============0952916865==-- From pce-bounces@lists.ietf.org Wed Mar 28 07:48:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWWcG-0003XM-Fb; Wed, 28 Mar 2007 07:47:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWWcE-0003Wh-Rc for pce@ietf.org; Wed, 28 Mar 2007 07:46:58 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWWc7-0007T6-Bm for pce@ietf.org; Wed, 28 Mar 2007 07:46:58 -0400 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1HWWc4-00059l-E3 for pce@ietf.org; Wed, 28 Mar 2007 11:46:48 +0000 Received: from your029b8cecfe ([217.158.132.13] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Mar 2007 12:46:46 +0100 Message-ID: <0cb301c7712e$c1f03e10$ea138182@your029b8cecfe> From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "Dan Li" , "fabien.verhaeghe" , References: Subject: Re: [Pce] Switching type Constraint in PCEP Date: Wed, 28 Mar 2007 12:46:33 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 28 Mar 2007 11:46:47.0204 (UTC) FILETIME=[C3E04E40:01C7712E] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 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: , Errors-To: pce-bounces@lists.ietf.org Just to complete the sequence of referenced I-Ds... http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-04.txt discusses the requirements for multi-layer path computation (while http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-03.txt gives a framework for the use of PCE in a multi-layer network). Section 5.1.3 of draft-ietf-pce-inter-layer-req-04.txt describes the specific requirements that you mention for switching type. And section 5.1.4 discusses adaptation capabilities. We have not, so far, added a requirement for encoding type and are not clear whether this is a constraint that is necessary. We'd be interested to have this discussion. Before the Prague meeting, Eiji Oki started to put together the necessary protocol extensions in support of this work, but we held off publication because the base PCEP needed to advance a bit more. I guess this sounds like the community is ready for this draft now. Cheers, Adrian ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Dan Li" ; "fabien.verhaeghe" ; Sent: Wednesday, March 28, 2007 11:18 AM Subject: RE: [Pce] Switching type Constraint in PCEP Hi Fabien, The switching type/encoding type used to be carried in earlier versions of PCEP ( GENERALIZED LABEL OBJECT in http://www.watersprings.org/pub/id/draft-vasseur-pce-pcep-00.txt). We decided to remove it from the base spec as this is application specific. This will be covered in a separate document (for instance switching/encoding type could be encoded in a optional TLV of the LSPA object). Best Regards, JL ________________________________ De : Dan Li [mailto:danli@huawei.com] Envoyé : mercredi 28 mars 2007 11:36 À : fabien.verhaeghe; pce@ietf.org Objet : Re: [Pce] Switching type Constraint in PCEP Hi Fabien, There is a draft "draft-otani-ccamp-gmpls-cspf-constraints-05.txt" which may relate to this issue. But the switching/encoding type may be considered as an attribute of a TE-link, so I doubt it has something to do with the PCEP. Regards, Dan ----- Original Message ----- From: fabien.verhaeghe To: pce@ietf.org Sent: Wednesday, March 28, 2007 4:56 PM Subject: [Pce] Switching type Constraint in PCEP Hi, In RFC4657 one of the generic requirement concerns the support of switching/encoding type constraint for GMPLS. Is there any ongoing work about this item? Thanks Fabien ________________________________ _______________________________________________ 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 Wed Mar 28 10:07:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWYnN-0002Jo-3O; Wed, 28 Mar 2007 10:06:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWYnL-0002Jj-W3 for pce@ietf.org; Wed, 28 Mar 2007 10:06:35 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee01s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWYnG-0001Wi-Fn for pce@ietf.org; Wed, 28 Mar 2007 10:06:35 -0400 Received: from wpwuee01s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 9B297F4085; Wed, 28 Mar 2007 16:06:27 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 79DE6F4089; Wed, 28 Mar 2007 16:06:27 +0200 (CEST) Message-ID: <002a01c77142$2cda9050$15600337@AOFR11476> From: "fabien.verhaeghe" To: "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , "Dan Li" , References: <0cb301c7712e$c1f03e10$ea138182@your029b8cecfe> Subject: Re: [Pce] Switching type Constraint in PCEP Date: Wed, 28 Mar 2007 16:05:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: ClamAV using ClamSMTP Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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: , Errors-To: pce-bounces@lists.ietf.org Hi Dan, JL, Adrian, Reading the generic and inter layer requirement documents it is not clear= to=20 me if Switching Type is really specific to inter layer application. As far as I understand inter-layer requirement refers to path computation= =20 which result path may comprise multiple layer technologies. Though I understand Switching type is required in this context, it is als= o=20 required for mono layer path computation in a multi-layer environment (e.g. to computate a Lambda path using a TE Database that contains also T= DM=20 TE Links). So it is more a GMPLS specific requirement to me. Acually it is not clear to me what is the scope of generic and "applicati= on=20 specific" requirements. Generic Requirement RFC4657 section 5.1.16 mention Switching and encoding= =20 type as "GMPLS specific requirements". Does it mean "GMPLS specific" is "considered as generic? Concerning the necessity of "encoding type" in PCEP I have to admit that = I'm=20 not sure to correctly understand the meaning of this parameter in the GMPLS architecture :-). What I understand at lea= st=20 is that it is both an interface and an LSP property, so from this it seems to be required in PCEP. I would be interested to see discussion about encoding type requirement i= n=20 PCEP cause it may clarify the encoding type meaning to me ;-). Regards Fabien ----- Original Message -----=20 From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" ;=20 "Dan Li" ; "fabien.verhaeghe"=20 ; Sent: Wednesday, March 28, 2007 1:46 PM Subject: Re: [Pce] Switching type Constraint in PCEP Just to complete the sequence of referenced I-Ds... http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-04.txt discusses the requirements for multi-layer path computation (while http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-03.tx= t gives a framework for the use of PCE in a multi-layer network). Section 5.1.3 of draft-ietf-pce-inter-layer-req-04.txt describes the specific requirements that you mention for switching type. And section 5.= 1.4 discusses adaptation capabilities. We have not, so far, added a requirement for encoding type and are not cl= ear whether this is a constraint that is necessary. We'd be interested to hav= e this discussion. Before the Prague meeting, Eiji Oki started to put together the necessary protocol extensions in support of this work, but we held off publication because the base PCEP needed to advance a bit more. I guess this sounds l= ike the community is ready for this draft now. Cheers, Adrian ----- Original Message -----=20 From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Dan Li" ; "fabien.verhaeghe" ; Sent: Wednesday, March 28, 2007 11:18 AM Subject: RE: [Pce] Switching type Constraint in PCEP Hi Fabien, The switching type/encoding type used to be carried in earlier versions o= f PCEP ( GENERALIZED LABEL OBJECT in http://www.watersprings.org/pub/id/draft-vasseur-pce-pcep-00.txt). We decided to remove it from the base spec as this is application specifi= c. This will be covered in a separate document (for instance switching/encod= ing type could be encoded in a optional TLV of the LSPA object). Best Regards, JL ________________________________ De : Dan Li [mailto:danli@huawei.com] Envoy=E9 : mercredi 28 mars 2007 11:36 =C0 : fabien.verhaeghe; pce@ietf.org Objet : Re: [Pce] Switching type Constraint in PCEP Hi Fabien, There is a draft "draft-otani-ccamp-gmpls-cspf-constraints-05.txt" which = may relate to this issue. But the switching/encoding type may be considered a= s an attribute of a TE-link, so I doubt it has something to do with the PCE= P. Regards, Dan ----- Original Message -----=20 From: fabien.verhaeghe To: pce@ietf.org Sent: Wednesday, March 28, 2007 4:56 PM Subject: [Pce] Switching type Constraint in PCEP Hi, In RFC4657 one of the generic requirement concerns the support of switching/encoding type constraint for GMPLS. Is there any ongoing work about this item? Thanks Fabien ________________________________ _______________________________________________ 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 Thu Mar 29 11:45:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwnk-0002zZ-2O; Thu, 29 Mar 2007 11:44:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwni-0002zT-IV for pce@ietf.org; Thu, 29 Mar 2007 11:44:34 -0400 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWwne-0002NR-GS for pce@ietf.org; Thu, 29 Mar 2007 11:44:34 -0400 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1HWwnd-0004S7-Me for pce@ietf.org; Thu, 29 Mar 2007 15:44:29 +0000 Received: from your029b8cecfe ([217.158.132.35] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Mar 2007 16:44:28 +0100 Message-ID: <0f4101c77219$08ec6f10$ea138182@your029b8cecfe> From: "Adrian Farrel" To: "fabien.verhaeghe" , "LE ROUX Jean-Louis RD-CORE-LAN" , "Dan Li" , References: <0cb301c7712e$c1f03e10$ea138182@your029b8cecfe> <002a01c77142$2cda9050$15600337@AOFR11476> Subject: Re: [Pce] Switching type Constraint in PCEP Date: Thu, 29 Mar 2007 16:18:53 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 29 Mar 2007 15:44:28.0934 (UTC) FILETIME=[22F15A60:01C77219] X-Originating-Heisenberg-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 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: , Errors-To: pce-bounces@lists.ietf.org Hi Fabien, > Reading the generic and inter layer requirement documents it is not clear > to me if Switching Type is really specific to inter layer application. > As far as I understand inter-layer requirement refers to path computation > which result path may comprise multiple layer technologies. > Though I understand Switching type is required in this context, it is also > required for mono layer path computation in a multi-layer environment > (e.g. to computate a Lambda path using a TE Database that contains also > TDM TE Links). > So it is more a GMPLS specific requirement to me. I think you are correct. That is, the switching type constraint is required in the multi-layer context, but it may have wider applicability. Provided that the multi-layer work progress quite quickly, I would suggest that it is convenient to group all of the protocol extensions together. You can then select from the set of optional objects as necessary for your application. I would hope that you would provide your review input to the multi-layer work to ensure that the protocol extensions give you what you need. On the other hand, if the multi-layer work seems to get stuck or held up, then I would understand you pushing to get the "GMPLS-specific" extensions done separately. > Acually it is not clear to me what is the scope of generic and > "application specific" requirements. Generic Requirement RFC4657 section > 5.1.16 > mention Switching and encoding type as "GMPLS specific requirements". > Does it mean "GMPLS specific" is "considered as generic? Hmmm. This is a line we have not succeeded in drawing very clearly. However, where we seem to have arrived is that the PCEP I-D contains the protocol definition and "core" functional units. Other units that were identified in 4657 (such as XRO, objective funcions, ...) are going into seperate I-Ds. Following that model, the GMPLS-specific work definitely goes into a separate draft. As above, I am comfortable for that to be in the multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to help keep the number of I-Ds manageable. > Concerning the necessity of "encoding type" in PCEP I have to admit that > I'm not sure to correctly understand the meaning of this parameter in the > GMPLS > architecture :-). I think this puts you in the majority! > What I understand at least is that it is both an interface and > an LSP property, so from this it seems to be required in PCEP. > I would be interested to see discussion about encoding type > requirement in PCEP cause it may clarify the encoding type meaning to me > ;-). So my view (other will surely correct me :-) is that encoding type is only needed where the signal is unpacked for some reason. Typically, this only happens at end points, so the PCE function is to ensure that the destination interface is capable of decoding the signal and delivering the data. In general, it has been considered that the destination capabilities are either known to the ingress (guaranteed LSP setup success - you wouldn't even bother trying to set up an LSP to someone you knew couldn't understand you) or are not known in which case the LSP will either succeed or fail (but no amount of re-routing will help). Now, it *is* possible that different interfaces on the egress have different levels of support for encoding types, but this has generally been considered as very advanced and not worth optimising for. However, recent discussion has suggested that in certain technologies, signal regeneration also requires knowledge of the encoding type. This would certainly expand the requirement for PCE to know about encoding type. I am not sure about the hardware specifics here and perhaps someone can enlighten us. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 29 15:32:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0MH-0003Ys-VB; Thu, 29 Mar 2007 15:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0MG-0003Yn-Uh for pce@ietf.org; Thu, 29 Mar 2007 15:32:28 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX0ME-0003YI-Mu for pce@ietf.org; Thu, 29 Mar 2007 15:32:28 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2007 15:32:23 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2TJWMSB020632; Thu, 29 Mar 2007 15:32:22 -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 l2TJWHGf002261; Thu, 29 Mar 2007 19:32:18 GMT 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.1830); Thu, 29 Mar 2007 15:32:17 -0400 Received: from [161.44.113.239] ([161.44.113.239]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 15:32:17 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8A700039-B848-4CB0-9AD3-62BD86B61240@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 29 Mar 2007 15:32:18 -0400 To: PAPADIMITRIOU Dimitri X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 29 Mar 2007 19:32:17.0439 (UTC) FILETIME=[F601B2F0:01C77238] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=142; t=1175196742; x=1176060742; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20ID=20Monitoring |Sender:=20 |To:=20PAPADIMITRIOU=20Dimitri=20; bh=s9zollUudKux/hkNvIF0+GnP9a38v8ESkNgJcMbt/d8=; b=JfpfDmoee+helG6pFUs7iBO3o+AEVBJDcaffo7Yh9iN/I+syQOggZ1ny1qaJvxs3IE0Nj5Wt taBA8lmQYcQTGUNWs/ZkAlNxHJcL8DfpmMCrs040AD7boGLj8eIlwHne; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: pce@ietf.org Subject: [Pce] ID Monitoring 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: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, In order to move forward here ... Could you list the set of items for which you'd like a clarification ? Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Mar 29 19:46:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX4J2-0000Bk-2S; Thu, 29 Mar 2007 19:45:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX4J0-000059-My for pce@ietf.org; Thu, 29 Mar 2007 19:45:22 -0400 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX4Iy-0002Ob-Dz for pce@ietf.org; Thu, 29 Mar 2007 19:45:22 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id AA548EC878; Fri, 30 Mar 2007 08:45:04 +0900 (JST) Received: from platinum.inc.kddilabs.jp (unknown [2001:200:601:1300:20a:48ff:fe12:3f1]) by mandala.kddilabs.jp (Postfix) with ESMTP id D5146EC86F; Fri, 30 Mar 2007 08:45:03 +0900 (JST) Received: from [IPv6:2001:200:601:1e02:0:5efe:ac13:5712] (unknown [IPv6:2001:200:601:1e02:0:5efe:ac13:5712]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 73756578107; Fri, 30 Mar 2007 08:44:58 +0900 (JST) Message-ID: <460C4F77.7040309@kddilabs.jp> Date: Fri, 30 Mar 2007 08:44:55 +0900 From: Tomohiro Otani User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Switching type Constraint in PCEP References: <0cb301c7712e$c1f03e10$ea138182@your029b8cecfe> <002a01c77142$2cda9050$15600337@AOFR11476> <0f4101c77219$08ec6f10$ea138182@your029b8cecfe> In-Reply-To: <0f4101c77219$08ec6f10$ea138182@your029b8cecfe> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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: , Errors-To: pce-bounces@lists.ietf.org Hi Fabien and Adrian, Looking at the discussion, path computation itself and a protocol staff such as PCEP are a different thing. I believe, touch upon by Dan, that our cspf draft is a kind of guideline how to consider GMPLS-specific constrains including encoding type for path computation. I hope that the cspf draft help Fabien to understand parameters. If you need any help for GMPLS specific extensions, please let me know. With best regards, Tomo Adrian Farrel wrote: > Hi Fabien, > >> Reading the generic and inter layer requirement documents it is not >> clear to me if Switching Type is really specific to inter layer >> application. >> As far as I understand inter-layer requirement refers to path >> computation which result path may comprise multiple layer technologies. >> Though I understand Switching type is required in this context, it is >> also >> required for mono layer path computation in a multi-layer environment >> (e.g. to computate a Lambda path using a TE Database that contains >> also TDM TE Links). >> So it is more a GMPLS specific requirement to me. > > I think you are correct. That is, the switching type constraint is > required in the multi-layer context, but it may have wider applicability. > > Provided that the multi-layer work progress quite quickly, I would > suggest that it is convenient to group all of the protocol extensions > together. You can then select from the set of optional objects as > necessary for your application. I would hope that you would provide your > review input to the multi-layer work to ensure that the protocol > extensions give you what you need. > > On the other hand, if the multi-layer work seems to get stuck or held > up, then I would understand you pushing to get the "GMPLS-specific" > extensions done separately. > >> Acually it is not clear to me what is the scope of generic and >> "application specific" requirements. Generic Requirement RFC4657 >> section 5.1.16 >> mention Switching and encoding type as "GMPLS specific requirements". >> Does it mean "GMPLS specific" is "considered as generic? > > Hmmm. > This is a line we have not succeeded in drawing very clearly. > > However, where we seem to have arrived is that the PCEP I-D contains the > protocol definition and "core" functional units. Other units that were > identified in 4657 (such as XRO, objective funcions, ...) are going into > seperate I-Ds. Following that model, the GMPLS-specific work definitely > goes into a separate draft. As above, I am comfortable for that to be in > the multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to > help keep the number of I-Ds manageable. > >> Concerning the necessity of "encoding type" in PCEP I have to admit >> that I'm not sure to correctly understand the meaning of this >> parameter in the GMPLS >> architecture :-). > > I think this puts you in the majority! > >> What I understand at least is that it is both an interface and >> an LSP property, so from this it seems to be required in PCEP. >> I would be interested to see discussion about encoding type >> requirement in PCEP cause it may clarify the encoding type meaning to >> me ;-). > > So my view (other will surely correct me :-) is that encoding type is > only needed where the signal is unpacked for some reason. Typically, > this only happens at end points, so the PCE function is to ensure that > the destination interface is capable of decoding the signal and > delivering the data. In general, it has been considered that the > destination capabilities are either known to the ingress (guaranteed LSP > setup success - you wouldn't even bother trying to set up an LSP to > someone you knew couldn't understand you) or are not known in which case > the LSP will either succeed or fail (but no amount of re-routing will > help). Now, it *is* possible that different interfaces on the egress > have different levels of support for encoding types, but this has > generally been considered as very advanced and not worth optimising for. > > However, recent discussion has suggested that in certain technologies, > signal regeneration also requires knowledge of the encoding type. This > would certainly expand the requirement for PCE to know about encoding > type. I am not sure about the hardware specifics here and perhaps > someone can enlighten us. > > Cheers, > Adrian > > > _______________________________________________ > 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 Mar 30 11:08:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXIhe-0008Q2-Rx; Fri, 30 Mar 2007 11:07:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXIhd-0008Px-F2 for pce@ietf.org; Fri, 30 Mar 2007 11:07:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXIhc-0004pV-6d for pce@ietf.org; Fri, 30 Mar 2007 11:07:45 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2007 11:07:44 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2UF7heY002863; Fri, 30 Mar 2007 11:07:43 -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 l2UF7blO007758; Fri, 30 Mar 2007 15:07:43 GMT 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.1830); Fri, 30 Mar 2007 11:07:37 -0400 Received: from [161.44.115.55] ([161.44.115.55]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 11:07:36 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: Eiji Oki , Adrian Farrel Message-Id: From: JP Vasseur Date: Fri, 30 Mar 2007 11:07:38 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Mar 2007 15:07:36.0896 (UTC) FILETIME=[26E0E400:01C772DD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=980; t=1175267264; x=1176131264; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20New=20Working=20Group=20document |Sender:=20 |To:=20Eiji=20Oki=20, =20Adrian=20Farrel=20; bh=vmu8yMwD7+Vwl/3ScSW167+WY/WPIvzUGP2BYg/g1e8=; b=KxkyhHIXxWVRXj+jYx5FmNOrmFRoP0WdSgS1mgGC3mpw8yGOILhT7VnGkEz2lZ1DkUUcmq7x 4GphF1XGjdj5N4pAhAnQGMvgLjYRXsdFfq94G8ZBN51jSdfYYAORmu1y; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.8 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: pce@ietf.org Subject: [Pce] New Working Group 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="===============1643728065==" Errors-To: pce-bounces@lists.ietf.org --===============1643728065== Content-Type: multipart/alternative; boundary=Apple-Mail-95--608436899 --Apple-Mail-95--608436899 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Considering the good support for adopting draft-oki-pce-pcep- xro-00.txt as a WG document, authors, please republish as draft-ietf- pce-pcep-xro-00.txt Thanks. JP. --Apple-Mail-95--608436899 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

Considering the good = support for adopting draft-oki-pce-pcep-xro-00.txt=A0=A0as = a WG document, authors, please republish = as=A0draft-ietf-pce-pcep-xro-00.txt=A0

Thanks.

JP.
= --Apple-Mail-95--608436899-- --===============1643728065== 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 --===============1643728065==--