From pce-bounces@ietf.org Wed Oct 8 08:06:28 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010E028C191; Wed, 8 Oct 2008 08:06:28 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1CB3828C138; Wed, 8 Oct 2008 08:06:26 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081008150627.1CB3828C138@core3.amsl.com> Date: Wed, 8 Oct 2008 08:06:27 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-path-key (Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism) to Proposed Standard X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15993&rfc_flag=0 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Oct 10 16:11:43 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6956928C127; Fri, 10 Oct 2008 16:11:43 -0700 (PDT) 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 CFF9328C127 for ; Fri, 10 Oct 2008 16:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.27 X-Spam-Level: X-Spam-Status: No, score=-5.27 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 bANE-rtiKD6g for ; Fri, 10 Oct 2008 16:11:41 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8BCDB28C11C for ; Fri, 10 Oct 2008 16:11:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,391,1220227200"; d="scan'208,217";a="23951893" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Oct 2008 23:12:28 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9ANCSml025668 for ; Fri, 10 Oct 2008 19:12:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9ANCSco001595 for ; Fri, 10 Oct 2008 23:12:28 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 19:12:27 -0400 Received: from 10.21.80.182 ([10.21.80.182]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Oct 2008 23:12:27 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 10 Oct 2008 16:12:26 -0700 From: JP Vasseur To: Message-ID: Thread-Topic: Provisioning Time Slot for PCE WG Meeting in Minneapolis Thread-Index: AckrLaipiGj1Fzdk4US9JzAuZ2iDbA== Mime-version: 1.0 X-OriginalArrivalTime: 10 Oct 2008 23:12:27.0872 (UTC) FILETIME=[A9C78E00:01C92B2D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1475; t=1223680348; x=1224544348; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Provisioning=20Time=20Slot=20for=20PCE=20WG=20M eeting=20in=20Minneapolis |Sender:=20 |To:=20; bh=HKsurU7dtHT5Pv8P2yFSeEriqBEZ1Desnf0rG4iNRqg=; b=WhZRckVuG6eZ+CIz3vnUNzUceLYA0dnbW48qgSW2aa5p/5MzpiOUHFJtLk VqmlvgWcfCBqDhceFHEr5Owwobn74C0RupnWWarIblBU89sHRYGF/ceIFZK1 AhB+T+ECtH; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Pce] Provisioning Time Slot for PCE WG Meeting in Minneapolis X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0667351778==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0667351778== Content-type: multipart/alternative; boundary="B_3306499946_11946645" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3306499946_11946645 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, Our WG meeting has been provisioned for: PCE Session 1 (1.5 hours) Thursday, Afternoon Session III 1740-1930 Room Name: Meeting Room ---------------------------------------------- Just bear in mind that this may change though. Final agenda will be known on Oct 27. Thanks. JP. --B_3306499946_11946645 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Provisioning Time Slot for PCE WG Meeting in Minneapolis Dear WG,

Our WG meeting has been provisioned for:

PCE Session 1 (1.5 hours)
Thursday, Afternoon Session III 1740-1930
Room Name: Meeting Room
----------------------------------------------

Just bear in mind that this may change though. Final = agenda will be known on Oct 27.

Thanks.

JP.

--B_3306499946_11946645-- --===============0667351778== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0667351778==-- From pce-bounces@ietf.org Mon Oct 13 11:16:54 2008 Return-Path: X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB53328C16E; Mon, 13 Oct 2008 11:16:54 -0700 (PDT) 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 162863A6ACB for ; Mon, 13 Oct 2008 11:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.214 X-Spam-Level: X-Spam-Status: No, score=-5.214 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 0g3yayACImmN for ; Mon, 13 Oct 2008 11:16:53 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CFE113A6452 for ; Mon, 13 Oct 2008 11:16:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,404,1220227200"; d="scan'208,217";a="24108446" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Oct 2008 18:17:14 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9DIHEaT002370 for ; Mon, 13 Oct 2008 14:17:14 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9DIHEp6006990 for ; Mon, 13 Oct 2008 18:17:14 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 14:17:14 -0400 Received: from 10.55.201.134 ([10.55.201.134]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Oct 2008 18:17:14 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 13 Oct 2008 20:17:11 +0200 From: JP Vasseur To: JP Vasseur , Message-ID: Thread-Topic: [Pce] Provisioning Time Slot for PCE WG Meeting in Minneapolis Thread-Index: AckrLaipiGj1Fzdk4US9JzAuZ2iDbACMkBGq In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 13 Oct 2008 18:17:14.0774 (UTC) FILETIME=[EB308B60:01C92D5F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2528; t=1223921834; x=1224785834; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Provisioning=20Time=20Slot=20fo r=20PCE=20WG=20Meeting=20in=20Minneapolis |Sender:=20 |To:=20JP=20Vasseur=20,=20; bh=FrA0zrU9G3Zvi1T9SnYmjoYQxJCKkdHyi6jbX+JIkgs=; b=E+QdAq823+6EsWqdFYHySEkFTFInj4iJHhFk8FVQfpnO88h/DU+Hx8shw3 SBwhAACUTCd8aeuDO5AOQ4vPgVvQbLuJ+krkuWWlcQgP8Cfs699Pet5bYOTV WXAKSU0Aay; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Pce] Provisioning Time Slot for PCE WG Meeting in Minneapolis X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1948233229==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1948233229== Content-type: multipart/alternative; boundary="B_3306773833_19627941" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3306773833_19627941 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Please let us know if you need a slot. Thanks. JP. On 10/10/08 4:12 PM, "JP Vasseur" wrote: > Dear WG, > > Our WG meeting has been provisioned for: > > PCE Session 1 (1.5 hours) > Thursday, Afternoon Session III 1740-1930 > Room Name: Meeting Room > ---------------------------------------------- > > Just bear in mind that this may change though. Final agenda will be known on > Oct 27. > > Thanks. > > JP. > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --B_3306773833_19627941 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Pce] Provisioning Time Slot for PCE WG Meeting in Minneapolis</= TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:13pt= '>Please let us know if you need a slot.<BR> <BR> Thanks.<BR> <BR> JP.<BR> <BR> <BR> On 10/10/08 4:12 PM, "JP Vasseur" <<a href=3D"jvasseur@cisco.com= ">jvasseur@cisco.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:13pt'>Dear WG,<BR> <BR> Our WG meeting has been provisioned for:<BR> <BR> </SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Consolas, Courier New, Courier"><S= PAN STYLE=3D'font-size:10pt'>PCE Session 1 (1.5 hours)<BR> Thursday, Afternoon Session III 1740-1930<BR> Room Name: Meeting Room<BR> ----------------------------------------------<BR> <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:13pt'>Just bear in mind that this may change though. Final = agenda will be known on Oct 27.<BR> <BR> Thanks.<BR> <BR> JP. <BR> <BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"1"><FONT FA= CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________= ____________________________________<BR> Pce mailing list<BR> <a href=3D"Pce@ietf.org">Pce@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/pce">https://www.ietf.org/ma= ilman/listinfo/pce</a><BR> </SPAN></FONT></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3306773833_19627941-- --===============1948233229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1948233229==-- From pce-bounces@ietf.org Wed Oct 15 09:45:03 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6611928C2AB; Wed, 15 Oct 2008 09:45:03 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C2AA728C23B; Wed, 15 Oct 2008 09: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: <20081015164501.C2AA728C23B@core3.amsl.com> Date: Wed, 15 Oct 2008 09:45:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-pcep-16.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element (PCE) Communication Protocol (PCEP) Author(s) : A. Ayyangar, et al. Filename : draft-ietf-pce-pcep-16.txt Pages : 85 Date : 2008-10-15 This document specifies the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future.Requirements Language 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-16.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-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-15093551.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Wed Oct 15 15:30:03 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA01F28C2E1; Wed, 15 Oct 2008 15:30:03 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5A79428C2D2; Wed, 15 Oct 2008 15: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: <20081015223001.5A79428C2D2@core3.amsl.com> Date: Wed, 15 Oct 2008 15:30:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-inter-layer-req-08.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-ietf-pce-inter-layer-req-08.txt Pages : 13 Date : 2008-10-15 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". Generic requirements for PCE discovery protocol are presented in "Requirements for Path Computation Element (PCE) Discovery". This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-08.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-req-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-15152528.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Wed Oct 15 16:00:03 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3C228C23F; Wed, 15 Oct 2008 16:00:03 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4516D3A69FC; Wed, 15 Oct 2008 16:00:00 -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: <20081015230001.4516D3A69FC@core3.amsl.com> Date: Wed, 15 Oct 2008 16:00:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-manageability-requirements-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Inclusion of Manageability Sections in PCE Working Group Drafts Author(s) : A. Farrel Filename : draft-ietf-pce-manageability-requirements-05.txt Pages : 12 Date : 2008-10-15 It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the recommendation for all new Internet-Drafts in the PCE Working Group to include a "Manageability Considerations" section, and gives guidance on what that section should contain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-manageability-requirements-05.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-manageability-requirements-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-15155912.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Wed Oct 22 02:34:33 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C653A6B7C; Wed, 22 Oct 2008 02:34:33 -0700 (PDT) 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 D1E063A6941 for <pce@core3.amsl.com>; Wed, 22 Oct 2008 02:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.806 X-Spam-Level: X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=1.300, 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 ov2KYzifYrcm for <pce@core3.amsl.com>; Wed, 22 Oct 2008 02:34:30 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B833C3A6B7C for <pce@ietf.org>; Wed, 22 Oct 2008 02:34:29 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9400967VYU1U@szxga03-in.huawei.com> for pce@ietf.org; Wed, 22 Oct 2008 17:35:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9400BW6VYUF5@szxga03-in.huawei.com> for pce@ietf.org; Wed, 22 Oct 2008 17:35:18 +0800 (CST) Received: from SSK1548 ([10.18.24.148]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K940041QVYQ5C@szxml04-in.huawei.com> for pce@ietf.org; Wed, 22 Oct 2008 17:35:18 +0800 (CST) Date: Wed, 22 Oct 2008 15:05:35 +0530 From: "S.SenthilKumar (Huawei)" <senthilKumars@huawei.com> To: pce@ietf.org Message-id: <000001c93429$8add6b40$9418120a@china.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ack0KYhQ5qJi0mw1RqarezixYSP/ag== Subject: [Pce] Length of Flag Field in RP Object X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: senthilKumars@huawei.com List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0132659723==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============0132659723== Content-type: multipart/alternative; boundary="Boundary_(ID_Yk6XsmtreXY/bRP7s3g5zQ)" This is a multi-part message in MIME format. --Boundary_(ID_Yk6XsmtreXY/bRP7s3g5zQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear All The following Section is taken from draft-ietf-pce-pcep-16.txt In this context, the length of the Flag field is not clear in the text. >From the figure, Flags field is 26 bits and the rest 6 bits are defined as Pri (Priority) - 3 bits, R (Reoptimization) - 1 bit, B (Bi-directional) - 1 bit and O (strict/loose) - 1 bit. But in the text, a) Flags field is mentioned as 24 bit b) Pri, R, B and O fields are part of the flags and is miss-leading ---------- Text of concern ----------------------------- Flags (24 bits) The following flags are currently defined: --------------------------------------------------------------- Please clarify. Best regards S.SenthilKumar 7.4. RP Object The RP (Request Parameters) object MUST be carried within each PCReq and PCRep messages and MAY be carried within PCNtf and PCErr messages. The RP object is used to specify various characteristics of the path computation request. The P flag of the RP object MUST be set in PCReq and PCReq messages and MUST be cleared in PCNtf and PCErr messages. If the RP objet is received with the P flag set incorrectly according to the rules states above, the receiving peer MUST send a PCErr message with Error-type=10 and Error-value=1. The corresponding path computation request MUST be cancelled by the PCE without further notification. 7.4.1. Object Definition RP Object-Class is to be assigned by IANA (recommended value=2) RP Object-Type is to be assigned by IANA (recommended value=1) The format of the RP object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: RP object body format The RP object body has a variable length and may contain additional TLVs. No TLVs are currently defined. Flags (24 bits) The following flags are currently defined: o Pri (Priority - 3 bits): the Priority field may be used by the requesting PCC to specify to the PCE the request's priority from 1 to 7. The decision of which priority should be used for a specific request is of a local matter and MUST be set to 0 when unused. Furthermore, the use of the path computation request priority by the PCE's scheduler is implementation specific and out of the scope of this document. Note that it is not required for a PCE to support the priority field: in this case, it is RECOMMENDED that the PCC set the priority field to 0 in the RP object. If the PCE does not take into account the request priority, it is RECOMMENDED to set the priority field to 0 in the RP object carried within the corresponding PCRep message, regardless of the priority value contained in the RP object carried within the corresponding PCReq message. A higher numerical value of the priority field reflects a higher priority. Note that it is the responsibility of the network administrator to make use of the priority values in a consistent manner across the various PCCs. The ability of a PCE to support request prioritization MAY be dynamically discovered by the PCCs by means of PCE capability discovery. If not advertised by the PCE, a PCC may decide to set the request priority and will learn the ability of the PCE to support request prioritization by observing the Priority field of the RP object received in the PCRep message. If the value of the Pri field is set to 0, this means that the PCE does not support the handling of request priorities: in other words, the path computation request has been honoured but without taking the request priority into account. o R (Reoptimization - 1 bit): when set, the requesting PCC specifies that the PCReq message relates to the reoptimization of an existing TE LSP. For all TE LSPs except 0-bandwidth LSPs, when the R bit is set, an RRO (see Section 7.10) MUST be included in the PCReq message to show the path of the existing TE LSP. Also, for all TE LSPs except 0-bandwidth LSPs, then the R bit is set, the existing bandwidth of the TE LSP to be reoptimized MUST be supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH object is in addition to the instance of that object used to describe the desired bandwidth of the reoptimized LSP. For 0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the characteristics of the existing TE LSP are optional. o B (Bi-directional - 1 bit): when set, the PCC specifies that the path computation request relates to a bidirectional TE LSP that has the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, TE Links, and resource requirements (e.g., latency and jitter) in each direction. When cleared, the TE LSP is unidirectional. o O (strict/loose - 1 bit): when set, in a PCReq message, this indicates that a loose path is acceptable. Otherwise, when cleared, this indicates to the PCE that a path exclusively made of strict hops is required. In a PCRep message, when the O bit is set this indicates that the returned path is a loose path, otherwise (the O bit is cleared), the returned path is made of strict hops. --Boundary_(ID_Yk6XsmtreXY/bRP7s3g5zQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD> <BODY> <DIV><FONT face=Arial size=2>Dear All</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>The following Section is taken from draft-ietf-pce-pcep-16.txt</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>In this context, the length of the Flag field is not clear in the text. </FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>From the figure, Flags field is 26 bits and the rest 6 bits are defined as Pri (Priority) - 3 bits, R (Reoptimization) - 1 bit, B (Bi-directional) - 1 bit and O (strict/loose) - 1 bit.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>But in the text, </FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>a) Flags field is mentioned as 24 bit<BR>b) Pri, R, B and O fields are part of the flags and is miss-leading</FONT></DIV> <DIV><BR><FONT face=Arial size=2>---------- Text of concern -----------------<SPAN class=593173109-22102008>------------</SPAN><BR>   Flags (24 bits)</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial><FONT size=2>   The following flags are currently defined:<BR>-------------------------------------------<SPAN class=593173109-22102008>--------------------</SPAN></FONT></FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Please clarify.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Best regards<BR>S.SenthilKumar</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>7.4.  RP Object</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   The RP (Request Parameters) object MUST be carried within each PCReq<BR>   and PCRep messages and MAY be carried within PCNtf and PCErr<BR>   messages.  The RP object is used to specify various characteristics<BR>   of the path computation request.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   The P flag of the RP object MUST be set in PCReq and PCReq messages<BR>   and MUST be cleared in PCNtf and PCErr messages.  If the RP objet is<BR>   received with the P flag set incorrectly according to the rules<BR>   states above, the receiving peer MUST send a PCErr message with<BR>   Error-type=10 and Error-value=1.  The corresponding path computation<BR>   request MUST be cancelled by the PCE without further notification.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>7.4.1.  Object Definition</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   RP Object-Class is to be assigned by IANA (recommended value=2)</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   RP Object-Type is to be assigned by IANA (recommended value=1)</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><BR><FONT face=Arial size=2>   The format of the RP object body is as follows:</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>    0                   1                   2                   3<BR>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<BR>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>   |                          Flags                    |O|B|R| Pri |<BR>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>   |                        Request-ID-number                      |<BR>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>   |                                                               |<BR>   //                      Optional TLVs                          //<BR>   |                                                               |<BR>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>                  Figure 10: RP object body format</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   The RP object body has a variable length and may contain additional<BR>   TLVs.  No TLVs are currently defined.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   Flags (24 bits)</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   The following flags are currently defined:</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   o  Pri (Priority - 3 bits): the Priority field may be used by the<BR>      requesting PCC to specify to the PCE the request's priority from 1<BR>      to 7.  The decision of which priority should be used for a<BR>      specific request is of a local matter and MUST be set to 0 when<BR>      unused.  Furthermore, the use of the path computation request<BR>      priority by the PCE's scheduler is implementation specific and out<BR>      of the scope of this document.  Note that it is not required for a<BR>      PCE to support the priority field: in this case, it is RECOMMENDED<BR>      that the PCC set the priority field to 0 in the RP object.  If the<BR>      PCE does not take into account the request priority, it is<BR>      RECOMMENDED to set the priority field to 0 in the RP object<BR>      carried within the corresponding PCRep message, regardless of the<BR>      priority value contained in the RP object carried within the<BR>      corresponding PCReq message.  A higher numerical value of the<BR>      priority field reflects a higher priority.  Note that it is the<BR>      responsibility of the network administrator to make use of the<BR>      priority values in a consistent manner across the various PCCs.<BR>      The ability of a PCE to support request prioritization MAY be<BR>      dynamically discovered by the PCCs by means of PCE capability<BR>      discovery.  If not advertised by the PCE, a PCC may decide to set<BR>      the request priority and will learn the ability of the PCE to<BR>      support request prioritization by observing the Priority field of<BR>      the RP object received in the PCRep message.  If the value of the<BR>      Pri field is set to 0, this means that the PCE does not support<BR>      the handling of request priorities: in other words, the path</FONT></DIV> <DIV><FONT face=Arial size=2>      computation request has been honoured but without taking the<BR>      request priority into account.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   o  R (Reoptimization - 1 bit): when set, the requesting PCC specifies<BR>      that the PCReq message relates to the reoptimization of an<BR>      existing TE LSP.  For all TE LSPs except 0-bandwidth LSPs, when<BR>      the R bit is set, an RRO (see Section 7.10) MUST be included in<BR>      the PCReq message to show the path of the existing TE LSP.  Also,<BR>      for all TE LSPs except 0-bandwidth LSPs, then the R bit is set,<BR>      the existing bandwidth of the TE LSP to be reoptimized MUST be<BR>      supplied in a BANDWIDTH object (see Section 7.7).  This BANDWIDTH<BR>      object is in addition to the instance of that object used to<BR>      describe the desired bandwidth of the reoptimized LSP.  For<BR>      0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the<BR>      characteristics of the existing TE LSP are optional.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   o  B (Bi-directional - 1 bit): when set, the PCC specifies that the<BR>      path computation request relates to a bidirectional TE LSP that<BR>      has the same traffic engineering requirements including fate<BR>      sharing, protection and restoration, LSRs, TE Links, and resource<BR>      requirements (e.g., latency and jitter) in each direction.  When<BR>      cleared, the TE LSP is unidirectional.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   o  O (strict/loose - 1 bit): when set, in a PCReq message, this<BR>      indicates that a loose path is acceptable.  Otherwise, when<BR>      cleared, this indicates to the PCE that a path exclusively made of<BR>      strict hops is required.  In a PCRep message, when the O bit is<BR>      set this indicates that the returned path is a loose path,<BR>      otherwise (the O bit is cleared), the returned path is made of<BR>      strict hops.</FONT></DIV></BODY></HTML> --Boundary_(ID_Yk6XsmtreXY/bRP7s3g5zQ)-- --===============0132659723== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0132659723==-- From pce-bounces@ietf.org Wed Oct 22 06:06:06 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71EDB3A69E9; Wed, 22 Oct 2008 06:06:06 -0700 (PDT) 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 E5B653A6B4E for <pce@core3.amsl.com>; Wed, 22 Oct 2008 06:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWfO-M1I1nbi for <pce@core3.amsl.com>; Wed, 22 Oct 2008 06:06:03 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 419A73A6823 for <pce@ietf.org>; Wed, 22 Oct 2008 06:06:03 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m9MD6sBw032497; Wed, 22 Oct 2008 14:06:57 +0100 Received: from your029b8cecfe ([207.226.254.178]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m9MD6qe2032454; Wed, 22 Oct 2008 14:06:53 +0100 Message-ID: <055101c93447$0de98560$84996d26@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <senthilKumars@huawei.com>, <pce@ietf.org> References: <000001c93429$8add6b40$9418120a@china.huawei.com> Date: Wed, 22 Oct 2008 14:02:10 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [Pce] Length of Flag Field in RP Object X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, Good catch, thanks. The figure is correct. The text should actually say Flags (32 bits) as the Pri, O, B, and R flags are part of the flags field We'll either fix this in the next revision or in the RFC Editor process. Thanks, Adrian ----- Original Message ----- From: "S.SenthilKumar (Huawei)" <senthilKumars@huawei.com> To: <pce@ietf.org> Sent: Wednesday, October 22, 2008 10:35 AM Subject: [Pce] Length of Flag Field in RP Object > Dear All > > The following Section is taken from draft-ietf-pce-pcep-16.txt > > In this context, the length of the Flag field is not clear in the text. > > From the figure, Flags field is 26 bits and the rest 6 bits are defined as > Pri (Priority) - 3 bits, R (Reoptimization) - 1 bit, B (Bi-directional) - > 1 > bit and O (strict/loose) - 1 bit. > > But in the text, > > a) Flags field is mentioned as 24 bit > b) Pri, R, B and O fields are part of the flags and is miss-leading > > ---------- Text of concern ----------------------------- > Flags (24 bits) > > The following flags are currently defined: > --------------------------------------------------------------- > > Please clarify. > > Best regards > S.SenthilKumar > > > > > > > 7.4. RP Object > > The RP (Request Parameters) object MUST be carried within each PCReq > and PCRep messages and MAY be carried within PCNtf and PCErr > messages. The RP object is used to specify various characteristics > of the path computation request. > > The P flag of the RP object MUST be set in PCReq and PCReq messages > and MUST be cleared in PCNtf and PCErr messages. If the RP objet is > received with the P flag set incorrectly according to the rules > states above, the receiving peer MUST send a PCErr message with > Error-type=10 and Error-value=1. The corresponding path computation > request MUST be cancelled by the PCE without further notification. > > 7.4.1. Object Definition > > RP Object-Class is to be assigned by IANA (recommended value=2) > > RP Object-Type is to be assigned by IANA (recommended value=1) > > > The format of the RP object body is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags |O|B|R| Pri | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Request-ID-number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > // Optional TLVs // > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 10: RP object body format > > The RP object body has a variable length and may contain additional > TLVs. No TLVs are currently defined. > > Flags (24 bits) > > The following flags are currently defined: > > o Pri (Priority - 3 bits): the Priority field may be used by the > requesting PCC to specify to the PCE the request's priority from 1 > to 7. The decision of which priority should be used for a > specific request is of a local matter and MUST be set to 0 when > unused. Furthermore, the use of the path computation request > priority by the PCE's scheduler is implementation specific and out > of the scope of this document. Note that it is not required for a > PCE to support the priority field: in this case, it is RECOMMENDED > that the PCC set the priority field to 0 in the RP object. If the > PCE does not take into account the request priority, it is > RECOMMENDED to set the priority field to 0 in the RP object > carried within the corresponding PCRep message, regardless of the > priority value contained in the RP object carried within the > corresponding PCReq message. A higher numerical value of the > priority field reflects a higher priority. Note that it is the > responsibility of the network administrator to make use of the > priority values in a consistent manner across the various PCCs. > The ability of a PCE to support request prioritization MAY be > dynamically discovered by the PCCs by means of PCE capability > discovery. If not advertised by the PCE, a PCC may decide to set > the request priority and will learn the ability of the PCE to > support request prioritization by observing the Priority field of > the RP object received in the PCRep message. If the value of the > Pri field is set to 0, this means that the PCE does not support > the handling of request priorities: in other words, the path > computation request has been honoured but without taking the > request priority into account. > > o R (Reoptimization - 1 bit): when set, the requesting PCC specifies > that the PCReq message relates to the reoptimization of an > existing TE LSP. For all TE LSPs except 0-bandwidth LSPs, when > the R bit is set, an RRO (see Section 7.10) MUST be included in > the PCReq message to show the path of the existing TE LSP. Also, > for all TE LSPs except 0-bandwidth LSPs, then the R bit is set, > the existing bandwidth of the TE LSP to be reoptimized MUST be > supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH > object is in addition to the instance of that object used to > describe the desired bandwidth of the reoptimized LSP. For > 0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the > characteristics of the existing TE LSP are optional. > > o B (Bi-directional - 1 bit): when set, the PCC specifies that the > path computation request relates to a bidirectional TE LSP that > has the same traffic engineering requirements including fate > sharing, protection and restoration, LSRs, TE Links, and resource > requirements (e.g., latency and jitter) in each direction. When > cleared, the TE LSP is unidirectional. > > o O (strict/loose - 1 bit): when set, in a PCReq message, this > indicates that a loose path is acceptable. Otherwise, when > cleared, this indicates to the PCE that a path exclusively made of > strict hops is required. In a PCRep message, when the O bit is > set this indicates that the returned path is a loose path, > otherwise (the O bit is cleared), the returned path is made of > strict hops. > -------------------------------------------------------------------------------- > _______________________________________________ > 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 pce-bounces@ietf.org Wed Oct 22 19:14:56 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9193A6B87; Wed, 22 Oct 2008 19:14:56 -0700 (PDT) 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 02FD03A6B87 for <pce@core3.amsl.com>; Wed, 22 Oct 2008 19:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.886 X-Spam-Level: X-Spam-Status: No, score=0.886 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, 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 AisOxjOoSZTS for <pce@core3.amsl.com>; Wed, 22 Oct 2008 19:14:48 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 848FB3A68A8 for <pce@ietf.org>; Wed, 22 Oct 2008 19:14:48 -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 <0K96008CE6AJP7@szxga01-in.huawei.com> for pce@ietf.org; Thu, 23 Oct 2008 10:15:56 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K96002OV6AJRN@szxga01-in.huawei.com> for pce@ietf.org; Thu, 23 Oct 2008 10:15:55 +0800 (CST) Received: from SSK1548 ([10.18.24.148]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9600DZT6AII4@szxml05-in.huawei.com> for pce@ietf.org; Thu, 23 Oct 2008 10:15:55 +0800 (CST) Date: Thu, 23 Oct 2008 07:46:16 +0530 From: "S.SenthilKumar (Huawei)" <senthilKumars@huawei.com> To: pce@ietf.org Message-id: <000001c934b5$554e9cb0$9418120a@china.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ack0tVMNTPfeuuK0TFmeZviGZMEXgQ== Subject: [Pce] BANDWIDTH Object X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: senthilKumars@huawei.com List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0013490828==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============0013490828== Content-type: multipart/related; boundary="Boundary_(ID_CCcYyc3aY6cPv3IFo6yN+A)" This is a multi-part message in MIME format. --Boundary_(ID_CCcYyc3aY6cPv3IFo6yN+A) Content-type: multipart/alternative; boundary="Boundary_(ID_GbUfkk4rKUuXravyMlvc7Q)" --Boundary_(ID_GbUfkk4rKUuXravyMlvc7Q) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Dear All The following text is taken from draft-ietf-pce-pcep-16.txt >> In the case of the reoptimization of a TE LSP, the bandwidth of the existing TE LSP MUST also be included in addition to the requested bandwidth if and only if the two values differ. I'm want to understand the negative meaning and PCE behavior in the following case. PCC is sending a PCReq message for reoptimization of a TE LSP and there is no bandwidth case. But PCC is sending PCReq with Existing and Requested bandwidth (containing same value in this case). Is this an error (PCE should drop the Request and send a PCERR or PCE can just ignore as the values are same. Please clarify. Best regards S.SenthilKumar 7.7. BANDWIDTH Object The BANDWIDTH object is used to specify the requested bandwidth for a TE LSP. The notion of bandwidth is similar to the one used for RSVP signaling in [RFC2205], [RFC3209] and [RFC3473]. If the requested bandwidth is equal to 0, the BANDWIDTH object is optional. Conversely, if the requested bandwidth is non equal to 0, the PCReq message MUST contain a BANDWIDTH object. In the case of the reoptimization of a TE LSP, the bandwidth of the existing TE LSP MUST also be included in addition to the requested bandwidth if and only if the two values differ. Consequently, two Object-Type values are defined that refer to the requested bandwidth and the bandwidth of the TE LSP for which a reoptimization is being performed. Thanking you, Best regards, S.SenthilKumar, Technical Project Lead, IPng, Technologies India Pvt Ltd, Level 3, Leela Galleria, The Leela Palace, 23, Airport Road, Bangalore - 560 008. Ph: +91-80-41781770 Ext: 1555 Mobile: +9198408-60866/+91 990-1982-365 EMail-ID: senthilkumars@huawei.com Performance, perseverance and persistence in spite of all obstacles, dicouragements, and impossibilities: It is this, that in all things distinguishes the strong soul from the weak." Disclaimer: 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! --Boundary_(ID_GbUfkk4rKUuXravyMlvc7Q) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD> <BODY> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008>Dear All</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008>The following text is taken from draft-ietf-pce-pcep-16.txt</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008>>><SPAN class=140241002-23102008>   In the case of the reoptimization of a TE LSP, the bandwidth of the existing TE LSP MUST also be included in addition to the requested bandwidth if and only if the two values differ.</SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008><SPAN class=140241002-23102008></SPAN></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008><SPAN class=140241002-23102008>I'm want to understand the negative meaning and PCE behavior in the following case.</SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008><SPAN class=140241002-23102008></SPAN></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008><SPAN class=140241002-23102008>PCC is sending a PCReq message for reoptimization of a TE LSP and there is no bandwidth case. But PCC is sending PCReq with Existing and Requested bandwidth (containing same value in this case). Is this an error (PCE should drop the Request and send a PCERR or PCE can just ignore as the values are same.</SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008><SPAN class=140241002-23102008></SPAN></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008><SPAN class=140241002-23102008>Please clarify.</SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008><SPAN class=140241002-23102008><FONT size=5><FONT size=2></FONT></FONT></SPAN></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008><SPAN class=140241002-23102008><FONT size=5><FONT size=2>Best regards</FONT></FONT></SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008><SPAN class=140241002-23102008><FONT size=5><FONT size=2>S.SenthilKumar</FONT></DIV></FONT></SPAN></SPAN></FONT> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008>7.7.  BANDWIDTH Object</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008>   The BANDWIDTH object is used to specify the requested bandwidth for a<BR>   TE LSP.  The notion of bandwidth is similar to the one used for RSVP<BR>   signaling in [RFC2205], [RFC3209] and [RFC3473].</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008>   If the requested bandwidth is equal to 0, the BANDWIDTH object is<BR>   optional.  Conversely, if the requested bandwidth is non equal to 0,<BR>   the PCReq message MUST contain a BANDWIDTH object.</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=140241002-23102008>   In the case of the reoptimization of a TE LSP, the bandwidth of the<BR>   existing TE LSP MUST also be included in addition to the requested<BR>   bandwidth if and only if the two values differ.  Consequently, two<BR>   Object-Type values are defined that refer to the requested bandwidth<BR>   and the bandwidth of the TE LSP for which a reoptimization is being<BR>   performed.<BR></SPAN></FONT></DIV> <DIV> </DIV> <DIV class=Section1> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial"><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">Thanking you,<o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">Best regards,<o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">S.SenthilKumar,<o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">Technical Project Lead, IPng,<o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial; mso-no-proof: yes"><IMG height=50 src="cid:140241002@23102008-1144" width=50 v:shapes="_x0000_i1025"><SPAN style="mso-spacerun: yes"> </SPAN></SPAN><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">Technologies India Pvt Ltd,<o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">Level 3, Leela Galleria,<o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">The Leela Palace,<o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">23, Airport Road, Bangalore - 560 008.<o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">Ph: +91-80-41781770 Ext: 1555<o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">Mobile: </SPAN><SPAN style="COLOR: blue; FONT-FAMILY: Arial; mso-no-proof: yes">+9198408-60866/+91 990-1982-365<o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">EMail-ID: <A title="Send mail" href="mailto:senthilkumars@huawei.com">senthilkumars@huawei.com</A><o:p></o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></P> <P class=MsoNormal><SPAN style="FONT-SIZE: 16pt; COLOR: #6600ff; FONT-FAMILY: 'Monotype Corsiva'">Performance, perseverance and persistence in spite of all obstacles, dicouragements, and impossibilities: It is this, that in all things distinguishes the strong soul from the weak.”<o:p></o:p></SPAN></P> <P class=MsoNormal style="TEXT-ALIGN: center" align=center><SPAN style="FONT-SIZE: 20pt; COLOR: #6600ff; FONT-FAMILY: 'Monotype Corsiva'"><o:p> </o:p></SPAN></P> <P class=MsoAutoSig><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></P> <P><SPAN style="COLOR: #999999">Disclaimer: 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!<o:p></o:p></SPAN></P> <P class=MsoNormal><o:p> </o:p></P></DIV> <DIV> </DIV></BODY></HTML> --Boundary_(ID_GbUfkk4rKUuXravyMlvc7Q)-- --Boundary_(ID_CCcYyc3aY6cPv3IFo6yN+A) Content-id: <140241002@23102008-1144> Content-type: image/jpeg; name=attd545b.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=attd545b.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2R3SN GkkYKijLMTgAetZmvayul+HLnVYCsoSMNEQcqxOAp+nIrm/ilqk1no9vYwsVF458wjuq44/EkflX N+F9XbVNCvPCd0+TPGTZMx6OPmCfmOPxrlqV7TdNb2/E93CZU6mHji5ax5tV/dT1f9dCrpOuX82s Q6jd3cs0qyBjuY4x3AHQDFeka9cK93BBvIVV38HueleNWk5t5CjgqQcEHsa7rWtVxqMeW/5doj+a g/1rghUapyT8j3sywSliIOCto9vl/mdjot+8sz2ruZNq7lY9celaqTRSSPEkis8eN6g8rnpmuC0z WV0rSrvV5cFm/cW6n+Nup/AcVgeGfEF1H40t5DK0n22Xyp8n7+49fwODXVTxHKoxl1PEllE6vtZx 0UV97Wr/AK7nsFFFFd58+eV3nizRfHenDT9R/wCJVexvut5nO6Pd0wT2B965G90/UNCvkS4jaCZC HikU5DY6MrdCPet/xl8OtRsNRl1DRoHu7Sdy7RRjLxEknAHcfSs3TJtftLf7HcaNdXtiTzbT27lR 7qcZQ+4ry60ZOXvLXufe5bXpQpfuJJxe8W9vRv8AJ6eaE11FvY4tdgUKl2Stwq9I5x978G+8PqfS r+u2t3deJbSxthmSa1twM9B+7GSfYYJP0rc8PeGoNQS7toVuoLK8jxNa3kRWSBxyjo2MPg8djg81 va74axFc3ttOsc8tslq0zIW8mID5ioHJZhgYpqhKUWzOeaUqVWNNdE0r+drX9NfVLTc801zUvtd1 HZWTM1naL5NuAOX55f6sefyrY0Oys/Csyaxr77bpButrBeZCccM4/h9s1C4utKBi0DRb9JMYN/Pb MZW/3BjCD6c+9UdO8Ka9rV8qGyuYw7/vLi4QqF9SSetYpNSuld/gejKVOVDklNQp9dVzPv6X69X5 HV/8LVuSMjSUwf8Apof8KK7C18K6RbWsMH2RJPKRU3sOWwMZNFd3s6/8x8o8Xld9KD+9/wCZY13S m1nSpbOO8ns5W5jngcqyMOnTqPUV5tB8P/HEmoeVda46WwPM/wBrd8j2Xrn64qOz+IevN8Mrm8kt NUkvwjFdSW3j8leRyTn/ANlrqtG13UrmbxWs90WGnrGbfKqPLzBuPbnnnmuiVNS3PKoYupQTULfc b+haBbaFbeXFLPcSsB5k88hZn/PoPYVozwx3ELwyrujcYYZ6ivKNV8f6lF4Z0CCHWoLTU57A31zP Oi/vMA7Y8YwC7foKvXfxBubZbjUkuN9nqmj/AGnTEKj91cqdjRjjk7mB5z0qkklZGEqkpy55PUta 94C1mOQzeH9XuTGT/wAe8tywK/Rs8j61qeDfDGsaZIbzW9UnuJiu1Lfz2dE9znqf5Vg6d4o8QTf2 d4bubzOtw6nJHfyoi5a3jXzCQMYG4Mqg0zwp4k8QeIpbPU7qXXEhuLniK1soPsioHxtLn58ccnr1 rNUYKXMjtqZliKlL2Umrd7a/eeoUV8yzfFXxss8ijXHADED9zH6/7tFannnoGlqP+FA3wwMeU3H/ AAJa5/4qs1p4o0sWzGEXlpELkRnb544GHx97jjmiigD0PwZbwJ4t8TIsMarELOOMBQAiCHhR6D2r h54Yjb6fGY0KR+MJURSowqllJAHYe1FFAHY6dFGPjjqz+Wu/+y0O7aM5ygrz3UpZLD4321lZyNbW rarDmCE7EOXGflHHNFFAHBXCJ9pl+UffPb3ooooA/9k= --Boundary_(ID_CCcYyc3aY6cPv3IFo6yN+A)-- --===============0013490828== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0013490828==-- From pce-bounces@ietf.org Thu Oct 23 08:32:44 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEBF3A6AD4; Thu, 23 Oct 2008 08:32:43 -0700 (PDT) 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 E73C43A690B for <pce@core3.amsl.com>; Thu, 23 Oct 2008 08:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 ctde+OY9IPrL for <pce@core3.amsl.com>; Thu, 23 Oct 2008 08:24:06 -0700 (PDT) Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id A07AF3A696E for <pce@ietf.org>; Thu, 23 Oct 2008 08:24:05 -0700 (PDT) Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 29CC6FE2D98 for <pce@ietf.org>; Thu, 23 Oct 2008 17:25:24 +0200 (CEST) Received: from ISHWANG (unknown [157.159.103.63]) by smtp2.int-evry.fr (Postfix) with ESMTP id 2F9244050CB for <pce@ietf.org>; Thu, 23 Oct 2008 17:24:49 +0200 (CEST) From: "Iksoon Hwang" <Iksoon.Hwang@it-sudparis.eu> To: <pce@ietf.org> Date: Thu, 23 Oct 2008 17:24:47 +0200 Message-ID: <7B291F962F904C8A901AD45049E2430D@ISHWANG> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Ack1I3uMFO5gL5OJQruG5vFQO/7c+Q== X-INT-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 2F9244050CB.2C599 X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: iksoon.hwang@it-sudparis.eu Subject: [Pce] Some questions and comments X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Dear all, I'm currently working on validation, verification, and testing of PCEP. PCEP was described in a formal language IF and some properties were validated. I have some questions and comments as follows. 1. A case that never happens In Appendix A, when a system in OpenWait state receives an Open message from its peer where no errors are detected, OpenRetry is 0, the session characteristics are unacceptable but negotiable, and LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait state. According to our experiments, the above case never happens. We can have LocalOK=1 only when the system receives a Keepalive message from its peer in KeepWait state. Since the system can move to KeepWait state only after receiving of an Open message from its peer in OpenWait state, the OpenRetry value is always more than 0 if we have LocalOK=1. 2. Contradiction In section 4.2.1, Keepalive messages are used to acknowledge Open messages, and once the PCEP session has been successfully established. In section 6.2, The PCEP session is considered as established once both PCEP peers have received a Keepalive message from their peer. In Appendix A, If a system in OpenWait state receives an Open message from the PCEP peer before the expiration of the OpenWait timer, it performs collision resolution procedure. If there is no collision, no errors are detected in Open message, and the session characteristics are acceptable to the local system, the system: o Sends a Keepalive message to the PCEP peer, o Starts the Keepalive timer, o Sets the RemoteOK variable to 1. If LocalOK=0 the system clears the OpenWait timer, starts the KeepWait timer and moves to the KeepWait state. The statement in section 4.2.1 and starting of the Keepalive timer in OpenWait state when LocalOK=0 are contradictory because the system starts keepalive mechanism although the session is not established yet. Also, there is another problem. In section 7.3, it is explained that "A sends an Open message to B with Keepalive=10 seconds and Deadtimer=40 seconds. This means that A sends Keepalive messages (or any other PCEP message) to B every 10 seconds and B can declare the PCEP session with A down if no PCEP message has been received from A within any 40 second period". The Keepalive timer should follow the Keepalive value in the Open message that was sent to its peer (not the Keepalive value in the Open message received from its peer). Therefore, the Keepalive timer can be set only after the peer accepted the parameter values in the Open message. I think the solution is to start the Keepalive timer and the Deadtimer when the system moves to UP state (there is no explanation when a system should start the Deadtimer). 3. The case of Error-Type=9, Error-Value=1 In section 7.15, If a PCEP peer detects an attempt from another PCEP peer to establish a second PCEP session, it MUST send a PCErr message with Error-type=9, Error-value=1. In section 6.2, Once the TCP connection has been successfully established, the first message sent by the PCC to the PCE or by the PCE to the PCC MUST be an Open message as specified in Appendix A. Any message received prior to an Open message MUST trigger a protocol error condition causing a PCErr message to be sent with Error-Type 'PCEP session establishment failure' and Error-Value 'reception of an invalid Open message or a non Open message' and the PCEP session establishment attempt MUST be terminated by closing the TCP connection. First of all, in such a case, do we have to try to establish the second session in order to send a PCErr message to its peer? In order to send a PCErr message it is necessary to send an Open message to its peer when a TCP connection is established. Otherwise, sending of Error-Type=9 and Error-value=1 will be useless because the peer will consider it as an error from the other side. Secondly, is it appropriate to ignore the second connection? In case of connection oriented protocols, we may have resource mismatch problems, i.e. one assumes that a connection is already released while the other is still holding it. If the second connection is always ignored, we cannot have any connection between two peers before resource mismatch problem is resolved. 4. Receiving Open message in KeepWait state According to the Appendix A, if an Open message is received from its peer when the system is in KeepWait state, the system should abort the establishment procedure. In order to have a successful session establishment, in such a case, reply messages must be sent in the order the requests are received. Isn't it too strong condition? I'm sorry for too long questions and comments. Thanks in advance! Iksoon _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Oct 23 14:30:02 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19343A695F; Thu, 23 Oct 2008 14:30:02 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EC36D3A695F; Thu, 23 Oct 2008 14: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: <20081023213001.EC36D3A695F@core3.amsl.com> Date: Thu, 23 Oct 2008 14:30:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-global-concurrent-optimization-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-ietf-pce-global-concurrent-optimization-05.txt Pages : 31 Date : 2008-10-23 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. In this context a PCC may be a Label Switching Router (LSR), a Network Management System (NMS), or another PCE. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of TE LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. While GCO is applicable to any simultaneous request for multiple TE LSPs (for example, a request for end-to-end protection), it is not envisaged that global concurrent reoptimization would be applied in a network (such as an MPLS-TE network) that contains a very large number of very low bandwidth or zero bandwidth TE LSPs since the large scope of the problem and the small benefit of concurrent reoptimization relative to single TE LSP reoptimization is unlikely to make the process worthwhile. Further, applying global concurrent reoptimization in a network with a high rate of change of TE LSPs (churn) is not advised because of the likelihood that TE LSPs would change before they could be globally reoptimized. Global reoptimization is more applicable to stable networks such as transport networks or those with long-term TE LSP tunnels. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-global-concurrent-optimization-05.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-global-concurrent-optimization-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-23141854.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Thu Oct 23 19:02:54 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2893A6A6A; Thu, 23 Oct 2008 19:02:54 -0700 (PDT) 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 EBE1B3A67A3 for <pce@core3.amsl.com>; Thu, 23 Oct 2008 19:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[AWL=0.984, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvs8arv2Ou0n for <pce@core3.amsl.com>; Thu, 23 Oct 2008 19:02:52 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0B66028B23E for <pce@ietf.org>; Thu, 23 Oct 2008 19:02:52 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K98001650EOYM@szxga03-in.huawei.com> for pce@ietf.org; Fri, 24 Oct 2008 10:04:00 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9800IJ30EO3A@szxga03-in.huawei.com> for pce@ietf.org; Fri, 24 Oct 2008 10:04:00 +0800 (CST) Received: from SSK1548 ([10.18.24.148]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9800ISY0EN98@szxml05-in.huawei.com> for pce@ietf.org; Fri, 24 Oct 2008 10:04:00 +0800 (CST) Date: Fri, 24 Oct 2008 07:34:23 +0530 From: "S.SenthilKumar (Huawei)" <senthilKumars@huawei.com> To: pce@ietf.org Message-id: <003c01c9357c$d5fe7610$9418120a@china.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ack1fNU4IrgJpg4YSSywWatSEpZ2EA== Subject: [Pce] Description of Value field in OVERLOADED-DURATION TLV - draft-ietf-pce-pcep-16.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: senthilKumars@huawei.com List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1949197070==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============1949197070== Content-type: multipart/alternative; boundary="Boundary_(ID_Ekr+CWqrlnfXlSZuVCYqsQ)" This is a multi-part message in MIME format. --Boundary_(ID_Ekr+CWqrlnfXlSZuVCYqsQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all The following line draft-ietf-pce-pcep-16.txt section 7.14 is misleading The OVERLOADED-DURATION TLV is compliant with the PCEP TLV format defined in section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the TLV length (length of the value portion in bytes) followed by a fix length value field of 32-bits flags field. TYPE: To be assigned by IANA (suggested value=2) LENGTH: 4 VALUE: 32-bits flags field indicates the estimated PCE congestion duration in seconds. I suggest instead of mentioning the VALUE field as "32-bits flags field", it can just mentioned as "32-bits field" Thanking you Best Regards S.SenthilKumar --Boundary_(ID_Ekr+CWqrlnfXlSZuVCYqsQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD> <BODY> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008>Dear all</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008>The following line <SPAN class=140241002-23102008>draft-ietf-pce-pcep-16.txt section 7.14 is misleading</SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008><SPAN class=140241002-23102008></SPAN></SPAN></FONT> </DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=062320002-24102008><SPAN class=140241002-23102008>The OVERLOADED-DURATION TLV is compliant with the PCEP TLV format<BR>defined in section 7.1 and is comprised of 2 bytes for the type,<BR>2 bytes specifying the TLV length (length of the value portion in bytes)<BR>followed by a fix length value field of 32-bits flags field.</SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=062320002-24102008><SPAN class=140241002-23102008>TYPE: To be assigned by IANA (suggested value=2)<BR>LENGTH: 4<BR>VALUE: 32-bits <FONT color=#ff0000>flags</FONT> field indicates the estimated PCE congestion<BR>duration in seconds.</SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008><SPAN class=140241002-23102008></SPAN></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008><SPAN class=140241002-23102008>I suggest instead of mentioning the VALUE field as "<FONT color=#ff0000>32-bits flags field",</FONT> it can just mentioned as <FONT color=#0000ff>"32-bits field"</FONT></SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008><SPAN class=140241002-23102008></SPAN></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008><SPAN class=140241002-23102008>Thanking you</SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008><SPAN class=140241002-23102008></SPAN></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008><SPAN class=140241002-23102008>Best Regards</SPAN></SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=062320002-24102008><SPAN class=140241002-23102008>S.SenthilKumar</SPAN></SPAN></FONT></DIV></BODY></HTML> --Boundary_(ID_Ekr+CWqrlnfXlSZuVCYqsQ)-- --===============1949197070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1949197070==-- From pce-bounces@ietf.org Thu Oct 23 20:39:21 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6CE03A677E; Thu, 23 Oct 2008 20:39:21 -0700 (PDT) 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 D5F593A6358 for <pce@core3.amsl.com>; Thu, 23 Oct 2008 20:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.063 X-Spam-Level: X-Spam-Status: No, score=-0.063 tagged_above=-999 required=5 tests=[AWL=0.431, 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 4Z4pAC1lZZdc for <pce@core3.amsl.com>; Thu, 23 Oct 2008 20:39:19 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BD5BB3A677E for <pce@ietf.org>; Thu, 23 Oct 2008 20:39:18 -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 <0K98008IT4V0N2@szxga04-in.huawei.com> for pce@ietf.org; Fri, 24 Oct 2008 11:40:12 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9800GSU4V0Q1@szxga04-in.huawei.com> for pce@ietf.org; Fri, 24 Oct 2008 11:40:12 +0800 (CST) Received: from SSK1548 ([10.18.24.148]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K98002OZ4UYIZ@szxml05-in.huawei.com> for pce@ietf.org; Fri, 24 Oct 2008 11:40:12 +0800 (CST) Date: Fri, 24 Oct 2008 09:10:33 +0530 From: "S.SenthilKumar (Huawei)" <senthilKumars@huawei.com> To: pce@ietf.org Message-id: <000b01c9358a$45631490$9418120a@china.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ack1ikSwcMUk0zHvQ2OJ7aKfRIbbkw== Subject: [Pce] OVERLOADED-DURATION and OVERLOAD-DURATION TLV X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: senthilKumars@huawei.com List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1051014882==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============1051014882== Content-type: multipart/alternative; boundary="Boundary_(ID_a7o1riww3G5OVZ155Hqqgw)" This is a multi-part message in MIME format. --Boundary_(ID_a7o1riww3G5OVZ155Hqqgw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear All Following is a review comment for draft-ietf-pce-pcep-16 In section 7.14, it is mentioned that PCE can provide the period of time during which no further request should be sent to the PCE in the OVERLOADED-DURATION TLV but in section 9.10. PCEP TLV Type Indicators, the same is mentioned as OVERLOAD-DURATION TLV I feel that OVERLOADED-DURATION and OVERLOAD-DURATION should be same. ---------------------------------------------------------------------------- --- Sections for reference ---------------------------------------------------------------------------- --- 7.14. NOTIFICATION Object ... ... ... Optionally, a TLV named OVERLOADED-DURATION may be included in the NOTIFICATION object that specifies the period of time during which no further request should be sent to the PCE. Once this period of time has elapsed, the PCE should no longer be considered in congested state. The OVERLOADED-DURATION TLV is compliant with the PCEP TLV format defined in section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the TLV length (length of the value portion in bytes) followed by a fix length value field of 32-bits flags field. TYPE: To be assigned by IANA (suggested value=2) LENGTH: 4 VALUE: 32-bits flags field indicates the estimated PCE congestion duration in seconds. ---------------------------------------------------------------------------- --- 9.10. PCEP TLV Type Indicators IANA is requested to create a registry for the PCEP TLVs. Value Meaning Reference 1 NO-PATH-VECTOR TLV This document 2 OVERLOAD-DURATION TLV This document 3 REQ-MISSING TLV This document Thanking you Best regards S.SenthilKumar --Boundary_(ID_a7o1riww3G5OVZ155Hqqgw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD> <BODY> <DIV><FONT face=Arial size=2>Dear All</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>Following is a review comment for draft-ietf-pce-pcep-16</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial><FONT size=2>In section 7.14, it is mentioned that PCE can provide the period of time during which no further request should be sent to the PCE in the OVERLOADED-DURATION TLV<SPAN class=109533803-24102008> </SPAN></FONT></FONT><FONT face=Arial size=2>but in section 9.10.  PCEP TLV Type Indicators, the same is mentioned as OVERLOAD-DURATION TLV</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>I feel that OVERLOAD<STRONG><FONT color=#ff0000>ED</FONT></STRONG>-DURATION and OVERLOAD-DURATION should be same.<BR></FONT><FONT face=Arial size=2></FONT></DIV> <DIV><FONT face=Arial size=2>-------------------------------------------------------------------------------<BR>Sections for reference<BR>-------------------------------------------------------------------------------<BR>7.14.  NOTIFICATION Object</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>...<BR>...<BR>...</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>Optionally, a TLV named OVERLOADED-DURATION may be included in the<BR>NOTIFICATION object that specifies the period of time during which<BR>no further request should be sent to the PCE. Once this period of<BR>time has elapsed, the PCE should no longer be considered in congested<BR>state.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>The OVERLOADED-DURATION TLV is compliant with the PCEP TLV format<BR>defined in section 7.1 and is comprised of 2 bytes for the type,<BR>2 bytes specifying the TLV length (length of the value portion in bytes)<BR>followed by a fix length value field of 32-bits flags field.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>TYPE: To be assigned by IANA (suggested value=2)<BR>LENGTH: 4<BR>VALUE: 32-bits flags field indicates the estimated PCE congestion<BR>duration in seconds.<BR>-------------------------------------------------------------------------------<BR>9.10.  PCEP TLV Type Indicators</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>   IANA is requested to create a registry for the PCEP TLVs.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>    Value         Meaning                    Reference</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>      1          NO-PATH-VECTOR TLV         This document<BR>      2          OVERLOAD-DURATION TLV      This document<BR>      3          REQ-MISSING TLV            This document</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Thanking you</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Best regards<BR>S.SenthilKumar<BR></FONT></DIV></BODY></HTML> --Boundary_(ID_a7o1riww3G5OVZ155Hqqgw)-- --===============1051014882== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============1051014882==-- From pce-bounces@ietf.org Fri Oct 24 03:45:02 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7638E3A6A9E; Fri, 24 Oct 2008 03:45:02 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CA76E3A6A9E; Fri, 24 Oct 2008 03: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: <20081024104501.CA76E3A6A9E@core3.amsl.com> Date: Fri, 24 Oct 2008 03:45:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-disc-mib-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Definitions of Managed Objects for Path Computation Element Discovery Author(s) : E. Stephan Filename : draft-ietf-pce-disc-mib-03.txt Pages : 25 Date : 2008-10-24 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing Path Computation Elements Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disc-mib-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-disc-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-24033301.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Fri Oct 24 09:06:54 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CE63A69B9; Fri, 24 Oct 2008 09:06:54 -0700 (PDT) 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 E60113A69B9 for <pce@core3.amsl.com>; Fri, 24 Oct 2008 09:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5IbQr1jQ75f for <pce@core3.amsl.com>; Fri, 24 Oct 2008 09:06:52 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id BEBDE3A6836 for <pce@ietf.org>; Fri, 24 Oct 2008 09:06:51 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m9OG7EA1007242 for <pce@ietf.org>; Fri, 24 Oct 2008 17:07:14 +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.12.11.20060308/8.12.11) with ESMTP id m9OG7AYO007185 for <pce@ietf.org>; Fri, 24 Oct 2008 17:07:14 +0100 Message-ID: <002a01c935f2$93a4d220$0200a8c0@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <pce@ietf.org> Date: Fri, 24 Oct 2008 17:06:31 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [Pce] A BNF Specification for PCEP X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Hi, This draft provides a specification of the BNF we already use in PCEP and makes it available for use in future PCEP extensions. I intend asking that this draft progress in the standards process relatively soon. Please review and comment as soon as possible. Thanks, Adrian ----- Original Message ----- From: <Internet-Drafts@ietf.org> To: <i-d-announce@ietf.org> Sent: Friday, October 24, 2008 5:00 PM Subject: I-D Action:draft-farrel-rtg-common-bnf-06.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Reduced Backus-Naur Form (RBNF) A Syntax Used in Various > Protocol Specifications > Author(s) : A. Farrel > Filename : draft-farrel-rtg-common-bnf-06.txt > Pages : 12 > Date : 2008-10-24 > > Several protocols have been specified using a common variant of the > Backus-Naur Form (BNF) of representing message syntax. However, there > is no formal definition of this version of BNF. > > There is value in using the same variant of BNF for the set of > protocols that are commonly used together. This reduces confusion and > simplifies implementation. > > Updating existing documents to use some other variant of BNF that is > already formally documented would be a substantial piece of work. > > This document provides a formal definition of the variant of BNF that > has been used (that we call Reduced BNF), and makes it available for > use by new protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-06.txt _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Oct 24 09:25:07 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809683A6BB2; Fri, 24 Oct 2008 09:25:07 -0700 (PDT) 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 093343A6B86 for <pce@core3.amsl.com>; Fri, 24 Oct 2008 09:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgmY8YGWph7U for <pce@core3.amsl.com>; Fri, 24 Oct 2008 09:25:01 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 85E3E3A6A72 for <pce@ietf.org>; Fri, 24 Oct 2008 09:25:01 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m9OGQMv9025326 for <pce@ietf.org>; Fri, 24 Oct 2008 17:26:22 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m9OGQL6H025310 for <pce@ietf.org>; Fri, 24 Oct 2008 17:26:21 +0100 Message-ID: <007c01c935f5$3fc40380$0200a8c0@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <pce@ietf.org> Date: Fri, 24 Oct 2008 17:26:18 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [Pce] PCE meeting time rescheduled X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Note well > PCE Session 1 (1.5 hours) > Tuesday, Afternoon Session I 1300-1500 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Oct 25 09:57:49 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA1028C1DB; Sat, 25 Oct 2008 09:57:49 -0700 (PDT) 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 B952828C1DB for <pce@core3.amsl.com>; Sat, 25 Oct 2008 09:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA64oaS3f08g for <pce@core3.amsl.com>; Sat, 25 Oct 2008 09:57:48 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id ADD3928C191 for <pce@ietf.org>; Sat, 25 Oct 2008 09:57:47 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m9PGx1Ec026544; Sat, 25 Oct 2008 17:59:01 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m9PGx0Lw026529; Sat, 25 Oct 2008 17:59:01 +0100 Message-ID: <020801c936c2$fa1a9050$0200a8c0@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <senthilKumars@huawei.com>, <pce@ietf.org> References: <000b01c9358a$45631490$9418120a@china.huawei.com> Date: Sat, 25 Oct 2008 17:45:55 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [Pce] OVERLOADED-DURATION and OVERLOAD-DURATION TLV X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org Looks like a typos we can fix in Auth48. Thanks. Adrian ----- Original Message ----- From: "S.SenthilKumar (Huawei)" <senthilKumars@huawei.com> To: <pce@ietf.org> Sent: Friday, October 24, 2008 4:40 AM Subject: [Pce] OVERLOADED-DURATION and OVERLOAD-DURATION TLV > Dear All > > Following is a review comment for draft-ietf-pce-pcep-16 > > In section 7.14, it is mentioned that PCE can provide the period of time > during which no further request should be sent to the PCE in the > OVERLOADED-DURATION TLV but in section 9.10. PCEP TLV Type Indicators, > the > same is mentioned as OVERLOAD-DURATION TLV > > I feel that OVERLOADED-DURATION and OVERLOAD-DURATION should be same. > > ---------------------------------------------------------------------------- > --- > Sections for reference > ---------------------------------------------------------------------------- > --- > 7.14. NOTIFICATION Object > > ... > ... > ... > > Optionally, a TLV named OVERLOADED-DURATION may be included in the > NOTIFICATION object that specifies the period of time during which > no further request should be sent to the PCE. Once this period of > time has elapsed, the PCE should no longer be considered in congested > state. > > The OVERLOADED-DURATION TLV is compliant with the PCEP TLV format > defined in section 7.1 and is comprised of 2 bytes for the type, > 2 bytes specifying the TLV length (length of the value portion in bytes) > followed by a fix length value field of 32-bits flags field. > > TYPE: To be assigned by IANA (suggested value=2) > LENGTH: 4 > VALUE: 32-bits flags field indicates the estimated PCE congestion > duration in seconds. > ---------------------------------------------------------------------------- > --- > 9.10. PCEP TLV Type Indicators > > IANA is requested to create a registry for the PCEP TLVs. > > Value Meaning Reference > > 1 NO-PATH-VECTOR TLV This document > 2 OVERLOAD-DURATION TLV This document > 3 REQ-MISSING TLV This document > > Thanking you > > Best regards > S.SenthilKumar > > -------------------------------------------------------------------------------- > _______________________________________________ > 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 pce-bounces@ietf.org Mon Oct 27 15:59:23 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C72728C14F; Mon, 27 Oct 2008 15:59:23 -0700 (PDT) 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 BD04D3A6A2C for <pce@core3.amsl.com>; Mon, 27 Oct 2008 15:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEwdtaewENAW for <pce@core3.amsl.com>; Mon, 27 Oct 2008 15:59:17 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 7E5A73A67D4 for <pce@ietf.org>; Mon, 27 Oct 2008 15:59:17 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9F003RC6ISC5@usaga04-in.huawei.com> for pce@ietf.org; Mon, 27 Oct 2008 17:59:16 -0500 (CDT) Received: from L73682 ([10.124.12.74]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9F00A2X6IO43@usaga04-in.huawei.com> for pce@ietf.org; Mon, 27 Oct 2008 17:59:16 -0500 (CDT) Date: Mon, 27 Oct 2008 17:59:12 -0500 From: Young Lee <ylee@huawei.com> To: pce@ietf.org Message-id: <000001c93887$a1270840$4a0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ack4h6CA4hticwugRMKiR5sLegswAg== Subject: [Pce] New Drafts X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0614662159==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org This is a multi-part message in MIME format. --===============0614662159== Content-type: multipart/alternative; boundary="Boundary_(ID_U3kEBo6ayaueuPHXDipkEw)" This is a multi-part message in MIME format. --Boundary_(ID_U3kEBo6ayaueuPHXDipkEw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All, A new version of PCEP support for WSON has been uploaded. We'd appreciate your input/comments and discussions in Minneapolis. Young ---------------------snipped------------------------------------------------ -------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PCEP Requirements and Extensions for WSON Routing and Wavelength Assignment Author(s) : Y. Lee, G. Bernstein Filename : draft-lee-pce-wson-routing-wavelength-03.txt Pages : 17 Date : 2008-10-27 This memo provides application-specific requirements and protocol enhancements 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. Different computational architectures for the RWA process are given and the PCEP extensions needed to support these architectures are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-pce-wson-routing-wavelength-03 .txt Internet-Drafts are also available by anonymous FTP at: <ftp://ftp.ietf.org/internet-drafts/> 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. --Boundary_(ID_U3kEBo6ayaueuPHXDipkEw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" = name=3D"City"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} h1 {margin-top:12.0pt; margin-right:0in; margin-bottom:3.0pt; margin-left:.3in; text-indent:-.3in; page-break-after:avoid; mso-list:l0 level1 lfo1; font-size:16.0pt; font-family:Arial;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} pre {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:Tahoma;} p.Style1, li.Style1, div.Style1 {margin-top:12.0pt; margin-right:0in; margin-bottom:3.0pt; margin-left:.3in; text-indent:-.3in; page-break-after:avoid; mso-list:l0 level1 lfo1; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle19 {mso-style-type:personal-compose; font-family:Arial; color:windowtext;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:1792360828; mso-list-template-ids:1288485006;} @list l0:level1 {mso-level-style-link:"Heading 1"; mso-level-text:%1; mso-level-tab-stop:.3in; mso-level-number-position:left; margin-left:.3in; text-indent:-.3in; font-family:"Times New Roman";} @list l0:level2 {mso-level-text:"%1\.%2"; mso-level-tab-stop:.4in; mso-level-number-position:left; margin-left:.4in; text-indent:-.4in; font-family:"Times New Roman";} @list l0:level3 {mso-level-text:"%1\.%2\.%3"; mso-level-tab-stop:.5in; mso-level-number-position:left; margin-left:.5in; text-indent:-.5in; font-family:"Times New Roman";} @list l0:level4 {mso-level-text:"%1\.%2\.%3\.%4"; mso-level-tab-stop:.6in; mso-level-number-position:left; margin-left:.6in; text-indent:-.6in;} @list l0:level5 {mso-level-text:"%1\.%2\.%3\.%4\.%5"; mso-level-tab-stop:.7in; mso-level-number-position:left; margin-left:.7in; text-indent:-.7in;} @list l0:level6 {mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6"; mso-level-tab-stop:.8in; mso-level-number-position:left; margin-left:.8in; text-indent:-.8in;} @list l0:level7 {mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7"; mso-level-tab-stop:.9in; mso-level-number-position:left; margin-left:.9in; text-indent:-.9in;} @list l0:level8 {mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8"; mso-level-tab-stop:1.0in; mso-level-number-position:left; margin-left:1.0in; text-indent:-1.0in;} @list l0:level9 {mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9"; mso-level-tab-stop:1.1in; mso-level-number-position:left; margin-left:1.1in; text-indent:-1.1in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><!--[if gte vml 1]><v:shapetype id=3D"_x0000_t74" = coordsize=3D"21600,21600"=20 o:spt=3D"74" = path=3D"m10860,2187c10451,1746,9529,1018,9015,730,7865,152,6685,,5415,,41= 75,152,2995,575,1967,1305,1150,2187,575,3222,242,4220,,5410,242,6560,575,= 7597l10860,21600,20995,7597v485,-1037,605,-2187,485,-3377c21115,3222,2042= 0,2187,19632,1305,18575,575,17425,152,16275,,15005,,13735,152,12705,730v-= 529,288,-1451,1016,-1845,1457xe"> <v:stroke joinstyle=3D"miter" /> <v:path gradientshapeok=3D"t" o:connecttype=3D"custom" = o:connectlocs=3D"10860,2187;2928,10800;10860,21600;18672,10800"=20 o:connectangles=3D"270,180,90,0" textboxrect=3D"5037,2277,16557,13677" = /> </v:shapetype><v:shape id=3D"DtsShapeName" o:spid=3D"_x0000_s1026" = type=3D"#_x0000_t74"=20 = alt=3D"47E529CG097D5920@5BB2C5D2BED5405097@8h9;J@ZM62793!!!!!!BIHO@]M6279= 3!!!!!!!!!!1110BCGBD3519Onsl`m/enu!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!1"=20 = style=3D'position:absolute;margin-left:0;margin-top:0;width:.05pt;height:= .05pt; z-index:1;visibility:hidden'> <w:anchorlock/> </v:shape><![endif]--></span></font><font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Hi = All,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>A new version of PCEP support for WSON has been = uploaded.  We’d appreciate your input/comments and discussions in <st1:City = w:st=3D"on"><st1:place = w:st=3D"on">Minneapolis</st1:place></st1:City>.<o:p></o:p></span></font><= /p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Young<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>---------------------snipped--------------------------= -------------------------------------------------------------------------= -----------<o:p></o:p></span></font></p> <pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>A New Internet-Draft is available from the = on-line Internet-Drafts <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>directories.<o:p></o:p></span></font></pre><pr= e><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><fon= t size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><fon= t size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>        = Title          : PCEP = Requirements and Extensions for WSON Routing and Wavelength = Assignment<o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>        = Author(s)      : Y. Lee, G. = Bernstein<o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>        = Filename       : = draft-lee-pce-wson-routing-wavelength-03.txt<o:p></o:p></span></font></pr= e><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>        = Pages          : = 17<o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>        = Date           : = 2008-10-27<o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>        = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>This memo = provides application-specific requirements and protocol = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>   enhancements for the Path = Computation Element communication Protocol = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>   (PCEP) for the support of = Wavelength Switched Optical Networks = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>   (WSON).  Lightpath = provisioning in WSONs requires a routing and = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>   wavelength assignment (RWA) = process.  From a path computation = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>   perspective, wavelength = assignment is the process of determining = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>   which wavelength can be = used on each hop of a path and forms an = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>   additional routing = constraint to optical light path computation. = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>   Different computational = architectures for the RWA process are given = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>   and the PCEP extensions = needed to support these architectures are = <o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>   defined.<o:p></o:p></span></= font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><fon= t size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>A URL for = this Internet-Draft is:<o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'><a href=3D"http://www.ietf.org/internet-drafts/draft-lee-pce-wson-routing-wa= velength-03.txt">http://www.ietf.org/internet-drafts/draft-lee-pce-wson-r= outing-wavelength-03.txt</a><o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><fon= t size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>Internet-Drafts are also available by = anonymous FTP at:<o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'><a href=3D"ftp://ftp.ietf.org/internet-drafts/"><span = lang=3DSV>ftp://ftp.ietf.org/internet-drafts/</span></a></span></font><sp= an lang=3DSV><o:p></o:p></span></pre><pre><font size=3D2 face=3D"Courier = New"><span lang=3DSV = style=3D'font-size:10.0pt'><o:p> </o:p></span></font></pre><pre><fon= t size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>Below is = the data which will enable a MIME compliant mail = reader<o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>implementation to automatically retrieve the = ASCII version of the<o:p></o:p></span></font></pre><pre><font size=3D2 face=3D"Courier New"><span = style=3D'font-size:10.0pt'>Internet-Draft.<o:p></o:p></span></font></pre>= <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> </div> </body> </html> --Boundary_(ID_U3kEBo6ayaueuPHXDipkEw)-- --===============0614662159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --===============0614662159==-- From pce-bounces@ietf.org Fri Oct 31 09:15:05 2008 Return-Path: <pce-bounces@ietf.org> X-Original-To: pce-archive@megatron.ietf.org Delivered-To: ietfarch-pce-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0883A6CB3; Fri, 31 Oct 2008 09:15:05 -0700 (PDT) X-Original-To: pce@ietf.org Delivered-To: pce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7D9EC3A6C50; Fri, 31 Oct 2008 09: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: <20081031161501.7D9EC3A6C50@core3.amsl.com> Date: Fri, 31 Oct 2008 09:15:01 -0700 (PDT) Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-policy-enabled-path-comp-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Path Computation Element <pce.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/pce> List-Post: <mailto:pce@ietf.org> List-Help: <mailto:pce-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe> Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Policy-Enabled Path Computation Framework Author(s) : I. Bryskin, et al. Filename : draft-ietf-pce-policy-enabled-path-comp-04.txt Pages : 36 Date : 2008-10-31 The Path Computation Element (PCE) Architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE Architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-policy-enabled-path-comp-04.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-policy-enabled-path-comp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-31090441.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --NextPart--