From julien.meuric@orange-ftgroup.com Tue Sep 1 06:04:50 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 2213D3A6FB2 for ; Tue, 1 Sep 2009 06:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_40=-0.185, HELO_EQ_FR=0.35] 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 I0BAeIck8ilm for ; Tue, 1 Sep 2009 06:04:49 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id BE88C3A6FB1 for ; Tue, 1 Sep 2009 06:04:48 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 15:05:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Sep 2009 15:04:59 +0200 Message-ID: In-Reply-To: <77ead0ec0908281814m77b76502xeea41fbd9324ea80@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RFC5440 Thread-Index: AcooRhajxozvdMeGTFG3pyvznj4nYQCto0NA References: <77ead0ec0908281814m77b76502xeea41fbd9324ea80@mail.gmail.com> From: To: X-OriginalArrivalTime: 01 Sep 2009 13:05:00.0305 (UTC) FILETIME=[D000B010:01CA2B04] Cc: pce@ietf.org Subject: Re: [Pce] RFC5440 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 13:04:50 -0000 Hi Vishwas. Good catch, but that seems even more complicated... Indeed, section 7.9 in RFC 5440 is named "Reported Route Object" while the text in that section mentions a "Route Record Object" (3rd variation). However, RRO is defined in RFC 3209 as: "Record Route Object", which leave us with not less than 4 expansion options! As it is purely an expansion issue, the solutions are not too complex: - RRO should be read as in RFC 3209: "Record Route Object"; - the title of section 7.9 in RFC 5440 does not (explicitly) claim to expand the acronym and could be considered as a functional description of the use in that context (indeed, the RRO reports a route ;-) ); RFC errata might be an option (not sure it's deserved provided we pay attention in next documents); - the text of section 7.9 in RFC 5440 does not claim to but implicitly expands the acronym, however it is a simple swap of R-terms (which you can even find in RFC 3209); - the IANA is not the standard reference for acronym expansion, however, if you feel that "Recorded" should be updated to "Record" I could contact them about that. I hope this clarifies. Regards, Julien -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Vishwas Manral Hi, While readint the RFC5440 and the http://www.iana.org/assignments/pcep/pcep.xml IANA assignments I noticed a discripancy. RRO in the RFC refers to a Reported Route Object but in the IANA it is refered to a Recorded Route Object. Thanks, Vishwas _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From jvasseur@cisco.com Wed Sep 2 01:07:14 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 7E7283A6F49 for ; Wed, 2 Sep 2009 01:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.167 X-Spam-Level: X-Spam-Status: No, score=-9.167 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 7w-SROoS7c-g for ; Wed, 2 Sep 2009 01:07:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5BA9F3A68DB for ; Wed, 2 Sep 2009 01:07:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsAALPBnUqQ/uCLe2dsb2JhbABGmm4BARYkBqVqiEEBkFcFhBs X-IronPort-AV: E=Sophos;i="4.44,317,1249257600"; d="scan'208";a="48412916" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Sep 2009 07:55:54 +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 n827tsSk028444 for ; Wed, 2 Sep 2009 09:55:54 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n827tsWZ023254 for ; Wed, 2 Sep 2009 07:55:54 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 09:55:54 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 09:55:54 +0200 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 v936) Date: Tue, 1 Sep 2009 20:30:25 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Sep 2009 07:55:54.0080 (UTC) FILETIME=[CC011600:01CA2BA2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=340; t=1251878154; x=1252742154; 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:=20Working=20Group=20Last=20Call=3A=20draft-ietf-p ce-pcep-svec-list-02.txt=20 |Sender:=20; bh=xm6loPcKWeMWgU7H3l+UHyC0fBrJOdjhdrsLYTqMPYM=; b=fAYPXwObxFL3zko6gkZS2Jcx9bXPIlh9KiUqWrMIytjCmb7BhLWrGPvk0c 7h0I4aeG4Fk8kzIZ4mRkjtuHF/KSAOF45g23KG2rn6h8R4fWorrx5uLAQFsr SalUl2RHVp; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.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, 02 Sep 2009 08:07:14 -0000 Dear all, This starts a 2-week WG Last Call for draft-ietf-pce-pcep-svec- list-02.txt, which has been stable for quite some time, and is ready for WG Last call. Please send your comments by September 16, 9:00am ET on the mailing list. We would also welcome feed-back from potential implementers. Thanks. JP and Julien. From filippo.cugini@cnit.it Wed Sep 2 09:49: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 5F6413A67AD for ; Wed, 2 Sep 2009 09:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.882 X-Spam-Level: * X-Spam-Status: No, score=1.882 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 dSwO6joigX5G for ; Wed, 2 Sep 2009 09:48:59 -0700 (PDT) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by core3.amsl.com (Postfix) with ESMTP id 563E73A6CE0 for ; Wed, 2 Sep 2009 09:48:58 -0700 (PDT) Received: from [10.30.2.217] (HELO Platini) by sssup.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 53354382; Wed, 02 Sep 2009 18:32:23 +0200 Message-ID: From: "Filippo Cugini" To: References: Date: Wed, 2 Sep 2009 18:47:21 +0200 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.5512 Subject: Re: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.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, 02 Sep 2009 16:49:00 -0000 Hi, just one clarification in the case of multiple associated end-to-end diverse path computations. Example: consider one additional end-to-end diverse path computation (say Requests #3 and #4, source S2 and dest. D2) associated to the diverse path computation S1-D1 reported in section 6. The EROs computed for Req #1 and #2 (those in section 6.2) may be related to the EROs computed for Req #3 and #4. Thus, up to 9 EROs per request could be necessary in each path list. However, if the two sets of computed EROs are independent, up to 3 EROs per request would be sufficient (as in 6.2). Is it required to enclose in the PCRep message all the combinations (even if they are independent)? Few typos: - section 4.1, "may in the SVEC may" - 6.2, last line, VSPT2 -> VSPT3 - 6.3, VSTP -> VSPT Br, Filippo ----- Original Message ----- From: "JP Vasseur" To: Sent: Tuesday, September 01, 2009 8:30 PM Subject: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.txt > Dear all, > > This starts a 2-week WG Last Call for draft-ietf-pce-pcep-svec- > list-02.txt, which has been stable for quite some time, and is ready for > WG Last call. Please send your comments by September 16, 9:00am ET on the > mailing list. > > We would also welcome feed-back from potential implementers. > > Thanks. > > JP and Julien. > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From julien.meuric@orange-ftgroup.com Mon Sep 7 01:18:47 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 D16493A67D6 for ; Mon, 7 Sep 2009 01:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 GpFNRMWd3uWS for ; Mon, 7 Sep 2009 01:18:47 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id BCF3B3A67B0 for ; Mon, 7 Sep 2009 01:18:46 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 10:19:06 +0200 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: Mon, 7 Sep 2009 10:19:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll on draft-lee-pce-wson-routing-wavelength-05.txt Thread-Index: Acovk96pDBztp1ZtTU2XEH/zTA7kaw== From: To: X-OriginalArrivalTime: 07 Sep 2009 08:19:06.0563 (UTC) FILETIME=[DE0DE130:01CA2F93] Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 08:18:47 -0000 Hello PCE members. As you probably now, CCAMP has already endorsed some WSON and RWA as = working items. In the same context, = draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on = PCEP. Do you think we should now take this I-D as a WG document? Thanks for expressing your minds, JP & Julien From danli@huawei.com Mon Sep 7 02:09:20 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 B67E43A6A4D for ; Mon, 7 Sep 2009 02:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.934 X-Spam-Level: * X-Spam-Status: No, score=1.934 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZxmfyd5-TU8 for ; Mon, 7 Sep 2009 02:09:19 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BEA4B3A68F1 for ; Mon, 7 Sep 2009 02:09:19 -0700 (PDT) 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 <0KPL00FVKG3VQ3@szxga04-in.huawei.com> for pce@ietf.org; Mon, 07 Sep 2009 17:09:31 +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 <0KPL00IXRG3UZ7@szxga04-in.huawei.com> for pce@ietf.org; Mon, 07 Sep 2009 17:09:30 +0800 (CST) Received: from l37133a ([10.70.77.63]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPL005C3G3ULE@szxml04-in.huawei.com> for pce@ietf.org; Mon, 07 Sep 2009 17:09:30 +0800 (CST) Date: Mon, 07 Sep 2009 17:09:30 +0800 From: Dan Li To: julien.meuric@orange-ftgroup.com, pce@ietf.org Message-id: <00e301ca2f9a$e8b251f0$3f4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_oNfFIbyImCimArSkSxutWA)" X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 09:09:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_oNfFIbyImCimArSkSxutWA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Yes, I support to take this I-D as a WG doc. Dan ----- Original Message ----- From: julien.meuric@orange-ftgroup.com To: pce@ietf.org Sent: Monday, September 07, 2009 4:19 PM Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt Hello PCE members. As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? Thanks for expressing your minds, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_oNfFIbyImCimArSkSxutWA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Yes, I support to take this I-D as a WG doc.
 
Dan
 
----- Original Message -----
Sent: Monday, September 07, 2009 4:19 PM
Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt

Hello PCE members.

As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document?

Thanks for expressing your minds,

JP & Julien
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--Boundary_(ID_oNfFIbyImCimArSkSxutWA)-- From jonas.martensson@acreo.se Mon Sep 7 04:18: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 52E543A63EC for ; Mon, 7 Sep 2009 04:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZhLCCoAAIzj for ; Mon, 7 Sep 2009 04:18:38 -0700 (PDT) Received: from dkcphmx24.softcom.dk (dkcphmx24.softcom.dk [194.192.15.188]) by core3.amsl.com (Postfix) with ESMTP id 77CF63A68A1 for ; Mon, 7 Sep 2009 04:18:36 -0700 (PDT) Received: (qmail 7951 invoked by uid 74); 7 Sep 2009 11:19:00 -0000 Received: from mail.acreo.se (217.151.195.216) by dkcphmx24.softcom.dk (envelope-from ) with ESMTP. tag msg.1252322339.977098.5426 (Processed in 0.244215 secs); 07 Sep 2009 11:19:00 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by dkcphmx24.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by dkcphmx24.softcom.dk over TLS secured channel with (RC4-MD5 encrypted) ESMTPS; Mon, 07 Sep 2009 13:18:59 +0200 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Mon, 7 Sep 2009 13:18:59 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: "julien.meuric@orange-ftgroup.com" , "pce@ietf.org" Date: Mon, 7 Sep 2009 13:18:58 +0200 Thread-Topic: Poll on draft-lee-pce-wson-routing-wavelength-05.txt Thread-Index: Acovk96pDBztp1ZtTU2XEH/zTA7kawAGF3Eg Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF43787012C68FEB98C@acreoexc01.ad.acreo.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 11:18:39 -0000 Yes, I support (as a co-author). Regards, Jonas > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On=20 > Behalf Of julien.meuric@orange-ftgroup.com > Sent: den 7 september 2009 10:19 > To: pce@ietf.org > Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt >=20 > Hello PCE members. >=20 > As you probably now, CCAMP has already endorsed some WSON and=20 > RWA as working items. In the same context,=20 > draft-lee-pce-wson-routing-wavelength-05.txt put some=20 > requirements on PCEP. Do you think we should now take this=20 > I-D as a WG document? >=20 > Thanks for expressing your minds, >=20 > JP & Julien > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >=20 > = From gregb@grotto-networking.com Mon Sep 7 10:38:36 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 D4EDD3A692E for ; Mon, 7 Sep 2009 10:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=-1.001, 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 va6O1vK29YAJ for ; Mon, 7 Sep 2009 10:38:36 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id 2E1043A68B8 for ; Mon, 7 Sep 2009 10:38:36 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n87HcmBf011931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Sep 2009 10:38:52 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4AA5452A.1010308@grotto-networking.com> Date: Mon, 07 Sep 2009 10:38:50 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: julien.meuric@orange-ftgroup.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 17:38:36 -0000 Yes (as a co-author). Greg B. julien.meuric@orange-ftgroup.com wrote: > Hello PCE members. > > As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? > > Thanks for expressing your minds, > > JP & Julien > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From qzhao@huawei.com Mon Sep 7 14:54:55 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 30A813A6A34 for ; Mon, 7 Sep 2009 14:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqRBCCCY1qXP for ; Mon, 7 Sep 2009 14:54:54 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 5A5F43A689A for ; Mon, 7 Sep 2009 14:54:54 -0700 (PDT) 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 <0KPM00FEMFK9ST@usaga04-in.huawei.com> for pce@ietf.org; Mon, 07 Sep 2009 16:55:22 -0500 (CDT) Received: from huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPM00CL5FK99B@usaga04-in.huawei.com> for pce@ietf.org; Mon, 07 Sep 2009 16:55:21 -0500 (CDT) Received: from [172.24.1.3] (Forwarded-For: [124.193.198.2]) by usams01-in.huawei.com (mshttpd); Tue, 08 Sep 2009 05:55:21 +0800 Date: Tue, 08 Sep 2009 05:55:21 +0800 From: ZhaoQianglin 73671 In-reply-to: To: pce@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: Cc: qzhao@huawei.com Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 21:54:55 -0000 Yes, I support. Regards, Quintin > > Hello PCE members. > > As you probably now, CCAMP has already endorsed some WSON and RWA > as working items. In the same context, draft-lee-pce-wson-routing- > wavelength-05.txt put some requirements on PCEP. Do you think we > should now take this I-D as a WG document? > > Thanks for expressing your minds, > > JP & Julien > > From i-nishioka@cb.jp.nec.com Tue Sep 8 06:15:01 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 36F903A6997 for ; Tue, 8 Sep 2009 06:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.324 X-Spam-Level: ** X-Spam-Status: No, score=2.324 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 MyGIZlPl6PUk for ; Tue, 8 Sep 2009 06:15:00 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id 25D903A69A3 for ; Tue, 8 Sep 2009 06:15:00 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.161]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n88DEo2O019917; Tue, 8 Sep 2009 22:14:50 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id n88DEoF04576; Tue, 8 Sep 2009 22:14:50 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id n88DEnAG003338; Tue, 8 Sep 2009 22:14:49 +0900 (JST) Received: from komachi.jp.nec.com ([10.26.220.10] [10.26.220.10]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-1797681; Tue, 8 Sep 2009 22:14:29 +0900 Received: from C08AUG00201 ([10.56.131.165] [10.56.131.165]) by mail.jp.nec.com with ESMTP; Tue, 8 Sep 2009 22:14:29 +0900 From: "Itaru Nishioka" To: "'Filippo Cugini'" , References: In-Reply-To: Date: Tue, 8 Sep 2009 22:14:29 +0900 Organization: NEC Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acor7VqOpPYQ5iOWSuiWRch4pprvgQEjvV5Q X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [Pce] Working Group Last Call:draft-ietf-pce-pcep-svec-list-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: i-nishioka@cb.jp.nec.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 13:15:01 -0000 Hi Filippo Thank you for comments. For independent request, it is not required to reply all combinations (just 3 EROs replied in section 6.2), because they are independent path computation.For dependent request, let me clarify your points. - For dependent (associated) diverse path requests in a single domain, concurrent path computation are required to meet good resource usage or maximize disjointness between diverse path pair. - When this concept is applied across PCE domains, downstream PCE must reply full combinations of potential path to meet same objective above, because final path decision would be made in upstream PCE using BRPC procedure. The second point was a reason why dependent diverse path request replied so much EROs (9 EROs). Right? If clarification above is correct, the same solution as in the independent case can be applied. This is because downstream PCE have responsibility on optimization of own domain, not upstream PCE. So the downstream PCE can choose suitable EROs set (just 3 EROs in section 6.2 example) based on own policy. Other typos will be revised in next version. Thank you. == Itaru Nishioka, > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On > Behalf Of Filippo Cugini > Sent: Thursday, September 03, 2009 1:47 AM > To: pce@ietf.org > Subject: Re: [Pce] Working Group Last > Call:draft-ietf-pce-pcep-svec-list-02.txt > > Hi, > > just one clarification in the case of multiple associated > end-to-end diverse path computations. > Example: consider one additional end-to-end diverse path > computation (say Requests #3 and #4, source S2 and dest. D2) > associated to the diverse path computation S1-D1 reported in > section 6. > The EROs computed for Req #1 and #2 (those in section 6.2) > may be related to the EROs computed for Req #3 and #4. > Thus, up to 9 EROs per request could be necessary in each path list. > However, if the two sets of computed EROs are independent, up > to 3 EROs per request would be sufficient (as in 6.2). > Is it required to enclose in the PCRep message all the > combinations (even if they are independent)? > > Few typos: > - section 4.1, "may in the SVEC may" > - 6.2, last line, VSPT2 -> VSPT3 > - 6.3, VSTP -> VSPT > > Br, > Filippo > > > > ----- Original Message ----- > From: "JP Vasseur" > To: > Sent: Tuesday, September 01, 2009 8:30 PM > Subject: [Pce] Working Group Last Call: > draft-ietf-pce-pcep-svec-list-02.txt > > > > Dear all, > > > > This starts a 2-week WG Last Call for draft-ietf-pce-pcep-svec- > > list-02.txt, which has been stable for quite some time, and > is ready for > > WG Last call. Please send your comments by September 16, > 9:00am ET on the > > mailing list. > > > > We would also welcome feed-back from potential implementers. > > > > Thanks. > > > > JP and Julien. > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From ylee@huawei.com Tue Sep 8 08:13:37 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 284293A68B4 for ; Tue, 8 Sep 2009 08:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 bFtMLe4jpcTF for ; Tue, 8 Sep 2009 08:13:36 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 710023A69B4 for ; Tue, 8 Sep 2009 08:13:36 -0700 (PDT) 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 <0KPN006XORNFD6@usaga04-in.huawei.com> for pce@ietf.org; Tue, 08 Sep 2009 10:14:04 -0500 (CDT) Received: from L73682 ([10.124.12.76]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPN00JSMRN69M@usaga04-in.huawei.com> for pce@ietf.org; Tue, 08 Sep 2009 10:14:03 -0500 (CDT) Date: Tue, 08 Sep 2009 10:13:53 -0500 From: Young Lee In-reply-to: To: pce@ietf.org Message-id: <001e01ca3096$fbc156e0$4c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acov7YpypMwGO7UcSzmTHxsMwiKsEgAqPTjw References: Subject: [Pce] Subject: Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 15:13:37 -0000 Yes, support. Young (co-author) ---------------------------------------- Date: Mon, 7 Sep 2009 10:19:07 +0200 From: Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt To: Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hello PCE members. As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? Thanks for expressing your minds, JP & Julien From anders.gavler@acreo.se Tue Sep 8 11:17: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 D8F2E28C178 for ; Tue, 8 Sep 2009 11:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=2.410, BAYES_00=-2.599, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwThK00ObGTe for ; Tue, 8 Sep 2009 11:17:15 -0700 (PDT) Received: from dkcphmx24.softcom.dk (dkcphmx24.softcom.dk [194.192.15.188]) by core3.amsl.com (Postfix) with ESMTP id 84F7C28C12B for ; Tue, 8 Sep 2009 11:17:13 -0700 (PDT) Received: from mail.acreo.se (217.151.195.216) by dkcphmx24.softcom.dk (envelope-from ) with ESMTP. tag msg.1252433863.487237.27692 (Processed in 0.078261 secs); 08 Sep 2009 18:17:43 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by dkcphmx24.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by dkcphmx24.softcom.dk over TLS secured channel with (RC4-MD5 encrypted) ESMTPS; Tue, 08 Sep 2009 20:17:43 +0200 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Tue, 8 Sep 2009 20:17:43 +0200 From: Anders Gavler To: "pce@ietf.org" Date: Tue, 8 Sep 2009 20:17:42 +0200 Thread-Topic: Poll on draft-lee-pce-wson-routing-wavelength-05.txt Thread-Index: Acovk96pDBztp1ZtTU2XEH/zTA7kawBBBwngAAXXjCA= Message-ID: <73B74934786FBB4F951B5F99724CEB60A3769777E9@acreoexc01.ad.acreo.se> References: <1EC35EEAF3A9FA439C7D6AE45BF43787012C68FEBA0F@acreoexc01.ad.acreo.se> In-Reply-To: <1EC35EEAF3A9FA439C7D6AE45BF43787012C68FEBA0F@acreoexc01.ad.acreo.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 18:17:15 -0000 Yes I do. /Anders > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > julien.meuric@orange-ftgroup.com > Sent: den 7 september 2009 10:19 > To: pce@ietf.org > Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt >=20 > Hello PCE members. >=20 > As you probably now, CCAMP has already endorsed some WSON and RWA as > working items. In the same context, draft-lee-pce-wson-routing-wavelength= - > 05.txt put some requirements on PCEP. Do you think we should now take thi= s > I-D as a WG document? >=20 > Thanks for expressing your minds, >=20 > JP & Julien > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From zhangfatai@huawei.com Tue Sep 8 23:04:43 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 0E6573A67F5 for ; Tue, 8 Sep 2009 23:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.907 X-Spam-Level: * X-Spam-Status: No, score=1.907 tagged_above=-999 required=5 tests=[AWL=2.401, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYQ0mE3ps9Qj for ; Tue, 8 Sep 2009 23:04:42 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 2C4DE3A67B1 for ; Tue, 8 Sep 2009 23:04:42 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPO009S7WWFSF@szxga02-in.huawei.com> for pce@ietf.org; Wed, 09 Sep 2009 14:05:03 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPO0047NWWFCD@szxga02-in.huawei.com> for pce@ietf.org; Wed, 09 Sep 2009 14:05:03 +0800 (CST) Received: from z41162b ([10.70.76.91]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPO00KG3WWFNS@szxml06-in.huawei.com> for pce@ietf.org; Wed, 09 Sep 2009 14:05:03 +0800 (CST) Date: Wed, 09 Sep 2009 14:05:02 +0800 From: Fatai Zhang To: julien.meuric@orange-ftgroup.com Message-id: <032601ca3113$78901a90$5b4c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_+CyuznVfOTOK+suKKCBDlg)" X-Priority: 3 X-MSMail-priority: Normal References: Cc: pce@ietf.org Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 06:04:43 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+CyuznVfOTOK+suKKCBDlg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Yes, I support. Fatai ----- Original Message ----- From: julien.meuric@orange-ftgroup.com To: pce@ietf.org Sent: Monday, September 07, 2009 4:19 PM Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt Hello PCE members. As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? Thanks for expressing your minds, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_+CyuznVfOTOK+suKKCBDlg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Yes, I support.
 
 
Fatai
 
----- Original Message -----
Sent: Monday, September 07, 2009 4:19 PM
Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt

Hello PCE members.

As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document?

Thanks for expressing your minds,

JP & Julien
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--Boundary_(ID_+CyuznVfOTOK+suKKCBDlg)-- From sureshbr@huawei.com Wed Sep 9 03:33:08 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 978F328C1FB for ; Wed, 9 Sep 2009 03:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS0NY1NTmete for ; Wed, 9 Sep 2009 03:33:08 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CC3F628C1E2 for ; Wed, 9 Sep 2009 03:33:07 -0700 (PDT) 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 <0KPP001BS97002@szxga04-in.huawei.com> for pce@ietf.org; Wed, 09 Sep 2009 18:30:36 +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 <0KPP00KKC970A9@szxga04-in.huawei.com> for pce@ietf.org; Wed, 09 Sep 2009 18:30:36 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPP006AF96YF4@szxml04-in.huawei.com> for pce@ietf.org; Wed, 09 Sep 2009 18:30:36 +0800 (CST) Date: Wed, 09 Sep 2009 16:00:23 +0530 From: Suresh In-reply-to: To: pce@ietf.org Message-id: <002001ca3138$91b3a6c0$1f01120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acovk96pDBztp1ZtTU2XEH/zTA7kawBpHZwg References: Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 10:33:08 -0000 I support. ____________________________________________________________________________ ____ This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of julien.meuric@orange-ftgroup.com Sent: Monday, September 07, 2009 1:49 PM To: pce@ietf.org Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt Hello PCE members. As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? Thanks for expressing your minds, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From giomarti@cisco.com Wed Sep 9 06:05:59 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 1042628C467 for ; Wed, 9 Sep 2009 06:05:59 -0700 (PDT) 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=[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 AILgIY+IfKmW for ; Wed, 9 Sep 2009 06:05:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E540F28C3DC for ; Wed, 9 Sep 2009 06:05:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMAACFFp0qQ/uCKe2dsb2JhbACbQgEBFiQGqQaIQwGQWQWEGA X-IronPort-AV: E=Sophos;i="4.44,358,1249257600"; d="scan'208";a="48973130" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Sep 2009 13:06:29 +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 n89D6TLB002532; Wed, 9 Sep 2009 15:06:29 +0200 Received: from [144.254.172.180] (mnza1-dhcp-vl250-144-254-172-180.cisco.com [144.254.172.180]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n89D6Sox011622; Wed, 9 Sep 2009 13:06:29 GMT Message-ID: <4AA7A855.4000304@cisco.com> Date: Wed, 09 Sep 2009 15:06:29 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: julien.meuric@orange-ftgroup.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=529; t=1252501589; x=1253365589; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re=3A=20[Pce]=20Poll=20on=20draft-lee-pce-wson- routing-wavelength-05.txt |Sender:=20; bh=1gISJNE4BHw3DL6fEgvLXcPswp4YaKrATk7dPiY6K+Q=; b=q64B2lGmvhAyzs50PdxZWLE1vNmeRdnow27cCKVTFXS/1SiDw7V4pUpvoL MinTuBO9APtGZX4PwjhTzPicv00b0ObtJsSdO6iSI3R4k5zsMfJ1gDmAXv6T mTJITAZREY; Authentication-Results: ams-dkim-1; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: pce@ietf.org Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 13:05:59 -0000 support Cheers G julien.meuric@orange-ftgroup.com wrote: > Hello PCE members. > > As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? > > Thanks for expressing your minds, > > JP & Julien > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From julien.meuric@orange-ftgroup.com Wed Sep 9 08:12: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 12EC228C256 for ; Wed, 9 Sep 2009 08:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=0.747, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 4v-imteUw6GF for ; Wed, 9 Sep 2009 08:11:59 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 8E59528C2D5 for ; Wed, 9 Sep 2009 08:11:58 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 17:12:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2009 17:12:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available Thread-Index: AcoxW435hhZUN9avSOu73t+gOTOW0QAAosjQ From: To: X-OriginalArrivalTime: 09 Sep 2009 15:12:29.0225 (UTC) FILETIME=[F26B4190:01CA315F] Subject: [Pce] FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available 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, 09 Sep 2009 15:12:00 -0000 Hi. For your information and, possibly, action. Keep in mind that this significant step for the IETF has a strong impact on the Routing Area as Ross' position is on the table (and we cannot nominate Adrian again). Regards, Julien -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of Mary Barnes Hi all, This is a 2nd reminder of the Call for Nominations that is underway. We *really* need more nominations in order to properly execute the task of selecting candidates for the open positions. At this time, the number of nominations for all the positions is about 1/2 of what is necessary for the Nomcom to do a conscientious job of evaluating the nominees and we are over 2/3 of the way through the nominations period. Nomcom cannot do their job without this important input from the community.=20 So, please consider making nominations for the open positions - it takes just a few minutes of your time - the details are below. Right now, we just need the names/email addresses for the nominees - we'll be soliciting feedback later. Also, consider that over 1/2 the nominees are not able to accept the nominations for a variety of reasons - e.g., lack of funding, lack of sponsor support, etc. Thus, please consider nominating more than one individual for each of the positions. =20 As well as the reminder for the call for nominations, this email also serves as a reminder for: 2) Local Office Hours 3) Questionnaires available for nominees=20 Best Regards,=20 Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D 1) Call for Nominations ------------------------ The nomination period ends in less than 2 weeks on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's fast, easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ Please consider that the sooner you make the nominations, the more time your nominee(s) will have to complete the necessary questionnaire (item 3 below). As well, please consider nominating more than one person for a particular position. You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination.=20 2) Local office hours ----------------------- In order facilitate additional feedback, the Nomcom has decided to make themselves available for office areas at various geographic locations for 3 weeks in September, starting on the 8th.=20 Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. =20 Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. =20 As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback.=20 Belgium:=20 Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French)=20 Boston, Mass, USA: =20 Stephen Kent - kent@bbn.com (Sept 16-18)=20 Boulder, CO, USA:=20 Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: =20 Mary Barnes - mary.h.barnes@gmail.com=20 Lucy Yong - lucyyong@huawei.com (Languages: Chinese)=20 Helsinki, Finland:=20 Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) =20 Ithaca, NY, USA:=20 Scott Brim - scott.brim@gmail.com Montevideo, Uruguay:=20 Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese)=20 Montreal, Quebec, Canada=20 Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested=20 Paris, France:=20 Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA:=20 Randall Gellens - rg+ietf@qualcomm.com =20 Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA:=20 Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) =20 Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees:=20 For folks that have been notified that they have been nominated for any of the positions, the questionnaires are now available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire If you have any questions, please let me know. I will be contacting everyone individually, as well as sending reminders.=20 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From julien.meuric@orange-ftgroup.com Wed Sep 9 10:42: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 1A88428C2D4 for ; Wed, 9 Sep 2009 10:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=1.323, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, J_CHICKENPOX_84=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 xbny9tJ00yuj for ; Wed, 9 Sep 2009 10:42:04 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 39B3E28C2C6 for ; Wed, 9 Sep 2009 10:42:01 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 19:42:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2009 19:42:32 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.txt Thread-Index: AcorpHfQSzapIFyVSeG399y9CymMqQFvMxTA References: From: To: , X-OriginalArrivalTime: 09 Sep 2009 17:42:32.0977 (UTC) FILETIME=[E912C810:01CA3174] Cc: pce@ietf.org Subject: Re: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.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, 09 Sep 2009 17:42:07 -0000 Hi Itaru, hi Dan. Here are some comments on draft-ietf-pce-pcep-svec-list-02, mostly editorial (some of them were already pointed out by Filippo). As a non native English speaker, some of them may be irrelevant but one of the authors being native, I am sure we will find kingly solutions. -------------------- As recommended (http://www.ietf.org/mail-archive/web/pce/current/msg02045.html), move the abstract on the 1st page, before the "Status of this Memo". -------------------- (Current) Page 2 ---------- OLD: protected path do not share common network points NEW: protected path which do not share common network points (alt NEW: protected path not sharing common network points) ---------- OLD: the working and protected path disjoint objective NEW: the working and protected path diversity/disjunction/disjointness objective -> The term can be discussed, but I feel more comfortable with a noun rather than an adjective. -------------------- Page 3 ---------- OLD: PCEP facilitates NEW: PCEP specifies/defines/standardizes... (Facilitates the interworking, not the communication.) ---------- OLD: reoptimize a set of service NEW: reoptimize a set of services -------------------- Page 4 ---------- OLD: o Single domain, multiple-PCE NEW: o Single domain, multi-PCE + alignment to the left to be adjusted -------------------- Page 5 ---------- OLD: The association among multiple SVECs for multiple sets of synchronized dependent path computation and disjoint VSPT encoding rule for end-to-end diverse path computation across domains are also described in this document. NEW: The association among multiple SVECs for multiple sets of synchronized dependent path computation is also described in this document as well as the disjoint VSPT encoding rule for end-to-end diverse path computation across domains. + Appart from the terminology section, this is the 1st occurrence of VSTP. As other acronyms are expanded the 1st time you use them, VSTP should also be expanded here. ---------- OLD: scenarios are out of scope in this document NEW: scenarios are out of the scope of this document ---------- OLD: The SVEC association and disjoint VSPT are available to both multiple PCE path computations as well as a single PCE path computation. NEW: The SVEC association and disjoint VSPT are available to both multi-PCE path computation and single PCE path=20 computation. (alt NEW: The SVEC association and disjoint VSPT are available to multi-PCE path computation as well as single PCE path computation.) ---------- OLD: When computing two or more point-to-point diverse paths, a PCE may compute these diverse paths concurrently NEW: A PCE may compute two or more point-to-point diverse paths concurrently ---------- OLD: primary and secondary path disjoint objective NEW: primary and secondary path diversity/disjunction/disjointness objective (as above) -------------------- Page 6 ---------- For point-to-multipoint path requests,SVEC association can be applied. -> missing space before "SVEC". ---------- OLD: point-to-multipoint paths and its secondary paths NEW: Point-to-multipoint paths and their secondary paths (capital letter + "their") -------------------- Page 7 ---------- OLD: Associated SVECs mean that NEW: Associated SVECs means that (alt NEW: "Associated SVECs" means that) ---------- OLD: only one request-ID may in the SVEC object NEW: only one request-ID in the SVEC object ---------- OLD: all of the path computation requests NEW: all the path computation requests ---------- OLD: the first SVEC is associating the other SVECs NEW: the first SVEC is associated with the other SVECs -------------------- Page 8 ---------- OLD: When PCEP receives NEW: When a PCE receives ---------- OLD: requests between multiple PCE`s NEW: requests between multiple PCEs -------------------- Page 9 ---------- OLD: Furthermore, if the PCReq message contains multiple associated SVEC objects and these SVEC objects contain path computation requests that will be sent to the next PCE along the path computation chain. NEW: Furthermore, if the PCReq message contains multiple associated SVEC objects and these SVEC objects contain path computation requests that will be sent to the next PCE along the path computation chain, the following procedure applies. ---------- OLD: received from neighbor PCEs NEW: received from all neighbor PCEs ---------- OLD: network operator`s point of view NEW: network operator's point of view ---------- The 2-step approach is described in [RFC5521]. -> No strong opinion here, but I find it easier to read for human beings when recalling what stands behind a RFC number (just as you do for RFC 5520 on page 11). For instance, you could append "and uses eXclude Route Object (XRO)" to the sentence. ---------- OLD: VSPT (virtual shortest path tree) NEW: VSPT -> Expansion should be sent to the introduction (see above). -> I like it with capital letters where appropriate. ---------- OLD: disjoint information among the potential paths NEW: diversity/disjunction/disjointness information among the potential paths ---------- OLD: to preserve disjoint information NEW: to preserve diversity/disjunction/disjointness information -------------------- Page 10 ---------- OLD: boarder nodes NEW: border nodes ---------- OLD: BR5 NEW: BN5 (on Figure-1) ---------- OLD: Figure-1; NEW: Figure-1: ---------- OLD: VSPTx; NEW: VSPTx: (3 times on Figure-2) ---------- OLD: BRx NEW: BNx (6 times on Figure-2) ---------- OLD: Figure-2; NEW: Figure-2: -------------------- Page 11 ---------- RP object; EROs -> Mentioned for the 1st time in the document, expansions would be welcome. ---------- OLD: Detail disjoint VSPT encoding NEW: Detailled disjoint VSPT encoding ---------- The 2 lines starting with "ERO1" and "ERO2" need to be brought into alignment. ---------- OLD: BRx NEW: BNx (6 times) ---------- OLD: ERO6... [for VSPT2] NEW: ERO6... [for VSPT3] ---------- OLD: PCE sending PCreq NEW: PCE sending PCReq -------------------- Page 12 ---------- OLD: If PCreq has NEW: If PCReq has ---------- OLD: the received PCrep NEW: the received PCRep ---------- OLD: the received VSTP NEW: the received VSPT ---------- o the capability to configure SVEC association. -> Should be deleted. -------------------- Page 13 ---------- OLD: the security of this document depends on that of PCEP protocol NEW: the security of the procedures described in this document depends on PCEP protocol -> We could discuss "the security of this document", but it will require a few beers... And yes, some people actually read the security section! ;-) -------------------- Page 15 ---------- Dan's address is just "UK", which I am perfectly fine with since noone ever needs to contact Old Dog Consulting, especially in the Routing Area. ---------- Good luck for the update, Julien -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Dear all, This starts a 2-week WG Last Call for draft-ietf-pce-pcep-svec-=20 list-02.txt, which has been stable for quite some time, and is ready =20 for WG Last call. Please send your comments by September 16, 9:00am ET =20 on the mailing list. We would also welcome feed-back from potential implementers. Thanks. JP and Julien. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From vishwas.ietf@gmail.com Wed Sep 9 11:39:57 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 E37CC3A6B1F for ; Wed, 9 Sep 2009 11:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 jdJqpiNvL1Ob for ; Wed, 9 Sep 2009 11:39:56 -0700 (PDT) Received: from mail-yw0-f203.google.com (mail-yw0-f203.google.com [209.85.211.203]) by core3.amsl.com (Postfix) with ESMTP id 3B71D3A6A9A for ; Wed, 9 Sep 2009 11:39:56 -0700 (PDT) Received: by ywh41 with SMTP id 41so5142626ywh.31 for ; Wed, 09 Sep 2009 11:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=6yMPHms49htnK7AFCiDG0dPOm+EA9RQedBxq8dCm9tg=; b=b0HEfuuLK1Rl0HK2MU2IUn8pQQnqLtWef/QzFADet6r0DmBijL/qXa40HwQc+uf41M 2/uBLb9OwekmXR8N7o146TNwRv1WNRSsif58u7NZXtXYJZDTmIOrmZRKCBxyhD7QU1eN oXl74f8+UXk/mhJwnTIEWO0NvkeSQo2F0bDkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=w/v2VBmFj2rVelHFNsl5VghBFcGGI16Ioq49a8nSjLhJWcJFkofk8xh9BcXo9zq0Xn AgjxLDIiKbX2fT9si3UaS/v5clisyziE+SOe8wFPJPhrEvVuDLNawAni+FHMr9G2rONK dM/TS1zr6TRT1aV0pyb4WlrHYigcrKWTqcA+A= MIME-Version: 1.0 Received: by 10.150.48.42 with SMTP id v42mr1079278ybv.65.1252521625588; Wed, 09 Sep 2009 11:40:25 -0700 (PDT) Date: Wed, 9 Sep 2009 11:40:25 -0700 Message-ID: <77ead0ec0909091140s2e5a41dbke3e8abb719b74115@mail.gmail.com> From: Vishwas Manral To: pce@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [Pce] PCE port number 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, 09 Sep 2009 18:39:58 -0000 Hi, I looked at the following in the spec: =93Transport Protocol PCEP operates over TCP using a registered TCP port (4189). This allows the requirements of reliable messaging and flow control to be met without further protocol work. All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port.=94 This has been worrying me a bit. Unlike other protocols like BGP or LDP In BGP it states clearly: A BGP implementation MUST connect to and listen on TCP port 179 for incoming connections in addition to trying to connect to peers. and BGP's destination port SHOULD be port 179, as defined by IANA. Why do we have this restriction on source port? It is becoming a challenging task in merchant OS. Thanks, Vishwas Vishwas From daniel@olddog.co.uk Wed Sep 9 14:36:18 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 1D1B73A6908 for ; Wed, 9 Sep 2009 14:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=1.925, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_84=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 cqYILaKTXvRk for ; Wed, 9 Sep 2009 14:36:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 4B17C28C190 for ; Wed, 9 Sep 2009 14:36:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n89LaT2I030389; Wed, 9 Sep 2009 22:36:34 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n89LaSHl030382; Wed, 9 Sep 2009 22:36:28 +0100 From: "Daniel King" To: , References: In-Reply-To: Date: Wed, 9 Sep 2009 22:36:37 +0100 Message-ID: <000f01ca3195$9cf41350$d6dc39f0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcorpHfQSzapIFyVSeG399y9CymMqQFvMxTAAA0D4oA= Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.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, 09 Sep 2009 21:36:18 -0000 Thanks Julien, good comments. We will take these and Filippo's and update accordingly. Br, Dan. -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of julien.meuric@orange-ftgroup.com Sent: 09 September 2009 18:43 To: i-nishioka@cb.jp.nec.com; daniel@olddog.co.uk Cc: pce@ietf.org Subject: Re: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.txt Hi Itaru, hi Dan. Here are some comments on draft-ietf-pce-pcep-svec-list-02, mostly editorial (some of them were already pointed out by Filippo). As a non native English speaker, some of them may be irrelevant but one of the authors being native, I am sure we will find kingly solutions. -------------------- As recommended (http://www.ietf.org/mail-archive/web/pce/current/msg02045.html), move the abstract on the 1st page, before the "Status of this Memo". -------------------- (Current) Page 2 ---------- OLD: protected path do not share common network points NEW: protected path which do not share common network points (alt NEW: protected path not sharing common network points) ---------- OLD: the working and protected path disjoint objective NEW: the working and protected path diversity/disjunction/disjointness objective -> The term can be discussed, but I feel more comfortable with a noun rather than an adjective. -------------------- Page 3 ---------- OLD: PCEP facilitates NEW: PCEP specifies/defines/standardizes... (Facilitates the interworking, not the communication.) ---------- OLD: reoptimize a set of service NEW: reoptimize a set of services -------------------- Page 4 ---------- OLD: o Single domain, multiple-PCE NEW: o Single domain, multi-PCE + alignment to the left to be adjusted -------------------- Page 5 ---------- OLD: The association among multiple SVECs for multiple sets of synchronized dependent path computation and disjoint VSPT encoding rule for end-to-end diverse path computation across domains are also described in this document. NEW: The association among multiple SVECs for multiple sets of synchronized dependent path computation is also described in this document as well as the disjoint VSPT encoding rule for end-to-end diverse path computation across domains. + Appart from the terminology section, this is the 1st occurrence of VSTP. As other acronyms are expanded the 1st time you use them, VSTP should also be expanded here. ---------- OLD: scenarios are out of scope in this document NEW: scenarios are out of the scope of this document ---------- OLD: The SVEC association and disjoint VSPT are available to both multiple PCE path computations as well as a single PCE path computation. NEW: The SVEC association and disjoint VSPT are available to both multi-PCE path computation and single PCE path computation. (alt NEW: The SVEC association and disjoint VSPT are available to multi-PCE path computation as well as single PCE path computation.) ---------- OLD: When computing two or more point-to-point diverse paths, a PCE may compute these diverse paths concurrently NEW: A PCE may compute two or more point-to-point diverse paths concurrently ---------- OLD: primary and secondary path disjoint objective NEW: primary and secondary path diversity/disjunction/disjointness objective (as above) -------------------- Page 6 ---------- For point-to-multipoint path requests,SVEC association can be applied. -> missing space before "SVEC". ---------- OLD: point-to-multipoint paths and its secondary paths NEW: Point-to-multipoint paths and their secondary paths (capital letter + "their") -------------------- Page 7 ---------- OLD: Associated SVECs mean that NEW: Associated SVECs means that (alt NEW: "Associated SVECs" means that) ---------- OLD: only one request-ID may in the SVEC object NEW: only one request-ID in the SVEC object ---------- OLD: all of the path computation requests NEW: all the path computation requests ---------- OLD: the first SVEC is associating the other SVECs NEW: the first SVEC is associated with the other SVECs -------------------- Page 8 ---------- OLD: When PCEP receives NEW: When a PCE receives ---------- OLD: requests between multiple PCE`s NEW: requests between multiple PCEs -------------------- Page 9 ---------- OLD: Furthermore, if the PCReq message contains multiple associated SVEC objects and these SVEC objects contain path computation requests that will be sent to the next PCE along the path computation chain. NEW: Furthermore, if the PCReq message contains multiple associated SVEC objects and these SVEC objects contain path computation requests that will be sent to the next PCE along the path computation chain, the following procedure applies. ---------- OLD: received from neighbor PCEs NEW: received from all neighbor PCEs ---------- OLD: network operator`s point of view NEW: network operator's point of view ---------- The 2-step approach is described in [RFC5521]. -> No strong opinion here, but I find it easier to read for human beings when recalling what stands behind a RFC number (just as you do for RFC 5520 on page 11). For instance, you could append "and uses eXclude Route Object (XRO)" to the sentence. ---------- OLD: VSPT (virtual shortest path tree) NEW: VSPT -> Expansion should be sent to the introduction (see above). -> I like it with capital letters where appropriate. ---------- OLD: disjoint information among the potential paths NEW: diversity/disjunction/disjointness information among the potential paths ---------- OLD: to preserve disjoint information NEW: to preserve diversity/disjunction/disjointness information -------------------- Page 10 ---------- OLD: boarder nodes NEW: border nodes ---------- OLD: BR5 NEW: BN5 (on Figure-1) ---------- OLD: Figure-1; NEW: Figure-1: ---------- OLD: VSPTx; NEW: VSPTx: (3 times on Figure-2) ---------- OLD: BRx NEW: BNx (6 times on Figure-2) ---------- OLD: Figure-2; NEW: Figure-2: -------------------- Page 11 ---------- RP object; EROs -> Mentioned for the 1st time in the document, expansions would be welcome. ---------- OLD: Detail disjoint VSPT encoding NEW: Detailled disjoint VSPT encoding ---------- The 2 lines starting with "ERO1" and "ERO2" need to be brought into alignment. ---------- OLD: BRx NEW: BNx (6 times) ---------- OLD: ERO6... [for VSPT2] NEW: ERO6... [for VSPT3] ---------- OLD: PCE sending PCreq NEW: PCE sending PCReq -------------------- Page 12 ---------- OLD: If PCreq has NEW: If PCReq has ---------- OLD: the received PCrep NEW: the received PCRep ---------- OLD: the received VSTP NEW: the received VSPT ---------- o the capability to configure SVEC association. -> Should be deleted. -------------------- Page 13 ---------- OLD: the security of this document depends on that of PCEP protocol NEW: the security of the procedures described in this document depends on PCEP protocol -> We could discuss "the security of this document", but it will require a few beers... And yes, some people actually read the security section! ;-) -------------------- Page 15 ---------- Dan's address is just "UK", which I am perfectly fine with since noone ever needs to contact Old Dog Consulting, especially in the Routing Area. ---------- Good luck for the update, Julien -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Dear all, This starts a 2-week WG Last Call for draft-ietf-pce-pcep-svec- list-02.txt, which has been stable for quite some time, and is ready for WG Last call. Please send your comments by September 16, 9:00am ET on the mailing list. We would also welcome feed-back from potential implementers. Thanks. JP and Julien. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From takeda.tomonori@lab.ntt.co.jp Wed Sep 9 17:37:19 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 BA0E73A6934 for ; Wed, 9 Sep 2009 17:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.769 X-Spam-Level: * X-Spam-Status: No, score=1.769 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 qHJ45vibeekI for ; Wed, 9 Sep 2009 17:37:18 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id AB10B3A68CC for ; Wed, 9 Sep 2009 17:37:18 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.3/8.14.3) with ESMTP id n8A0bpD1027866; Thu, 10 Sep 2009 09:37:51 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 886B85E64; Thu, 10 Sep 2009 09:37:51 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 75CCD5C66; Thu, 10 Sep 2009 09:37:51 +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 n8A0bjGc007951; Thu, 10 Sep 2009 09:37:51 +0900 (JST) Message-ID: <4AA84A12.7010504@lab.ntt.co.jp> Date: Thu, 10 Sep 2009 09:36:34 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: julien.meuric@orange-ftgroup.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 00:37:19 -0000 Yes (as a co-author). Tomonori julien.meuric@orange-ftgroup.com wrote: > Hello PCE members. > > As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? > > Thanks for expressing your minds, > > JP & Julien > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From julien.meuric@orange-ftgroup.com Thu Sep 10 01:57: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 646903A68F1 for ; Thu, 10 Sep 2009 01:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBQfrAwczUSw for ; Thu, 10 Sep 2009 01:57:02 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 2A1E73A67B6 for ; Thu, 10 Sep 2009 01:57:02 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 10:57:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Sep 2009 10:57:31 +0200 Message-ID: In-Reply-To: <77ead0ec0909091140s2e5a41dbke3e8abb719b74115@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] PCE port number Thread-Index: AcoxfQOoIMJkDKIQRYuZzhE35U+IqwAc4VoA References: <77ead0ec0909091140s2e5a41dbke3e8abb719b74115@mail.gmail.com> From: To: , , X-OriginalArrivalTime: 10 Sep 2009 08:57:33.0599 (UTC) FILETIME=[BC64E2F0:01CA31F4] Cc: pce@ietf.org Subject: Re: [Pce] PCE port number X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 08:57:03 -0000 Hi Vishwas. Interesting comment. We must admit the wording is a bit ambiguous. RFC 5440 says: "The system listens to the PCEP-registered TCP port" and = "Upon receiving a TCP connection on the PCEP-registered TCP port"; I do = not see any behavior description for the source TCP port (good thing!). My guess is that there is no intend to put constraints on the TCP = initiator port. I would interpret the sentence you mention as "using the = registered TCP port on the PCE side, i.e. for the source TCP port for = PCE to PCC messages and for destination TCP port for PCC to PCE = messages"... A little cumbersome, I agree. Authors of RFC 5440, would there be an actual intend to specify = otherwise? Implementers, any other interpretation? Thanks, Julien -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Vishwas Manral Hi, I looked at the following in the spec: =93Transport Protocol PCEP operates over TCP using a registered TCP port (4189). This allows the requirements of reliable messaging and flow control to be met without further protocol work. All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port.=94 This has been worrying me a bit. Unlike other protocols like BGP or LDP In BGP it states clearly: A BGP implementation MUST connect to and listen on TCP port 179 for incoming connections in addition to trying to connect to peers. and BGP's destination port SHOULD be port 179, as defined by IANA. Why do we have this restriction on source port? It is becoming a challenging task in merchant OS. Thanks, Vishwas Vishwas _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From diego.caviglia@ericsson.com Thu Sep 10 03:44:29 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 1AB093A67F2 for ; Thu, 10 Sep 2009 03:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.451 X-Spam-Level: X-Spam-Status: No, score=-4.451 tagged_above=-999 required=5 tests=[AWL=1.798, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 HWmUsuSfg7r2 for ; Thu, 10 Sep 2009 03:44:28 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0A2D23A635F for ; Thu, 10 Sep 2009 03:44:27 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2cae000005a8f-41-4aa8d8acdacb Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 92.DD.23183.CA8D8AA4; Thu, 10 Sep 2009 12:45:01 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 12:43:26 +0200 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, 10 Sep 2009 12:43:25 +0200 Message-ID: In-Reply-To: <4AA84A12.7010504@lab.ntt.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt thread-index: AcoxrvG/oaG7efkRTnCOm/Rx8ZUa5AAVIxGw References: <4AA84A12.7010504@lab.ntt.co.jp> From: "Diego Caviglia" To: "Tomonori TAKEDA" , X-OriginalArrivalTime: 10 Sep 2009 10:43:26.0205 (UTC) FILETIME=[86D7A2D0:01CA3203] X-Brightmail-Tracker: AAAAAA== Cc: pce@ietf.org Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 10:44:29 -0000 Yes also for me. Br diego -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Tomonori TAKEDA Sent: gioved=EC 10 settembre 2009 2.37 To: julien.meuric@orange-ftgroup.com Cc: pce@ietf.org Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt Yes (as a co-author). Tomonori julien.meuric@orange-ftgroup.com wrote: > Hello PCE members. >=20 > As you probably now, CCAMP has already endorsed some WSON and RWA as = working items. In the same context, = draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on = PCEP. Do you think we should now take this I-D as a WG document? >=20 > Thanks for expressing your minds, >=20 > JP & Julien > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >=20 >=20 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From vishwas.ietf@gmail.com Thu Sep 10 07:49:40 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 9CC203A6A08 for ; Thu, 10 Sep 2009 07:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 sEtVCVbUK-E6 for ; Thu, 10 Sep 2009 07:49:39 -0700 (PDT) Received: from mail-yw0-f195.google.com (mail-yw0-f195.google.com [209.85.211.195]) by core3.amsl.com (Postfix) with ESMTP id A21983A6A4C for ; Thu, 10 Sep 2009 07:49:39 -0700 (PDT) Received: by ywh33 with SMTP id 33so254352ywh.18 for ; Thu, 10 Sep 2009 07:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TnRZ2XoEBzHO/XHZSz7aDcuNsvl71SF9pzlIniVz6+Y=; b=RacMxyY4YUQRjSSuQt8h7CAXGW8AVd8RoyHc6M5M8Q/O1Xw4ZEPYK1PzyJdM4iOTeF BtAYOrvfiK4k8AbI0cvcgF+eLEKIwweWU/kCUyIBhR2rviSBE58SZTcGtHxXD8iOgIyp Ma70mpAF1M9xFhbM5HJmhLThOLrnu0BW+ilKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZkfGVtG4k6VVsth3y2f5eOE2OXxvCwwg5nR7RWgME2QmTJyqgwpMEblb3WWWy8vuLW xP3Gvf+GH1rB5n02Ia0HIL/2JO38dou5VVE3TCPIHfrIcppv1UQ1RoRr/VqtPjqaLqZA UrCfbr6swl5c9zdZzCbtxtj0qjV57bWkOtv8g= MIME-Version: 1.0 Received: by 10.150.45.20 with SMTP id s20mr2800064ybs.211.1252594211935; Thu, 10 Sep 2009 07:50:11 -0700 (PDT) In-Reply-To: References: <77ead0ec0909091140s2e5a41dbke3e8abb719b74115@mail.gmail.com> Date: Thu, 10 Sep 2009 07:50:11 -0700 Message-ID: <77ead0ec0909100750m49c00447i6ca9a7b6675a0652@mail.gmail.com> From: Vishwas Manral To: julien.meuric@orange-ftgroup.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, jpv@cisco.com Subject: Re: [Pce] PCE port number X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 14:49:40 -0000 Hi Julien, Thanks for your comment. I agree with it. I am actually concerned about the below statement which in my view means we have to use the same source and destination port: "All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port.=94 I believe the same may not be achieveable in a lot of merchant OS's in some of the cases. Can the implementors of the same please confirm if they are using the source and destination port as the PCE port? Thanks, Vishwas On Thu, Sep 10, 2009 at 1:57 AM, wrote: > Hi Vishwas. > > Interesting comment. We must admit the wording is a bit ambiguous. > > RFC 5440 says: "The system listens to the PCEP-registered TCP port" and "= Upon receiving a TCP connection on the PCEP-registered TCP port"; I do not = see any behavior description for the source TCP port (good thing!). > My guess is that there is no intend to put constraints on the TCP initiat= or port. I would interpret the sentence you mention as "using the registere= d TCP port on the PCE side, i.e. for the source TCP port for PCE to PCC mes= sages and for destination TCP port for PCC to PCE messages"... A little cum= bersome, I agree. > > Authors of RFC 5440, would there be an actual intend to specify otherwise= ? Implementers, any other interpretation? > > Thanks, > > Julien > > > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Vis= hwas Manral > > Hi, > > I looked at the following in the spec: > > =93Transport Protocol > > =A0PCEP operates over TCP using a registered TCP port (4189). =A0This > =A0allows the requirements of reliable messaging and flow control to be > =A0met without further protocol work. =A0All PCEP messages MUST be sent > =A0using the registered TCP port for the source and destination TCP > =A0port.=94 > > This has been worrying me a bit. Unlike other protocols like BGP or LDP > > In BGP it states clearly: > > =A0 A BGP implementation MUST connect to and listen on TCP port 179 for > =A0 incoming connections in addition to trying to connect to peers. > > and > > =A0 BGP's destination port SHOULD be port 179, as defined by IANA. > > Why do we have this restriction on source port? It is becoming a > challenging task > in merchant OS. > > Thanks, > Vishwas > Vishwas > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From julien.meuric@orange-ftgroup.com Fri Sep 11 02:41:29 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 0E2513A6AC9; Fri, 11 Sep 2009 02:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 M6zadnUCaGPi; Fri, 11 Sep 2009 02:41:27 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id C1EDF3A6A78; Fri, 11 Sep 2009 02:41:26 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 11:41:20 +0200 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: Fri, 11 Sep 2009 11:41:18 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12, and Q14 on WSON Impairments Thread-Index: AcotajJwLzHgQ3siTeujCLjYQVrJwQFUYooA References: From: To: , X-OriginalArrivalTime: 11 Sep 2009 09:41:20.0331 (UTC) FILETIME=[047621B0:01CA32C4] Cc: pce@ietf.org Subject: Re: [Pce] [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12, and Q14 on WSON Impairments 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, 11 Sep 2009 09:41:29 -0000 Hi Deborah, hi Lou. I would like to see some clarification to the statement "the parameter = information which is needed to be distributed by either a control plane = or Path Computation Element". May I suggest to rephrase by something = like: "the parameter information which is needed to be distributed by a = control plane, so as to be used by either node internal path computation = or a Path Computation Element"? I CC the PCE list in case some interested people be not subscribed to = CCAMP. Thanks, Julien -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of BRUNGARD, DEBORAH A, ATTLABS CCAMP, As we agreed, we need to send a liaison to ITU's SG15 Q6, Q12, and Q14, = informing them of our CCAMP document, "A Framework for the Control of = Wavelength Switched Optical Networks (WSON) with Impairments".=20 This is in response to the ITU liaison: https://datatracker.ietf.org/liaison/479/ Note, the link below in the liaison points to the ITU link. The link for = CCAMP is: http://www.ccamp.labn.net/old_ccamp/www.olddog.co.uk/download/WD6-38.doc Let us know if any comments on this proposal. Deborah and Lou -----------------Proposed Liaison-------------------- From: IETF CCAMP WG To: ITU-T Study Group 15 Question 6, Question 12, and Question 14 Peter Stassar Pete Anslow Malcolm Betts Hing-Kam Lam Ross Callon Adrian Farrel Cc: Patrik F=E4ltstr=F6m=20 Francesco Montalti Stephen Trowbridge Title: WSON Impairment Work in CCAMP Purpose: For Information =20 The CCAMP Working Group of IETF thanks Question 12 for their liaison = from the September 2008 meeting informing of their initiation of work to = be done in cooperation with Question 6 on developing a network model for = WSON which will include optical impairments. We would like to inform you = of our progress in this area as documented in the CCAMP document "A = Framework for the Control of Wavelength Switched Optical Networks (WSON) = with Impairments": http://www.ietf.org/id/draft-ietf-ccamp-wson-impairments-00.txt This document provides a framework for GMPLS protocols and mechanisms to = support impairment aware routing and wavelength assignment. The = deployment scenarios are based on the categories discussed at Question = 6's Sunnyvale meeting: = http://ifa.itu.int/t/2009/sg15/exchange/wp2/q6/Meetings/2009-03-Sunnyvale= /Contributions/WD6-38.doc We would appreciate your consideration of this document in your work and = would you please inform us of the scope of your work and the timelines. = For CCAMP's impairment work, CCAMP is focused on scenarios where = approximated impairment estimation using ITU-T defined parameters and = approximation techniques [G.680] may be used. The objective of CCAMP = work is to distribute the information which is needed to allow path = computation and signaling of new paths. We would appreciate your input = on the parameter information which is needed to be distributed by either = a control plane or Path Computation Element (PCE) and its properties so = as to understand the control plane distribution requirements. In = addition, we would appreciate your perspective on control plane modeling = and implications with regard to ITU-T's G.872 OTN aspects e.g. OTN = multi-layers (OTS, OMS, OCh), regenerators, and o/e/o (OCh/OTU/ODU). Best Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From xsg@nict.go.jp Fri Sep 11 03:51:31 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 AA1093A6BD3 for ; Fri, 11 Sep 2009 03:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 v-hmU0z711AA for ; Fri, 11 Sep 2009 03:51:30 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 4F2933A6BDA for ; Fri, 11 Sep 2009 03:51:30 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n8BAq6Dq003104 for ; Fri, 11 Sep 2009 19:52:06 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n8BAq6WW018006 for ; Fri, 11 Sep 2009 19:52:06 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n8BAq6Wc018003 for ; Fri, 11 Sep 2009 19:52:06 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 1588B2C32A for ; Fri, 11 Sep 2009 19:52:06 +0900 (JST) Received: from [127.0.0.1] (ssh2.nict.go.jp [133.243.3.50]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 4B4BC2C2FC for ; Fri, 11 Sep 2009 19:52:04 +0900 (JST) Message-ID: <4AAA2BBE.3030902@nict.go.jp> Date: Fri, 11 Sep 2009 19:51:42 +0900 From: Sugang XU User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 10:51:31 -0000 I support to take this I-D as a WG doc. Best Regards, Sugang ---------------------------------------- Date: Mon, 7 Sep 2009 10:19:07 +0200 From: Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt To: Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hello PCE members. As you probably now, CCAMP has already endorsed some WSON and RWA as workingitems. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? Thanks for expressing your minds, JP & Julien From ke-oogaki@cn.kddilabs.jp Fri Sep 11 09:11: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 E785F28C1A1 for ; Fri, 11 Sep 2009 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 kFzBFRNJwu3C for ; Fri, 11 Sep 2009 09:11:56 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 02AEA3A6AC0 for ; Fri, 11 Sep 2009 09:11:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 0FDB0EC8E1 for ; Sat, 12 Sep 2009 01:12:32 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id BB6B8EC860 for ; Sat, 12 Sep 2009 01:12:31 +0900 (JST) Received: from oogaki-kenichi-no-macbook-pro.local (ebisu.kddilabs.jp [IPv6:2001:200:601:11::214]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 0158C578111 for ; Sat, 12 Sep 2009 01:12:30 +0900 (JST) Message-ID: <4AAA76EE.6060803@cn.kddilabs.jp> Date: Fri, 11 Sep 2009 12:12:30 -0400 From: "Ogaki, Kenichi" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: pce@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 16:11:57 -0000 I support. Kenichi KDDI R&D Labs. > Date: Mon, 7 Sep 2009 10:19:07 +0200 > From: > Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt > To: > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > Hello PCE members. > > As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? > > Thanks for expressing your minds, > > JP & Julien > From adrian@olddog.co.uk Fri Sep 11 09:34:12 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 E609628C1CC for ; Fri, 11 Sep 2009 09:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] 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 wrazvDfDL-o3 for ; Fri, 11 Sep 2009 09:34:12 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 4B25E3A689B for ; Fri, 11 Sep 2009 09:33:54 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n8BGXffv011159; Fri, 11 Sep 2009 17:33:46 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n8BGXeKL011154; Fri, 11 Sep 2009 17:33:41 +0100 Message-ID: <2AA6B590D7B04C28826192EFBCB5FFAD@your029b8cecfe> From: "Adrian Farrel" To: , , , References: <77ead0ec0909091140s2e5a41dbke3e8abb719b74115@mail.gmail.com> Date: Fri, 11 Sep 2009 17:33:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by asmtp2.iomartmail.com id n8BGXeKL011154 Cc: pce@ietf.org Subject: Re: [Pce] PCE port number 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, 11 Sep 2009 16:34:13 -0000 Hi, For my part (I only worked as an author quite late in the process, but I = was=20 helping to get this through the IESG review that raised issued about TCP=20 ports) I think Julien has not captured the point. The RFC is not silent about source ports because it does intend to limit = the=20 scope. As Julien says, it does matter which port is listened on, and this is=20 deliberately a well-known port number so that it is not necessary to=20 configure (or advertise) the port that must be called. But in Section 4.2.1 you will find... Only one PCEP session can exist between a pair of PCEP peers at any one time. Only one TCP connection on the PCEP port can exist between a pair of PCEP peers at any one time. One way to help ensure this is to reduce the number of available ports to= =20 use as the source port. Does restricting the source port cause any implementation or deployment=20 problems? Thanks, Adrian ----- Original Message -----=20 From: To: ; ;=20 Cc: Sent: Thursday, September 10, 2009 9:57 AM Subject: Re: [Pce] PCE port number Hi Vishwas. Interesting comment. We must admit the wording is a bit ambiguous. RFC 5440 says: "The system listens to the PCEP-registered TCP port" and=20 "Upon receiving a TCP connection on the PCEP-registered TCP port"; I do n= ot=20 see any behavior description for the source TCP port (good thing!). My guess is that there is no intend to put constraints on the TCP initiat= or=20 port. I would interpret the sentence you mention as "using the registered= =20 TCP port on the PCE side, i.e. for the source TCP port for PCE to PCC=20 messages and for destination TCP port for PCC to PCE messages"... A littl= e=20 cumbersome, I agree. Authors of RFC 5440, would there be an actual intend to specify otherwise= ?=20 Implementers, any other interpretation? Thanks, Julien -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of=20 Vishwas Manral Hi, I looked at the following in the spec: =93Transport Protocol PCEP operates over TCP using a registered TCP port (4189). This allows the requirements of reliable messaging and flow control to be met without further protocol work. All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port.=94 This has been worrying me a bit. Unlike other protocols like BGP or LDP In BGP it states clearly: A BGP implementation MUST connect to and listen on TCP port 179 for incoming connections in addition to trying to connect to peers. and BGP's destination port SHOULD be port 179, as defined by IANA. Why do we have this restriction on source port? It is becoming a challenging task in merchant OS. Thanks, Vishwas Vishwas _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From dbrungard@att.com Fri Sep 11 09:35:58 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 1E4053A6A31; Fri, 11 Sep 2009 09:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 KL3pJSAQnkal; Fri, 11 Sep 2009 09:35:57 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id C6F083A689B; Fri, 11 Sep 2009 09:35:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1252686992!22665903!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 28292 invoked from network); 11 Sep 2009 16:36:32 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Sep 2009 16:36:32 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n8BGaWMr019871; Fri, 11 Sep 2009 12:36:32 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n8BGaRTC019843; Fri, 11 Sep 2009 12:36:29 -0400 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: Fri, 11 Sep 2009 12:35:52 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12, and Q14 on WSON Impairments Thread-Index: AcotajJwLzHgQ3siTeujCLjYQVrJwQFUYooAABB004A= References: From: "BRUNGARD, DEBORAH A, ATTLABS" To: , Cc: pce@ietf.org Subject: Re: [Pce] [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12, and Q14 on WSON Impairments 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, 11 Sep 2009 16:35:58 -0000 Hi Julien, Great - thanks for the clarification. I'll update. Deborah -----Original Message----- From: julien.meuric@orange-ftgroup.com = [mailto:julien.meuric@orange-ftgroup.com]=20 Sent: Friday, September 11, 2009 5:41 AM To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ietf.org Cc: pce@ietf.org Subject: RE: [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12,and Q14 on = WSON Impairments Hi Deborah, hi Lou. I would like to see some clarification to the statement "the parameter = information which is needed to be distributed by either a control plane = or Path Computation Element". May I suggest to rephrase by something = like: "the parameter information which is needed to be distributed by a = control plane, so as to be used by either node internal path computation = or a Path Computation Element"? I CC the PCE list in case some interested people be not subscribed to = CCAMP. Thanks, Julien -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of BRUNGARD, DEBORAH A, ATTLABS CCAMP, As we agreed, we need to send a liaison to ITU's SG15 Q6, Q12, and Q14, = informing them of our CCAMP document, "A Framework for the Control of = Wavelength Switched Optical Networks (WSON) with Impairments".=20 This is in response to the ITU liaison: https://datatracker.ietf.org/liaison/479/ Note, the link below in the liaison points to the ITU link. The link for = CCAMP is: http://www.ccamp.labn.net/old_ccamp/www.olddog.co.uk/download/WD6-38.doc Let us know if any comments on this proposal. Deborah and Lou -----------------Proposed Liaison-------------------- From: IETF CCAMP WG To: ITU-T Study Group 15 Question 6, Question 12, and Question 14 Peter Stassar Pete Anslow Malcolm Betts Hing-Kam Lam Ross Callon Adrian Farrel Cc: Patrik F=E4ltstr=F6m=20 Francesco Montalti Stephen Trowbridge Title: WSON Impairment Work in CCAMP Purpose: For Information =20 The CCAMP Working Group of IETF thanks Question 12 for their liaison = from the September 2008 meeting informing of their initiation of work to = be done in cooperation with Question 6 on developing a network model for = WSON which will include optical impairments. We would like to inform you = of our progress in this area as documented in the CCAMP document "A = Framework for the Control of Wavelength Switched Optical Networks (WSON) = with Impairments": http://www.ietf.org/id/draft-ietf-ccamp-wson-impairments-00.txt This document provides a framework for GMPLS protocols and mechanisms to = support impairment aware routing and wavelength assignment. The = deployment scenarios are based on the categories discussed at Question = 6's Sunnyvale meeting: = http://ifa.itu.int/t/2009/sg15/exchange/wp2/q6/Meetings/2009-03-Sunnyvale= /Contributions/WD6-38.doc We would appreciate your consideration of this document in your work and = would you please inform us of the scope of your work and the timelines. = For CCAMP's impairment work, CCAMP is focused on scenarios where = approximated impairment estimation using ITU-T defined parameters and = approximation techniques [G.680] may be used. The objective of CCAMP = work is to distribute the information which is needed to allow path = computation and signaling of new paths. We would appreciate your input = on the parameter information which is needed to be distributed by either = a control plane or Path Computation Element (PCE) and its properties so = as to understand the control plane distribution requirements. In = addition, we would appreciate your perspective on control plane modeling = and implications with regard to ITU-T's G.872 OTN aspects e.g. OTN = multi-layers (OTS, OMS, OCh), regenerators, and o/e/o (OCh/OTU/ODU). Best Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From vishwas.ietf@gmail.com Fri Sep 11 10:01:05 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 17C393A689B for ; Fri, 11 Sep 2009 10:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 N7gG5HWlseNb for ; Fri, 11 Sep 2009 10:01:04 -0700 (PDT) Received: from mail-yx0-f200.google.com (mail-yx0-f200.google.com [209.85.210.200]) by core3.amsl.com (Postfix) with ESMTP id EBF2A3A6932 for ; Fri, 11 Sep 2009 10:01:03 -0700 (PDT) Received: by yxe38 with SMTP id 38so1595042yxe.6 for ; Fri, 11 Sep 2009 10:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RqEOgY7qaiZrde9uVh2htTwxexSQDPzKh48c+DbN60k=; b=rIgWq4YHURbs0UILBxAm0QwpgtV4nVQbUIeZ9Di0P+XWd8KKBVlNPL3Zz2X7xAFbNI T4FRK4oDQDBnKeuqXw88tePrmKbfOeZitinjYrk8iS4Lgmd23D06ixnqf/Yfa+yjMH4Y 3Ol8XrNLzo2Zua1Npk1K+9L6TuhABjmmbhKNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vmD+w/cqXFEXbPbm5ULmBheS7K0AVBIV3wLRG0OOsVGT4BQ/C/ERybmgSBTwXOfC3d +nZkmTCWDOpwy6jmkXdy4bc956Ok6EKpqq8xrbSwB5VcTpxH/07obSlpQ77Z6l7+XYBc 5p2JPJ8tMTlIEi68RJFa6/DtTGv8XEIg4uVEM= MIME-Version: 1.0 Received: by 10.150.55.4 with SMTP id d4mr5229092yba.318.1252688498148; Fri, 11 Sep 2009 10:01:38 -0700 (PDT) In-Reply-To: <2AA6B590D7B04C28826192EFBCB5FFAD@your029b8cecfe> References: <77ead0ec0909091140s2e5a41dbke3e8abb719b74115@mail.gmail.com> <2AA6B590D7B04C28826192EFBCB5FFAD@your029b8cecfe> Date: Fri, 11 Sep 2009 10:01:38 -0700 Message-ID: <77ead0ec0909111001w73c7d3b4w71d3c2cbede85551@mail.gmail.com> From: Vishwas Manral To: Adrian Farrel Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, jpv@cisco.com Subject: Re: [Pce] PCE port number 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, 11 Sep 2009 17:01:05 -0000 Hi Adrian, It would have been ok if it was a connectionless transport like UDP. However I notice a problem when I want multiple sockets to use the same port number in particular cases. I figured that I cannot have a server socket (accepting connections) as well as a client socket trying to connect having the same port number, though I can allow same port to be shared across multiple sockets in some cases by using the socket option SO_REUSEPORT. Thanks, Vishwas On Fri, Sep 11, 2009 at 9:33 AM, Adrian Farrel wrote: > Hi, > > For my part (I only worked as an author quite late in the process, but I = was > helping to get this through the IESG review that raised issued about TCP > ports) I think Julien has not captured the point. > > The RFC is not silent about source ports because it does intend to limit = the > scope. > > As Julien says, it does matter which port is listened on, and this is > deliberately a well-known port number so that it is not necessary to > configure (or advertise) the port that must be called. > > But in Section 4.2.1 you will find... > > =A0Only one PCEP session can exist between a pair of PCEP peers at any > =A0one time. =A0Only one TCP connection on the PCEP port can exist betwee= n > =A0a pair of PCEP peers at any one time. > > One way to help ensure this is to reduce the number of available ports to > use as the source port. > > Does restricting the source port cause any implementation or deployment > problems? > > Thanks, > Adrian > > ----- Original Message ----- From: > To: ; ; > > Cc: > Sent: Thursday, September 10, 2009 9:57 AM > Subject: Re: [Pce] PCE port number > > > Hi Vishwas. > > Interesting comment. We must admit the wording is a bit ambiguous. > > RFC 5440 says: "The system listens to the PCEP-registered TCP port" and > "Upon receiving a TCP connection on the PCEP-registered TCP port"; I do n= ot > see any behavior description for the source TCP port (good thing!). > My guess is that there is no intend to put constraints on the TCP initiat= or > port. I would interpret the sentence you mention as "using the registered > TCP port on the PCE side, i.e. for the source TCP port for PCE to PCC > messages and for destination TCP port for PCC to PCE messages"... A littl= e > cumbersome, I agree. > > Authors of RFC 5440, would there be an actual intend to specify otherwise= ? > Implementers, any other interpretation? > > Thanks, > > Julien > > > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Vishwas Manral > > Hi, > > I looked at the following in the spec: > > =93Transport Protocol > > =A0PCEP operates over TCP using a registered TCP port (4189). =A0This > =A0allows the requirements of reliable messaging and flow control to be > =A0met without further protocol work. =A0All PCEP messages MUST be sent > =A0using the registered TCP port for the source and destination TCP > =A0port.=94 > > This has been worrying me a bit. Unlike other protocols like BGP or LDP > > In BGP it states clearly: > > =A0A BGP implementation MUST connect to and listen on TCP port 179 for > =A0incoming connections in addition to trying to connect to peers. > > and > > =A0BGP's destination port SHOULD be port 179, as defined by IANA. > > Why do we have this restriction on source port? It is becoming a > challenging task > in merchant OS. > > Thanks, > Vishwas > Vishwas > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From mach@huawei.com Mon Sep 14 18:02: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 044523A695D for ; Mon, 14 Sep 2009 18:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=-1.305, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 n6VDNKp1Ui2b for ; Mon, 14 Sep 2009 18:02:02 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 38B223A6931 for ; Mon, 14 Sep 2009 18:02:02 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPZ00HONMVQMU@szxga01-in.huawei.com> for pce@ietf.org; Tue, 15 Sep 2009 09:02:15 +0800 (CST) Received: from m55527c ([10.111.12.100]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPZ00NQFMVQ2R@szxga01-in.huawei.com> for pce@ietf.org; Tue, 15 Sep 2009 09:02:14 +0800 (CST) Date: Tue, 15 Sep 2009 09:02:14 +0800 From: Mach Chen In-reply-to: To: julien.meuric@orange-ftgroup.com, pce@ietf.org Message-id: <1F4E08DA2F6248E0B2404C64F58869EB@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 01:02:03 -0000 Yes, I support! Best regards, Mach Chen -------------------------------------------------- From: Sent: Monday, September 07, 2009 4:19 PM To: Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt > Hello PCE members. > > As you probably now, CCAMP has already endorsed some WSON and RWA as > working items. In the same context, > draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on > PCEP. Do you think we should now take this I-D as a WG document? > > Thanks for expressing your minds, > > JP & Julien > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From mkattan@cisco.com Wed Sep 9 08:57: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 8CDFA3A6BD3 for ; Wed, 9 Sep 2009 08:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ydrFGoXPT6VV for ; Wed, 9 Sep 2009 08:57:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C90CE3A69AC for ; Wed, 9 Sep 2009 08:57:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACttp0qrR7MV/2dsb2JhbADFUohDAZBiBYQY X-IronPort-AV: E=Sophos;i="4.44,359,1249257600"; d="scan'208";a="385192548" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Sep 2009 15:57:48 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n89Fvmg4001364; Wed, 9 Sep 2009 08:57:48 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n89Fvm9k029354; Wed, 9 Sep 2009 15:57:48 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 08:57:48 -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 Date: Wed, 9 Sep 2009 08:57:47 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt Thread-Index: Acovk96pDBztp1ZtTU2XEH/zTA7kawB0lkgg References: From: "Moustafa Kattan (mkattan)" To: , X-OriginalArrivalTime: 09 Sep 2009 15:57:48.0430 (UTC) FILETIME=[473102E0:01CA3166] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=722; t=1252511868; x=1253375868; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mkattan@cisco.com; z=From:=20=22Moustafa=20Kattan=20(mkattan)=22=20 |Subject:=20RE=3A=20[Pce]=20Poll=20on=20draft-lee-pce-wson- routing-wavelength-05.txt |Sender:=20; bh=2xRrVx4a8N4Bxww08N6wU27GK4Y1AozY4YDuxE51lHs=; b=EedpBhM+v3enuLEfO+bWc6OTz2p/86Bqr4icHZfUkd619Ujmkr2Ub9AjMP muLB2V63Zy21r05+V2NpeUkMv9U6+c9aYRwXPLEA0GXqyK8XKtc38GtAudWa DRhqH98TFOkhqVbg85MNYgTLuJd72+3MA8P1ZNHZBDXezfNPOoA+E=; Authentication-Results: sj-dkim-1; header.From=mkattan@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Mailman-Approved-At: Wed, 16 Sep 2009 02:37:55 -0700 Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:57:16 -0000 Support.=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of julien.meuric@orange-ftgroup.com Sent: Monday, September 07, 2009 11:19 AM To: pce@ietf.org Subject: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt Hello PCE members. As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? Thanks for expressing your minds, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From wwwrun@core3.amsl.com Wed Sep 16 08:48:48 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 9A9313A6A0D; Wed, 16 Sep 2009 08:48:48 -0700 (PDT) From: Deborah Brungard(IETF CCAMP WG) To: Peter.Stassar@ties.itu.int, Malcolm.Betts@huawei.com, hklam@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090916154848.9A9313A6A0D@core3.amsl.com> Date: Wed, 16 Sep 2009 08:48:48 -0700 (PDT) X-Mailman-Approved-At: Wed, 16 Sep 2009 08:52:55 -0700 Cc: ccamp@ietf.org, sjtrowbridge@alcatel-lucent.com, paf@cisco.com, Adrian.Farrel@huawei.com, rcallon@juniper.com, pce@ietf.org, pja@nortel.com, francesco.montalti@telecomitalia.it Subject: [Pce] New Liaison Statement, "WSON Impairment Work in CCAMP" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dbrungard@att.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 15:48:48 -0000 Title: WSON Impairment Work in CCAMP Submission Date: 2009-09-16 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=578 Please reply by 2009-10-30 From: Deborah Brungard(IETF CCAMP WG) To: ITU-T SG15 Question 6, Question 12, and Question 14(Peter.Stassar@ties.itu.int,Malcolm.Betts@huawei.com,hklam@alcatel-lucent.com) Cc: Greg.Jones@itu.int sjtrowbridge@alcatel-lucent.com francesco.montalti@telecomitalia.it pja@nortel.com paf@cisco.com Adrian.Farrel@huawei.com rcallon@juniper.com lberger@labn.net ccamp@ietf.org pce@ietf.org Reponse Contact: dbrungard@att.com Technical Contact: dbrungard@att.com Purpose: For action Body: The CCAMP Working Group of IETF thanks Question 12 for their liaison from the September 2008 meeting informing of their initiation of work to be done in cooperation with Question 6 on developing a network model for WSON which will include optical impairments. We would like to inform you of our progress in this area as documented in the CCAMP document "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments": http://www.ietf.org/id/draft-ietf-ccamp-wson-impairments-00.txt This document provides a framework for GMPLS protocols and mechanisms to support impairment aware routing and wavelength assignment. The deployment scenarios are based on the categories discussed at Question 6's Sunnyvale meeting: http://ifa.itu.int/t/2009/sg15/exchange/wp2/q6/Meetings/2009-03-Sunnyvale/Contributions/WD6-38.doc We would appreciate your consideration of this document in your work and would you please inform us of the scope of your work and the timelines. For CCAMP's impairment work, CCAMP is focused on scenarios where approximated impairment estimation using ITU-T defined parameters and approximation techniques (G.680) may be used. The objective of CCAMP work is to distribute the information which is needed to allow path computation and signaling of new paths. We would appreciate your input on the parameter information which is needed to be distributed by a control plane, to be used by either a node for internal path computation or a Path Computation Element, and its properties, so as to understand the control plane distribution requirements. In addition, we would appreciate your perspective on control plane modeling and implications with regard to ITU-T's G.872 OTN aspects e.g. OTN multi-layers (OTS, OMS, OCh), regenerators, and o/e/o (OCh, OTU, ODU). Best Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs Attachment(s): No document has been attached From vishwas.ietf@gmail.com Wed Sep 16 11:55:13 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 8EAD93A6942 for ; Wed, 16 Sep 2009 11:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 EoGBv1ek7MeV for ; Wed, 16 Sep 2009 11:55:12 -0700 (PDT) Received: from mail-yw0-f186.google.com (mail-yw0-f186.google.com [209.85.211.186]) by core3.amsl.com (Postfix) with ESMTP id 5D9083A6A4E for ; Wed, 16 Sep 2009 11:55:12 -0700 (PDT) Received: by ywh16 with SMTP id 16so7961335ywh.13 for ; Wed, 16 Sep 2009 11:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TVtU/Xsc+YU/kcLHyu/Naj/iwKGPiZx69pggJbGpyIk=; b=aFy7i6PdvEjGqMGKmeZ8hoOk4OyEtsbMjkMk10pgUuQOQHz2vlD+EE9+0A03WnebHj D227pDUtPishxFQoXEXUyQhEnayhy2v+/ZLHGUrYMnyXRh/K4lQQz/FaWx/q+ZUv20rI /IjHWt1KVE4WCIrwH/OTA3dWjGe7K6xe794ME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YmLNycNO5z5gVbStgkHadBBBIxejqbZPqZtiOgps/AZnMwmSRNQ/3KoJHzGUIH65jd rFRT3qA529+HqMzfKUT1xZLUIIeH/1gpGD7vbivogMZx49sD2dI2Rn/hwJtC7SfWbEBA lymDHBd0XRwegwtQ9FABSS8kXoZzOvNNyoNsA= MIME-Version: 1.0 Received: by 10.150.87.7 with SMTP id k7mr15122427ybb.304.1253127358494; Wed, 16 Sep 2009 11:55:58 -0700 (PDT) In-Reply-To: <77ead0ec0909111001w73c7d3b4w71d3c2cbede85551@mail.gmail.com> References: <77ead0ec0909091140s2e5a41dbke3e8abb719b74115@mail.gmail.com> <2AA6B590D7B04C28826192EFBCB5FFAD@your029b8cecfe> <77ead0ec0909111001w73c7d3b4w71d3c2cbede85551@mail.gmail.com> Date: Wed, 16 Sep 2009 11:55:58 -0700 Message-ID: <77ead0ec0909161155t274537cdocfe804c4ddbadbd8@mail.gmail.com> From: Vishwas Manral To: Adrian Farrel Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, jpv@cisco.com Subject: Re: [Pce] PCE port number 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, 16 Sep 2009 18:55:13 -0000 Hi Adrian, What do you suggest the path forward from here regarding this issue? Should we just put it in an Errata? Thanks, Vishwas On Fri, Sep 11, 2009 at 10:01 AM, Vishwas Manral w= rote: > Hi Adrian, > > It would have been ok if it was a connectionless transport like UDP. > > However I notice a problem when I want multiple sockets to use the > same port number in particular cases. I figured that I cannot have a > server socket (accepting connections) as well as a client socket > trying to connect having the same port number, though I can allow same > port to be shared across multiple sockets in some cases by using the > socket option SO_REUSEPORT. > > Thanks, > Vishwas > > On Fri, Sep 11, 2009 at 9:33 AM, Adrian Farrel wrot= e: >> Hi, >> >> For my part (I only worked as an author quite late in the process, but I= was >> helping to get this through the IESG review that raised issued about TCP >> ports) I think Julien has not captured the point. >> >> The RFC is not silent about source ports because it does intend to limit= the >> scope. >> >> As Julien says, it does matter which port is listened on, and this is >> deliberately a well-known port number so that it is not necessary to >> configure (or advertise) the port that must be called. >> >> But in Section 4.2.1 you will find... >> >> =A0Only one PCEP session can exist between a pair of PCEP peers at any >> =A0one time. =A0Only one TCP connection on the PCEP port can exist betwe= en >> =A0a pair of PCEP peers at any one time. >> >> One way to help ensure this is to reduce the number of available ports t= o >> use as the source port. >> >> Does restricting the source port cause any implementation or deployment >> problems? >> >> Thanks, >> Adrian >> >> ----- Original Message ----- From: >> To: ; ; >> >> Cc: >> Sent: Thursday, September 10, 2009 9:57 AM >> Subject: Re: [Pce] PCE port number >> >> >> Hi Vishwas. >> >> Interesting comment. We must admit the wording is a bit ambiguous. >> >> RFC 5440 says: "The system listens to the PCEP-registered TCP port" and >> "Upon receiving a TCP connection on the PCEP-registered TCP port"; I do = not >> see any behavior description for the source TCP port (good thing!). >> My guess is that there is no intend to put constraints on the TCP initia= tor >> port. I would interpret the sentence you mention as "using the registere= d >> TCP port on the PCE side, i.e. for the source TCP port for PCE to PCC >> messages and for destination TCP port for PCC to PCE messages"... A litt= le >> cumbersome, I agree. >> >> Authors of RFC 5440, would there be an actual intend to specify otherwis= e? >> Implementers, any other interpretation? >> >> Thanks, >> >> Julien >> >> >> -----Original Message----- >> From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of >> Vishwas Manral >> >> Hi, >> >> I looked at the following in the spec: >> >> =93Transport Protocol >> >> =A0PCEP operates over TCP using a registered TCP port (4189). =A0This >> =A0allows the requirements of reliable messaging and flow control to be >> =A0met without further protocol work. =A0All PCEP messages MUST be sent >> =A0using the registered TCP port for the source and destination TCP >> =A0port.=94 >> >> This has been worrying me a bit. Unlike other protocols like BGP or LDP >> >> In BGP it states clearly: >> >> =A0A BGP implementation MUST connect to and listen on TCP port 179 for >> =A0incoming connections in addition to trying to connect to peers. >> >> and >> >> =A0BGP's destination port SHOULD be port 179, as defined by IANA. >> >> Why do we have this restriction on source port? It is becoming a >> challenging task >> in merchant OS. >> >> Thanks, >> Vishwas >> Vishwas >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >> > From vishwas.ietf@gmail.com Wed Sep 16 11:56:06 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 A79C83A6A82 for ; Wed, 16 Sep 2009 11:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 wJe9lv1bkaxq for ; Wed, 16 Sep 2009 11:56:05 -0700 (PDT) Received: from mail-yw0-f186.google.com (mail-yw0-f186.google.com [209.85.211.186]) by core3.amsl.com (Postfix) with ESMTP id 9BDA93A68E0 for ; Wed, 16 Sep 2009 11:56:05 -0700 (PDT) Received: by ywh16 with SMTP id 16so7962760ywh.13 for ; Wed, 16 Sep 2009 11:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jsaMsHjOPmMndiQC/9aAxbylFWIZfC4iRMt5nT+Yqwk=; b=S1y8EyRL4ltgOKe4PPz1yUF7td6zNs23YPS6i8tJMD9kvpM6id/11aFH8ZU7YZ2aqv qWRy725HD/mnRhPiTBV88LIv3y+qYFetMoEd728IvWyHdPKyIlhcTXqWTmrAicE0S437 4J9bB8YB2WDCjRBWeugxwSYqhCyRwQoAyBXmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BGUaD7v8F1VT+1ZV8N1NWF78ut2O0L8RMUBCbM52EfyX4BHNLQkU+y4pVMSQyJ/vY6 cuUR/MicMTNKkjFn4LzPCcnTbal2/Qx3JlOFaifRVFTPx5y3j4JJymBpR2+X2f7eMVGL MTrS0LiwJS/VC3RHOCHTmvDH1qPDHieSUQo9Q= MIME-Version: 1.0 Received: by 10.150.81.13 with SMTP id e13mr15134743ybb.247.1253127410399; Wed, 16 Sep 2009 11:56:50 -0700 (PDT) In-Reply-To: References: <77ead0ec0908281814m77b76502xeea41fbd9324ea80@mail.gmail.com> Date: Wed, 16 Sep 2009 11:56:50 -0700 Message-ID: <77ead0ec0909161156k6bb45f4bkbb7eeb7fd6b7d5c3@mail.gmail.com> From: Vishwas Manral To: julien.meuric@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Cc: pce@ietf.org Subject: Re: [Pce] RFC5440 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, 16 Sep 2009 18:56:06 -0000 Hi Julien, So what do you suggest we do to correct this? Thanks, Vishwas On Tue, Sep 1, 2009 at 6:04 AM, wrote: > Hi Vishwas. > > Good catch, but that seems even more complicated... > > Indeed, section 7.9 in RFC 5440 is named "Reported Route Object" while > the text in that section mentions a "Route Record Object" (3rd > variation). However, RRO is defined in RFC 3209 as: "Record Route > Object", which leave us with not less than 4 expansion options! > > As it is purely an expansion issue, the solutions are not too complex: > - RRO should be read as in RFC 3209: "Record Route Object"; > - the title of section 7.9 in RFC 5440 does not (explicitly) claim to > expand the acronym and could be considered as a functional description > of the use in that context (indeed, the RRO reports a route ;-) ); RFC > errata might be an option (not sure it's deserved provided we pay > attention in next documents); > - the text of section 7.9 in RFC 5440 does not claim to but implicitly > expands the acronym, however it is a simple swap of R-terms (which you > can even find in RFC 3209); > - the IANA is not the standard reference for acronym expansion, however, > if you feel that "Recorded" should be updated to "Record" I could > contact them about that. > > I hope this clarifies. > > Regards, > > Julien > > > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Vishwas Manral > > Hi, > > While readint the RFC5440 and the > http://www.iana.org/assignments/pcep/pcep.xml IANA assignments I > noticed a discripancy. > > RRO in the RFC refers to a Reported Route Object but in the IANA it is > refered to a Recorded Route Object. > > Thanks, > Vishwas > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From rfc-editor@rfc-editor.org Thu Sep 17 16:09:46 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 0CE1C3A6B45; Thu, 17 Sep 2009 16:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.889 X-Spam-Level: X-Spam-Status: No, score=-16.889 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 XDxvKeIhg5Sx; Thu, 17 Sep 2009 16:09:45 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id B3C6E28C16A; Thu, 17 Sep 2009 16:08:43 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 528193256F8; Thu, 17 Sep 2009 16:09:08 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090917230908.528193256F8@bosco.isi.edu> Date: Thu, 17 Sep 2009 16:09:08 -0700 (PDT) Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] RFC 5623 on Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 23:09:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5623 Title: Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Author: E. Oki, T. Takeda, JL. Le Roux, A. Farrel Status: Informational Date: September 2009 Mailbox: oki@ice.uec.ac.jp, takeda.tomonori@lab.ntt.co.jp, jeanlouis.leroux@orange-ftgroup.com, adrian@olddog.co.uk Pages: 34 Characters: 81033 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-inter-layer-frwk-10.txt URL: http://www.rfc-editor.org/rfc/rfc5623.txt 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). This memo provides information for the Internet community. This document is a product of the Path Computation Element Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From julien.meuric@orange-ftgroup.com Mon Sep 21 07:04:27 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 61D793A6A96 for ; Mon, 21 Sep 2009 07:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 gNDKaEQW7fNt for ; Mon, 21 Sep 2009 07:04:26 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 346F93A6A5D for ; Mon, 21 Sep 2009 07:04:08 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 16:05:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Sep 2009 16:05:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.txt Thread-Index: AcorpHfQSzapIFyVSeG399y9CymMqQPH5kuQ References: From: To: , , X-OriginalArrivalTime: 21 Sep 2009 14:05:08.0311 (UTC) FILETIME=[86CDB670:01CA3AC4] Subject: Re: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 14:04:27 -0000 Hi all. The Last Call for draft-ietf-pce-pcep-svec-list-02 has ended. Authors, could please address received comments in the next revision. Thanks, JP & Julien -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Dear all, This starts a 2-week WG Last Call for draft-ietf-pce-pcep-svec-=20 list-02.txt, which has been stable for quite some time, and is ready =20 for WG Last call. Please send your comments by September 16, 9:00am ET =20 on the mailing list. We would also welcome feed-back from potential implementers. Thanks. JP and Julien. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From julien.meuric@orange-ftgroup.com Wed Sep 23 01:10:19 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 5106E3A687F for ; Wed, 23 Sep 2009 01:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aLePNKWjI9Q for ; Wed, 23 Sep 2009 01:10:18 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 002D03A6851 for ; Wed, 23 Sep 2009 01:10:17 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 10:11:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Sep 2009 10:11:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt Thread-Index: Acovk96pDBztp1ZtTU2XEH/zTA7kawL7y5EA References: From: To: , , , , , X-OriginalArrivalTime: 23 Sep 2009 08:11:07.0161 (UTC) FILETIME=[66EAF090:01CA3C25] Subject: Re: [Pce] Poll on draft-lee-pce-wson-routing-wavelength-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 08:10:19 -0000 Hi all. We have WG's support: the I-D is adopted into the fold of the PCE WG. Authors, could you please republish as draft-ietf-pce-wson-routing-wavelength-00.txt? Thanks, JP & Julien -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of julien.meuric@orange-ftgroup.com Hello PCE members. As you probably now, CCAMP has already endorsed some WSON and RWA as working items. In the same context, draft-lee-pce-wson-routing-wavelength-05.txt put some requirements on PCEP. Do you think we should now take this I-D as a WG document? Thanks for expressing your minds, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From root@core3.amsl.com Wed Sep 23 07:45: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 D6BD528C101; Wed, 23 Sep 2009 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090923144501.D6BD528C101@core3.amsl.com> Date: Wed, 23 Sep 2009 07:45:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-pcep-svec-list-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:45: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 : The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations Author(s) : I. Nishioka, D. King Filename : draft-ietf-pce-pcep-svec-list-03.txt Pages : 15 Date : 2009-09-23 A Path Computation Element (PCE) performing dependent path computations, for instance calculating a diverse working and protected path not sharing common network points, would need to synchronize the computations in order to increase the probability of meeting the working and protected path diversity (or disjointness) objective and network resource optimization objective. When a PCE computes multiple sets of dependent path computation requests concurrently, it is required to use Synchronization VECtor (SVEC) list for association among the sets of dependent path computation requests. SVEC is also applicable to end-to-end diverse path computation across multiple domains. This document describes the usage of SVECs in the SVEC list and diverse path computation guideline, for the synchronized computation of dependent paths. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 23, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-svec-list-03.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-pcep-svec-list-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-23073135.I-D@ietf.org> --NextPart-- From i-nishioka@cb.jp.nec.com Wed Sep 23 07:53:22 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 8F8223A6908 for ; Wed, 23 Sep 2009 07:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.324 X-Spam-Level: ** X-Spam-Status: No, score=2.324 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 v2uEjqHMDotg for ; Wed, 23 Sep 2009 07:53:21 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id 9958B3A6823 for ; Wed, 23 Sep 2009 07:53:21 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n8NEsQvw021529; Wed, 23 Sep 2009 23:54:26 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id n8NEsQi24351; Wed, 23 Sep 2009 23:54:26 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id n8NEsPIk025611; Wed, 23 Sep 2009 23:54:25 +0900 (JST) Received: from saigo.jp.nec.com ([10.26.220.6] [10.26.220.6]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-2083979; Wed, 23 Sep 2009 23:53:54 +0900 Received: from C08AUG00201 ([10.56.131.165] [10.56.131.165]) by mail.jp.nec.com with ESMTP; Wed, 23 Sep 2009 23:53:52 +0900 From: "Itaru Nishioka" To: , References: In-Reply-To: Date: Wed, 23 Sep 2009 23:53:52 +0900 Organization: NEC Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcorpHfQSzapIFyVSeG399y9CymMqQPH5kuQAGXgj7A= X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: i-nishioka@cb.jp.nec.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:53:22 -0000 Hi Julien, and all. Thank you for kind review and many good comments. I have posted new version of draft (draft-ietf-pce-pcep-svec-list-03), which addressed all comments from Julien and Filippo during the Last Call. Regards, Itaru. > -----Original Message----- > From: julien.meuric@orange-ftgroup.com > [mailto:julien.meuric@orange-ftgroup.com] > Sent: Monday, September 21, 2009 11:05 PM > To: i-nishioka@cb.jp.nec.com; daniel@olddog.co.uk; pce@ietf.org > Subject: RE: [Pce] Working Group Last Call: > draft-ietf-pce-pcep-svec-list-02.txt > > Hi all. > > The Last Call for draft-ietf-pce-pcep-svec-list-02 has ended. > Authors, could please address received comments in the next revision. > > Thanks, > > JP & Julien > > > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On > Behalf Of JP Vasseur > > Dear all, > > This starts a 2-week WG Last Call for > draft-ietf-pce-pcep-svec- list-02.txt, which has been stable > for quite some time, and is ready for WG Last call. Please > send your comments by September 16, 9:00am ET on the mailing list. > > We would also welcome feed-back from potential implementers. > > Thanks. > > JP and Julien. > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > From root@core3.amsl.com Wed Sep 23 09:30:02 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 167773A699D; Wed, 23 Sep 2009 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090923163002.167773A699D@core3.amsl.com> Date: Wed, 23 Sep 2009 09:30:02 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-wson-routing-wavelength-00.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, 23 Sep 2009 16:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Requirements for WSON Routing and Wavelength Assignment Author(s) : Y. Lee, et al. Filename : draft-ietf-pce-wson-routing-wavelength-00.txt Pages : 11 Date : 2009-09-23 This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. >From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for Optical impairments will be addressed in a separate document. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-wson-routing-wavelength-00.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-wson-routing-wavelength-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-23092021.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Sep 28 15:15: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 C2A2C3A68C6; Mon, 28 Sep 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090928221501.C2A2C3A68C6@core3.amsl.com> Date: Mon, 28 Sep 2009 15:15:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-ext-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 22:15: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 : Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, T. Takeda, J. Le Roux, A. Farrel Filename : draft-ietf-pce-inter-layer-ext-03.txt Pages : 15 Date : 2009-9-27 The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol 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 through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-ext-03.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-inter-layer-ext-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-9-28150746.I-D@ietf.org> --NextPart-- From web-usrn@ISI.EDU Wed Sep 30 04:42:52 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 A5EDD3A6838 for ; Wed, 30 Sep 2009 04:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.904 X-Spam-Level: X-Spam-Status: No, score=-16.904 tagged_above=-999 required=5 tests=[AWL=0.695, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 TQ9jgvkkemXv for ; Wed, 30 Sep 2009 04:42:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 607A73A67E3 for ; Wed, 30 Sep 2009 04:42:51 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8UBgug1023131; Wed, 30 Sep 2009 04:42:57 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n8UBgs2a023105; Wed, 30 Sep 2009 04:42:54 -0700 (PDT) Date: Wed, 30 Sep 2009 04:42:54 -0700 (PDT) Message-Id: <200909301142.n8UBgs2a023105@boreas.isi.edu> To: oki@ice.uec.ac.jp, takeda.tomonori@lab.ntt.co.jp, jeanlouis.leroux@orange-ftgroup.com, adrian@olddog.co.uk, rcallon@juniper.net, adrian.farrel@huawei.com, jpv@cisco.com, julien.meuric@orange-ftgroup.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Wed, 30 Sep 2009 09:51:43 -0700 Cc: ah@TR-Sys.de, pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Editorial Errata Reported] RFC5623 (1897) 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, 30 Sep 2009 11:42:52 -0000 The following errata report has been submitted for RFC5623, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5623&eid=1897 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 4.1, Original Text ------------- a) Section 4.1, 2nd paragraph (bottom of page 10): A VNT Manager (VNTM) is defined as a functional element that manages and controls the VNT. The PCE and VNT Manager are distinct | functional elements that may or may not be collocated. ^^ b) Section 4.2.4, trailing Note below Table 1 (on page 22): * Note that, in case of NSM-VNTM cooperation (separate flavor) and single PCE inter-layer path computation, the PCE function used by | NMS and VNTM may be collocated, but it will operate on separate TEDs. ^^ Corrected Text -------------- a) A VNT Manager (VNTM) is defined as a functional element that manages and controls the VNT. The PCE and VNT Manager are distinct | functional elements that may or may not be co-located. b) * Note that, in case of NSM-VNTM cooperation (separate flavor) and single PCE inter-layer path computation, the PCE function used by | NMS and VNTM may be co-located, but it will operate on separate TEDs. Notes ----- Rationale: "collocated" and "co-located" (or "colocated") have very different semantics! The latter seems to be the appropriate choice: two logical entites (or subsystems) are located within the same system. The former means "arranged/placed/sorted *somehow*, in the proper way", without emphasis on neighborship or common enclosement. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5623 (draft-ietf-pce-inter-layer-frwk-10) -------------------------------------- Title : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Publication Date : September 2009 Author(s) : E. Oki, T. Takeda, JL. Le Roux, A. Farrel Category : INFORMATIONAL Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From web-usrn@ISI.EDU Wed Sep 30 05:01:57 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 41E273A6A7C for ; Wed, 30 Sep 2009 05:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.906 X-Spam-Level: X-Spam-Status: No, score=-16.906 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 S+NW6zocmPjm for ; Wed, 30 Sep 2009 05:01:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 394B03A6A80 for ; Wed, 30 Sep 2009 05:01:56 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8UC1DiN001459; Wed, 30 Sep 2009 05:01:14 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n8UC1DHk001458; Wed, 30 Sep 2009 05:01:13 -0700 (PDT) Date: Wed, 30 Sep 2009 05:01:13 -0700 (PDT) Message-Id: <200909301201.n8UC1DHk001458@boreas.isi.edu> To: oki@ice.uec.ac.jp, takeda.tomonori@lab.ntt.co.jp, jeanlouis.leroux@orange-ftgroup.com, adrian@olddog.co.uk, rcallon@juniper.net, adrian.farrel@huawei.com, jpv@cisco.com, julien.meuric@orange-ftgroup.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Wed, 30 Sep 2009 09:51:43 -0700 Cc: ah@TR-Sys.de, pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Editorial Errata Reported] RFC5623 (1898) 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, 30 Sep 2009 12:01:57 -0000 The following errata report has been submitted for RFC5623, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5623&eid=1898 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 4.2.2,pg.14 Original Text ------------- Step 4: H1 initiates higher-layer signaling using the computed | explicit router of H2-L1-L2-H3-H4. ^ Corrected Text -------------- Step 4: H1 initiates higher-layer signaling using the computed | explicit route of H2-L1-L2-H3-H4. Notes ----- Rationale: confusing typo. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5623 (draft-ietf-pce-inter-layer-frwk-10) -------------------------------------- Title : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Publication Date : September 2009 Author(s) : E. Oki, T. Takeda, JL. Le Roux, A. Farrel Category : INFORMATIONAL Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG