From pce-bounces@ietf.org Mon Feb 2 00:44:12 2009 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9725F3A69D7; Mon, 2 Feb 2009 00:44:12 -0800 (PST) X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984A93A69D7 for ; Mon, 2 Feb 2009 00:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.017 X-Spam-Level: *** X-Spam-Status: No, score=3.017 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nu-10SsMAt5k for ; Mon, 2 Feb 2009 00:44:10 -0800 (PST) Received: from mx06.melco.co.jp (mx06.melco.co.jp [192.218.140.146]) by core3.amsl.com (Postfix) with ESMTP id 03E463A6927 for ; Mon, 2 Feb 2009 00:44:09 -0800 (PST) Received: from mr06.melco.co.jp (mr06 [133.141.98.164]) by mx06.melco.co.jp (Postfix) with ESMTP id E57185F0A6 for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: from mr06.melco.co.jp (localhost [127.0.0.1]) by mr06.imss (Postfix) with ESMTP id C2F9125EBA for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: from elgw.isl.melco.co.jp (unknown [133.141.13.130]) by mr06.melco.co.jp (Postfix) with ESMTP id AD6D025E8A for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: from eliswall.isl.melco.co.jp (eliswall.isl.melco.co.jp [10.74.245.38]) by elgw.isl.melco.co.jp (Postfix) with ESMTP id 95C8031F3EA for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: from eliswall.isl.melco.co.jp (localhost.localdomain [127.0.0.1]) by localhost.isl.melco.co.jp (Postfix) with ESMTP id 59DFD22CB98 for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: from LeakStopper182 (stopper2.isl.melco.co.jp [10.74.245.36]) by eliswall.isl.melco.co.jp (Postfix) with SMTP id 3FD5822CB97 for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: (qmail 25327 invoked by uid 507); 2 Feb 2009 17:43:47 +0900 Received: from unknown (HELO ELL2SENO) (10.74.8.54) by 0 with SMTP; 2 Feb 2009 17:39:10 +0900 From: "Shoichiro Seno" To: , , , , Date: Mon, 2 Feb 2009 17:39:11 +0900 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: Acl83napCLZqADbiT0CXLGI2JmotcQH+EUEg Subject: [Pce] iPOP 2009 Call for Presentations X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Dear CAMP, PCE, L1VPN, MPLS and MPLS-TP subscribers, (Apologies for multiple copies, appreciated if you can forward to potentially interested people. Following the successful events of iPOP, the 5th Conference on IP + Optical Network (iPOP 2009) will be held at NICT Headquarters, Koganei, Tokyo, Japan, June 11-12, 2009. The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. See Call for presentation details at http://www.pilab.jp/ipop2009/ Important Dates: Submission deadline of one page summary: February 20, 2009 Notification of acceptance: April 3, 2009 Submission deadline of final presentation slides: April 24, 2009 The Technical Program Committee for iPOP 2009 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstract of 400 words and a maximum of 1 page, including figures and diagrams, speaker's name, affiliation, and contact information to the Technical Program Committee at ipop2009-CFP@pilab.jp. Kind regards, Sho Seno Exhibition Committee Vice-chair, iPOP 2009 -- Shoichiro Seno (E-mail) Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Information Technology R&D Center, Mitsubishi Electric Corporation _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From ylee@huawei.com Fri Feb 6 09:07:51 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D008E3A699F for ; Fri, 6 Feb 2009 09:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiXuzTcqvlMp for ; Fri, 6 Feb 2009 09:07:50 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 57A1D3A6B69 for ; Fri, 6 Feb 2009 09:06:52 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEN003GOM7HGV@usaga04-in.huawei.com> for pce@ietf.org; Fri, 06 Feb 2009 11:06:54 -0600 (CST) Received: from L73682 ([10.124.12.74]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KEN00MF0M7GIQ@usaga04-in.huawei.com> for pce@ietf.org; Fri, 06 Feb 2009 11:06:53 -0600 (CST) Date: Fri, 06 Feb 2009 11:06:52 -0600 From: Young Lee To: pce@ietf.org Message-id: <001001c9887d$4ee2b660$4a0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_jY4Ix3CQZPh1T6uXPT0IMA)" Thread-index: AcmIfU4rAxL7H6sMTMusB9Ns5yFnHw== Subject: [Pce] Impairment aware RWA X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 17:07:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jY4Ix3CQZPh1T6uXPT0IMA) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi PCEers, for those interested in WSON and the recent work on optical impairments we have updated our impairment framework draft: http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairments-0 2.txt In this update we have described further the requirement that may occur in some situations to keep a vendors impairment information private and given architectural options leveraging PCE to realize this goal. This allows us to accommodate ITU-T G.680 "situation 1" in a flexible and effective manner. The requirements section has been reorganized as well as the architectural alternatives. Figures have been furnished for architecture alternatives and example PCE configuration. Note that this document focuses on impairment aware path computation (IA-RWA) and does not address optical measurement in any way. Although this work has been primarily addressed in CCAMP WG, we have explored several architecture options including PCE to realize the goal. Your comments are appreciated. Young L. & Greg B. --Boundary_(ID_jY4Ix3CQZPh1T6uXPT0IMA) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: quoted-printable

Hi PCEers, for = those interested in WSON and the recent work on optical impairments we have = updated our impairment framework draft:

http://www.ietf.org/internet-drafts/draft-bernstein-cca= mp-wson-impairments-02.txt

 

In this update we = have described further the requirement that may occur in some situations to = keep a vendors impairment information private and given architectural options = leveraging PCE to realize this goal. This allows us to accommodate ITU-T G.680 "situation 1" in a flexible and effective manner. The = requirements section has been reorganized as well as the architectural = alternatives.  Figures have been furnished for architecture alternatives and example = PCE configuration. Note that this document focuses on impairment aware path computation (IA-RWA) and does not address optical measurement in any = way.

 

Although this work = has been primarily addressed in CCAMP WG, we have explored several architecture options = including PCE to realize the goal. Your comments are appreciated. =

 

Young L. & Greg = B.

 

--Boundary_(ID_jY4Ix3CQZPh1T6uXPT0IMA)-- From ylee@huawei.com Fri Feb 6 12:35:38 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CE73A6B2E for ; Fri, 6 Feb 2009 12:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jllOPg0Wn4SX for ; Fri, 6 Feb 2009 12:35:35 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 2325A3A6AC5 for ; Fri, 6 Feb 2009 12:35:35 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEN00HEPVVC4R@usaga04-in.huawei.com> for pce@ietf.org; Fri, 06 Feb 2009 14:35:37 -0600 (CST) Received: from L73682 ([10.124.12.74]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KEN00NI6VV808@usaga04-in.huawei.com> for pce@ietf.org; Fri, 06 Feb 2009 14:35:36 -0600 (CST) Date: Fri, 06 Feb 2009 14:35:32 -0600 From: Young Lee To: pce@ietf.org Message-id: <002a01c9889a$777fb8d0$4a0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_ynYQ0GYaylMAGxHNQkSWwA)" Thread-index: AcmImnStDLz210JmQiKj5q70FBTVZw== Cc: 'Diego Caviglia' Subject: [Pce] PCEP requirement to support RWA X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 20:35:38 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ynYQ0GYaylMAGxHNQkSWwA) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hello PCErs, while WSON RWA has been moving steadily forward at CCAMP we seem to be stuck in getting the necessary enhancements to PCEP. There has been some discussion that our PCEP WSON RWA requirements may be general GMPLS requirements. If so we'd be happy to incorporate them into a GMPLS requirements document, however we're not sure if these would then become a burden for non-WSON GMPLS networks. PCE is crucial to the control of WSON we'd like to get this hammered out prior to the San Francisco meeting. A quick summary of WSON requirements (in term of label assignment): (a) There are currently two accepted WSON architectural options R&WA and R+Distributed WA. One requires wavelength assignment one doesn't. Hence we need in our Request message the ability to ask for label assignment or not. (b) Laser transmitters maybe tunable with limited ranges. Hence we need in our Request message the ability to specify that a restricted label range is required. (c) PCEP currently allows us to specify if we desire a bidirectional LSP. In WSONs we may have the additional need to specify that the wavelengths (labels) used in both directions should be the same (or not). (d) PCEP supports re-optimization. One useful type of re-optimization for WSONs is the ability to change the wavelength assignment without changing the route. This is also similar to a third WSON architectural option (not required) where one PCE that computes routes asks another for wavelength assignment (WA). Comments and suggestions are invited and encouraged Best Regards Young L. and Greg B. --Boundary_(ID_ynYQ0GYaylMAGxHNQkSWwA) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: quoted-printable

Hello PCErs, while = WSON RWA has been moving steadily forward at CCAMP we seem to be stuck in getting = the necessary enhancements to PCEP. There has been some discussion that our = PCEP WSON RWA requirements may be general GMPLS = requirements.

If so we'd be happy = to incorporate them into a GMPLS requirements document, however we're not = sure if these would then become a burden for non-WSON GMPLS networks. PCE is = crucial to the control of WSON we'd like to get this hammered out prior to the = San Francisco = meeting.

 

A quick summary of = WSON requirements (in term of label assignment):

(a) There are = currently two accepted WSON architectural options R&WA and =

R+Distributed WA. = One requires wavelength assignment one doesn't.  = Hence

we need in our = Request message the ability to ask for label assignment or = not.

(b) Laser = transmitters maybe tunable with limited ranges. Hence we need in our Request message the = ability to specify  that a restricted label range is = required.

(c) PCEP currently = allows us to specify if we desire a bidirectional LSP. In WSONs we may have the additional need to specify that the wavelengths (labels) used in both directions should be the same (or not).

(d) PCEP supports re-optimization. One useful type of re-optimization for WSONs is the = ability to change the wavelength assignment without changing the route. This is = also similar to a third WSON architectural option (not required) where one = PCE that computes routes asks another for wavelength assignment = (WA).

 

Comments and = suggestions are invited and encouraged

 

Best = Regards

 

Young L. and Greg = B.

 

--Boundary_(ID_ynYQ0GYaylMAGxHNQkSWwA)-- From senthilKumars@huawei.com Sun Feb 8 20:35:16 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629293A6984 for ; Sun, 8 Feb 2009 20:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHv3EVCc2c+l for ; Sun, 8 Feb 2009 20:35:15 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6AAA63A696C for ; Sun, 8 Feb 2009 20:35:15 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KES004B37ESBM@szxga04-in.huawei.com> for pce@ietf.org; Mon, 09 Feb 2009 12:35:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KES000E77ESQL@szxga04-in.huawei.com> for pce@ietf.org; Mon, 09 Feb 2009 12:35:16 +0800 (CST) Received: from htipl10764 ([10.18.4.175]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KES001NE7EOFW@szxml04-in.huawei.com> for pce@ietf.org; Mon, 09 Feb 2009 12:35:16 +0800 (CST) Date: Mon, 09 Feb 2009 10:05:12 +0530 From: "S.SenthilKumar" In-reply-to: To: pce@ietf.org Message-id: <002101c98a6f$cc6083d0$64000981@china.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmJXrAHdeCbIDDfRkOLwZmAX7zU4gBD6YxA Cc: senthilKumars@huawei.com Subject: [Pce] Reg TLVs and Sub-Objects X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: senthilKumars@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 04:35:16 -0000 Dear All Draft 19 of PCEP has defined 3 TLVs that can appear inside the object. In addition, It is referring to other RFCs (RSVP-TE - RFC3209, RFC3473 and RFC3477) which uses the term Sub-Objects. Type or the Object Type is more or less same >In some Sub-objects, Only 15 bits are allocated to Sub-object Type >In all TLVs (Defined in Draft 16), Type is always 16 bits The meaning of Length field is different between TLV and Sub-object >Length field in TLV is length of Value alone and can be Zero indicating that no Value is present >Length field in Sub-Object is the length of the whole sub-object and it starts from 4. I feel that TLV defined in Draft 19 can be made as same as the sub-object. Please let me know your thoughts. Thanking you, Best regards, S.SenthilKumar From adrian@olddog.co.uk Mon Feb 9 00:44:03 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56F13A6959 for ; Mon, 9 Feb 2009 00:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHpAlRJcDknZ for ; Mon, 9 Feb 2009 00:44:03 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 8D26B3A6963 for ; Mon, 9 Feb 2009 00:44:01 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n198hm4X022714; Mon, 9 Feb 2009 08:43:48 GMT Received: from your029b8cecfe (dhcp154.dagstuhl.de [192.76.146.154]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n198hlDK022692; Mon, 9 Feb 2009 08:43:48 GMT Message-ID: From: "Adrian Farrel" To: References: <002101c98a6f$cc6083d0$64000981@china.huawei.com> Date: Mon, 9 Feb 2009 08:43:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: pce@ietf.org Subject: Re: [Pce] Reg TLVs and Sub-Objects X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 08:44:04 -0000 Hi, It may be a little bit late to raise this question as the draft has been through all of the last call process and has even been edited by the RFC editor (I expect to see RFC 5440 published very soon). Since we want to carry information encoded as closely as possible to RSVP-TE encodings, we definitely want to use sub-objects (such as in the ERO). It might make the PCEP implementation more simple to use only TLV encoding, but it would make the integration of PCEP into the RSVP-TE-capable PCC more complex. The alternative would be to move all TLVs to be in sub-object format. Could have done this. But we didn't. Maybe the TLV format is a little more obvious for recursive nesting. Adrian ----- Original Message ----- From: "S.SenthilKumar" To: Cc: Sent: Monday, February 09, 2009 4:35 AM Subject: [Pce] Reg TLVs and Sub-Objects > > Dear All > > Draft 19 of PCEP has defined 3 TLVs that can appear inside the object. In > addition, It is referring to other RFCs (RSVP-TE - RFC3209, RFC3473 and > RFC3477) which uses the term Sub-Objects. > > Type or the Object Type is more or less same >>In some Sub-objects, Only 15 bits are allocated to Sub-object Type >>In all TLVs (Defined in Draft 16), Type is always 16 bits > > The meaning of Length field is different between TLV and Sub-object >>Length field in TLV is length of Value alone and can be Zero indicating > that no Value is present >>Length field in Sub-Object is the length of the whole sub-object and it > starts from 4. > > I feel that TLV defined in Draft 19 can be made as same as the sub-object. > > Please let me know your thoughts. > > Thanking you, > > Best regards, > S.SenthilKumar > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From adrian@olddog.co.uk Thu Feb 12 14:19:30 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0143A67FC for ; Thu, 12 Feb 2009 14:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgnlsAV8EJK4 for ; Thu, 12 Feb 2009 14:19:28 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id C316D3A6C29 for ; Thu, 12 Feb 2009 14:19:12 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n1CMJ1Pn018057; Thu, 12 Feb 2009 22:19:01 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n1CMJ0s2018051; Thu, 12 Feb 2009 22:19:00 GMT Message-ID: <95FEE54C2CED4049B8ADC90E89765B7E@your029b8cecfe> From: "Adrian Farrel" To: "Ross Callon" Date: Thu, 12 Feb 2009 22:18:56 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: iesg-secretary@iesg.org, pce@ietf.org Subject: [Pce] Please publish draft-ietf-pce-monitoring-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 22:19:30 -0000 Proto-write-up for draft-ietf-pce-monitoring-04.txt Intended status : Standards Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D had a relatively low level of discussions and review in the PCE working group. However, the work makes only a small modification to the base PCE protocol (PCEP) and is only of interest to people building large PCE-based systems. It has been authored by individuals associated with three separate PCEP implementations. It has not had review in any wider forums, but none was deemed necessary or appropriate. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. No IPR discolsed > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? As per document review, the consensus represents the strong concurrence of a few individuals, with others being silent. There has been no dissent at all. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? The document defines small protocol enhancements to PCEP. The PCEP specification is progressing through the RFC Editor process and no the IANA registry that has been created is not quite definitive yet. Nevertheless, this I-D requests further allocations from the PCEP registry that IANA will create and manage. The IANA section of this I-D uses the same language as the PCEP specification and, in particular, uses the same sub-registry names. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? A small amount of BNF is used. A normative reference to draft-farrel-rtg-common-bnf is included to scope the form of BNF in use. No automated checker has been used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. A Path Computation Element (PCE) based architecture has been specified in RFC 4655 for the computation of Traffic Engineering (TE) Label Switched Paths in MPLS and GMPLS networks. This architecture can be used in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). Path Computation Clients send computation requests to PCEs using the Path Computation Protocol (PCEP). These PCEs may forward the requests to, and cooperate with, other PCEs forming a "path computation chain". In PCE-based environments, it is critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential computational resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to PCEP in order to gather such information. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? Nothing of note. Not a very loud consensus, but no dissent. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There are no known implementations of this minor addition to the protocol. There are long-term plans to implement, but nothing in the immediate future. Althought the specification got ahead of the implementation, it is felt that it would be useful to complete the publication process and move on. From adrian@olddog.co.uk Fri Feb 13 09:18:00 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A4C3A6D70 for ; Fri, 13 Feb 2009 09:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.515 X-Spam-Level: X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PSb+vj-qwsQ for ; Fri, 13 Feb 2009 09:18:00 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id B29283A69CA for ; Fri, 13 Feb 2009 09:17:59 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n1DHI2jg027278 for ; Fri, 13 Feb 2009 17:18:04 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n1DHI01H027267 for ; Fri, 13 Feb 2009 17:18:01 GMT Message-ID: From: "Adrian Farrel" To: Date: Fri, 13 Feb 2009 17:17:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Pce] Cut-off dates for San Francisco X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 17:18:00 -0000 Hi, Please be aware... March 2, 2009 Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 3 UTC/GMT), upload using IETF ID Submission Tool. March 9, 2009 Monday - Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. Adrian From root@core3.amsl.com Fri Feb 13 14:30:01 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C49303A6C4D; Fri, 13 Feb 2009 14:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090213223001.C49303A6C4D@core3.amsl.com> Date: Fri, 13 Feb 2009 14:30:01 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 22:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Author(s) : S. Yasukawa, A. Farrel Filename : draft-ietf-pce-p2mp-req-01.txt Pages : 11 Date : 2009-02-13 The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-p2mp-req-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-p2mp-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-13141929.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Feb 13 16:00:01 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D98F928C1A3; Fri, 13 Feb 2009 16:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090214000001.D98F928C1A3@core3.amsl.com> Date: Fri, 13 Feb 2009 16:00:01 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-p2mp-app-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 00:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)and Generalized MPLS (GMPLS) Traffic Engineering (TE) Author(s) : S. Yasukawa, A. Farrel Filename : draft-ietf-pce-p2mp-app-01.txt Pages : 16 Date : 2009-2-13 The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths, and examines which of the PCE architectural models are appropriate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-p2mp-app-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-p2mp-app-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-2-13154809.I-D@ietf.org> --NextPart-- From adrian@olddog.co.uk Sat Feb 14 00:46:56 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031BA3A69AD for ; Sat, 14 Feb 2009 00:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti8lQzD33U0S for ; Sat, 14 Feb 2009 00:46:55 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 0FAD33A6921 for ; Sat, 14 Feb 2009 00:46:54 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n1E8kuUB001694 for ; Sat, 14 Feb 2009 08:46:56 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n1E8ksb2001680 for ; Sat, 14 Feb 2009 08:46:56 GMT Message-ID: From: "Adrian Farrel" To: Date: Sat, 14 Feb 2009 08:46:50 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Pce] PCE - Requested session has been scheduled for IETF 74 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 08:46:56 -0000 Hi, *DRAFT* schedule is at https://datatracker.ietf.org/meeting/74/agenda.html PCE has been allocated Friday night. This should solve any problems with room size :-( Adrian ----- Original Message ----- From: "IETF Secretariat" To: Cc: ; ; ; Sent: Friday, February 13, 2009 11:40 PM Subject: PCE - Requested session has been scheduled for IETF 74 > Dear JP Vasseur, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > PCE Session 1 (1 hour) > Friday, Afternoon Session II 1415-1515 > Room Name: Breakout 3 > ---------------------------------------------- > > > > Requested Information: > > > --------------------------------------------------------- > Working Group Name: pce > Area Name: Routing Area > Session Requester: JP Vasseur > > Number of Sessions: 1 > Length of Session(s): 1 hour > > > Number of Attendees: 90 > Conflicts to Avoid: > First Priority: ccamp mpls pwe3 l1vpn l2vpn l3vpn rtgarea rtgwg 6lowpan > roll idr isis autoconf ospf > > Special Requests: > > --------------------------------------------------------- > > > From jvasseur@cisco.com Sat Feb 14 01:11:07 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C953A6B00 for ; Sat, 14 Feb 2009 01:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP-Sy7qEiQnX for ; Sat, 14 Feb 2009 01:11:06 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D88BE3A69F7 for ; Sat, 14 Feb 2009 01:11:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,205,1233532800"; d="scan'208,217";a="33784743" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2009 09:11:12 +0000 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 n1E9BCMZ032563 for ; Sat, 14 Feb 2009 10:11:12 +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.13.8/8.13.8) with ESMTP id n1E9BChp014631 for ; Sat, 14 Feb 2009 09:11:12 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); Sat, 14 Feb 2009 10:11:11 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Feb 2009 10:11:11 +0100 Message-Id: From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-12-744917085 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 14 Feb 2009 10:11:11 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 Feb 2009 09:11:11.0545 (UTC) FILETIME=[2E018A90:01C98E84] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6866; t=1234602672; x=1235466672; 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:=20Important=20meeting=20Dates=20for=20IETF-73 |Sender:=20; bh=+gedF4aWVaDDDQ1YSKelCJayQPI53lOrmtYlcErmdQc=; b=AeOWPix7DIOOAR8ceDgmj2Vq9U7Lw2YEigChbHSWb7c34q8EzFPsPAZuMx jlsxbWs/iEnyKBRDHI8lF0cVbviBM7FI0nsDXPCrB+Tt9COZ8yGRomB6V50r Sjbage+YPz; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Pce] Important meeting Dates for IETF-73 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 09:11:07 -0000 --Apple-Mail-12-744917085 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Please note that these dates are subject to change. December 15, 2008 (Week of) - IETF Online Registration is now open. December 22, 2008 Monday - Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool. January 19, 2009 Monday (Extended to January 21, 2009) - Cutoff date for requests to schedule Working Group meetings and for preliminary BOF proposals to ADs at 17:00 PST (01:00 Tuesday, January 20 UTC/GMT). To request a Working Group session, use the IETF Meeting Session Request Tool. February 2, 2009 Monday - Cutoff date for requests to Area Directors to schedule BOFs at 17:00 PST (01:00 Tuesday, February 3 UTC/GMT). To request a BOF, please see instructions on Requesting a BOF. February 9, 2009 Monday - Cutoff date for Area Directors to approve BOF requests at 17:00 PST (01:00 Tuesday, February 10 UTC/GMT). February 13, 2009 Friday - Preliminary agenda published for comment. February 23, 2009 Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PST (01:00 Tuesday, February 24 UTC/GMT). February 25, 2009 Wednesday - Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PST (01:00 Thursday, February 26 UTC/GMT). March 2, 2009 Monday - Final agenda to be published. March 2, 2009 Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 3 UTC/GMT), upload using IETF ID Submission Tool. March 9, 2009 Monday - Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. March 11, 2009 Wednesday - Draft Working Group agendas due by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. March 13, 2009 Friday - Early-Bird registration and payment cut-off at 17:00 PDT (24:00 UTC/GMT). March 16, 2009 Monday - Revised Working Group agendas due by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. March 16, 2009 Monday - Registration cancellation cut-off at 17:00 PDT (24:00 UTC/GMT). March 20, 2009 Friday - Final Pre-Registration and Pre-Payment cut-off at 17:00 PDT (24:00 UTC/GMT). March 22-27, 2009 - 74th IETF Meeting in San Francisco, CA, USA April 24, 2009 Friday - Proceedings submission cutoff date by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. May 13, 2009, Wednesday - Proceedings submission corrections cutoff date by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. **** Times are in US Pacific Time and UTC/GMT **** --Apple-Mail-12-744917085 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Please note that = these dates are subject to change.

December 15, 2008 (Week = of) - IETF Online = Registration is now open.
December 22, 2008 Monday - Working = Group and BOF scheduling begins. To request a Working Group session, use = the = IETF Meeting Session Request Tool.
January 19, 2009 Monday = (Extended to January 21, 2009) - Cutoff date for requests to schedule = Working Group meetings and for preliminary BOF proposals to ADs at 17:00 = PST (01:00 Tuesday, January 20 UTC/GMT). To request a Working Group = session, use the = IETF Meeting Session Request Tool.
February 2, 2009 Monday - = Cutoff date for requests to Area Directors to schedule BOFs at 17:00 PST = (01:00 Tuesday, February 3 UTC/GMT). To request a BOF, please see = instructions on Requesting a = BOF.
February 9, 2009 Monday - Cutoff date for Area Directors to = approve BOF requests at 17:00 PST (01:00 Tuesday, February 10 = UTC/GMT).
February 13, 2009 Friday - Preliminary agenda published for = comment.
February 23, 2009 Monday - Working Group Chair approval for = initial document (Version -00) submissions appreciated by 17:00 PST = (01:00 Tuesday, February 24 UTC/GMT).
February 25, 2009 Wednesday - = Cutoff date for requests to reschedule Working Group and BOF meetings = 17:00 PST (01:00 Thursday, February 26 UTC/GMT).
March 2, 2009 Monday = - Final agenda to be published.
March 2, 2009 Monday - Internet Draft = Cut-off for initial document (-00) submission by 17:00 PST (01:00 = Tuesday, March 3 UTC/GMT), upload using IETF ID Submission = Tool.
March 9, 2009 Monday - Internet Draft final submission = cut-off by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission = Tool.
March 11, 2009 Wednesday - Draft Working Group agendas due = by 17:00 PDT (24:00 UTC/GMT), upload using IETF = Meeting Materials Management Tool.
March 13, 2009 Friday = - Early-Bird&nb= sp;registration and payment cut-off at 17:00 PDT (24:00 = UTC/GMT).
March 16, 2009 Monday - Revised Working Group agendas due = by 17:00 PDT (24:00 UTC/GMT), upload using IETF = Meeting Materials Management Tool.
March 16, 2009 Monday - = Registration cancellation cut-off at 17:00 PDT (24:00 UTC/GMT).
March = 20, 2009 Friday - Final Pre-Registration and Pre-Payment cut-off at = 17:00 PDT (24:00 UTC/GMT).
March 22-27, 2009 - 74th IETF Meeting in = San Francisco, CA, USA
April 24, 2009 Friday - Proceedings submission = cutoff date by 17:00 PDT (24:00 UTC/GMT), upload using IETF = Meeting Materials Management Tool.
May 13, 2009, Wednesday - = Proceedings submission corrections cutoff date by 17:00 PDT (24:00 = UTC/GMT), upload using IETF = Meeting Materials Management Tool.

**** Times are in US = Pacific Time and UTC/GMT ****

= --Apple-Mail-12-744917085-- From jvasseur@cisco.com Sat Feb 14 01:12:34 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490D73A6B38 for ; Sat, 14 Feb 2009 01:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNIycQlHakZI for ; Sat, 14 Feb 2009 01:12:33 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2C6863A6AF0 for ; Sat, 14 Feb 2009 01:12:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,205,1233532800"; d="scan'208,217";a="33784783" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2009 09:12:39 +0000 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 n1E9Cd3E019685 for ; Sat, 14 Feb 2009 10:12:39 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1E9CdVW014747 for ; Sat, 14 Feb 2009 09:12:39 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Feb 2009 10:12:39 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Feb 2009 10:12:39 +0100 Message-Id: From: JP Vasseur To: pce@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-14-745004580 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 14 Feb 2009 10:12:38 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 Feb 2009 09:12:39.0105 (UTC) FILETIME=[62322310:01C98E84] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3194; t=1234602759; x=1235466759; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Preliminary=20Agenda=20PCE=20WG=20Meeting=20IET F-73 |Sender:=20; bh=C8MaIKBWja3D4Qyi4v7sxTjgopUmcZZQFihEBitBxEM=; b=WWs5XZwhLSIO7O+m6wiITYgtNd5tMSnYUxL2A4tAlfRBhbXz3z+P3Mq4bj HDIejkE3/91SIwZR8OShfLc2VHGMqj5eQcBxfxiIXOkboFYy92XQCl0OP/Sx ibAZmfYJQu; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Pce] Preliminary Agenda PCE WG Meeting IETF-73 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 09:12:34 -0000 --Apple-Mail-14-745004580 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit The preliminary agenda shows FRIDAY, March 27, 2009 1415-1515 Afternoon Session II RTG pce Path Computation Element WG --Apple-Mail-14-745004580 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The preliminary agenda = shows

FRIDAY, March 27, = 2009 

1415-1515 Afternoon = Session II

Path Computation Element = WG
RTGpce
= --Apple-Mail-14-745004580-- From jvasseur@cisco.com Sun Feb 15 03:03:15 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AFBF3A6ABB for ; Sun, 15 Feb 2009 03:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbtV-+2HfWRH for ; Sun, 15 Feb 2009 03:03:14 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 42F673A6AB9 for ; Sun, 15 Feb 2009 03:03:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,210,1233532800"; d="scan'208";a="33814187" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Feb 2009 11:03:21 +0000 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 n1FB3LMp024297 for ; Sun, 15 Feb 2009 12:03:21 +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.13.8/8.13.8) with ESMTP id n1FB3L7F007105 for ; Sun, 15 Feb 2009 11:03:21 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); Sun, 15 Feb 2009 12:03:21 +0100 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Feb 2009 12:03:21 +0100 Message-Id: From: JP Vasseur To: pce@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 15 Feb 2009 12:03:21 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 15 Feb 2009 11:03:21.0386 (UTC) FILETIME=[03B788A0:01C98F5D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=137; t=1234695801; x=1235559801; 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:=20Slot=20for=20the=20PCE=20WG=20meeting=20IETF-73 |Sender:=20; bh=9yJwOGlKKwqwFCgRY/MdQUJQyrAPtzwLwh+q1EWs3/I=; b=IOlEbBXInBcpPE0TTCxiTAGANT8DnqOi5/MGuURah+PNtj1aqjD6O1d7nf VOCGJtPDF29pN/vTK6sSlHwbKcUXGb/EpNE+Uiu9o+GUP41KpJxUsP7bRk6m +lyjTP0S3B; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Pce] Slot for the PCE WG meeting IETF-73 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 11:03:15 -0000 Dear all, Please let us know no later than end of February if you request a slot for the PCE WG meeting in SFO. Thanks. JP. From Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Sun Feb 22 19:18:56 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53A03A6A00 for ; Sun, 22 Feb 2009 19:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.41 X-Spam-Level: ** X-Spam-Status: No, score=2.41 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inJeBqD1yidC for ; Sun, 22 Feb 2009 19:18:55 -0800 (PST) Received: from mx06.melco.co.jp (mx06.melco.co.jp [192.218.140.146]) by core3.amsl.com (Postfix) with ESMTP id 1835D3A696A for ; Sun, 22 Feb 2009 19:18:54 -0800 (PST) Received: from mr06.melco.co.jp (mr06 [133.141.98.164]) by mx06.melco.co.jp (Postfix) with ESMTP id 19ED25E7FA for ; Mon, 23 Feb 2009 12:05:03 +0900 (JST) Received: from mr06.melco.co.jp (localhost [127.0.0.1]) by mr06.imss (Postfix) with ESMTP id E554F25C8B for ; Mon, 23 Feb 2009 12:05:02 +0900 (JST) Received: from elgw.isl.melco.co.jp (unknown [133.141.13.130]) by mr06.melco.co.jp (Postfix) with ESMTP id CBE1825C89 for ; Mon, 23 Feb 2009 12:05:02 +0900 (JST) Received: from eliswall.isl.melco.co.jp (eliswall.isl.melco.co.jp [10.74.245.38]) by elgw.isl.melco.co.jp (Postfix) with ESMTP id 9933231F3E5 for ; Mon, 23 Feb 2009 12:05:02 +0900 (JST) Received: from eliswall.isl.melco.co.jp (localhost.localdomain [127.0.0.1]) by localhost.isl.melco.co.jp (Postfix) with ESMTP id 4C2EB22CBA0 for ; Mon, 23 Feb 2009 12:05:02 +0900 (JST) Received: from LeakStopper182 (stopper.isl.melco.co.jp [10.74.245.35]) by eliswall.isl.melco.co.jp (Postfix) with SMTP id 2FF7522CB92 for ; Mon, 23 Feb 2009 12:05:02 +0900 (JST) Received: (qmail 8016 invoked by uid 507); 23 Feb 2009 12:05:02 +0900 Received: from unknown (HELO ELL2SENO) (10.74.8.54) by 0 with SMTP; 23 Feb 2009 12:02:51 +0900 From: "Shoichiro Seno" To: , , , , Date: Mon, 23 Feb 2009 12:02:51 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: Acl83napCLZqADbiT0CXLGI2JmotcQH+EUEgBCKnbYA= Subject: [Pce] iPOP 2009 CFP Deadline Extended to March 2nd X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 03:18:56 -0000 Dear CAMP, PCE, L1VPN, MPLS and MPLS-TP subscribers, (Apologies for disturbing MLs with multiple copies; appreciated if you can forward this to potentially interested people.) Submission deadline to iPOP 2009, the 5th Conference on IP + Optical Network, has been extended to March 2nd. See details below. ---- Following the successful events of iPOP, the 5th Conference on IP + Optical Network (iPOP 2009) will be held at NICT Headquarters, Koganei, Tokyo, Japan, June 11-12, 2009. The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. See Call for presentation details at http://www.pilab.jp/ipop2009/ Important Dates: Submission deadline of one page summary: March 2, 2009 Notification of acceptance: April 3, 2009 Submission deadline of final presentation slides: April 24, 2009 The Technical Program Committee for iPOP 2009 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstract of 400 words and a maximum of 1 page, including figures and diagrams, speaker's name, affiliation, and contact information to the Technical Program Committee at ipop2009-CFP@pilab.jp. Kind regards, Sho Seno Exhibition Committee Vice-chair, iPOP 2009 -- Shoichiro Seno (E-mail) Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Information Technology R&D Center, Mitsubishi Electric Corporation From takeda.tomonori@lab.ntt.co.jp Tue Feb 24 18:07:39 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751383A687E for ; Tue, 24 Feb 2009 18:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_25=0.6, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmY3IuZpaakr for ; Tue, 24 Feb 2009 18:07:38 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id E0F633A67AF for ; Tue, 24 Feb 2009 18:07:37 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n1P27uuw014952; Wed, 25 Feb 2009 11:07:56 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 5F30A63E9; Wed, 25 Feb 2009 11:07:56 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 547D863B3; Wed, 25 Feb 2009 11:07:56 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n1P27tgj024165; Wed, 25 Feb 2009 11:07:56 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n1P27tNZ024162; Wed, 25 Feb 2009 11:07:55 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.55]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n1P27qMT010438; Wed, 25 Feb 2009 11:07:55 +0900 (JST) Message-ID: <49A4A7CC.60300@lab.ntt.co.jp> Date: Wed, 25 Feb 2009 11:07:08 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Rambach, Franz (NSN - DE/Munich)" , pce@ietf.org References: <3FBAA33B-D92D-4A9D-862A-BA2F936208F1@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [Pce] Working Group Last Call:draft-ietf-pce-inter-layer-frwk-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 02:07:39 -0000 Hi Franz, Thanks for various comments. Sorry that authors are a bit behind on this. We will update the document addressing your comments. Thanks, Tomonori Rambach, Franz (NSN - DE/Munich) wrote: > Dear WG, > > Some comments/questions regarding draft-ietf-pce-inter-layer-frwk-09.txt: > > Page 5, section "2. Inter-Layer Path Computation": > The document enumerats the different PCE-based path computation models, i.e. single PCE, multiple PCE with and without inter-PCE communication. > If the multi-layer path computation only incorporates two layers, the enumeration is fine. However, if a path traversing three (or more) layers is computed, also combinations of the three mentioned approaches are possible. > An example for such a combination of the different approaches: A network with three layers is given. Single PCE computation is applied for the two highest layers, i.e. for layer 3 and layer 2. Multiple PCE computation with inter-PCE communication is deployed for layer 1 and layer 2. Therefore, two PCEs - one PCE for layer 3 and layer 2 and one PCE responsible for layer 1 - are deployed in this network. For a path computation over the three layers the single PCE approach in combination with the multiple PCE computation approach is used. > > I propose to add one sentence about the combination of the approaches. > > Page 5/6, section "2. Inter-Layer Path Computation", paragraph about mono-layer path: > Document says: "The second case is that the PCE computes a path that includes a loose hop that spans the lower-layer network." > If a loose hop is specified, does this automatically mean, that the node before is the entry to the lower layer? This would be in contradiction to the case that a single layer path computation can include loose hops in the response and this computed path is completely setup in a single layer, i.e. the hop before the loose hop does not specify an entry point to the lower layer. > > Let's assume that a loose hop does not automatically indicate that a lower layer path should be used: > This means for the multi-layer case that the node before the loose hop, i.e. the node which expands the loose hop, does not necessarily know that it has to go into lower-layer. So, it will first ask the PCE in the higher layer and if it receives a "NO-PATH" object from the PCE, it will ask the PCE responsible for the lower layer. > > Of course, another option is that in the signalling message the node before the loose hop is marked explicitly as an entry point to the lower layer. (Is such a feature already defined in the RSVP-TE protocol?) > > > Page 6, section "3. Inter-Layer Path Computation Models": > Document says: "As stated in Section 2, two PCE modes defined in the PCE architecture can be used to perform inter-layer path computation." > In Section "2. Inter-Layer Path Computation" three different PCE approaches were introduced (single PCE, multiple PCE with and multiple PCE without inter-PCE communication). You are summarizing the two "multiple PCE approaches (with or without inter-PCE communication)" in section two into one. Perhaps one sentence in the introduction of section 3 should state this. > > Page 12, section "4.2.2 Higher-Layer Signaling Trigger Model", typo: > "Note that these actions depends on a policy being applied at the border LSR." > Should be: > "depend" instead of "depends" > > Page 15, section "4.2.3. NMS-VNTM Cooperation Model": > "Note that multiple PCE path computation with inter-PCE communication does not fit in with this model." > Why does this model or the single PCE model not fit to the NMS-VNTM cooperation model? > > An example how the multiple PCE with inter-PCE communication in combination with the NMS-VNTM cooperation model can look like is as follows: > Step 1: NMS requests a path computation from PCE Hi. > > Step 2: PCE Hi and PCE Lo collaborate to compute a ML path. The result (H1-H2-L1-L2-H3-H4) is sent back to the NMS. > > Step 3: NMS discovers that lower layer links are used. NMS suggests (or requests) to VNTM that a new TE link connecting H2 and H3 would be useful. Furthermore, it provides one solution (H2-L1-L2-H3) for such a TE link. The NMS notifies VNTM that it will be waiting for the TE link to be created. VNTM considers whether the suggested lower-layer LSP or any alternative LSP connecting H2 and H3 should be established if necessary and if acceptable within VNTM's policy constraints. > > Step 4: VNTM requests the ingress LSR in the lower-layer network (H2) to establish a lower-layer LSP. The request message includes the suggested lower-layer LSP route obtained from the NMS. > > Step 5: H2 signals the lower-layer LSP. > > Step 6: If the lower-layer LSP setup is successful, H2 notifies VNTM that the LSP is complete and supplies the tunnel information. > > Step 7: H2 advertises the new LSP as a TE link in the higher-layer network routing instance. > > Step 8: VNTM notifies NMS that the underlying lower-layer LSP has been set up, and NMS notices the new TE link advertisement. > > Step 9: NMS requests H1 to set up a higher-layer LSP between H1 and H4 with the path computed in Step 2. The lower layer links are replaced by the corresponding higher layer TE link. Hence, the NMS sends the path H1-H2-H3-H4 to H1. > > Step 10: H1 initiates signaling with the path H2-H3-H4 to establish the higher-layer LSP. > > Instead of Step 9 and 10 there is of course the possibility that analog to the example described in the draft the procedure goes on, i.e. > Step 9': NMS again requests H1 to set up a higher-layer LSP between H1 and H4. > > Step 10': H1 requests the higher-layer PCE to compute a path and obtains a successful result that includes the higher-layer route that is specified as H1-H2-H3-H4, where all hops are strict. > > Step 11': H1 initiates signaling with the computed path H2-H3-H4 to establish the higher-layer LSP. > > Quite similar to the above could the single PCE approach fit with this path control model. (The only difference would be in step 2.) > > > Page 15, section "4.2.3. NMS-VNTM Cooperation Model": > "When the PCE fails to compute a path, it informs the PCC (i.e., head-end LSR) that notifies the NMS. The notification may include the information that there is no TE link between the border LSRs." > What happens if the PCE just returns a "NO-PATH" object and the PCE does not include any indication why no path could be found? In this case the NMS is missing the information which lower layer path is needed to establish a path between H1 and H4. So, what should the NMS do in this case? > > Page 15, section "4.2.3. NMS-VNTM Cooperation Model": > If no path could be found and the request included additional constraints, e.g. the maimux delay, it is not enough that the PCE indicates which TE link in the higher layer is missing, but the PCE must also indicate which constraints such a new TE link must fullfill. > (Let's assume that in the example described in the draft a maximum delay for the path is given. In this case the PCE must indicate H1 (or NMS) which TE link is missing and it must additional indicate how much delay such a new TE link can have. If the delay is not taken into account during the path computation and path establishment of the lower layer path, it can be that even with the new TE link in the higher layer the path computation of PCE Hi fails.) > Hence, PCE Hi must exactly indicate what problems it encountered during the path computation. > > Perhaps one sentence about additional constraints should be added in the description of the NMS-VNTM cooperation model > > > Page 18, section "5. Choosing between Inter-Layer Path Control Models": > "This section compares the cooperation model between PCE and VNTM, and the higher-layer signaling trigger model, in terms of ..." > In this chapter also the NMS-VNTM cooperation model is compared, e.g. in section "5.1 VNTM Functions". > Add in the above sentence something like > "This section compares the cooperation model between PCE and VNTM, the higher-layer signaling trigger model and the NMS-VNTM cooperation model in terms of ..." > > > Page 19, section "5.3. Complete Inter-Layer LSP Setup Time", typo: > "between PCC and PCE, PCE and VNTM, NSM and VNTM" > Instead of "NSM" it should be "NMS" > > Page 20, section "5.4. Network Complexity": > "Where PCEs cooperate to determine a path, an iterative computation model such as [BRPC] can be used to select an optimal path across layers." > That's fine, but one should keep in mind that BRPC assumes that a domain sequence is given, i.e. in this case the "layer sequence". For an optimal path you must do a brute force over all possible "layer sequences" using BRPC. Since one doesn't know in advance how often the layers will be changed, the path computation can be cumbersome. > > Page 21, section "5.5. Separation of Layer Management", 2nd line: > "and security concerns (see next section)." > The next section is "6. Stability Considerations". You should reference section "9. Security Considerations". > > Page 22, 7. IANA Considerations, typo: > "This informaitonal" should be > "This informational" > > Page 28, in section references: > " JP. Vasseur et al, "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 -" draft-ietf-pce-pcep, work in progress. " > Title of the draft is: "Path Computation Element (PCE) Communication Protocol (PCEP)" without "- Version 1 -" > > > Other general comment: > I can think of at least one other approache for a path control model sketched in the following: > Step 1: PCE(s) calculate multi-layer path. > Step 2: Path is signalled up to the border node of the lower layer. > Step 3: This border node asks VNTM to setup the lower layer path. The border node can provide the VNTM the exact path defined by strict hops. > Step 4: VNTM configures the nodes of the lower layer path. > Step 5: A new TE link is established and announced in the higher layer. > Step 6: The border node continues to signal the path in the higher layer using the newly established TE link. > > The main point in this approach is that a network node can request a lower layer path setup from the VNTM. > > This approach can can be useful if the lower-layer does not support the feature to setup a path using the control plane. > > > > Best regards, > Franz Rambach > > Nokia Siemens Networks GmbH & Co. KG > COO RTP RT TAF Multi-Layer Networks & Resilience > St.-Martin-Str. 53, Room 63.404 > D-81669 Munich, Germany > Phone: +49-89-636-44188 > Fax: +49-89-636-45814 > > franz.rambach@nsn.com > http://www.nokiasiemensnetworks.com/global/ > > Nokia Siemens Networks GmbH & Co. KG > Sitz der Gesellschaft: Mu"nchen / Registered office: Munich > Registergericht: Mu"nchen / Commercial registry: Munich, HRA 88537 > WEEE-Reg.-Nr.: DE 52984304 > > Perso"nlich haftende Gesellschafterin / General Partner: Nokia Siemens Networks Management GmbH > Gescha"ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke > Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivinen > Sitz der Gesellschaft: Mu"nchen / Registered office: Munich > Registergericht: Mu"nchen / Commercial registry: Munich, HRB 163416 > > > > ________________________________ > > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of ext JP Vasseur > Sent: Tuesday, January 06, 2009 4:53 PM > To: pce@ietf.org > Subject: [Pce] Working Group Last Call:draft-ietf-pce-inter-layer-frwk-09.txt > > > Dear WG, > > > First of all, happy new year to all of you. > > > > This email starts a 2-week Working Group Last Call on draft-ietf-pce-inter-layer-frwk-09.txt, which will end on January 20 at noon ET. > > > Please send your comment on the Mailing list and to the authors. > > > Thanks. > > > JP. > > > From adrian@olddog.co.uk Thu Feb 26 14:30:07 2009 Return-Path: X-Original-To: pce@core3.amsl.com Delivered-To: pce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96C228C32F for ; Thu, 26 Feb 2009 14:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0AGjspLc9w1 for ; Thu, 26 Feb 2009 14:30:07 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id D7F7328C32B for ; Thu, 26 Feb 2009 14:30:06 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n1QMUQQF027132 for ; Thu, 26 Feb 2009 22:30:26 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n1QMUOdf027118 for ; Thu, 26 Feb 2009 22:30:25 GMT Message-ID: From: "Adrian Farrel" To: Date: Thu, 26 Feb 2009 22:30:20 -0000 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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Pce] Fw: Initial Version I-D Submission Deadline Extended to March 4, 2009 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 22:30:08 -0000 ----- Original Message ----- From: "Alexa Morris" To: ; ; Sent: Thursday, February 26, 2009 7:27 PM Subject: Initial Version I-D Submission Deadline Extended to March 4, 2009 > The IESG has extended the deadline for initial version (00) > submissions of Internet Drafts by 2 days (48 hours). The new deadline > is March 4, 2009 at 1700 Pacific (March 5, 2009 at 0100 UTC / GMT) > and the extension is for IETF 74 only. The deadline has been extended > due to the copyright legend text alternative being recently finalized, > approved and implemented. > > Please note that the date for updated I-D versions has NOT been > extended, and is still March 9, 2009. > > Regards, > Alexa > > ----------- > Alexa Morris / Executive Director / IETF > 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 > Phone: +1.510.492.4089 / Fax: +1.510.492.4001 > Email: amorris@amsl.com > > Managed by Association Management Solutions (AMS) > Forum Management, Meeting and Event Planning > www.amsl.com From wwwrun@core3.amsl.com Fri Feb 27 09:19:13 2009 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1091A3A6888; Fri, 27 Feb 2009 09:19:12 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090227171913.1091A3A6888@core3.amsl.com> Date: Fri, 27 Feb 2009 09:19:13 -0800 (PST) Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-global-concurrent-optimization (Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:19:13 -0000 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-global-concurrent-optimization-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16157&rfc_flag=0 The following IPR Declarations may be related to this I-D: