From pce-bounces@lists.ietf.org Mon Sep 03 05:20:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS852-0007Ot-4N; Mon, 03 Sep 2007 05:18:48 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IS851-0007On-4H for pce-confirm+ok@megatron.ietf.org; Mon, 03 Sep 2007 05:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS850-0007Of-R0 for pce@ietf.org; Mon, 03 Sep 2007 05:18:46 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IS84z-0005jX-DN for pce@ietf.org; Mon, 03 Sep 2007 05:18:46 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1IS84y-0007HQ-2T for pce@ietf.org; Mon, 03 Sep 2007 09:18:44 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Sep 2007 10:18:43 +0100 Message-ID: <076401c7ee0b$6c36cc50$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> Subject: Re: [Pce] New PCE working group I-Ds Date: Mon, 3 Sep 2007 10:18:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 03 Sep 2007 09:18:43.0803 (UTC) FILETIME=[6CA322B0:01C7EE0B] X-Originating-Pythagoras-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: msiva@cisco.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org All, I think we have adequate support for these two I-Ds. Authors, please submit new versions as... draft-ietf-pce-of-00.txt draft-sivabalan-pce-dste-00.txt Authors of draft-sivabalan-pce-dste, please note: you will need to resolve the issues raised by Dimitri as one of your first actions within the WG. Please don't leave it until Vancouver to close on these issues. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Sunday, August 12, 2007 4:31 PM Subject: [Pce] New PCE working group I-Ds > Hi, > > The meeting in Chicago was broadly in support of adopting two I-Ds as > working group drafts: > > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt > > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt > > Can you please indicate your opinion. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 04 07:19:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISWPZ-0003FA-Lt; Tue, 04 Sep 2007 07:17:37 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ISWPX-00038w-Th for pce-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 07:17:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISWPX-00038o-IM; Tue, 04 Sep 2007 07:17:35 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISWPW-0005NY-I2; Tue, 04 Sep 2007 07:17:35 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4446dd57ec; Tue, 04 Sep 2007 19:29:47 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm7746d88776; Sat, 01 Sep 2007 01:29:36 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 01 Sep 2007 01:29:36 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRA5q-0008C4-C4; Fri, 31 Aug 2007 13:15:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRA5k-00088N-O7; Fri, 31 Aug 2007 13:15:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRA5k-0004Hd-Ac; Fri, 31 Aug 2007 13:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3599C2AC4F; Fri, 31 Aug 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IRA5F-0006uT-Vm; Fri, 31 Aug 2007 13:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 31 Aug 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-manageability-requirements-02.txt X-BeenThere: pce@lists.ietf.org Reply-To: internet-drafts@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Inclusion of Manageability Sections in PCE Working Group Drafts Author(s) : A. Farrel Filename : draft-ietf-pce-manageability-requirements-02.txt Pages : 12 Date : 2007-8-31 It has often been the case that manageability considerations have been retrofitted to protocols after they have been speicified, 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-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-manageability-requirements-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-manageability-requirements-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-31125352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-manageability-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-manageability-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-31125352.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed Sep 05 06:25:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISs2Y-0008FN-0h; Wed, 05 Sep 2007 06:23:18 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ISs2W-0008FG-UC for pce-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 06:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISs2W-0008F8-KJ for pce@ietf.org; Wed, 05 Sep 2007 06:23:16 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISs2V-0006vV-76 for pce@ietf.org; Wed, 05 Sep 2007 06:23:16 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1ISs2U-00072m-MT for pce@ietf.org; Wed, 05 Sep 2007 10:23:14 +0000 Received: from your029b8cecfe ([88.96.235.138] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Sep 2007 11:23:13 +0100 Message-ID: <012b01c7efa6$c25a35d0$0302a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 5 Sep 2007 11:22:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 05 Sep 2007 10:23:13.0540 (UTC) FILETIME=[C401A440:01C7EFA6] X-Originating-Rutherford-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Pce] Acceptance of draft-vasseur-pce-monitoring-03.txt ? X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, Some time back we had a relatively good show of support for draft-vasseur-pce-monitoring as a working group I-D. There are still some questions being raised, but in my opinion, that is fine. We expect questions, discussions, and modifications of the draft in its lifetime within the working group. However, since we all expressed our opinions on the draft, JP has drawn our attention to the IPR claim registered at https://datatracker.ietf.org/ipr/872/. So, before we go ahead and adopt the work, I just need to check that there is no new strong opinion against it. I'll give you a few days to respond. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Sep 05 15:44:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT0lu-0004ft-Op; Wed, 05 Sep 2007 15:42:42 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IT0lr-0004cj-9Q for pce-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 15:42:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT0lq-0004cb-Ud; Wed, 05 Sep 2007 15:42:38 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT0lq-0007gt-Hl; Wed, 05 Sep 2007 15:42:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 4220E2AC64; Wed, 5 Sep 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IT0L7-0003Or-TN; Wed, 05 Sep 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 05 Sep 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-xro-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions Author(s) : E. Oki, A. Farrel Filename : draft-ietf-pce-pcep-xro-02.txt Pages : 0 Date : 2007-9-5 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed route exclusions. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-xro-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-pcep-xro-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-pcep-xro-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-5145042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcep-xro-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcep-xro-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-5145042.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed Sep 05 16:16:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1HE-0003La-AR; Wed, 05 Sep 2007 16:15:04 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IT1HD-0003LE-9f for pce-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 16:15:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1HC-0003L2-UW; Wed, 05 Sep 2007 16:15:02 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT1HC-0000wb-Ge; Wed, 05 Sep 2007 16:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6CB632AC63; Wed, 5 Sep 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IT1HC-00041Y-6b; Wed, 05 Sep 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 05 Sep 2007 16:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-brpc-06.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-brpc-06.txt Pages : 18 Date : 2007-9-5 The ability to compute shortest constrained Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constrained paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-brpc-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-brpc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-5150506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-brpc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-brpc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-5150506.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed Sep 05 17:16:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT2DA-0006Mm-Bt; Wed, 05 Sep 2007 17:14:56 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IT2D9-0006Mh-Hh for pce-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 17:14:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT2D9-0006MZ-55 for pce@ietf.org; Wed, 05 Sep 2007 17:14:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT2D8-0003BU-4f for pce@ietf.org; Wed, 05 Sep 2007 17:14:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Sep 2007 17:14:54 -0400 X-IronPort-AV: i="4.20,212,1186372800"; d="scan'208,217"; a="131060403:sNHT141785552" 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 l85LErak008387 for ; Wed, 5 Sep 2007 17:14:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l85LEhZO016042 for ; Wed, 5 Sep 2007 21:14:56 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 17:14:51 -0400 Received: from [10.86.104.180] ([10.86.104.180]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 17:14:50 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: References: From: JP Vasseur Subject: Fwd: [Pce] I-D ACTION:draft-ietf-pce-brpc-06.txt Date: Wed, 5 Sep 2007 17:14:16 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 05 Sep 2007 21:14:50.0966 (UTC) FILETIME=[CBE36760:01C7F001] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=19940; t=1189026893; x=1189890893; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[Pce]=20I-D=20ACTION=3Adraft-ietf-pce-brpc-06.txt=20 |Sender:=20 |To:=20pce@ietf.org; bh=9WxzGrDZJCfgDMdLGvZeWbOPZzDro+liAA17Er2jXh8=; b=c6BnEz7ybE0Ff4jhYB3KNigDd1NCrMasBGW2ZLAMOzdxWpVEcDFNscyCRS3zqRD9COYxy3jm uu1FG1w3qZjgUT/1L8ijo/ZS59xx8z2NaAnDM9UCnvCSPEcbi7ZeHsmq; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0369063665==" Errors-To: pce-bounces@lists.ietf.org --===============0369063665== Content-Type: multipart/alternative; boundary=Apple-Mail-82-266258852 --Apple-Mail-82-266258852 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Just a refresh. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: September 5, 2007 4:15:02 PM EDT > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D ACTION:draft-ietf-pce-brpc-06.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working > Group of the IETF. > > Title : A Backward Recursive PCE-based Computation (BRPC) > procedure to compute shortest inter-domain Traffic Engineering > Label Switched Paths > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-pce-brpc-06.txt > Pages : 18 > Date : 2007-9-5 > > The ability to compute shortest constrained Traffic Engineering (TE) > Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) networks across multiple domains > (where > a domain is referred to as a collection of network elements > within a > common sphere of address management or path computational > responsibility such as IGP areas and Autonomous Systems) has been > identified as a key requirement . This document specifies a > procedure relying on the use of multiple Path Computation Elements > (PCEs) in order to compute such inter-domain shortest constrained > paths along a determined sequence of domains, using a backward > recursive path computation technique while preserving > confidentiality > across domains, which is sometimes required when domains are > managed > by different Service Providers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-06.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-pce-brpc-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pce-brpc-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-9-5150506.I-D@ietf.org> > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-82-266258852 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Just a refresh.

JP.

= Begin forwarded message:

Date: September 5, 2007 4:15:02 PM = EDT
To: i-d-announce@ietf.org
Subject: = [Pce] I-D ACTION:draft-ietf-pce-brpc-06.txt=A0

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

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


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

A URL for this Internet-Draft is:

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

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

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


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

=

= --Apple-Mail-82-266258852-- --===============0369063665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0369063665==-- From pce-bounces@lists.ietf.org Fri Sep 07 07:09:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITbgC-00011P-GL; Fri, 07 Sep 2007 07:07:16 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ITbgA-00011J-SL for pce-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 07:07:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITbgA-00011B-HI for pce@ietf.org; Fri, 07 Sep 2007 07:07:14 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITbg9-0001Td-VT for pce@ietf.org; Fri, 07 Sep 2007 07:07:14 -0400 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l87B6dH8012065; Fri, 7 Sep 2007 13:06:39 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 7 Sep 2007 13:07:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Acceptance of draft-vasseur-pce-monitoring-03.txt ? Date: Fri, 7 Sep 2007 13:07:11 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001320FCC@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <012b01c7efa6$c25a35d0$0302a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Acceptance of draft-vasseur-pce-monitoring-03.txt ? thread-index: Acfvpuxgzh+VyguCTTyHyv8QXbhWnQBk4XUA References: <012b01c7efa6$c25a35d0$0302a8c0@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , X-OriginalArrivalTime: 07 Sep 2007 11:07:12.0024 (UTC) FILETIME=[3D7DD980:01C7F13F] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org adrian - see inline: > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Wednesday, September 05, 2007 12:23 PM > To: pce@ietf.org > Subject: [Pce] Acceptance of draft-vasseur-pce-monitoring-03.txt ? >=20 > Hi, >=20 > Some time back we had a relatively good show of support for=20 > draft-vasseur-pce-monitoring as a working group I-D. >=20 > There are still some questions being raised, but in my=20 > opinion, that is=20 > fine. We expect questions, discussions, and modifications of=20 > the draft in=20 > its lifetime within the working group. >=20 > However, since we all expressed our opinions on the draft, JP=20 > has drawn our=20 > attention to the IPR claim registered at=20 > https://datatracker.ietf.org/ipr/872/. So, before we go ahead=20 > and adopt the=20 > work, I just need to check that there is no new strong=20 > opinion against it. -> the question is what is the object of the support that=20 we have seen on the list ? the need for monitoring of the performance or the solution ? =3D> both aspects are strongly inter-related. > I'll give you a few days to respond. >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Sep 07 09:19:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdit-0001xA-Uc; Fri, 07 Sep 2007 09:18:11 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ITdis-0001x5-Qn for pce-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 09:18:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdis-0001wx-Fj for pce@ietf.org; Fri, 07 Sep 2007 09:18:10 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITdir-0004m8-RP for pce@ietf.org; Fri, 07 Sep 2007 09:18:10 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1ITdiq-0002KQ-Jq for pce@ietf.org; Fri, 07 Sep 2007 13:18:08 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Sep 2007 14:18:08 +0100 Message-ID: <042201c7f151$85395300$0302a8c0@your029b8cecfe> From: "Adrian Farrel" To: References: <014401c7e6b3$163d5080$3407a8c0@your029b8cecfe> Subject: Re: [Pce] Question about PCEP Keepalive Date: Fri, 7 Sep 2007 14:17:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 07 Sep 2007 13:18:08.0195 (UTC) FILETIME=[88226930:01C7F151] X-Originating-Pythagoras-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hello? Anyone got an answer? Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Saturday, August 25, 2007 1:56 AM Subject: [Pce] Question about PCEP Keepalive > Hi, > > I'm looking at r08 sections 6.3 and 7.2. > > Section 6.3 has > > Note that sending Keepalive messages to maintain the session alive is > optional and PCEP peers may decide to not send Keepalive messages > once the PCEP session is established. > > Section 7.2 has > > Keepalive (8 bits): maximum period of time (in seconds) between the > sending of PCEP messages. The minimum value for the Keepalive is 1 > second. When set to 0, once the session is established, no further > Keepalive messages need to be sent to the remote peer. > > And also > > A sends an Open message to B with Keepalive=10 seconds and > Deadtimer=30 seconds. This means that A sends Keepalive messages (or > ay other PCEP message) to B every 30 seconds and B can declare the > PCEP session with A down if no PCEP has been received from A. > > I find this peculiar. Sending a keepalive message does not verify for the > sender that the session is open. It verifies for the receiver. So, surely > the parameter in the Open object says how frequently the sender of the > Open > message wants to receive a Keepalive message. That is, how often the > receiver of the Open message must send a Keepalive message. > > For example, if a PCC is worried that the session may fail, it will want > to > operate the keepalive process. But as currently specified, the PCC can > only > tell the PCE how often the PCC will send Keepalive messages, and after > what > period the PCE may declare the session dead. This is no help to the PCC! > If > the PCE decides that it will not send Keepalive messages then the PCC > cannot > determine the health of the session and cannot switch to a new PCE. > > In other words, the keepalive process is back-to-front. > > Further, I don't see why you need the keepalive timer value and the dead > timer value. One value can be derived from the other, probably through a > recommended ratio of 3.5. > > Lastly, when describing that the use of keepalive is optional, there are a > couple of points: > > 1. Optional should be an RFC 2119 word > 2. You need to make it clear that it is not the "PCEP peers" > that decide to not send keepalives, but "each PCEP peer" > that decides "whether it wants to receive keepalives" > 3. You should indicate the circumstances surrounding > the choice for this option. I think that, you might suggest > that if PCE discovery is in use, the failure of a PCE can > be speedily detected by the failure of the IGP, and can > be flooded by timing out the LSA containing the discovery > information. In this case, keepalive would not be needed. > > Yes? > > Adrian > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Sep 07 12:26:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgd3-00026T-0L; Fri, 07 Sep 2007 12:24:21 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ITgd1-00026J-VO for pce-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 12:24:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgd1-00026A-Kc for pce@ietf.org; Fri, 07 Sep 2007 12:24:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITgd1-0001Ep-A1 for pce@ietf.org; Fri, 07 Sep 2007 12:24:19 -0400 X-IronPort-AV: E=Sophos;i="4.20,221,1186372800"; d="scan'208";a="70414714" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Sep 2007 12:24:20 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l87GOI6H011120; Fri, 7 Sep 2007 12:24:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l87GNtCI002195; Fri, 7 Sep 2007 16:24:18 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 12:24:16 -0400 Received: from [10.86.104.180] ([10.86.104.180]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 12:24:16 -0400 In-Reply-To: <076401c7ee0b$6c36cc50$0300a8c0@your029b8cecfe> References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> <076401c7ee0b$6c36cc50$0300a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] New PCE working group I-Ds Date: Fri, 7 Sep 2007 12:23:40 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Sep 2007 16:24:16.0678 (UTC) FILETIME=[8911AC60:01C7F16B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1314; t=1189182259; x=1190046259; 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]=20New=20PCE=20working=20group=20I-Ds |Sender:=20 |To:=20Adrian=20Farrel=20; bh=kvm4jmeTEquLrL2+zb+gbiKHslvGj1eGHGIqfSg1uYQ=; b=pdUVJ6nSoQkv/DCWwP2Pvjc2hj481VnmJxNWG28K+De6yCqGf729elwfa5U44r71P33RXlMr xBPVG8CaRbKBeXxj/IzdHXMHkTSND9ECJJX6F8b0tBO5j54FNGXfrH8W; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: pce@ietf.org, msiva@cisco.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org On Sep 3, 2007, at 5:18 AM, Adrian Farrel wrote: > All, > > I think we have adequate support for these two I-Ds. > > Authors, please submit new versions as... > > draft-ietf-pce-of-00.txt > draft-sivabalan-pce-dste-00.txt => draft-ietf-pce-dste-00.txt. > > Authors of draft-sivabalan-pce-dste, please note: you will need to > resolve the issues raised by Dimitri as one of your first actions > within the WG. Please don't leave it until Vancouver to close on > these issues. > > Thanks, > Adrian > ----- Original Message ----- From: "Adrian Farrel" > > To: > Sent: Sunday, August 12, 2007 4:31 PM > Subject: [Pce] New PCE working group I-Ds > > >> Hi, >> >> The meeting in Chicago was broadly in support of adopting two I-Ds >> as working group drafts: >> >> - Encoding of Objective Functions in Path Computation Element (PCE) >> communication and discovery protocols >> draft-leroux-pce-of-01.txt >> >> - Diff-Serv Aware Class Type Object for Path Computation Element >> Communication Protocol draft-sivabalan-pce-dste-01.txt >> >> Can you please indicate your opinion. > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Sep 07 12:53:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITh37-0007da-CN; Fri, 07 Sep 2007 12:51:17 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ITh36-0007dT-1a for pce-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 12:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITh35-0007dL-O8 for pce@ietf.org; Fri, 07 Sep 2007 12:51:15 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITh34-0005bG-8f for pce@ietf.org; Fri, 07 Sep 2007 12:51:15 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 18:51:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Question about PCEP Keepalive Date: Fri, 7 Sep 2007 18:51:10 +0200 Message-ID: In-Reply-To: <042201c7f151$85395300$0302a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Question about PCEP Keepalive Thread-Index: AcfxUY44DnMaU4J/Ql2yEu0f9RbPMgABj8Xg References: <014401c7e6b3$163d5080$3407a8c0@your029b8cecfe> <042201c7f151$85395300$0302a8c0@your029b8cecfe> From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 07 Sep 2007 16:51:08.0101 (UTC) FILETIME=[498D4F50:01C7F16F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Adrian, Please see inline, > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Envoy=E9 : vendredi 7 septembre 2007 15:18 > =C0 : pce@ietf.org > Objet : Re: [Pce] Question about PCEP Keepalive >=20 > Hello? >=20 > Anyone got an answer? >=20 > Thanks, > Adrian > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Saturday, August 25, 2007 1:56 AM > Subject: [Pce] Question about PCEP Keepalive >=20 >=20 > > Hi, > > > > I'm looking at r08 sections 6.3 and 7.2. > > > > Section 6.3 has > > > > Note that sending Keepalive messages to maintain the=20 > session alive is > > optional and PCEP peers may decide to not send Keepalive messages > > once the PCEP session is established. > > > > Section 7.2 has > > > > Keepalive (8 bits): maximum period of time (in seconds)=20 > between the > > sending of PCEP messages. The minimum value for the=20 > Keepalive is 1 > > second. When set to 0, once the session is established,=20 > no further > > Keepalive messages need to be sent to the remote peer. > > > > And also > > > > A sends an Open message to B with Keepalive=3D10 seconds and > > Deadtimer=3D30 seconds. This means that A sends Keepalive=20 > messages (or > > ay other PCEP message) to B every 30 seconds and B can declare the > > PCEP session with A down if no PCEP has been received from A. > > > > I find this peculiar. Sending a keepalive message does not=20 > verify for the > > sender that the session is open. It verifies for the=20 > receiver.=20 Yes So, surely > > the parameter in the Open object says how frequently the=20 > sender of the > > Open > > message wants to receive a Keepalive message.=20 as currently specified the sender says how often it is ready to send = Keepalive messages That is, how often the > > receiver of the Open message must send a Keepalive message. > > > > For example, if a PCC is worried that the session may fail,=20 > it will want > > to > > operate the keepalive process. But as currently specified,=20 > the PCC can > > only > > tell the PCE how often the PCC will send Keepalive=20 > messages, and after > > what > > period the PCE may declare the session dead. This is no=20 > help to the PCC! But there is a negociation. As described in the FSM section, the PCC may = reject an open message with an unacceptable keepalive from the PCE, and = indicate an acceptable value in the PCErr message. So in this way the = PCC can control the frequency at which the PCE will send keepalive. > > If > > the PCE decides that it will not send Keepalive messages=20 > then the PCC > > cannot > > determine the health of the session and cannot switch to a new PCE. The PCC can reject the Open and start negociating... > > > > In other words, the keepalive process is back-to-front. > > > > Further, I don't see why you need the keepalive timer value=20 > and the dead > > timer value. One value can be derived from the other,=20 > probably through a > > recommended ratio of 3.5. This is a good point > > > > Lastly, when describing that the use of keepalive is=20 > optional, there are a > > couple of points: > > > > 1. Optional should be an RFC 2119 word Right, > > 2. You need to make it clear that it is not the "PCEP peers" > > that decide to not send keepalives, but "each PCEP peer" > > that decides "whether it wants to receive keepalives" Each peer takes part into the decision, this is a negociation. > > 3. You should indicate the circumstances surrounding > > the choice for this option. I think that, you might suggest > > that if PCE discovery is in use, the failure of a PCE can > > be speedily detected by the failure of the IGP, and can > > be flooded by timing out the LSA containing the discovery > > information. In this case, keepalive would not be needed. OK, we will add this point.=20 Regards, JL > > > > Yes? > > > > Adrian > > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Sep 07 13:09:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IThIe-00073r-6j; Fri, 07 Sep 2007 13:07:20 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IThIc-00073m-2e for pce-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 13:07:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IThIb-00073d-JT for pce@ietf.org; Fri, 07 Sep 2007 13:07:17 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IThIa-0002Kg-AH for pce@ietf.org; Fri, 07 Sep 2007 13:07:17 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 19:07:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] PCEP Request ID Date: Fri, 7 Sep 2007 19:07:08 +0200 Message-ID: In-Reply-To: <002001c7db49$994303f0$75600337@AOFR11476> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] PCEP Request ID Thread-Index: AcfasLubc8kSH1yqRFit9qXiDRobwgAlbSyABYpQS/A= References: <002001c7db49$994303f0$75600337@AOFR11476> From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 07 Sep 2007 17:07:10.0243 (UTC) FILETIME=[87088730:01C7F171] X-Spam-Score: 0.0 (/) X-Scan-Signature: 919970d5fe16e84197d564bf094e8b04 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0993730450==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0993730450== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F171.86C335CB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F171.86C335CB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fabien =20 Thanks for your comment. =20 Please see inline, ________________________________ De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]=20 Envoy=E9 : vendredi 10 ao=FBt 2007 14:26 =C0 : pce@ietf.org Objet : [Pce] PCEP Request ID =09 =09 Hello all, =20 I have a little comment/suggestion on PCEP regarding the request Id. In section 7.3.1 states that "The Request-ID-number value combined with the source IP address of the = PCC and the PCE address uniquely=20 identify the path computation request context". =20 I agree with that, however there may be 2 requests with same request Id = exchanged on the same session in=20 the case of session between 2 PCEs.=20 One Path Request being sent by PCE#1 to PCE#2 and the other one by = PCE#2 to PCE#1. =20 I don't think there is any problem with that but I am a little = concerned about potential misinterpretation especially in PCErr and PCNotif message. If a PCNtf/PCErr message contains an RP object, nothing indicates if it = is related to the Request from PCE#1 to PCE#2 or the one from PCE#2 to PCE#1, except the notification/error type and = value.=20 =20 =20 =20 I guess this is why for instance for the "Pending Request cancelled" = notification there are 2 values. One for PCC and one for the PCE.=20 =20 Yes, this is exactly the reason why there are two values.=20 =20 One of the problem, from an implementation perspective, is that we must = first ready the Notification type/value in order to retrieve the correct PathRequest.=20 =20 Anyway, you have to parse the entire message.=20 There are other implementations that first parse the whole message and = then start processing the objects. This is IMO and implementation issue. =20 Another problem is if an implementation does not recognize a given = Error type/value, then it can't tell for sure which PathRequest it is related to.=20 =20 Anyway an Error related to a request is always sent in the PCE-PCC = direction=20 =20 =20 So it seems to me it would be more consistent to add a bit in the RP = object (in the flag field) to indicate the "direction" of the PathRequest. For instance if the bit is set the Message that carry the RP object is = related to the request sent by the destination of the message.=20 Hence, an RP object would actually uniquely indentifies a PathRequest.=20 =20 There maybe an ambiguity only in a few error/notif situations, and I = don't think adding a generic bit would be really useful. By the way this would be a significant change wilth potentially new = error situations to handle (what do you do if the direction PCC to PCE = is set in a reply message?) . =20 Is that OK with you if we keep as is? =20 Best Regards, =20 JL =20 Regards Fabien Verhaeghe =20 ------_=_NextPart_001_01C7F171.86C335CB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Fabien
 
Thanks for your comment.
 
Please see inline,

De : Fabien VERHAEGHE=20 [mailto:fabien.verhaeghe@marben-products.com] =
Envoy=E9 :=20 vendredi 10 ao=FBt 2007 14:26
=C0 :=20 pce@ietf.org
Objet : [Pce] PCEP Request = ID

Hello=20 all,

 

I have a = little=20 comment/suggestion on PCEP regarding the request Id.

In section = 7.3.1=20 states that

=93The=20 Request-ID-number value combined with the source IP address of the PCC = and the=20 PCE address uniquely

identify = the path=20 computation request context=94.

 

I agree = with that,=20 however there may be 2 requests with same request Id exchanged on the = same=20 session in

the case of = session=20 between 2 PCEs.

One Path = Request=20 being sent by PCE#1 to PCE#2 and the other one by PCE#2 to=20 PCE#1.

 

I don=92t = think there=20 is any problem with that but I am a little concerned about potential=20 misinterpretation especially

in PCErr = and PCNotif=20 message.

If a = PCNtf/PCErr=20 message contains an RP object, nothing indicates if it is related to = the=20 Request from PCE#1 to PCE#2

or the one = from PCE#2=20 to PCE#1, except the notification/error type and value. 

 

 

 <= /P>

I guess = this is why=20 for instance for the =93Pending Request cancelled=94 notification = there are 2=20 values. One for PCC and

one for the = PCE. 

 

Yes, this is = exactly the=20 reason why there are two=20 = values. =

 

One of the = problem,=20 from an implementation perspective, is that we must first ready the=20 Notification type/value in order to = retrieve

the correct = PathRequest. 

 

Anyway, you have to = parse the=20 entire message.

There are=20 other implementations that first parse the whole message and then = start=20 processing the objects.

This is IMO and = implementation=20 issue.

 <= /P>

Another = problem is if=20 an implementation does not recognize a given Error type/value, then it = can=92t=20 tell for sure which PathRequest it

is related = to. 

 

Anyway an Error = related to a=20 request is always sent in the PCE-PCC direction=20

 <= /P>

 

So it seems = to me it=20 would be more consistent to add a bit in the RP object (in the flag = field) to=20 indicate the

=93direction=94 of the=20 PathRequest.

For = instance if the=20 bit is set the Message that carry the RP object is related to the = request sent=20 by the destination of the message. 

Hence, an = RP object=20 would actually uniquely indentifies a PathRequest. 

 

There maybe=20 an ambiguity only in a few error/notif situations, and = I don't=20 think adding a generic bit would be really=20 useful.

 By the way this = would be a=20 significant change wilth potentially new error situations to = handle (what=20 do you do if the direction PCC to PCE is set in a reply=20 message?) .

 

Is that OK with you = if we keep as=20 is?

 

Best=20 Regards,

 

JL

 

Regards

Fabien=20 Verhaeghe

 

------_=_NextPart_001_01C7F171.86C335CB-- --===============0993730450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0993730450==-- From pce-bounces@lists.ietf.org Fri Sep 07 14:33:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITicV-00086H-LV; Fri, 07 Sep 2007 14:31:55 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ITicU-00086B-MS for pce-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 14:31:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITicU-000863-B0 for pce@ietf.org; Fri, 07 Sep 2007 14:31:54 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITicT-0004fB-Fo for pce@ietf.org; Fri, 07 Sep 2007 14:31:54 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1ITicS-0001ud-G2 for pce@ietf.org; Fri, 07 Sep 2007 18:31:52 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Sep 2007 19:31:51 +0100 Message-ID: <053201c7f17d$559dcf00$0302a8c0@your029b8cecfe> From: "Adrian Farrel" To: References: <014401c7e6b3$163d5080$3407a8c0@your029b8cecfe> <042201c7f151$85395300$0302a8c0@your029b8cecfe> Subject: Re: [Pce] Question about PCEP Keepalive Date: Fri, 7 Sep 2007 19:16:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 07 Sep 2007 18:31:51.0820 (UTC) FILETIME=[5BE3A4C0:01C7F17D] X-Originating-Rutherford-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Thanks Jean-Louis, You seem to be saying that the responder to an Open can use a PCErr to define how often it wants to receive a Keepalive. To me this is back-to-front and is likely to require additional message exchanges. That is, if the PCE is configured to send infrequent Keepalives (this is likely, because the default should be to keep the Keepalive traffic low), the PCC must reject the Open message causing an extra message exchange. If the Open message says how often the sender wants to receive Keepalives, then there is no negotiation to be performed. I think this is more natural. Note that I think it is a Good Thing (TM) that Hellos can be uni-directional and/or have very different timeouts in opposite directions. Adrian ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" To: ; Sent: Friday, September 07, 2007 5:51 PM Subject: RE: [Pce] Question about PCEP Keepalive Hi Adrian, Please see inline, > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk] > Envoyé : vendredi 7 septembre 2007 15:18 > À : pce@ietf.org > Objet : Re: [Pce] Question about PCEP Keepalive > > Hello? > > Anyone got an answer? > > Thanks, > Adrian > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Saturday, August 25, 2007 1:56 AM > Subject: [Pce] Question about PCEP Keepalive > > > > Hi, > > > > I'm looking at r08 sections 6.3 and 7.2. > > > > Section 6.3 has > > > > Note that sending Keepalive messages to maintain the > session alive is > > optional and PCEP peers may decide to not send Keepalive messages > > once the PCEP session is established. > > > > Section 7.2 has > > > > Keepalive (8 bits): maximum period of time (in seconds) > between the > > sending of PCEP messages. The minimum value for the > Keepalive is 1 > > second. When set to 0, once the session is established, > no further > > Keepalive messages need to be sent to the remote peer. > > > > And also > > > > A sends an Open message to B with Keepalive=10 seconds and > > Deadtimer=30 seconds. This means that A sends Keepalive > messages (or > > ay other PCEP message) to B every 30 seconds and B can declare the > > PCEP session with A down if no PCEP has been received from A. > > > > I find this peculiar. Sending a keepalive message does not > verify for the > > sender that the session is open. It verifies for the > receiver. Yes So, surely > > the parameter in the Open object says how frequently the > sender of the > > Open > > message wants to receive a Keepalive message. as currently specified the sender says how often it is ready to send Keepalive messages That is, how often the > > receiver of the Open message must send a Keepalive message. > > > > For example, if a PCC is worried that the session may fail, > it will want > > to > > operate the keepalive process. But as currently specified, > the PCC can > > only > > tell the PCE how often the PCC will send Keepalive > messages, and after > > what > > period the PCE may declare the session dead. This is no > help to the PCC! But there is a negociation. As described in the FSM section, the PCC may reject an open message with an unacceptable keepalive from the PCE, and indicate an acceptable value in the PCErr message. So in this way the PCC can control the frequency at which the PCE will send keepalive. > > If > > the PCE decides that it will not send Keepalive messages > then the PCC > > cannot > > determine the health of the session and cannot switch to a new PCE. The PCC can reject the Open and start negociating... > > > > In other words, the keepalive process is back-to-front. > > > > Further, I don't see why you need the keepalive timer value > and the dead > > timer value. One value can be derived from the other, > probably through a > > recommended ratio of 3.5. This is a good point > > > > Lastly, when describing that the use of keepalive is > optional, there are a > > couple of points: > > > > 1. Optional should be an RFC 2119 word Right, > > 2. You need to make it clear that it is not the "PCEP peers" > > that decide to not send keepalives, but "each PCEP peer" > > that decides "whether it wants to receive keepalives" Each peer takes part into the decision, this is a negociation. > > 3. You should indicate the circumstances surrounding > > the choice for this option. I think that, you might suggest > > that if PCE discovery is in use, the failure of a PCE can > > be speedily detected by the failure of the IGP, and can > > be flooded by timing out the LSA containing the discovery > > information. In this case, keepalive would not be needed. OK, we will add this point. Regards, JL > > > > Yes? > > > > Adrian > > > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Sep 07 15:32:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITjWy-0007nf-Bp; Fri, 07 Sep 2007 15:30:16 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ITjWq-0007g1-Ms for pce-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 15:30:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITjWp-0007d9-VF for pce@ietf.org; Fri, 07 Sep 2007 15:30:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITjWp-000696-5l for pce@ietf.org; Fri, 07 Sep 2007 15:30:07 -0400 X-IronPort-AV: E=Sophos;i="4.20,221,1186372800"; d="scan'208";a="70432980" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Sep 2007 15:30:06 -0400 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 l87JU6hg030897; Fri, 7 Sep 2007 15:30:06 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l87JU6Z4016143; Fri, 7 Sep 2007 19:30:06 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 15:30:06 -0400 Received: from [10.86.104.180] ([10.86.104.180]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 15:30:06 -0400 In-Reply-To: <053201c7f17d$559dcf00$0302a8c0@your029b8cecfe> References: <014401c7e6b3$163d5080$3407a8c0@your029b8cecfe> <042201c7f151$85395300$0302a8c0@your029b8cecfe> <053201c7f17d$559dcf00$0302a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] Question about PCEP Keepalive Date: Fri, 7 Sep 2007 15:29:26 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Sep 2007 19:30:06.0227 (UTC) FILETIME=[7EB7D630:01C7F185] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6622; t=1189193406; x=1190057406; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Question=20about=20PCEP=20Keepalive |Sender:=20 |To:=20Adrian=20Farrel=20; bh=mib2JMlCSX1E1dBOwOtSE7dZTbk+e0vO/somFER94f8=; b=igL7ozWNOkz6FaH3Si8bVgC9rTu/NdoyPfcfIq8CrwXadxgFVW/BecI1GqRNsWxyDqgDMkGB TMuPzkA46zpLGWJVF2MQ8w9q8bJJ3nNGx41Y2ZOKcOGu+JJ6vKcqjL7p; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Adrian, On Sep 7, 2007, at 2:16 PM, Adrian Farrel wrote: > Thanks Jean-Louis, > > You seem to be saying that the responder to an Open can use a PCErr =20= > to define how often it wants to receive a Keepalive. > > To me this is back-to-front and is likely to require additional =20 > message exchanges. That is, if the PCE is configured to send =20 > infrequent Keepalives (this is likely, because the default should =20 > be to keep the Keepalive traffic low), the PCC must reject the Open =20= > message causing an extra message exchange. > > If the Open message says how often the sender wants to receive =20 > Keepalives, then there is no negotiation to be performed. > > I think this is more natural. > > Note that I think it is a Good Thing (TM) that Hellos can be uni-=20 > directional and/or have very different timeouts in opposite =20 > directions. > Just to shed more light here ... You could indeed reverse the logic but this would be equivalent to what we have and in many cases it is more logical for the PCC to indicate the frequency at which it will send KA rather then requesting the PCE to =20 send KA at a certain frequency (there are circumstances in which it is not desirable to proceed this way: the PCE may have a high number of PCEP sessions opened, may just not want to dedicate too much resources =20 sending hellos because the PCC wants to, ...). Note that it is quite usual to =20= proceed with that logic (OSPF, ...). And as we said, there is a possibility =20 for the PCE to request different parameters during PCEP negotiation. Make sense ? Cheers, JP. > Adrian > > ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" =20= > > To: ; > Sent: Friday, September 07, 2007 5:51 PM > Subject: RE: [Pce] Question about PCEP Keepalive > > > Hi Adrian, > > Please see inline, > >> -----Message d'origine----- >> De : Adrian Farrel [mailto:adrian@olddog.co.uk] >> Envoy=E9 : vendredi 7 septembre 2007 15:18 >> =C0 : pce@ietf.org >> Objet : Re: [Pce] Question about PCEP Keepalive >> >> Hello? >> >> Anyone got an answer? >> >> Thanks, >> Adrian >> ----- Original Message ----- >> From: "Adrian Farrel" >> To: >> Sent: Saturday, August 25, 2007 1:56 AM >> Subject: [Pce] Question about PCEP Keepalive >> >> >> > Hi, >> > >> > I'm looking at r08 sections 6.3 and 7.2. >> > >> > Section 6.3 has >> > >> > Note that sending Keepalive messages to maintain the >> session alive is >> > optional and PCEP peers may decide to not send Keepalive messages >> > once the PCEP session is established. >> > >> > Section 7.2 has >> > >> > Keepalive (8 bits): maximum period of time (in seconds) >> between the >> > sending of PCEP messages. The minimum value for the >> Keepalive is 1 >> > second. When set to 0, once the session is established, >> no further >> > Keepalive messages need to be sent to the remote peer. >> > >> > And also >> > >> > A sends an Open message to B with Keepalive=3D10 seconds and >> > Deadtimer=3D30 seconds. This means that A sends Keepalive >> messages (or >> > ay other PCEP message) to B every 30 seconds and B can declare =20= >> the >> > PCEP session with A down if no PCEP has been received from A. >> > >> > I find this peculiar. Sending a keepalive message does not >> verify for the >> > sender that the session is open. It verifies for the >> receiver. > > Yes > > So, surely >> > the parameter in the Open object says how frequently the >> sender of the >> > Open >> > message wants to receive a Keepalive message. > > as currently specified the sender says how often it is ready to =20 > send Keepalive messages > > That is, how often the >> > receiver of the Open message must send a Keepalive message. >> > >> > For example, if a PCC is worried that the session may fail, >> it will want >> > to >> > operate the keepalive process. But as currently specified, >> the PCC can >> > only >> > tell the PCE how often the PCC will send Keepalive >> messages, and after >> > what >> > period the PCE may declare the session dead. This is no >> help to the PCC! > > But there is a negociation. As described in the FSM section, the =20 > PCC may reject an open message with an unacceptable keepalive from =20 > the PCE, and indicate an acceptable value in the PCErr message. So =20 > in this way the PCC can control the frequency at which the PCE will =20= > send keepalive. > >> > If >> > the PCE decides that it will not send Keepalive messages >> then the PCC >> > cannot >> > determine the health of the session and cannot switch to a new PCE. > > The PCC can reject the Open and start negociating... > >> > >> > In other words, the keepalive process is back-to-front. >> > >> > Further, I don't see why you need the keepalive timer value >> and the dead >> > timer value. One value can be derived from the other, >> probably through a >> > recommended ratio of 3.5. > > This is a good point > >> > >> > Lastly, when describing that the use of keepalive is >> optional, there are a >> > couple of points: >> > >> > 1. Optional should be an RFC 2119 word > > Right, > >> > 2. You need to make it clear that it is not the "PCEP peers" >> > that decide to not send keepalives, but "each PCEP peer" >> > that decides "whether it wants to receive keepalives" > > Each peer takes part into the decision, this is a negociation. > > >> > 3. You should indicate the circumstances surrounding >> > the choice for this option. I think that, you might suggest >> > that if PCE discovery is in use, the failure of a PCE can >> > be speedily detected by the failure of the IGP, and can >> > be flooded by timing out the LSA containing the discovery >> > information. In this case, keepalive would not be needed. > > OK, we will add this point. > > Regards, > > JL > > >> > >> > Yes? >> > >> > Adrian >> > >> > >> > >> > >> > _______________________________________________ >> > Pce mailing list >> > Pce@lists.ietf.org >> > https://www1.ietf.org/mailman/listinfo/pce >> > >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Sep 08 17:20:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU7hB-0007qG-PD; Sat, 08 Sep 2007 17:18:25 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IU7hA-0007qA-Jw for pce-confirm+ok@megatron.ietf.org; Sat, 08 Sep 2007 17:18:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU7h9-0007q2-02 for pce@ietf.org; Sat, 08 Sep 2007 17:18:23 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IU7h7-0003JK-Fo for pce@ietf.org; Sat, 08 Sep 2007 17:18:22 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1IU7h6-0008Ep-Hu for pce@ietf.org; Sat, 08 Sep 2007 21:18:20 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Sep 2007 22:18:14 +0100 Message-ID: <07ac01c7f25d$c1b20c20$0302a8c0@your029b8cecfe> From: "Adrian Farrel" To: References: <014401c7e6b3$163d5080$3407a8c0@your029b8cecfe> <042201c7f151$85395300$0302a8c0@your029b8cecfe> <053201c7f17d$559dcf00$0302a8c0@your029b8cecfe> Subject: Re: [Pce] Question about PCEP Keepalive Date: Sat, 8 Sep 2007 22:18:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 08 Sep 2007 21:18:20.0348 (UTC) FILETIME=[C7EDCFC0:01C7F25D] X-Originating-Pythagoras-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org >> You seem to be saying that the responder to an Open can use a PCErr to >> define how often it wants to receive a Keepalive. >> >> To me this is back-to-front and is likely to require additional message >> exchanges. That is, if the PCE is configured to send infrequent >> Keepalives (this is likely, because the default should be to keep the >> Keepalive traffic low), the PCC must reject the Open message causing an >> extra message exchange. >> >> If the Open message says how often the sender wants to receive >> Keepalives, then there is no negotiation to be performed. >> >> I think this is more natural. >> >> Note that I think it is a Good Thing (TM) that Hellos can be uni- >> directional and/or have very different timeouts in opposite directions. > > Just to shed more light here ... > You could indeed reverse the logic but this would be equivalent to what > we have and in many cases it is more logical for the PCC to indicate the > frequency at which it will send KA rather then requesting the PCE to send > KA at a certain frequency (there are circumstances in which it is > not desirable to proceed this way: the PCE may have a high number of PCEP > sessions opened, may just not want to dedicate too much resources sending > hellos because the PCC wants to, ...). Note that it is quite usual to > proceed with that logic (OSPF, ...). And as we said, there is a > possibility for the PCE to request different parameters > during PCEP negotiation. > > Make sense ? Not sure :-( I think that the keepalive function is at the request of the speaker that wants to determine whether the session is alive. This is valuable to the PCC because it helps it select a PCE to which to send a PCReq. It is much less valuable for a PCE, but might be used to allow the PCE to discard dead sessions. So, the PCE wants to be able to say to the PCC: "Don't bother sending me KA." Or maybe: "Only send me KA every 10 minutes". After all, the PCE does not want to be swamped with KA messages. Thus, it is important to give the PCE control of how often the PCC sends KA. JL is right that this *can* be achieved using the Open from the PCC to propose the KA transmission frequency used by the PCC, followed by a PCErr from the PCE to "negotiate" the KA frequency, followed by a new Open from the PCC with the revised KA frequency. This is functional, but excessive and not very clever! The PCC does not care what KA frequency it uses so long as it is: - acceptable for the PCE (that needs to receive the messages) - not going to kill the PCC's CPU So it is *far* more natural to allow the PCE to request the PCC's KA transmission timer on the PCE's Open message, reserving the PCErr for the unusual case. In the other direction, the same thing applies. It seems that you want the PCE to simply announce its KA retransmission time, but this isn't good enough. A PCC that needs to know about session failures in a hurry will want a more rapid KA time and should be allowed to request it up front, rather than negotiate it using an error message. The comparison with OSPF is a little ambiguous. The OSPF Hello message contains both the Hello Interval (how often the router will retransmit Hellos) and the Router Dead Interval (how soon the router will declare the adjacency dead if it does not receive a Hello - or another message). A router is expected to modify is own Hello Interval according to the received Router Dead Interval - that is, it is expected to behave as I suggest, not as you suggest. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Sep 10 15:17:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUojP-0003zK-Ab; Mon, 10 Sep 2007 15:15:35 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IUojN-0003yp-EM for pce-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 15:15:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUojN-0003yV-2o; Mon, 10 Sep 2007 15:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUojM-0002Hd-Im; Mon, 10 Sep 2007 15:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 373A0175F6; Mon, 10 Sep 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IUoir-0001Aj-OS; Mon, 10 Sep 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 10 Sep 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-of-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --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 : Encoding of Objective Functions in Path Computation Element (PCE) communication and discovery protocols Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-of-00.txt Pages : 19 Date : 2007-9-10 The computation of one or a series of Traffic Engineering Label Switched Paths (TE LSP) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks, is subject to a set of one or more specific optimization criteria(s), referred to as an objective function (e.g. minimum cost path, widest path, etc.). A Path Computation Element (PCE) may support one or multiple objective functions, and it is desired for a Path Computation Client (PCC) to automatically discover the set of objective functions supported by a PCE. Furthermore, it may be useful for a PCC to specify in a path computation request the required objective function used by the PCE to compute a TE LSP or a set of TE LSPs. Thus the aim of this document is to define extensions to the PCE Discovery (PCED) TLV carried within the IS-IS Router Capability TLV and the OSPF Router Information LSA so as to allow a PCC to discover the set of objective functions supported by a PCE. Extensions to the PCE communication Protocol (PCEP) are also specified allowing a PCC to indicate in a path computation request the required objective function and a PCE to indicate in a path computation reply the objective function actually applied. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-of-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-of-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-of-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-10140536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-of-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-of-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-10140536.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue Sep 11 09:37:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV5uL-0001x1-Tk; Tue, 11 Sep 2007 09:36:01 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IUeJv-0006Vq-S8 for pce-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 04:08:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUeJr-0006VE-Ky for pce@ietf.org; Mon, 10 Sep 2007 04:08:31 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee01s.mail.mercury.atosorigin.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUeJq-00050G-F1 for pce@ietf.org; Mon, 10 Sep 2007 04:08:31 -0400 Received: from wpwuee01s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 1CE66F4031; Mon, 10 Sep 2007 10:08:29 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 86D18F4029; Mon, 10 Sep 2007 10:08:28 +0200 (CEST) From: "Fabien VERHAEGHE" To: "'LE ROUX Jean-Louis RD-CORE-LAN'" , Subject: RE: [Pce] PCEP Request ID Date: Mon, 10 Sep 2007 10:07:33 +0200 Message-ID: <003301c7f381$a4f4b5e0$18600337@AOFR11476> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: thread-index: AcfasLubc8kSH1yqRFit9qXiDRobwgAlbSyABYpQS/AAg63f4A== X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1706e8b1dd7082b120fc79a4178b9c89 X-Mailman-Approved-At: Tue, 11 Sep 2007 09:36:00 -0400 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabien.verhaeghe@marben-products.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1261330095==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1261330095== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C7F392.687D85E0" This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C7F392.687D85E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jean-Louis, =20 Thanks for the reply. See inline for mine=85 =20 Best regards Fabien =20 _____ =20 De : LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@orange-ftgroup.com]=20 Envoy=E9 : vendredi 7 septembre 2007 19:07 =C0 : fabien.verhaeghe@marben-products.com; pce@ietf.org Objet : RE: [Pce] PCEP Request ID =20 Hi Fabien =20 Thanks for your comment. =20 Please see inline, =20 _____ =20 De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]=20 Envoy=E9 : vendredi 10 ao=FBt 2007 14:26 =C0 : pce@ietf.org Objet : [Pce] PCEP Request ID Hello all, =20 I have a little comment/suggestion on PCEP regarding the request Id. In section 7.3.1 states that =93The Request-ID-number value combined with the source IP address of = the PCC and the PCE address uniquely=20 identify the path computation request context=94. =20 I agree with that, however there may be 2 requests with same request Id exchanged on the same session in=20 the case of session between 2 PCEs.=20 One Path Request being sent by PCE#1 to PCE#2 and the other one by PCE#2 = to PCE#1. =20 I don=92t think there is any problem with that but I am a little = concerned about potential misinterpretation especially in PCErr and PCNotif message. If a PCNtf/PCErr message contains an RP object, nothing indicates if it = is related to the Request from PCE#1 to PCE#2 or the one from PCE#2 to PCE#1, except the notification/error type and value.=20 =20 =20 =20 I guess this is why for instance for the =93Pending Request cancelled=94 notification there are 2 values. One for PCC and one for the PCE.=20 =20 Yes, this is exactly the reason why there are two values.=20 =20 So we would not need to define 2 values if the RP object fully identify = the PathRequest.=20 >From a protocol specification point of view it seems more = straightforward to me. =20 One of the problem, from an implementation perspective, is that we must first ready the Notification type/value in order to retrieve the correct PathRequest.=20 =20 Anyway, you have to parse the entire message.=20 There are other implementations that first parse the whole message and = then start processing the objects. This is IMO and implementation issue. =20 I agree that it is partly an implementation issue. However, the implementation can be optimised if the RP object fully identifies the PathRequest. For instance, you would not need to decode the Error object if the PathRequest is unknown.=20 =20 =20 Another problem is if an implementation does not recognize a given Error type/value, then it can=92t tell for sure which PathRequest it is related to.=20 =20 Anyway an Error related to a request is always sent in the PCE-PCC = direction =20 =20 I agree this is true today but will it still be true with future PCEP extensions. If it is this a strict rules I think it should be mentioned in the = draft. However can=92t we imagine that a PCC sends an Error message to a PCE = because it does not like the Reply sent by the PCE? e.g. the Path does not respect the requested constraints. =20 Besides we still that have a problem in case of unrecognised = Notification type/value. =20 =20 So it seems to me it would be more consistent to add a bit in the RP = object (in the flag field) to indicate the =93direction=94 of the PathRequest. For instance if the bit is set the Message that carry the RP object is related to the request sent by the destination of the message.=20 Hence, an RP object would actually uniquely indentifies a PathRequest.=20 =20 There maybe an ambiguity only in a few error/notif situations, and I = don't think adding a generic bit would be really useful. By the way this would be a significant change wilth potentially new = error situations to handle (what do you do if the direction PCC to PCE is set = in a reply message?) . =20 I don=92t really see it as a significant change. For the Error case I think it would be ok to say that the bit must be = set in PCReq and Clear in PCRep message and must be ignored upon reception. Besides if we keep the RP object as is what do you do if you receive a = PCNtf message with formatted as follows: =20 with Notif 1 and Notif2 being =93pending request cancelled=94 but one with Notification value 1 and the other with = notification value 2. =20 It seems this is anyway an error case that must be specified with = current PCEP specification. =20 Is that OK with you if we keep as is? =20 So basically I agree that it is partly an implementation problem and = that it is possible to do with current specification But it seems to me, from a protocol design point of view it would be = more consistent if the RP object fully identify the PathRequest. =20 Best Regards, =20 JL =20 Regards Fabien Verhaeghe =20 ------=_NextPart_000_0034_01C7F392.687D85E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Jean-Louis,

 

Thanks for the = reply.

See inline for = mine…

 =

Best = regards

Fabien=

 =

De : LE = ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@orange-ftgroup.com]
Envoy=E9 : vendredi = 7 septembre 2007 19:07
=C0 : fabien.verhaeghe@marben-products.com; pce@ietf.org
Objet : RE: [Pce] = PCEP Request ID

 

Hi = Fabien

 

Thanks for your = comment.

 

Please see = inline,

 

De :<= /span> Fabien = VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]
Envoy=E9 : vendredi = 10 ao=FBt 2007 14:26
=C0 : = pce@ietf.org
Objet : [Pce] PCEP = Request ID

Hello = all,

 =

I have a little = comment/suggestion on PCEP regarding the request Id.

In section 7.3.1 = states that

“The Request-ID-number value combined with the source IP address of the PCC = and the PCE address uniquely

identify the = path computation request context”.

 =

I agree with = that, however there may be 2 requests with same request Id exchanged on the same = session in

the case of = session between 2 PCEs.

One Path Request = being sent by PCE#1 to PCE#2 and the other one by PCE#2 to = PCE#1.

 =

I don’t = think there is any problem with that but I am a little concerned about potential misinterpretation especially

in PCErr and = PCNotif message.

If a PCNtf/PCErr = message contains an RP object, nothing indicates if it is related to the Request = from PCE#1 to PCE#2

or the one from = PCE#2 to PCE#1, except the notification/error type and value. 

 

 

 =

I guess this is = why for instance for the “Pending Request cancelled” notification = there are 2 values. One for PCC and

one for the = PCE. 

 

Yes, this is exactly the reason why there are two = values. 

 =

So we would not = need to define 2 values if the RP object fully identify the PathRequest. =

From a protocol specification point of view it seems more straightforward to = me.

 =

One of the = problem, from an implementation perspective, is that we must first ready the = Notification type/value in order to retrieve

the correct = PathRequest. 

 

Anyway, you have = to parse the entire message.

There are other implementations that first parse the whole message and then = start processing the objects.

This is IMO and implementation issue.

 =

I agree that it = is partly an implementation issue. However, the implementation can be optimised if = the RP object fully identifies the PathRequest.

For instance, you = would not need to decode the Error object if the PathRequest is unknown. =

 =

 =

Another problem = is if an implementation does not recognize a given Error type/value, then it = can’t tell for sure which PathRequest it

is related = to. 

 

Anyway = an Error related to a request is always sent in the PCE-PCC direction =

 =

 =

I agree this is = true today but will it still be true with future PCEP = extensions.

If it is this a = strict rules I think it should be mentioned in the = draft.

However = can’t we imagine that a PCC sends an Error message to a PCE because it does not = like the Reply sent by the PCE?

e.g. the Path = does not respect the requested constraints.

 <= /span>

Besides we still = that have a problem in case of unrecognised Notification = type/value.

 =

 =

So it seems to = me it would be more consistent to add a bit in the RP object (in the flag = field) to indicate the

“direction&= #8221; of the PathRequest.

For instance if = the bit is set the Message that carry the RP object is related to the request = sent by the destination of the message. 

Hence, an RP = object would actually uniquely indentifies a PathRequest. 

 

There maybe an ambiguity only in a few error/notif situations, and I = don't think adding a generic bit would be really useful.

By the way this = would be a significant change wilth potentially new error situations to = handle (what do you do if the direction PCC to PCE is set in a reply message?) .

 

I don’t = really see it as a significant change.

For the Error = case I think it would be ok to say that the bit must be set in PCReq and Clear in = PCRep =A0message and must be ignored upon reception.

Besides if we = keep the RP object as is what do you do if you receive a PCNtf message with = formatted as follows:

 <= /span>

<RP><Noti= f1><Notif2> with Notif 1 and Notif2 being “pending request cancelled” = but one with Notification value 1 and the other with notification value = 2.

 <= /span>

It seems this is = anyway an error case that must be specified with current PCEP = specification.

 =

Is that OK with = you if we keep as is?

 =

So basically I = agree that it is partly an implementation problem and that it is possible to do = with current specification

But it seems to = me, from a protocol design point of view it would be more consistent if the RP = object fully identify the PathRequest.

 

Best = Regards,

 

JL<= font size=3D2 color=3Dnavy face=3DArial>

 =

Regards

Fabien = Verhaeghe

 

------=_NextPart_000_0034_01C7F392.687D85E0-- --===============1261330095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1261330095==-- From pce-bounces@lists.ietf.org Tue Sep 11 11:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7SJ-0000HL-88; Tue, 11 Sep 2007 11:15:11 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IV7SB-0000Ap-8x for pce-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 11:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7SA-00008f-MK; Tue, 11 Sep 2007 11:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV7SA-0005V5-7W; Tue, 11 Sep 2007 11:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 257E726E74; Tue, 11 Sep 2007 15:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IV7SA-00073p-1E; Tue, 11 Sep 2007 11:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Sep 2007 11:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-isis-07.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : IS-IS protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-isis-07.txt Pages : 17 Date : 2007-9-11 There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCE), along with some information that can be used for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to discover PCEs consists of using IGP flooding. For that purpose this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-isis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-11104406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-isis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-11104406.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue Sep 11 11:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7Si-0000mw-E1; Tue, 11 Sep 2007 11:15:36 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IV7Sf-0000jp-P8 for pce-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 11:15:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7Sf-0000jh-Fe; Tue, 11 Sep 2007 11:15:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV7Se-0005WM-BJ; Tue, 11 Sep 2007 11:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 177EB32893; Tue, 11 Sep 2007 15:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IV7S9-00073j-W9; Tue, 11 Sep 2007 11:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Sep 2007 11:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-07.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : OSPF protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-ospf-07.txt Pages : 20 Date : 2007-9-11 There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCE), along with some information that can be used for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to discover PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-ospf-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-11104247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-ospf-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-11104247.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed Sep 12 12:16:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUrr-0002jN-EQ; Wed, 12 Sep 2007 12:15:07 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IVUrn-0002ia-IO for pce-confirm+ok@megatron.ietf.org; Wed, 12 Sep 2007 12:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUrn-0002iF-4y; Wed, 12 Sep 2007 12:15:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVUrm-0002uo-I3; Wed, 12 Sep 2007 12:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5629726E4D; Wed, 12 Sep 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IVUrm-0007xC-79; Wed, 12 Sep 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 12 Sep 2007 12:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-path-key-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism Author(s) : R. Bradford, et al. Filename : draft-ietf-pce-path-key-01.txt Pages : 0 Date : 2007-9-12 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g. when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary LSR during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-path-key-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-path-key-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-12113917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-path-key-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-path-key-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-12113917.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Thu Sep 13 17:31:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVwHd-00032X-RN; Thu, 13 Sep 2007 17:31:33 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IVwHd-00032G-5n for pce-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 17:31:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVwHc-000328-Rm; Thu, 13 Sep 2007 17:31:32 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVwHc-0004w7-Gs; Thu, 13 Sep 2007 17:31:32 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1IVwHb-000770-G2; Thu, 13 Sep 2007 21:31:31 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Sep 2007 22:31:30 +0100 Message-ID: <05da01c7f64d$6e7dc780$3901850a@your029b8cecfe> From: "Adrian Farrel" To: Date: Thu, 13 Sep 2007 22:30:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 13 Sep 2007 21:31:30.0982 (UTC) FILETIME=[733FBC60:01C7F64D] X-Originating-Rutherford-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: pce@ietf.org Subject: [Pce] Please comment on draft-ietf-pce-disco-proto-isis-07.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-07.txt has recently been posted. The last couple of revisions addressed comments raised by the IESG and by the IGP working group chairs, etc. This is a call to you for a further review of the I-D. We'll run with a two week deadline to 28th September. Many thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Sep 13 17:31:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVwHf-00033c-Cn; Thu, 13 Sep 2007 17:31:35 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IVwHe-00032b-07 for pce-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 17:31:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVwHd-00032P-Kt; Thu, 13 Sep 2007 17:31:33 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVwHd-0004wB-A3; Thu, 13 Sep 2007 17:31:33 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1IVwHc-0004ZB-C8; Thu, 13 Sep 2007 21:31:32 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Sep 2007 22:31:31 +0100 Message-ID: <05db01c7f64d$6ec075d0$3901850a@your029b8cecfe> From: "Adrian Farrel" To: Date: Thu, 13 Sep 2007 22:30:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 13 Sep 2007 21:31:31.0935 (UTC) FILETIME=[73D126F0:01C7F64D] X-Originating-Pythagoras-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: pce@ietf.org Subject: [Pce] Please comment on draft-ietf-pce-disco-proto-ospf-07.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-07.txt has recently been posted. The last couple of revisions addressed comments raised by the IESG and by the IGP working group chairs, etc. This is a call to you for a further review of the I-D. We'll run with a two week deadline to 28th September. Many thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Sep 13 18:38:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVxKr-00041j-5a; Thu, 13 Sep 2007 18:38:57 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IVxKp-000408-Fu for pce-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 18:38:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVxKp-0003zy-5w for pce@ietf.org; Thu, 13 Sep 2007 18:38:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVxKn-00010h-FC for pce@ietf.org; Thu, 13 Sep 2007 18:38:55 -0400 X-IronPort-AV: E=Sophos;i="4.20,251,1186372800"; d="scan'208,217";a="131885023" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Sep 2007 18:38:52 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8DMcrgr023755; Thu, 13 Sep 2007 18:38:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DMciDw006110; Thu, 13 Sep 2007 22:38:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 18:38:44 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 18:38:42 -0400 In-Reply-To: <003301c7f381$a4f4b5e0$18600337@AOFR11476> References: <003301c7f381$a4f4b5e0$18600337@AOFR11476> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: JP Vasseur Subject: Re: [Pce] PCEP Request ID Date: Thu, 13 Sep 2007 18:38:00 -0400 To: fabien.verhaeghe@marben-products.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Sep 2007 22:38:42.0689 (UTC) FILETIME=[D6556710:01C7F656] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=35505; t=1189723133; x=1190587133; 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]=20PCEP=20Request=20ID |Sender:=20 |To:=20fabien.verhaeghe@marben-products.com; bh=1fmj1j4CXHxm+0VJy0AXXIf7358MPDLzu42wLMas5Mo=; b=Z04Iwh/lxB8um9nixVeLNjSzdhrxBaWrJieZHTXx6f/RPjfm/JRB8pNlBVZa8yI83fvdrpOV W4Joc/AK4UHb6kI4ZfcKW8hksbtB0fawQVw0flP4FbMsIKVzVX7Ub1qR; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: fc33afc280b74ce7916a8c9e6ab57db8 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0885779590==" Errors-To: pce-bounces@lists.ietf.org --===============0885779590== Content-Type: multipart/alternative; boundary=Apple-Mail-71-962482682 --Apple-Mail-71-962482682 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Fabien, Jumping at the end .... You wrote: > So basically I agree that it is partly an implementation problem =20 > and that it is possible to do with current specification > > But it seems to me, from a protocol design point of view it would =20 > be more consistent if the RP object fully identify the PathRequest. > As you know the only potential issue is in the case of two pending requests with the same ID between two PCEs and the related potential Notification messages. In that case, we do have the Notification =20 Value to make sure that there is no ambiguity, as we did for the request =20 cancellation Notification message. And if one of the PCEs does not "understand" the Notification itself, then trying to determine the request it relates =20 to is not relevant. Agree ? Thanks. JP. On Sep 10, 2007, at 4:07 AM, Fabien VERHAEGHE wrote: > Hi Jean-Louis, > > > > Thanks for the reply. > > See inline for mine=85 > > > > Best regards > > Fabien > > > > De : LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@orange-=20= > ftgroup.com] > Envoy=E9 : vendredi 7 septembre 2007 19:07 > =C0 : fabien.verhaeghe@marben-products.com; pce@ietf.org > Objet : RE: [Pce] PCEP Request ID > > > > Hi Fabien > > > > Thanks for your comment. > > > > Please see inline, > > > > De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com] > Envoy=E9 : vendredi 10 ao=FBt 2007 14:26 > =C0 : pce@ietf.org > Objet : [Pce] PCEP Request ID > > Hello all, > > > > I have a little comment/suggestion on PCEP regarding the request Id. > > In section 7.3.1 states that > > =93The Request-ID-number value combined with the source IP address of =20= > the PCC and the PCE address uniquely > > identify the path computation request context=94. > > > > I agree with that, however there may be 2 requests with same =20 > request Id exchanged on the same session in > > the case of session between 2 PCEs. > > One Path Request being sent by PCE#1 to PCE#2 and the other one by =20 > PCE#2 to PCE#1. > > > > I don=92t think there is any problem with that but I am a little =20 > concerned about potential misinterpretation especially > > in PCErr and PCNotif message. > > If a PCNtf/PCErr message contains an RP object, nothing indicates =20 > if it is related to the Request from PCE#1 to PCE#2 > > or the one from PCE#2 to PCE#1, except the notification/error type =20 > and value. > > > > > > > > I guess this is why for instance for the =93Pending Request =20 > cancelled=94 notification there are 2 values. One for PCC and > > one for the PCE. > > > > Yes, this is exactly the reason why there are two values. > > > > So we would not need to define 2 values if the RP object fully =20 > identify the PathRequest. > > =46rom a protocol specification point of view it seems more =20 > straightforward to me. > > > > One of the problem, from an implementation perspective, is that we =20 > must first ready the Notification type/value in order to retrieve > > the correct PathRequest. > > > > Anyway, you have to parse the entire message. > > There are other implementations that first parse the whole message =20 > and then start processing the objects. > > This is IMO and implementation issue. > > > > I agree that it is partly an implementation issue. However, the =20 > implementation can be optimised if the RP object fully identifies =20 > the PathRequest. > > For instance, you would not need to decode the Error object if the =20 > PathRequest is unknown. > > > > > > Another problem is if an implementation does not recognize a given =20 > Error type/value, then it can=92t tell for sure which PathRequest it > > is related to. > > > > Anyway an Error related to a request is always sent in the PCE-PCC =20 > direction > > > > > > I agree this is true today but will it still be true with future =20 > PCEP extensions. > > If it is this a strict rules I think it should be mentioned in the =20 > draft. > > However can=92t we imagine that a PCC sends an Error message to a PCE =20= > because it does not like the Reply sent by the PCE? > > e.g. the Path does not respect the requested constraints. > > > > Besides we still that have a problem in case of unrecognised =20 > Notification type/value. > > > > > > So it seems to me it would be more consistent to add a bit in the =20 > RP object (in the flag field) to indicate the > > =93direction=94 of the PathRequest. > > For instance if the bit is set the Message that carry the RP object =20= > is related to the request sent by the destination of the message. > > Hence, an RP object would actually uniquely indentifies a PathRequest. > > > > There maybe an ambiguity only in a few error/notif situations, and =20 > I don't think adding a generic bit would be really useful. > > By the way this would be a significant change wilth potentially new =20= > error situations to handle (what do you do if the direction PCC to =20 > PCE is set in a reply message?) . > > > > I don=92t really see it as a significant change. > > For the Error case I think it would be ok to say that the bit must =20 > be set in PCReq and Clear in PCRep message and must be ignored =20 > upon reception. > > Besides if we keep the RP object as is what do you do if you =20 > receive a PCNtf message with formatted as follows: > > > > with Notif 1 and Notif2 being =93pending request =20= > cancelled=94 but one with Notification value 1 and the other with =20 > notification value 2. > > > > It seems this is anyway an error case that must be specified with =20 > current PCEP specification. > > > > Is that OK with you if we keep as is? > > > > So basically I agree that it is partly an implementation problem =20 > and that it is possible to do with current specification > > But it seems to me, from a protocol design point of view it would =20 > be more consistent if the RP object fully identify the PathRequest. > > > > Best Regards, > > > > JL > > > > Regards > > Fabien Verhaeghe > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-71-962482682 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Fabien,

Jumping = at the end .... You wrote:

So = basically I agree that it is partly an implementation problem and that = it is possible to do with current = specification

But it seems to = me, from a protocol design point of view it would be more consistent if = the RP object fully identify the = PathRequest.


As you know the only = potential issue is in the case of two pending
requests with = the same ID between two PCEs and the related = potential
Notification messages. In that case, we do have the = Notification Value to=A0
make sure that there is = no=A0ambiguity,=A0as we did for the request = cancellation
Notification message. And if one of the PCEs does = not "understand" the
Notification itself, then trying to = determine the request it relates to is
not = relevant.

Agree ?

Thanks.

JP.

= On Sep 10, 2007, at 4:07 AM, Fabien VERHAEGHE wrote:

Hi = Jean-Louis,

=A0

Thanks for the = reply.

See inline for = mine=85

=A0

Best = regards

Fabien<= /span>

=A0

De=A0: LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.lerou= x@orange-ftgroup.com]
Envoy=E9=A0: vendredi 7 septembre = 2007 19:07
=C0=A0: fabien.verhaeghe@marb= en-products.com; pce@ietf.org
= Objet=A0: RE: [Pce] PCEP = Request ID

=A0

Hi = Fabien

=A0

Thanks for your = comment.

=A0

Please see = inline,

=

=A0

=
=

De=A0: Fabien = VERHAEGHE [mailto:fabien.verhaeg= he@marben-products.com]
Envoy=E9=A0: vendredi 10 ao=FBt = 2007 14:26
=C0=A0: pce@ietf.org
Objet=A0: [Pce] PCEP Request = ID

Hello = all,

=A0

I have a little = comment/suggestion on PCEP regarding the request Id.

In = section 7.3.1 states that

=93The = Request-ID-number value combined with the source IP address of the PCC = and the PCE address uniquely

identify the = path computation request context=94.

=A0

I agree with = that, however there may be 2 requests with same request Id exchanged on = the same session in

the= case of session between 2 PCEs.

One= Path Request being sent by PCE#1 to PCE#2 and the other one by PCE#2 to = PCE#1.

=A0

I don=92t think = there is any problem with that but I am a little concerned about = potential misinterpretation especially

in = PCErr and PCNotif message.

If = a PCNtf/PCErr message contains an RP object, nothing indicates if it is = related to the Request from PCE#1 to = PCE#2

or the one from = PCE#2 to PCE#1, except the notification/error type and = value.=A0

=A0

=A0

=A0

I guess this is = why for instance for the =93Pending Request cancelled=94 notification = there are 2 values. One for PCC and

one= for the PCE.=A0

=A0

Yes, this is = exactly=A0the reason why there are two = values.=A0

=A0

So we would not = need to define 2 values if the RP object fully identify the PathRequest. =

=46rom a protocol = specification point of view it seems more straightforward to = me.

=A0

One of the = problem, from an implementation perspective, is that we must first ready = the Notification type/value in order to = retrieve

the correct = PathRequest.=A0

=A0

Anyway, you have = to parse the entire message.

There are = other=A0implementations that first parse the whole message and then = start processing the objects.

This is IMO and = implementation issue.

=A0

I agree that it = is partly an implementation issue. However, the implementation can be = optimised if the RP object fully identifies the = PathRequest.

For instance, you = would not need to decode the Error object if the PathRequest is unknown. =

=A0

=A0

Another problem = is if an implementation does not recognize a given Error type/value, = then it can=92t tell for sure which PathRequest = it

is related = to.=A0

=A0

Anyway an=A0Error = related to a request is always sent in the PCE-PCC direction =

=A0

=A0

I agree this is = true today but will it still be true with future PCEP = extensions.

If it is this a = strict rules I think it should be mentioned in the = draft.

However can=92t = we imagine that a PCC sends an Error message to a PCE because it does = not like the Reply sent by the PCE?

e.g.= the Path does not respect the requested = constraints.

=A0

Besides we still = that have a problem in case of unrecognised Notification = type/value.

=A0

=A0

So it seems to = me it would be more consistent to add a bit in the RP object (in the = flag field) to indicate the

=93direction=94 = of the PathRequest.

For= instance if the bit is set the Message that carry the RP object is = related to the request sent by the destination of the = message.=A0

Hence, an RP = object would actually uniquely indentifies a = PathRequest.=A0

=A0

There maybe = an=A0ambiguity=A0only=A0in a few error/notif situations, and I don't = think adding a generic bit would be really useful.

By = the way this would be a significant change=A0wilth potentially new error = situations to handle (what do you do if=A0the direction PCC to PCE is = set in a reply message?)=A0.=

=A0

I = don=92t really see it as a significant = change.

For the Error = case I think it would be ok to say that the bit must be set in PCReq and = Clear in PCRep =A0message and must be ignored upon = reception.

Besides if we = keep the RP object as is what do you do if you receive a PCNtf message = with formatted as follows:

=A0

<RP><Notif= 1><Notif2> with Notif 1 and Notif2 being =93pending request = cancelled=94 but one with Notification value 1 and the other with = notification value 2.

=A0

It seems this is = anyway an error case that must be specified with current PCEP = specification.

=A0

Is that OK with = you if we keep as is?=

=A0

So basically I = agree that it is partly an implementation problem and that it is = possible to do with current specification

But = it seems to me, from a protocol design point of view it would be more = consistent if the RP object fully identify the = PathRequest.

=A0

Best = Regards,

=A0

JL

=A0

Regards=

Fabien = Verhaeghe

=

=A0

=
=
Pce mailing list
=

= --Apple-Mail-71-962482682-- --===============0885779590== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0885779590==-- From pce-bounces@lists.ietf.org Fri Sep 14 05:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7pb-0000es-4b; Fri, 14 Sep 2007 05:51:23 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IW5sA-0007Yh-Nt for pce-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 03:45:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW5s6-0007XE-03 for pce@ietf.org; Fri, 14 Sep 2007 03:45:50 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee01s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW5s4-00056z-13 for pce@ietf.org; Fri, 14 Sep 2007 03:45:49 -0400 Received: from wpwuee01s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 9F512F400B for ; Fri, 14 Sep 2007 09:45:46 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 675B6F4009 for ; Fri, 14 Sep 2007 09:45:46 +0200 (CEST) From: "Fabien VERHAEGHE" To: Date: Fri, 14 Sep 2007 09:44:50 +0200 Message-ID: <003b01c7f6a3$2221c890$18600337@AOFR11476> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acf2VwM43sRGcqKgQF6zmE6MnXLWAAASX58g X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a X-Mailman-Approved-At: Fri, 14 Sep 2007 05:51:22 -0400 Cc: Subject: [Pce] TLV Format X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabien.verhaeghe@marben-products.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0459779908==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0459779908== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C7F6B3.E5AA9890" This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C7F6B3.E5AA9890 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I think there is a little problem with PCEP object TLV format. The main problem being that the general format of the TLVs is not described (Type, length value length, 4 bytes alignment.). Besides for existing TLVs we have: "The REQ-MISSING TLV is composed of 1 byte for the type, 1 byte specifying the number of bytes in the value field, 2 bytes for an "Unused" field (the value of which MUST be set to 0), followed by a fix length value field of 4 bytes specifying the request-id-number that correspond to the missing request. The REQ-MISSING TLV is padded to eight-byte alignment. TYPE: To be assigned by IANA LENGTH: 4 VALUE: request-id-number that corresponds to the missing request" I think the LENGTH field should be set to 6, the unused field 2 bytes being part of the Value field. Otherwise it means those 2 bytes are part of the TLV header and it should be said that all TLVs will be formatted with this 4 bytes header i.e. Type (1byte) - Value field Length (1byte) - Unused field (2bytes) - Value field Otherwise, there may be some problem when decoding a message with unknown TLV. Besides I'm not sure about the "The REQ-MISSING TLV is padded to eight-byte alignment." statement. Is it really needed? For the NO-PATH-VECTFrom pce-bounces@lists.ietf.org Fri Sep 14 05:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7pb-0000es-4b; Fri, 14 Sep 2007 05:51:23 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IW5sA-0007Yh-Nt for pce-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 03:45:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW5s6-0007XE-03 for pce@ietf.org; Fri, 14 Sep 2007 03:45:50 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee01s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW5s4-00056z-13 for pce@ietf.org; Fri, 14 Sep 2007 03:45:49 -0400 Received: from wpwuee01s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 9F512F400B for ; Fri, 14 Sep 2007 09:45:46 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 675B6F4009 for ; Fri, 14 Sep 2007 09:45:46 +0200 (CEST) From: "Fabien VERHAEGHE" To: Date: Fri, 14 Sep 2007 09:44:50 +0200 Message-ID: <003b01c7f6a3$2221c890$18600337@AOFR11476> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acf2VwM43sRGcqKgQF6zmE6MnXLWAAASX58g X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a X-Mailman-Approved-At: Fri, 14 Sep 2007 05:51:22 -0400 Cc: Subject: [Pce] TLV Format X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabien.verhaeghe@marben-products.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0459779908==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0459779908== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C7F6B3.E5AA9890" This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C7F6B3.E5AA9890 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I think there is a little problem with PCEP object TLV format. The main problem being that the general format of the TLVs is not described (Type, length value length, 4 bytes alignment.). Besides for existing TLVs we have: "The REQ-MISSING TLV is composed of 1 byte for the type, 1 byte specifying the number of bytes in the value field, 2 bytes for an "Unused" field (the value of which MUST be set to 0), followed by a fix length value field of 4 bytes specifying the request-id-number that correspond to the missing request. The REQ-MISSING TLV is padded to eight-byte alignment. TYPE: To be assigned by IANA LENGTH: 4 VALUE: request-id-number that corresponds to the missing request" I think the LENGTH field should be set to 6, the unused field 2 bytes being part of the Value field. Otherwise it means those 2 bytes are part of the TLV header and it should be said that all TLVs will be formatted with this 4 bytes header i.e. Type (1byte) - Value field Length (1byte) - Unused field (2bytes) - Value field Otherwise, there may be some problem when decoding a message with unknown TLV. Besides I'm not sure about the "The REQ-MISSING TLV is padded to eight-byte alignment." statement. Is it really needed? For the NO-PATH-VECTOR TLV we have "The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte specifying the number of bytes in the value field, followed by a fix length value field of 32-bits flags field used to report the reason(s) that led to unsuccessful path computation. The NO-PATH-VECTOR TLV is padded to eight-byte alignment. TYPE: To be assigned by IANA LENGTH: 4 VALUE: 32-bits flags field" In this case there is no Unused field 2 bytes. I think it would be better to have the same format for all TLVs of all object. And again I'm wondering if the LENGTH field should be set to 4 or 6? Can you please clarify this to me? Am I missing something? Thanks Fabien ------=_NextPart_000_003C_01C7F6B3.E5AA9890 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 =

I think there is = a little problem with PCEP object TLV format.

 =

The main problem = being that the general format of the TLVs is not described (Type, length value length, 4 bytes alignment…).

 =

Besides for = existing TLVs we have:

 =

 =

“The = REQ-MISSING TLV is composed of 1 byte for the type,

Hi,

 =

I think there is = a little problem with PCEP object TLV format.

 =

The main problem = being that the general format of the TLVs is not described (Type, length value length, 4 bytes alignment…).

 =

Besides for = existing TLVs we have:

 =

 =

“The = REQ-MISSING TLV is composed of 1 byte for the type,

1 byte = specifying the number of bytes in the value field, 2 bytes

for an = "Unused" field (the value of which MUST be set to 0), followed = by

a fix length = value field of 4 bytes specifying the request-id-number

that correspond = to the missing request.

The REQ-MISSING = TLV is padded to eight-byte alignment.

 =

TYPE: To be = assigned by IANA

LENGTH: = 4

VALUE: = request-id-number that corresponds to the missing = request”

 =

I think the = LENGTH field should be set to 6, the unused field 2 bytes being part of the Value = field. Otherwise

it means those 2 = bytes are part of the TLV header and it should be said that all TLVs will be formatted with

this 4 bytes = header i.e. Type (1byte) – Value field Length (1byte) – Unused field (2bytes) = – Value field

Otherwise, there = may be some problem when decoding a message with unknown = TLV.

 =

Besides = I’m not sure about the “The REQ-MISSING TLV is padded to eight-byte = alignment.” statement.

Is it really = needed?

 =

<=3DMsoNormal>1 byte = specifying the number of bytes in the value field, 2 bytes

for an = "Unused" field (the value of which MUST be set to 0), followed = by

a fix length = value field of 4 bytes specifying the request-id-number

that correspond = to the missing request.

The REQ-MISSING = TLV is padded to eight-byte alignment.

 =

TYPE: To be = assigned by IANA

LENGTH: = 4

VALUE: = request-id-number that corresponds to the missing = request”

 =

I think the = LENGTH field should be set to 6, the unused field 2 bytes being part of the Value = field. Otherwise

it means those 2 = bytes are part of the TLV header and it should be said that all TLVs will be formatted with

this 4 bytes = header i.e. Type (1byte) – Value field Length (1byte) – Unused field (2bytes) = – Value field

Otherwise, there = may be some problem when decoding a message with unknown = TLV.

 =

Besides = I’m not sure about the “The REQ-MISSING TLV is padded to eight-byte = alignment.” statement.

Is it really = needed?

 =

For the = NO-PATH-VECTOR TLV we have

 =

“The = NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 = byte

   = specifying the number of bytes in the value field, followed by a = fix

   = length value field of 32-bits flags field used to report = the

   = reason(s) that led to unsuccessful path computation.

 =

   The NO-PATH-VECTOR TLV is padded to eight-byte = alignment.

 =

TYPE: To be = assigned by IANA

 =

   = LENGTH: 4

 =

   = VALUE: 32-bits flags field”

 =

In this case = there is no Unused field 2 bytes.

I think it would = be better to have the same format for all TLVs of all = object.

And again = I’m wondering if the LENGTH field should be set to 4 or = 6?

 =

For the = NO-PATH-VECTOR TLV we have

 =

“The = NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 = byte

   = specifying the number of bytes in the value field, followed by a = fix

   = length value field of 32-bits flags field used to report = the

   = reason(s) that led to unsuccessful path computation.

 =

   The NO-PATH-VECTOR TLV is padded to eight-byte = alignment.

 =

TYPE: To be = assigned by IANA

 =

   = LENGTH: 4

 =

   = VALUE: 32-bits flags field”

 =

In this case = there is no Unused field 2 bytes.

I think it would = be better to have the same format for all TLVs of all = object.

And again = I’m wondering if the LENGTH field should be set to 4 or = 6?

 =

Can you please = clarify this to me? Am I missing something?

 =

Thanks=

Fabien=

 =

------=_NextPart_000_003C_01C7F6B3.E5AA9890-- --===============0459779908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0459779908==-- From pce-bounces@lists.ietf.org Fri Sep 14 05:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7pb-0000ey-C0; Fri, 14 Sep 2007 05:51:23 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IW77f-0002kN-3F for pce-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 05:05:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW77e-0002kD-Ov for pce@ietf.org; Fri, 14 Sep 2007 05:05:58 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee03s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW77c-0007KI-HK for pce@ietf.org; Fri, 14 Sep 2007 05:05:58 -0400 Received: from wpwuee03s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee03s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 6B8C011404A; Fri, 14 Sep 2007 11:05:55 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee03s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 0B804114038; Fri, 14 Sep 2007 11:05:55 +0200 (CEST) From: "Fabien VERHAEGHE" To: "'JP Vasseur'" Subject: RE: [Pce] PCEP Request ID Date: Fri, 14 Sep 2007 11:04:59 +0200 Message-ID: <004301c7f6ae$5446ffb0$18600337@AOFR11476> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acf2VvMhAwnbAYCnRcG7QqEnB/aghwAVIm+Q X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 20b955f68be7aec1a8ed33c9636ede4b X-Mailman-Approved-At: Fri, 14 Sep 2007 05:51:22 -0400 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabien.verhaeghe@marben-products.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1909946282==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1909946282== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C7F6BF.17CFCFB0" This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C7F6BF.17CFCFB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printabe=3D'font-size:10.0pt;font-family:Arial;color:navy'>Can you please = clarify this to me? Am I missing something?

 =

Thanks=

Fabien=

 =

------=_NextPart_000_003C_01C7F6B3.E5AA9890-- --===============0459779908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0459779908==-- From pce-bounces@lists.ietf.org Fri Sep 14 05:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7pb-0000ey-C0; Fri, 14 Sep 2007 05:51:23 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IW77f-0002kN-3F for pce-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 05:05:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW77e-0002kD-Ov for pce@ietf.org; Fri, 14 Sep 2007 05:05:58 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee03s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW77c-0007KI-HK for pce@ietf.org; Fri, 14 Sep 2007 05:05:58 -0400 Received: from wpwuee03s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee03s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 6B8C011404A; Fri, 14 Sep 2007 11:05:55 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee03s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 0B804114038; Fri, 14 Sep 2007 11:05:55 +0200 (CEST) From: "Fabien VERHAEGHE" To: "'JP Vasseur'" Subject: RE: [Pce] PCEP Request ID Date: Fri, 14 Sep 2007 11:04:59 +0200 Message-ID: <004301c7f6ae$5446ffb0$18600337@AOFR11476> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acf2VvMhAwnbAYCnRcG7QqEnB/aghwAVIm+Q X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 20b955f68be7aec1a8ed33c9636ede4b X-Mailman-Approved-At: Fri, 14 Sep 2007 05:51:22 -0400 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabien.verhaeghe@marben-products.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1909946282==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1909946282== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C7F6BF.17CFCFB0" This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C7F6BF.17CFCFB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, =20 About the unknown notification I was thinking about cases where an implementation may pass the notification with the associated pathRequest to another module that = may be able to understand=20 it. Or for instance if you just want to display the Notification with information about the related PathRequest. =20 But my main point is rather that IMHO it would be more consistent if the = RP object unambiguously identifies the PathRequest rather than defining 2 Error/Notification values. =20 However I agree that there is no actual issue with current specification = and if you think that work is maybe too advanced to change this now that would be fine to me to let it as is. =20 Just another point regarding the discussion with Jean-Louis, About the = fact that Error message related to a PathRequest are always in PCE to PCC direction, I just realized that this may not be totally true. Error-Type 8 =93Unknown request reference=94 is in the PCC to PCE = direction. Unless an implementation is not supposed to put the RP object in the error message in this case (It is not explicitly said in section = 7.3.2). =20 Best regards Fabien =20 _____ =20 De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : vendredi 14 septembre 2007 00:38 =C0 : fabien.verhaeghe@marben-products.com Cc : pce@ietf.org Objet : Re: [Pce] PCEP Request ID =20 Hi Fabien, =20 Jumping at the end .... You wrote: =20 So basically I agree that it is partly an implementation problem and = that it is possible to do with current specification But it seems to me, from a protocol design point of view it would be = more consistent if the RP object fully identify the PathRequest. =20 As you know the only potential issue is in the case of two pending requests with the same ID between two PCEs and the related potential Notification messages. In that case, we do have the Notification Value = to=20 make sure that there is no ambiguity, as we did for the request = cancellation Notification message. And if one of the PCEs does not "understand" the Notification itself, then trying to determine the request it relates to = is not relevant. =20 Agree ? =20 Thanks. =20 JP. =20 On Sep 10, 2007, at 4:07 AM, Fabien VERHAEGHE wrote: Hi Jean-Louis, =20 Thanks for the reply. See inline for mine=85 =20 Best regards Fabien =20 _____ =20 De : LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@orange-ftgroup.com]=20 Envoy=E9 : vendredi 7 septembre 2007 19:07 =C0 : fabien.verhaeghe@marben-products.com; pce@ietf.org Objet : RE: [Pce] PCEP Request ID =20 Hi Fabien =20 Thanks for your comment. =20 Please see inline, =20 _____ =20 De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]=20 Envoy=E9 : vendredi 10 ao=FBt 2007 14:26 =C0 : pce@ietf.org Objet : [Pce] PCEP Request ID Hello all, =20 I have a little comment/suggestion on PCEP regarding the request Id. In section 7.3.1 states that =93The Request-ID-number value combined with the source IP address of = the PCC and the PCE address uniquely=20 identify the path computation request context=94. =20 I agree with that, however there may be 2 requests with same request Id exchanged on the same session in=20 the case of session between 2 PCEs.=20 One Path Request being sent by PCE#1 to PCE#2 and the other one by PCE#2 = to PCE#1. =20 I don=92t think there is any problem with that but I am a little = concerned about potential misinterpretation especially in PCErr and PCNotif message. If a PCNtf/PCErr message contains an RP object, nothing indicates if it = is related to the Request from PCE#1 to PCE#2 or the one from PCE#2 to PCE#1, except the notification/error type and value.=20 =20 =20 =20 I guess this is why for instance for the =93Pending Request cancelled=94 notification there are 2 values. One for PCC and one for the PCE.=20 =20 Yes, this is exactly the reason why there are two values.=20 =20 So we would not need to define 2 values if the RP object fully identify = the PathRequest.=20 >From a protocol specification ple Hi JP, =20 About the unknown notification I was thinking about cases where an implementation may pass the notification with the associated pathRequest to another module that = may be able to understand=20 it. Or for instance if you just want to display the Notification with information about the related PathRequest. =20 But my main point is rather that IMHO it would be more consistent if the = RP object unambiguously identifies the PathRequest rather than defining 2 Error/Notification values. =20 However I agree that there is no actual issue with current specification = and if you think that work is maybe too advanced to change this now that would be fine to me to let it as is. =20 Just another point regarding the discussion with Jean-Louis, About the = fact that Error message related to a PathRequest are always in PCE to PCC direction, I just realized that this may not be totally true. Error-Type 8 =93Unknown request reference=94 is in the PCC to PCE = direction. Unless an implementation is not supposed to put the RP object in the error message in this case (It is not explicitly said in section = 7.3.2). =20 Best regards Fabien =20 _____ =20 De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : vendredi 14 septembre 2007 00:38 =C0 : fabien.verhaeghe@marben-products.com Cc : pce@ietf.org Objet : Re: [Pce] PCEP Request ID =20 Hi Fabien, =20 Jumping at the end .... You wrote: =20 So basically I agree that it is partly an implementation problem and = that it is possible to do with current specification But it seems to me, from a protocol design point of view it would be = more consistent if the RP object fully identify the PathRequest. =20 As you know the only potential issue is in the case of two pending requests with the same ID between two PCEs and the related potential Notification messages. In that case, we do have the Notification Value = to=20 make sure that there is no ambiguity, as we did for the request = cancellation Notification message. And if one of the PCEs does not "understand" the Notification itself, then trying to determine the request it relates to = is not relevant. =20 Agree ? =20 Thanks. =20 JP. =20 On Sep 10, 2007, at 4:07 AM, Fabien VERHAEGHE wrote: Hi Jean-Louis, =20 Thanks for the reply. See inline for mine=85 =20 Best regards Fabien =20 _____ =20 De : LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@orange-ftgroup.com]=20 Envoy=E9 : vendredi 7 septembre 2007 19:07 =C0 : fabien.verhaeghe@marben-products.com; pce@ietf.org Objet : RE: [Pce] PCEP Request ID =20 Hi Fabien =20 Thanks for your comment. =20 Please see inline, =20 _____ =20 De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]=20 Envoy=E9 : vendredi 10 ao=FBt 2007 14:26 =C0 : pce@ietf.org Objet : [Pce] PCEP Request ID Hello all, =20 I have a little comment/suggestion on PCEP regarding the request Id. In section 7.3.1 states that =93The Request-ID-number value combined with the source IP address of = the PCC and the PCE address uniquely=20 identify the path computation request context=94. =20 I agree with that, however there may be 2 requests with same request Id exchanged on the same session in=20 the case of session between 2 PCEs.=20 One Path Request being sent by PCE#1 to PCE#2 and the other one by PCE#2 = to PCE#1. =20 I don=92t think there is any problem with that but I am a little = concerned about potential misinterpretation especially in PCErr and PCNotif message. If a PCNtf/PCErr message contains an RP object, nothing indicates if it = is related to the Request from PCE#1 to PCE#2 or the one from PCE#2 to PCE#1, except the notification/error type and value.=20 =20 =20 =20 I guess this is why for instance for the =93Pending Request cancelled=94 notification there are 2 values. One for PCC and one for the PCE.=20 =20 Yes, this is exactly the reason why there are two values.=20 =20 So we would not need to define 2 values if the RP object fully identify = the PathRequest.=20 >From a protocol specification point of view it seems more = straightforward to me. =20 One of the problem, from an implementation perspective, is that we must first ready the Notification type/value in order to retrieve the correct PathRequest.=20 =20 Anyway, you have to parse the entire message.=20 There are other implementations that first parse the whole message and = then start processing the objects. This is IMO and implementation issue. =20 I agree that it is partly an implementation issue. However, the implementation can be optimised if the RP object fully identifies the PathRequest. For instance, you would not need to decode the Error object if the PathRequest is unknown.=20 =20 =20 Another problem is if an implementation does not recognize a given Error type/value, then it can=92t tell for sure which PathRequest it is related to.=20 =20 Anyway an Error related to a request is always sent in the PCE-PCC = direction =20 =20 I agree this is true today but will it still be true with future PCEP extensions. If it is this a strict rules I think it should be mentioned in the = draft. However can=92t we imagine that a PCC sends an Error message to a PCE = because it does not like the Reply sent by the PCE? e.g. the Path does not respect the requested constraints. =20 Besides we still that have a problem in case of unrecognised = Notification type/value. =20 =20 So it seems to me it would be more consistent to add a bit in the RP = object (in the flag field) to indicate the =93direction=94 of the PathRequest. For instance if the bit is set the Message that carry the RP object is related to the request sent by the destination of the message.=20 Hence, an RP object would actually uniquely indentifies a PathRequest.=20 =20 There maybe an ambiguity only in a few error/notif situations, and I = don't think adding a generic bit would be really useful. By the way this would be a significant change wilth potentially new = error situations to handle (what do you do if the direction PCC to PCE is set = in a reply message?) . =20 I don=92t really see it as a significant change. For the Error case I think it would be ok to say that the bit must be = set in PCReq and Clear in PCRep message and must be ignored upon reception. Besides if we keep the RP object as is what do you do if you receive a = PCNtf message with formatted as follows: =20 with Notif 1 and Notif2 being =93pending request cancelled=94 but one with Notification value 1 and the other with = notification value 2. =20 It seems this is anyway an error case that must be specified with = current PCEP specification. =20 Is that OK with you if we keep as is? =20 So basically I agree that it is partly an implementation problem and = that it is possible to do with current specification But it seems to me, from a protocol design point of view it would be = more consistent if the RP object fully identify the PathRequest. =20 Best Regards, =20 JL =20 Regards Fabien Verhaeghe =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 ------=_NextPart_000_0044_01C7F6BF.17CFCFB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable with Notif 1 and Notif2 being =93pending request cancelled=94 but one with Notification value 1 and the other with = notification value 2. =20 It seems this is anyway an error case that must be specified with = current PCEP specification. =20 Is that OK with you if we keep as is? =20 So basically I agree that it is partly an implementation problem and = that it is possible to do with current specification But it seems to me, from a protocol design point of view it would be = more consistent if the RP object fully identify the PathRequest. =20 Best Regards, =20 JL =20 Regards Fabien Verhaeghe =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 ------=_NextPart_000_0044_01C7F6BF.17CFCFB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi JP,

 

About the = unknown notification I was thinking about cases where an implementation may = pass

the notification = with the associated pathRequest to another module that may be able to understand =

it. Or for = instance if you just want to display the Notification with information about the = related PathRequest.

 =

But my main = point is rather that IMHO it would be more consistent if the RP object unambiguously = identifies the PathRequest rather

than defining 2 Error/Notification values.

 =

However I agree = that there is no actual issue with current specification and if you think = that work is maybe too advanced to change this

now that would = be fine to me to let it as is.

 =

Just another = point regarding the discussion with Jean-Louis, About the fact that Error = message related to a PathRequTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"PersonName"/>

Hi JP,

 

About the = unknown notification I was thinking about cases where an implementation may = pass

the notification = with the associated pathRequest to another module that may be able to understand =

it. Or for = instance if you just want to display the Notification with information about the = related PathRequest.

 =

But my main = point is rather that IMHO it would be more consistent if the RP object unambiguously = identifies the PathRequest rather

than defining 2 Error/Notification values.

 =

However I agree = that there is no actual issue with current specification and if you think = that work is maybe too advanced to change this

now that would = be fine to me to let it as is.

 =

Just another = point regarding the discussion with Jean-Louis, About the fact that Error = message related to a PathRequest are always in

PCE to PCC = direction, I just realized that this may not be totally = true.

Error-Type 8 = “Unknown request reference” is in the PCC to PCE direction. Unless an implementation is not supposed to put the RP object = in

the error = message in this case (It is not explicitly said in section = 7.3.2).

 =

Best = regards

Fabien=

 =

De : = JP Vasseur [mailto:jvasseur@cisco.com]
Envoy=E9 : vendredi = 14 septembre 2007 00:38
=C0 : = fabien.verhaeghe@marben-products.com
Cc : = pce@ietf.org
Objet : Re: [Pce] = PCEP Request ID

 

Hi Fabien,

 

Jumping at the end .... You wrote:

 

So basically I agree that it is partly an implementation problem and that it is possible to do with current = specification

But it seems to me, from a protocol design = point of view it would be more consistent if the RP object fully identify the Pathest are always in

PCE to PCC = direction, I just realized that this may not be totally = true.

Error-Type 8 = “Unknown request reference” is in the PCC to PCE direction. Unless an implementation is not supposed to put the RP object = in

the error = message in this case (It is not explicitly said in section = 7.3.2).

 =

Best = regards

Fabien=

 =

De : = JP Vasseur [mailto:jvasseur@cisco.com]
Envoy=E9 : vendredi = 14 septembre 2007 00:38
=C0 : = fabien.verhaeghe@marben-products.com
Cc : = pce@ietf.org
Objet : Re: [Pce] = PCEP Request ID

 

Hi Fabien,

 

Jumping at the end .... You wrote:

 

So basically I agree that it is partly an implementation problem and that it is possible to do with current = specification

But it seems to me, from a protocol design = point of view it would be more consistent if the RP object fully identify the PathRequest.

 

As you know the only potential issue is in the case of two = pending

requests with the same ID between two PCEs and the related = potential

Notification messages. In that case, we do have the Notification = Value to 

make sure that there is no ambiguity, as we did for = the request cancellation

Notification message. And if one of the PCEs does not "understand" the

Notification itself, then trying to determine the request it = relates to is

not relevant.

 

Agree ?

 

Thanks.

 

JP.

 

On Sep 10, 2007, at 4:07 AM, Fabien = VERHAEGHE wrote:



Hi Jean-Louis,

 

 

As you know the only potential issue is in the case of two = pending

requests with the same ID between two PCEs and the related = potential

Notification messages. In that case, we do have the Notification = Value to 

make sure that there is no ambiguity, as we did for = the request cancellation

Notification message. And if one of the PCEs does not "understand" the

Notification itself, then trying to determine the request it = relates to is

not relevant.

 

Agree ?

 

Thanks.

 

JP.

 

On Sep 10, 2007, at 4:07 AM, Fabien = VERHAEGHE wrote:



Hi Jean-Louis,

 

Thanks for the = reply.

See inline for = mine…

 

Best = regards

Fabien

 

De : LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.lero= ux@orange-ftgroup.com]
Envoy=E9 : vendredi = 7 septembre 2007 19:07
=C0 : fabien.verhaeghe@mar= ben-products.com; pce@ietf.org
Objet : RE: [Pce] = PCEP Request ID

 

Hi Fabien

 

Thanks for your = comment.

 

Please see inline,

Thanks for the = reply.

See inline for = mine…

 

Best = regards

Fabien

 

De : LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.lero= ux@orange-ftgroup.com]
Envoy=E9 : vendredi = 7 septembre 2007 19:07
=C0 : fabien.verhaeghe@mar= ben-products.com; pce@ietf.org
Objet : RE: [Pce] = PCEP Request ID

 

Hi Fabien

 

Thanks for your = comment.

 

Please see inline,

 

De : Fabien = VERHAEGHE [mailto:fabien.verhae= ghe@marben-products.com]
Envoy=E9 : vendredi = 10 ao=FBt 2007 14:26
=C0 : pce@ietf.org
Objet : [Pce] PCEP = Request ID

Hello = all,

 

I have a little comment/suggestion on PCEP regarding the request Id.

In section 7.3.1 states = that

“The Request-ID-number value = combined with the source IP address of the PCC and the PCE address uniquely =

identify the path computation request context”.

 

I agree with that, however there may be 2 requests with same request Id exchanged on the same session in =

the case of session bet= style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> 

De : Fabien = VERHAEGHE [mailto:fabien.verhae= ghe@marben-products.com]
Envoy=E9 : vendredi = 10 ao=FBt 2007 14:26
=C0 : pce@ietf.org
Objet : [Pce] PCEP = Request ID

Hello = all,

 

I have a little comment/suggestion on PCEP regarding the request Id.

In section 7.3.1 states = that

“The Request-ID-number value = combined with the source IP address of the PCC and the PCE address uniquely =

identify the path computation request context”.

 

I agree with that, however there may be 2 requests with same request Id exchanged on the same session in =

the case of session between 2 PCEs. =

One Path Request being sent by PCE#1 to = PCE#2 and the other one by PCE#2 to = PCE#1.

 

I don’t think there is any problem = with that but I am a little concerned about potential misinterpretation = especially

in PCErr and PCNotif = message.

If a PCNtf/PCErr message contains an RP = object, nothing indicates if it is related to the Request from PCE#1 to = PCE#2

or the one from PCE#2 to PCE#1, except the notification/error type and value. 

 

 

 

I guess this is why for instance for the “Pending Request cancelled” notification there are 2 values. = One for PCC and

one for the PCE. 

 

Yes, this is exactly the reason why = there are two values. 

One Path Request being sent by PCE#1 to = PCE#2 and the other one by PCE#2 to = PCE#1.

 

I don’t think there is any problem = with that but I am a little concerned about potential misinterpretation = especially

in PCErr and PCNotif = message.

If a PCNtf/PCErr message contains an RP = object, nothing indicates if it is related to the Request from PCE#1 to = PCE#2

or the one from PCE#2 to PCE#1, except the notification/error type and value. 

 

 

 

I guess this is why for instance for the “Pending Request cancelled” notification there are 2 values. = One for PCC and

one for the PCE. 

 

Yes, this is exactly the reason why = there are two values. 

 

So we would not need to define 2 values if = the RP object fully identify the PathRequest. =

From a protocol specification point of view = it seems more straightforward to = me.

 

One of the problem, from an implementation perspective, is that we must first ready the Notification type/value in = order to retrieve

the correct = PathRequest. 

 

Anyway, you have to parse the entire = message.

There are other implementations that = first parse the whole message and then start processing the = objects.

This is IMO and implementation = issue.

 

I agree that it is partly an implementation = issue. However, the implementation can be optimised if the RP object fully = identifies the PathRequest.

For instance, you would not need to decode = the Error object if the PathRequest is unknown. =

 

So we would not need to define 2 values if = the RP object fully identify the PathRequest. =

From a protocol specification point of view = it seems more straightforward to = me.

 

One of the problem, from an implementation perspective, is that we must first ready the Notification type/value in = order to retrieve

the correct = PathRequest. 

 

Anyway, you have to parse the entire = message.

There are other implementations that = first parse the whole message and then start processing the = objects.

This is IMO and implementation = issue.

 

I agree that it is partly an implementation = issue. However, the implementation can be optimised if the RP object fully = identifies the PathRequest.

For instance, you would not need to decode = the Error object if the PathRequest is unknown. =

 

 

Another problem is if an implementation = does not recognize a given Error type/value, then it can’t tell for sure = which PathRequest it

is related to. 

 

Anyway an Error related to a request = is always sent in the PCE-PCC direction =

 

 

I agree this is true today but will it = still be true with future PCEP = extensions.

If it is this a strict rules I think it = should be mentioned in the draft.

However can’t we imagine that a PCC = sends an Error message to a PCE because it does not like the Reply sent by the = PCE?

e.g. the Path does not respect the = requested constraints.

 =

 

 

Another problem is if an implementation = does not recognize a given Error type/value, then it can’t tell for sure = which PathRequest it

is related to. 

 

Anyway an Error related to a request = is always sent in the PCE-PCC direction =

 

 

I agree this is true today but will it = still be true with future PCEP = extensions.

If it is this a strict rules I think it = should be mentioned in the draft.

However can’t we imagine that a PCC = sends an Error message to a PCE because it does not like the Reply sent by the = PCE?

e.g. the Path does not respect the = requested constraints.

 =

Besides we still that have a problem in = case of unrecognised Notification = type/value.

 

 

So it seems to me it would be more = consistent to add a bit in the RP object (in the flag field) to indicate = the

“direction” of the = PathRequest.

For instance if the bit is set the Message = that carry the RP object is related to the request sent by the destination of = the message. 

Hence, an RP object would actually = uniquely indentifies a PathRequest. 

 

There maybe = an ambiguity only in a few error/notif situations, and I don't think adding a generic bit would = be really useful.

By the way this would be a significant change wilth potentially new error situations to handle (what do = you do if the direction PCC to PCE is set in a reply = message?) .

 

I don’t really see it as a = significant change.

Besides we still that have a problem in = case of unrecognised Notification = type/value.

 

 

So it seems to me it would be more = consistent to add a bit in the RP object (in the flag field) to indicate = the

“direction” of the = PathRequest.

For instance if the bit is set the Message = that carry the RP object is related to the request sent by the destination of = the message. 

Hence, an RP object would actually = uniquely indentifies a PathRequest. 

 

There maybe = an ambiguity only in a few error/notif situations, and I don't think adding a generic bit would = be really useful.

By the way this would be a significant change wilth potentially new error situations to handle (what do = you do if the direction PCC to PCE is set in a reply = message?) .

 

I don’t really see it as a = significant change.

For the Error case I think it would be ok = to say that the bit must be set in PCReq and Clear in PCRep  message and = must be ignored upon reception.

Besides if we keep the RP object as is what = do you do if you receive a PCNtf message with formatted as = follows:

 =

<RP><Notif1><Notif2> with = Notif 1 and Notif2 being “pending request cancelled” but one with Notification value 1 and the other with notification value = 2.

 =

It seems this is anyway an error case that = must be specified with current PCEP = specification.

 

Is that OK with you if we keep as = is?

 

So basically I agree that it is partly an implementation problem and that it is possible to do with current = specification

But it seems to me, from a protocol design = point of view it would be more consistent if the RP object fully identify the PathRequest.

 

Best Regards,

For the Error case I think it would be ok = to say that the bit must be set in PCReq and Clear in PCRep  message and = must be ignored upon reception.

Besides if we keep the RP object as is what = do you do if you receive a PCNtf message with formatted as = follows:

 =

<RP><Notif1><Notif2> with = Notif 1 and Notif2 being “pending request cancelled” but one with Notification value 1 and the other with notification value = 2.

 =

It seems this is anyway an error case that = must be specified with current PCEP = specification.

 

Is that OK with you if we keep as = is?

 

So basically I agree that it is partly an implementation problem and that it is possible to do with current = specification

But it seems to me, from a protocol design = point of view it would be more consistent if the RP object fully identify the PathRequest.

 

Best Regards,

 

JL

 

Regards

Fabien = Verhaeghe

 

___________= ____________________________________

Pce mailing list

 

------=_NextPart_000_0044_01C7F6BF.17CFCFB0-- --===============1909946282== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1909946282==-- lang=3DEN-GB = style=3D'font-size: 12.0pt;color:blue'> 

JL

 

Regards

Fabien = Verhaeghe

 

___________= ____________________________________

Pce mailing list

 

------=_NextPart_000_0044_01C7F6BF.17CFCFB0-- --===============1909946282== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1909946282==-- From pce-bounces@lists.ietf.org Fri Sep 14 17:36:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWIq9-0001Gr-1X; Fri, 14 Sep 2007 17:36:41 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IWIq7-0001Gd-He for pce-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 17:36:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWIq7-0001GV-7m; Fri, 14 Sep 2007 17:36:39 -0400 Received: from smtp.polymtl.ca ([132.207.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWIq6-0003tw-0k; Fri, 14 Sep 2007 17:36:39 -0400 Received: from localhost (imp-4-3.polymtl.ca [132.207.4.78]) by smtp.polymtl.ca (8.13.6/8.13.6) with ESMTP id l8ELaXi9006175; Fri, 14 Sep 2007 17:36:33 -0400 Received: from lmcpra.ericsson.ca (lmcpra.ericsson.ca [192.75.88.231]) by www.imp.polymtl.ca (IMP) with HTTP for ; Fri, 14 Sep 2007 17:36:34 -0400 Message-ID: <1189805794.46eafee2b6808@www.imp.polymtl.ca> Date: Fri, 14 Sep 2007 17:36:34 -0400 From: Meral Shirazipour To: jpv@cisco.com, jeanlouis.leroux@orange-ftgroup.com Subject: Re: [Pce] Please comment on draft-ietf-pce-disco-proto-isis-07.txt References: <05da01c7f64d$6e7dc780$3901850a@your029b8cecfe> In-Reply-To: <05da01c7f64d$6e7dc780$3901850a@your029b8cecfe> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 192.75.88.231 X-Poly-FromMTA: (imp-4-3.polymtl.ca [132.207.4.78]) at Fri, 14 Sep 2007 21:36:33 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.polymtl.ca id l8ELaXi9006175 X-Spam-Score: -0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: pce@ietf.org, isis-wg@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, In draft draft-ietf-pce-disco-proto-isis-07 Section 4 Page 7, it is mentioned: =93 No additional sub-TLVs will be added to the PCED TLV in the future. If a = future application requires advertising additional PCE information in IS-IS, thi= s will not be carried in the CAPABILITY TLV. =93 -Is there a technical reasoning behind this decision? -I would also change the last two words :=94 CAPABILITY TLV =93 to =93IS-= IS Router Capability TLV ([IS-IS-CAP])=94 to avoid any confusion with the PCE-CAP-F= LAGS sub-TLV :) In draft draft-ietf-pce-disco-proto-ospf-07 Section 4 Page 7, it is mentioned: =93 No additional sub-TLVs will be added to the PCED TLV in the future. If a = future application requires advertising additional PCE information in OSPF, this= will not be carried in the Router Information LSA. =94 -Same question here. Warm Regards, Meral Selon Adrian Farrel : > Hi, > > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-07.= txt > has recently been posted. The last couple of revisions addressed commen= ts > raised by the IESG and by the IGP working group chairs, etc. > > This is a call to you for a further review of the I-D. > > We'll run with a two week deadline to 28th September. > > Many thanks, > Adrian > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Sep 17 17:39:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXOIn-0002SO-UZ; Mon, 17 Sep 2007 17:38:46 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IXNrP-0002yf-0O for pce-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 17:10:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNrO-0002yX-I9 for pce@ietf.org; Mon, 17 Sep 2007 17:10:26 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXNrL-0004QO-U7 for pce@ietf.org; Mon, 17 Sep 2007 17:10:26 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Sep 2007 17:10:24 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8HLANr2031382; Mon, 17 Sep 2007 17:10:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8HLAAga024207; Mon, 17 Sep 2007 21:10:14 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 17:10:12 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 17:10:09 -0400 In-Reply-To: <004301c7f6ae$5446ffb0$18600337@AOFR11476> References: <004301c7f6ae$5446ffb0$18600337@AOFR11476> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <9E68B718-2DC7-42A9-BC9C-16AAAC02FBA6@cisco.com> From: JP Vasseur Subject: Re: [Pce] PCEP Request ID Date: Mon, 17 Sep 2007 17:09:26 -0400 To: X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Sep 2007 21:10:09.0890 (UTC) FILETIME=[214F9C20:01C7F96F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=72028; t=1190063423; x=1190927423; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20PCEP=20Request=20ID |Sender:=20 |To:=20; bh=vKkDsMivrN/wKZrkK656/QdzIIR51UiKjoBeXI2AdtY=; b=QFRfdvf5Im9aF9Aa4AUdxRUFKJ4kFQF3A/3N7d3wCZ7qSnGI0TvXqaKlcgX1BEfxg28/UrQG FBTfYRUbSkkR6/Pa/cGtuQf5fachfsXYXqnwM+1yF3Gk0WYW63/aJ/K6; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 994e950297cbb8d1e4f7363bcfbbacd3 X-Mailman-Approved-At: Mon, 17 Sep 2007 17:38:45 -0400 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1560048172==" Errors-To: pce-bounces@lists.ietf.org --===============1560048172== Content-Type: multipart/alternative; boundary=Apple-Mail-112--844714602 --Apple-Mail-112--844714602 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Fabien, On Sep 14, 2007, at 5:04 AM, Fabien VERHAEGHE wrote: > Hi JP, > > About the unknown notification I was thinking about cases where an =20 > implementation may pass > the notification with the associated pathRequest to another module =20 > that may be able to understand > it. Then the info should be passed via the API. > Or for instance if you just want to display the Notification with =20 > information about the related PathRequest. > > But my main point is rather that IMHO it would be more consistent =20 > if the RP object unambiguously identifies the PathRequest rather > than defining 2 Error/Notification values. > > However I agree that there is no actual issue with current =20 > specification and if you think that work is maybe too advanced to =20 > change this > now that would be fine to me to let it as is. OK. > > Just another point regarding the discussion with Jean-Louis, About =20 > the fact that Error message related to a PathRequest are always in > PCE to PCC direction, I just realized that this may not be totally =20 > true. > Error-Type 8 =93Unknown request reference=94 is in the PCC to PCE =20 > direction. Unless an implementation is not supposed to put the RP =20 > object in > the error message in this case (It is not explicitly said in =20 > section 7.3.2). But in this case there is no ambiguity that this is coming from the PCC. Thanks. JP. > > Best regards > Fabien > > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoy=E9 : vendredi 14 septembre 2007 00:38 > =C0 : fabien.verhaeghe@marben-products.com > Cc : pce@ietf.org > Objet : Re: [Pce] PCEP Request ID > > Hi Fabien, > > Jumping at the end .... You wrote: > >> So basically I agree that it is partly an implementation problem =20 >> and that it is possible to do with current specification >> But it seems to me, from a protocol design point of view it would =20 >> be more consistent if the RP object fully identify the PathRequest. > > As you know the only potential issue is in the case of two pending > requests with the same ID between two PCEs and the related potential > Notification messages. In that case, we do have the Notification =20 > Value to > make sure that there is no ambiguity, as we did for the request =20 > cancellation > Notification message. And if one of the PCEs does not "understand" the > Notification itself, then trying to determine the request it =20 > relates to is > not relevant. > > Agree ? > > Thanks. > > JP. > > On Sep 10, 2007, at 4:07 AM, Fabien VERHAEGHE wrote: > > > Hi Jean-Louis, > > Thanks for the reply. > See inline for mine=85 > > Best regards > Fabien > > De : LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@orange-=20= > ftgroup.com] > Envoy=E9 : vendredi 7 septembre 2007 19:07 > =C0 : fabien.verhaeghe@marben-products.com; pce@ietf.org > Objet : RE: [Pce] PCEP Request ID > > Hi Fabien > > Thanks for your comment. > > Please see inline, > > De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com] > Envoy=E9 : vendredi 10 ao=FBt 2007 14:26 > =C0 : pce@ietf.org > Objet : [Pce] PCEP Request ID > Hello all, > > I have a little comment/suggestion on PCEP regarding the request Id. > In section 7.3.1 states that > =93The Request-ID-number value combined with the source IP address of =20= > the PCC and the PCE address uniquely > identify the path computation request context=94. > > I agree with that, however there may be 2 requests with same =20 > request Id exchanged on the same session in > the case of session between 2 PCEs. > One Path Request being sent by PCE#1 to PCE#2 and the other one by =20 > PCE#2 to PCE#1. > > I don=92t think there is any problem with that but I am a little =20 > concerned about potential misinterpretation especially > in PCErr and PCNotif message. > If a PCNtf/PCErr message contains an RP object, nothing indicates =20 > if it is related to the Request from PCE#1 to PCE#2 > or the one from PCE#2 to PCE#1, except the notification/error type =20 > and value. > > > > I guess this is why for instance for the =93Pending Request =20 > cancelled=94 notification there are 2 values. One for PCC and > one for the PCE. > > Yes, this is exactly the reason why there are two values. > > So we would not need to define 2 values if the RP object fully =20 > identify the PathRequest. > =46rom a protocol specification point of view it seems more =20 > straightforward to me. > > One of the problem, from an implementation perspective, is that we =20 > must first ready the Notification type/value in order to retrieve > the correct PathRequest. > > Anyway, you have to parse the entire message. > There are other implementations that first parse the whole message =20 > and then start processing the objects. > This is IMO and implementation issue. > > I agree that it is partly an implementation issue. However, the =20 > implementation can be optimised if the RP object fully identifies =20 > the PathRequest. > For instance, you would not need to decode the Error object if the =20 > PathRequest is unknown. > > > Another problem is if an implementation does not recognize a given =20 > Error type/value, then it can=92t tell for sure which PathRequest it > is related to. > > Anyway an Error related to a request is always sent in the PCE-PCC =20 > direction > > > I agree this is true today but will it still be true with future =20 > PCEP extensions. > If it is this a strict rules I think it should be mentioned in the =20 > draft. > However can=92t we imagine that a PCC sends an Error message to a PCE =20= > because it does not like the Reply sent by the PCE? > e.g. the Path does not respect the requested constraints. > > Besides we still that have a problem in case of unrecognised =20 > Notification type/value. > > > So it seems to me it would be more consistent to add a bit in the =20 > RP object (in the flag field) to indicate the > =93direction=94 of the PathRequest. > For instance if the bit is set the Message that carry the RP object =20= > is related to the request sent by the destination of the message. > Hence, an RP object would actually uniquely indentifies a PathRequest. > > There maybe an ambiguity only in a few error/notif situations, and =20 > I don't think adding a generic bit would be really useful. > By the way this would be a significant change wilth potentially new =20= > error situations to handle (what do you do if the direction PCC to =20 > PCE is set in a reply message?) . > > I don=92t really see it as a significant change. > For the Error case I think it would be ok to say that the bit must =20 > be set in PCReq and Clear in PCRep message and must be ignored =20 > upon reception. > Besides if we keep the RP object as is what do you do if you =20 > receive a PCNtf message with formatted as follows: > > with Notif 1 and Notif2 being =93pending request =20= > cancelled=94 but one with Notification value 1 and the other with =20 > notification value 2. > > It seems this is anyway an error case that must be specified with =20 > current PCEP specification. > > Is that OK with you if we keep as is? > > So basically I agree that it is partly an implementation problem =20 > and that it is possible to do with current specification > But it seems to me, from a protocol design point of view it would =20 > be more consistent if the RP object fully identify the PathRequest. > > Best Regards, > > JL > > Regards > Fabien Verhaeghe > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-112--844714602 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Fabien,

On Sep 14, 2007, at 5:04 AM, Fabien = VERHAEGHE wrote:

Hi = JP,
=A0
About the = unknown notification I was thinking about cases where an implementation = may pass
the notification = with the associated pathRequest to another module that may be able to = understand
it. =

Then the info should be = passed via the API.

Or for instance = if you just want to display the Notification with information about the = related PathRequest.
=A0
But= my main point is rather that IMHO it would be more consistent if the RP = object unambiguously identifies the PathRequest = rather
than defining 2 = Error/Notification values.
=A0
However I agree = that there is no actual issue with current specification and if you = think that work is maybe too advanced to change = this
now that would = be fine to me to let it as = is.

OK.

=
=A0
Just another = point regarding the discussion with Jean-Louis, About the fact that = Error message related to a PathRequest are always = in
PCE to PCC = direction, I just realized that this may not be totally = true.
Error-Type 8 = =93Unknown request reference=94 is in the PCC to PCE direction. Unless = an implementation is not supposed to put the RP object = in
the error = message in this case (It is not explicitly said in section = 7.3.2).

But in this case there is = no ambiguity that this is coming from the PCC.

Thanks.

JP.

=
=A0
Best = regards
Fabien<= /span>
=A0
De=A0:=A0JP Vasseur=A0[mailto:jvasseur@cisco.com]=A0
Envoy=E9=A0:=A0vendredi 14 septembre 2007 = 00:38
=C0=A0:=A0fabien.verhaeghe@marb= en-products.com
Cc=A0:=A0pce@ietf.org
Objet=A0:=A0Re: [Pce] PCEP Request = ID
=A0
Hi = Fabien,
=A0
Jumping at the end .... You = wrote:
=A0
So basically I = agree that it is partly an implementation problem and that it is = possible to do with current = specification
But it seems to = me, from a protocol design point of view it would be more consistent if = the RP object fully identify the = PathRequest.
=A0
As you know the only potential issue is in the case of two = pending
requests with = the same ID between two PCEs and the related = potential
Notification messages. In that case, we do have the Notification = Value to=A0
make sure that there is no=A0ambiguity,=A0as we did for the = request cancellation
Notification message. And if one of the PCEs does not = "understand" the
Notification itself, then trying to determine the request it = relates to is
not relevant.
=A0
Agree ?
=A0
Thanks.
=A0
JP.
=A0
On Sep 10, 2007, at 4:07 AM,=A0Fabien = VERHAEGHE=A0wrote:<= /div>


Hi = Jean-Louis,
=A0
Thanks for the = reply.
See inline for = mine=85
=A0
Best = regards
Fabien=
=A0=
Hi = Fabien
=A0
=
Thanks for your = comment.
=A0
=
Please see = inline,
=
=A0
=
=A0
I have a little = comment/suggestion on PCEP regarding the request=A0Id.
In section 7.3.1 states = that
=93The = Request-ID-number value combined with the source IP address of the PCC = and the PCE address = uniquely
identify the = path computation request = context=94.
=A0
I agree with = that, however there may be 2 requests with same request Id exchanged on = the same session in
the case of = session between 2 PCEs.
One Path = Request being sent by PCE#1 to PCE#2 and the other one by PCE#2 to = PCE#1.
=A0
I don=92t think = there is any problem with that but I am a little concerned about = potential misinterpretation = especially
in PCErr and = PCNotif message.
If a = PCNtf/PCErr message contains an RP object, nothing indicates if it is = related to the Request from PCE#1 to = PCE#2
or the one from = PCE#2 to PCE#1, except the notification/error type and = value.=A0
=A0
=
=A0
=
=A0
I guess this is = why for instance for the =93Pending Request cancelled=94 notification = there are 2 values. One for PCC = and
one for the = PCE.=A0
=A0
=
Yes, this is = exactly=A0the reason why there are two = values.=A0
=A0
So we would not = need to define 2 values if the RP object fully identify the = PathRequest.
=46rom a = protocol specification point of view it seems more straightforward to = me.
=A0
One of the = problem, from an implementation perspective, is that we must first ready = the Notification type/value in order to = retrieve
the correct = PathRequest.=A0
=A0
=
Anyway, you = have to parse the entire = message.
There are = other=A0implementations that first parse the whole message and then = start processing the = objects.
This is IMO and = implementation issue.
=A0
I agree that it = is partly an implementation issue. However, the implementation can be = optimised if the RP object fully identifies the = PathRequest.
For instance, = you would not need to decode the Error object if the PathRequest is = unknown.
=A0
=A0
Another problem = is if an implementation does not recognize a given Error type/value, = then it can=92t tell for sure which PathRequest = it
is related = to.=A0
=A0
=
Anyway an=A0Error= related to a request is always sent in the PCE-PCC = direction
=A0
=A0
I agree this is = true today but will it still be true with future PCEP = extensions.
If it is this a = strict rules I think it should be mentioned in the = draft.
However can=92t = we imagine that a PCC sends an Error message to a PCE because it does = not like the Reply sent by the = PCE?
e.g. the Path = does not respect the requested = constraints.
=A0
Besides we still = that have a problem in case of unrecognised Notification = type/value.
=A0
=A0
So it seems to = me it would be more consistent to add a bit in the RP object (in the = flag field) to indicate = the
=93direction=94 = of the PathRequest.
For instance if = the bit is set the Message that carry the RP object is related to the = request sent by the destination of the message.=A0<= u1:p>
Hence, an RP object would actually = uniquely indentifies a PathRequest.=A0<= u1:p>
=A0
=
There maybe = an=A0ambiguity=A0only=A0in a few error/notif situations, and I don't = think adding a generic bit would be really = useful.
By the way this = would be a significant change=A0wilth potentially new error situations = to handle (what do you do if=A0the direction PCC to PCE is set in a = reply message?)=A0.
=A0
I don=92t really = see it as a significant = change.
For the Error = case I think it would be ok to say that the bit must be set in PCReq and = Clear in PCRep =A0message and must be ignored upon = reception.
Besides if we = keep the RP object as is what do you do if you receive a PCNtf message = with formatted as = follows:
=A0
<RP><Notif1><Notif2> with = Notif 1 and Notif2 being =93pending request cancelled=94 but one with = Notification value 1 and the other with notification value = 2.
=A0
It seems this is = anyway an error case that must be specified with current PCEP = specification.
=A0
Is that OK with = you if we keep as is?
=A0
So basically I = agree that it is partly an implementation problem and that it is = possible to do with current = specification
But it seems to = me, from a protocol design point of view it would be more consistent if = the RP object fully identify the = PathRequest.
=A0
Best = Regards,
=A0
JL
=A0
Regards
Fabien = Verhaeghe
=
=A0
=

<= /body>= --Apple-Mail-112--844714602-- --===============1560048172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1560048172==-- From pce-bounces@lists.ietf.org Tue Sep 18 08:08:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXbro-0002GL-7I; Tue, 18 Sep 2007 08:07:48 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IXbrm-0002G6-T6 for pce-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 08:07:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXbrm-0002Fy-IC for pce@ietf.org; Tue, 18 Sep 2007 08:07:46 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXbrm-0001FJ-1c for pce@ietf.org; Tue, 18 Sep 2007 08:07:46 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1IXbrk-0007mM-Qm for pce@ietf.org; Tue, 18 Sep 2007 12:07:45 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Sep 2007 13:07:44 +0100 Message-ID: <0a5a01c7f9ec$802169e0$3901850a@your029b8cecfe> From: "Adrian Farrel" To: References: <012b01c7efa6$c25a35d0$0302a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E38001320FCC@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: [Pce] Acceptance of draft-vasseur-pce-monitoring-03.txt ? Date: Tue, 18 Sep 2007 13:07:30 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0A57_01C7F9F4.DE903E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 18 Sep 2007 12:07:44.0515 (UTC) FILETIME=[852B3D30:01C7F9EC] X-Originating-Pythagoras-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0A57_01C7F9F4.DE903E40 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, I asked: >> ... since we all expressed our opinions on the draft, JP >> has drawn our attention to the IPR claim registered at > https://datatracker.ietf.org/ipr/872/. So, before we go ahead >> and adopt the work, I just need to check that there is no >> new strong opinion against it. And no-one has expressed such an opinion, so we can go ahead. Authors, please resubmit as draft-ietf-pce-monitoring-00.txt making only the usual minimal changes. Please attach a copy of the email supplied here so that the Secretariat accept your submission. Dimitri asked: > the question is what is the object of the support that > we have seen on the list ? the need for monitoring of the > performance or the solution ? > > => both aspects are strongly inter-related. I can't really judge that since the question I originally asked was whether there was support for adopting the I-D. It seems to me that the support for the I-D indicates definite support for the need for monitoring. It seems likely that the support for the I-D suggests using this as the basis for the WG solution, but the WG is (of course) free to work on this solution and modify it as driven by consensus. Thanks, Adrian ------=_NextPart_000_0A57_01C7F9F4.DE903E40 Content-Type: message/rfc822; name="New PCE I-D.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="New PCE I-D.eml" Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Jean Philippe Vasseur'" Subject: New PCE I-D Date: Tue, 7 Aug 2007 16:07:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Hi, Please make space for draft-ietf-pce-monitoring-00.txt that will replace draft-vasseur-pce-monitoring-03.txt The authors will submit it soon. Thanks, Adrian ------=_NextPart_000_0A57_01C7F9F4.DE903E40 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0A57_01C7F9F4.DE903E40-- From pce-bounces@lists.ietf.org Tue Sep 18 13:11:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXgaR-00030b-KQ; Tue, 18 Sep 2007 13:10:11 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IXgaR-00030W-1d for pce-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 13:10:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXgaQ-00030O-O4 for pce@ietf.org; Tue, 18 Sep 2007 13:10:10 -0400 Received: from pro.abac.com ([66.226.64.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXgaK-0004Vz-FG for pce@ietf.org; Tue, 18 Sep 2007 13:10:10 -0400 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id l8IH9if6013913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 10:09:45 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <46F00655.9080803@grotto-networking.com> Date: Tue, 18 Sep 2007 10:09:41 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp , pce@ietf.org X-Spam-Score: 1.046 (HTML_10_20,HTML_MESSAGE) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Subject: [Pce] Wavelength Switched Optical Networks -- revised draft available X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0146742404==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0146742404== Content-Type: multipart/alternative; boundary="------------090308000305090504020604" This is a multi-part message in MIME format. --------------090308000305090504020604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello fellow, CCAMPers and PCEers, a revised draft on wavelength switched optical networks entitled: "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" is now available at: http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt The intention is to have this document adopted as a working group draft at either CCAMP or PCE and use it to guide the various "solution" drafts that are being generated with respect to wavelength switched optical networks. *Abstract: * This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. Regards Greg B, Young L. and Wataru I. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090308000305090504020604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello fellow, CCAMPers and PCEers,
a revised draft on wavelength switched optical networks entitled: "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" is now available at: http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt

The intention is to have this document adopted as a working group draft at either CCAMP or PCE and use it to guide the various "solution" drafts that are being generated with respect to wavelength switched optical networks.

Abstract:
This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul.

Regards

Greg B, Young L. and Wataru I.
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------090308000305090504020604-- --===============0146742404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0146742404==-- From pce-bounces@lists.ietf.org Tue Sep 18 14:14:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXhZt-0000Q5-Jr; Tue, 18 Sep 2007 14:13:41 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IXhZt-0000P3-55 for pce-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 14:13:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXhZs-0000Ov-RZ for pce@ietf.org; Tue, 18 Sep 2007 14:13:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXhZm-0005zq-AJ for pce@ietf.org; Tue, 18 Sep 2007 14:13:40 -0400 X-IronPort-AV: E=Sophos;i="4.20,269,1186383600"; d="scan'208,217";a="220422044" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2007 11:13:29 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8IIDTHe004054; Tue, 18 Sep 2007 11:13:29 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8IIDJfF015797; Tue, 18 Sep 2007 18:13:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 14:12:59 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 14:12:58 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org, Lou Berger , Igor Bryskin , Dimitri Papadimitriou , gash5107@yahoo.com Message-Id: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com> From: JP Vasseur Date: Tue, 18 Sep 2007 14:10:12 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 18 Sep 2007 18:12:58.0856 (UTC) FILETIME=[8B224E80:01C7FA1F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2468; t=1190139209; x=1191003209; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Update=20on=20draft-ietf-pce-policy-enabled-path-comp |Sender:=20; bh=A9b9tbW5eXffPtGIkBpX5tXIPyHfBNqt7Zy64/Kn3mk=; b=csFdWIr5U4rFQx8+r1ztDDbxtGSrIzG/dtCqSGfiMmSYDu/BmhsddnHVcx5eR3WixNAm4qtf RWjF8dR/0A350CGOHv54k9z0VEX/XJCRdbfdAa1VQ3cjdmEFc8CYe2uo; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Thomas Walsh , JACQUENET Christian RD-TCH-REN Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1153702165==" Errors-To: pce-bounces@lists.ietf.org --===============1153702165== Content-Type: multipart/alternative; boundary=Apple-Mail-151--769067862 --Apple-Mail-151--769067862 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, From the WG minutes of the IETF-69 meeting: 12) Update on Policy-Enabled Path Computation Framework draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110] Lou> ready for Last Call JP> It sounds ready. Suggestion: offer IPSphere to have a look at the doc before last call. JP will be the point of contact. Asked Ross whether this is a good idea, and Ross agreed. Once comments are received, last call. Adrian> OK, but this is not an indefinite consultation. We want to be able to move ahead and complete the I-D relatively soon. We have contacted IPSphere and RA WG of IPSphere should provide us some feed-back by mid-October. I have copied Tom Walsh and Christian Jacquenet (chair of the RAWG) IPSphere. Thanks. JP. --Apple-Mail-151--769067862 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII Dear WG,

=46rom the WG minutes of = the IETF-69 meeting:

12) = Update on Policy-Enabled Path Computation = Framework
draft-ietf-pce-policy-enabled-path-comp-01.txt = (Lou - 5mn) [110]

Lou> ready for = Last Call
JP> It sounds ready. Suggestion: offer = IPSphere to have a look at the doc before last call. JP will be the = point
of contact. Asked Ross whether this is a good = idea, and Ross agreed. Once comments are received, last = call.
Adrian> OK, but this is not an indefinite = consultation. We want to be able to move ahead and complete the = I-D
relatively soon.

We have contacted IPSphere = and RA WG of IPSphere should provide us some feed-back = by
mid-October. I have copied Tom Walsh and Christian = Jacquenet (chair of the RAWG) IPSphere.

Thanks.

JP.
= --Apple-Mail-151--769067862-- --===============1153702165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1153702165==-- From pce-bounces@lists.ietf.org Tue Sep 18 15:46:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXj0y-0007iH-IL; Tue, 18 Sep 2007 15:45:44 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IXj0x-0007gU-AX for pce-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 15:45:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXj0w-0007g7-UU for pce@ietf.org; Tue, 18 Sep 2007 15:45:42 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXj0v-0005US-Aa for pce@ietf.org; Tue, 18 Sep 2007 15:45:42 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8IJixm5025152; Tue, 18 Sep 2007 21:44:59 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Sep 2007 21:45:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Acceptance of draft-vasseur-pce-monitoring-03.txt ? Date: Tue, 18 Sep 2007 21:45:18 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001510646@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <0a5a01c7f9ec$802169e0$3901850a@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Acceptance of draft-vasseur-pce-monitoring-03.txt ? thread-index: Acf57OlobGB5woruQ92DIaR6Zv9jbQAPMphA References: <012b01c7efa6$c25a35d0$0302a8c0@your029b8cecfe><8144761F31F48D43AD53D09F5350E38001320FCC@FRVELSMBS22.ad2.ad.alcatel.com> <0a5a01c7f9ec$802169e0$3901850a@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , X-OriginalArrivalTime: 18 Sep 2007 19:45:40.0448 (UTC) FILETIME=[7E19E600:01C7FA2C] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org adrian, > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Tuesday, September 18, 2007 2:08 PM > To: pce@ietf.org > Subject: Re: [Pce] Acceptance of draft-vasseur-pce-monitoring-03.txt ? >=20 > Hi, >=20 > I asked: >=20 > >> ... since we all expressed our opinions on the draft, JP > >> has drawn our attention to the IPR claim registered at > > https://datatracker.ietf.org/ipr/872/. So, before we go ahead > >> and adopt the work, I just need to check that there is no > >> new strong opinion against it. >=20 > And no-one has expressed such an opinion, so we can go ahead. >=20 > Authors, please resubmit as draft-ietf-pce-monitoring-00.txt=20 > making only the=20 > usual minimal changes. > Please attach a copy of the email supplied here so that the=20 > Secretariat=20 > accept your submission. >=20 > Dimitri asked: >=20 > > the question is what is the object of the support that > > we have seen on the list ? the need for monitoring of the > > performance or the solution ? > > > > =3D> both aspects are strongly inter-related. >=20 > I can't really judge that since the question I originally=20 > asked was whether=20 > there was support for adopting the I-D. It seems to me that=20 > the support for=20 > the I-D indicates definite support for the need for=20 > monitoring. It seems=20 > likely that the support for the I-D suggests using this as=20 > the basis for the=20 > WG solution, but the WG is (of course) free to work on this=20 > solution and=20 > modify it as driven by consensus. hence the question should be rephrased as is there any other PCE monitoring technique going to remove that claim ? it is a known practice of ietf to look at alternative techniques in case a given claims is blocking open access to a protocol - and such call should be launched on the list - the Cisco claim does not provide any specific information on the technique(s) part of the claim =3D> imho the initial question should be asked when more information is made available about the claim itself - if you look at the details of it is not possible to determine whether such decision is possible at this point in time - there is a side issue here - the chair belongs to the same affiliation than the patent applicant - how comes this came so late in the process ? the fact the document becomes a working-group i-d or not does not change the base problem. -d (let's not transform the IETF as the IVTF - Internet Vendor Task Force) > Thanks, > Adrian=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 18 16:06:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXjJo-00055h-M4; Tue, 18 Sep 2007 16:05:13 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IXjJj-0004yp-QP for pce-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 16:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXjJj-0004vY-59 for pce@ietf.org; Tue, 18 Sep 2007 16:05:07 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXjJX-0000tN-Nm for pce@ietf.org; Tue, 18 Sep 2007 16:05:01 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8IK3wkX030422; Tue, 18 Sep 2007 22:03:58 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Sep 2007 22:04:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp Date: Tue, 18 Sep 2007 22:04:17 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001510648@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp thread-index: Acf6H9tr5jMnc3lfREu51HpTYsHIDwADv7qQ References: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com> From: "PAPADIMITRIOU Dimitri" To: "JP Vasseur" , , "Lou Berger" , "Igor Bryskin" , "Dimitri Papadimitriou" , , "Adrian Farrel" X-OriginalArrivalTime: 18 Sep 2007 20:04:39.0318 (UTC) FILETIME=[24EBAB60:01C7FA2F] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Thomas Walsh , JACQUENET Christian RD-TCH-REN X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org j-p simple question: why only the policy doc. ?=20 why are the other documents not liaised to IP Sphere ? or you would like to reserve a specific treatment to the policy document (the enabler of the whole stuff at the inter-domain level) ? -d.=20 > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com]=20 > Sent: Tuesday, September 18, 2007 8:10 PM > To: pce@ietf.org; Lou Berger; Igor Bryskin; Dimitri=20 > Papadimitriou; gash5107@yahoo.com > Cc: Thomas Walsh; JACQUENET Christian RD-TCH-REN > Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp >=20 > Dear WG, >=20 > From the WG minutes of the IETF-69 meeting: >=20 >=20 > 12) Update on Policy-Enabled Path Computation Framework > draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110] >=20 >=20 > Lou> ready for Last Call > JP> It sounds ready. Suggestion: offer IPSphere to have a=20 > look at the doc before last call. JP will be the point > of contact. Asked Ross whether this is a good idea, and Ross=20 > agreed. Once comments are received, last call. > Adrian> OK, but this is not an indefinite consultation. We=20 > want to be able to move ahead and complete the I-D > relatively soon. >=20 > We have contacted IPSphere and RA WG of IPSphere should=20 > provide us some feed-back by > mid-October. I have copied Tom Walsh and Christian Jacquenet=20 > (chair of the RAWG) IPSphere. >=20 > Thanks. >=20 > JP. >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 18 18:10:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXlGH-0000sO-7Q; Tue, 18 Sep 2007 18:09:41 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IXlGF-0000oO-4N for pce-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 18:09:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXlGE-0000oG-PI for pce@ietf.org; Tue, 18 Sep 2007 18:09:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXlGE-0001TG-At for pce@ietf.org; Tue, 18 Sep 2007 18:09:38 -0400 X-IronPort-AV: E=Sophos;i="4.20,270,1186383600"; d="scan'208";a="176608642" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 18 Sep 2007 15:09:35 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8IM9ZHK016673; Tue, 18 Sep 2007 15:09:35 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l8IM9CuS019997; Tue, 18 Sep 2007 22:09:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 18:09:12 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 18:09:11 -0400 In-Reply-To: <8144761F31F48D43AD53D09F5350E38001510648@FRVELSMBS22.ad2.ad.alcatel.com> References: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com> <8144761F31F48D43AD53D09F5350E38001510648@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp Date: Tue, 18 Sep 2007 18:08:29 -0400 To: PAPADIMITRIOU Dimitri X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 18 Sep 2007 22:09:11.0920 (UTC) FILETIME=[8AF03F00:01C7FA40] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2096; t=1190153375; x=1191017375; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Update=20on=20draft-ietf-pce-policy-enabled-p ath-comp |Sender:=20; bh=jp8WxPF2oa7uE/Kwtq7WvmzbMhVtdg4XhR/jY8KCpMU=; b=OpDMxrAbkaaoYcgUv6kV59S4QlVwd4J5kGrXxfiqwPefSWI0yn7w+M/0FlStjq55U0E8bJgP qB7C4pEldEwHvwDobXljXVagzaFzMdlXaHQwF+5jKUjuIowu6fAl83hx; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: JACQUENET Christian RD-TCH-REN , gash5107@yahoo.com, Thomas Walsh , pce@ietf.org, Igor Bryskin X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, On Sep 18, 2007, at 4:04 PM, PAPADIMITRIOU Dimitri wrote: > j-p > > simple question: why only the policy doc. ? > > why are the other documents not liaised to IP Sphere ? or you would > like > to reserve a specific treatment to the policy document (the enabler of > the whole stuff at the inter-domain level) ? > As discussed during the last PCE IETF meeting and as reported in the minutes, the idea was simply to see whether IPSphere might have comments/feed- backs to provide. There is no "specific treatment", the idea of seeking for comments from IPSphere on this document is motivated by the fact that they are actively working on policy. This is not a formal liaison, just a proposal for comments. Note that the goal is to not delay the progress of document by all means (thus the dead-line for comments (mid-October). Thanks. JP. > -d. > >> -----Original Message----- >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Tuesday, September 18, 2007 8:10 PM >> To: pce@ietf.org; Lou Berger; Igor Bryskin; Dimitri >> Papadimitriou; gash5107@yahoo.com >> Cc: Thomas Walsh; JACQUENET Christian RD-TCH-REN >> Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp >> >> Dear WG, >> >> From the WG minutes of the IETF-69 meeting: >> >> >> 12) Update on Policy-Enabled Path Computation Framework >> draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110] >> >> >> Lou> ready for Last Call >> JP> It sounds ready. Suggestion: offer IPSphere to have a >> look at the doc before last call. JP will be the point >> of contact. Asked Ross whether this is a good idea, and Ross >> agreed. Once comments are received, last call. >> Adrian> OK, but this is not an indefinite consultation. We >> want to be able to move ahead and complete the I-D >> relatively soon. >> >> We have contacted IPSphere and RA WG of IPSphere should >> provide us some feed-back by >> mid-October. I have copied Tom Walsh and Christian Jacquenet >> (chair of the RAWG) IPSphere. >> >> Thanks. >> >> JP. >> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 18 18:13:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXlJW-0005gU-UG; Tue, 18 Sep 2007 18:13:03 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IXlJV-0005gF-8O for pce-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 18:13:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXlJU-0005g7-TQ for pce@ietf.org; Tue, 18 Sep 2007 18:13:00 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXlJU-0001XV-7a for pce@ietf.org; Tue, 18 Sep 2007 18:13:00 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8IMCJQt020260; Wed, 19 Sep 2007 00:12:19 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Sep 2007 00:12:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp Date: Wed, 19 Sep 2007 00:12:35 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001510685@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp thread-index: Acf6QJ03n1ylkJdQR5Gsev4zLDxJfAAAEZKw References: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com> <8144761F31F48D43AD53D09F5350E38001510648@FRVELSMBS22.ad2.ad.alcatel.com> From: "PAPADIMITRIOU Dimitri" To: "JP Vasseur" X-OriginalArrivalTime: 18 Sep 2007 22:12:57.0265 (UTC) FILETIME=[11412A10:01C7FA41] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: JACQUENET Christian RD-TCH-REN , gash5107@yahoo.com, Thomas Walsh , pce@ietf.org, Igor Bryskin X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-p just wanted to know why only this document. i do not have=20 any specific objection in accommodating comments from the IP Sphere in case they are valuable of course. -d.=20 > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com]=20 > Sent: Wednesday, September 19, 2007 12:08 AM > To: PAPADIMITRIOU Dimitri > Cc: pce@ietf.org; Lou Berger; Igor Bryskin; Dimitri=20 > Papadimitriou; gash5107@yahoo.com; Adrian Farrel; Thomas=20 > Walsh; JACQUENET Christian RD-TCH-REN > Subject: Re: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp >=20 > Hi Dimitri, >=20 > On Sep 18, 2007, at 4:04 PM, PAPADIMITRIOU Dimitri wrote: >=20 > > j-p > > > > simple question: why only the policy doc. ? > > > > why are the other documents not liaised to IP Sphere ? or=20 > you would =20 > > like > > to reserve a specific treatment to the policy document (the=20 > enabler of > > the whole stuff at the inter-domain level) ? > > >=20 > As discussed during the last PCE IETF meeting and as reported in the =20 > minutes, > the idea was simply to see whether IPSphere might have comments/feed-=20 > backs > to provide. There is no "specific treatment", the idea of=20 > seeking for =20 > comments from > IPSphere on this document is motivated by the fact that they are =20 > actively working > on policy. This is not a formal liaison, just a proposal for comments. > Note that the goal is to not delay the progress of document by all =20 > means (thus the > dead-line for comments (mid-October). >=20 > Thanks. >=20 > JP. >=20 > > -d. > > > >> -----Original Message----- > >> From: JP Vasseur [mailto:jvasseur@cisco.com] > >> Sent: Tuesday, September 18, 2007 8:10 PM > >> To: pce@ietf.org; Lou Berger; Igor Bryskin; Dimitri > >> Papadimitriou; gash5107@yahoo.com > >> Cc: Thomas Walsh; JACQUENET Christian RD-TCH-REN > >> Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp > >> > >> Dear WG, > >> > >> From the WG minutes of the IETF-69 meeting: > >> > >> > >> 12) Update on Policy-Enabled Path Computation Framework > >> draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110] > >> > >> > >> Lou> ready for Last Call > >> JP> It sounds ready. Suggestion: offer IPSphere to have a > >> look at the doc before last call. JP will be the point > >> of contact. Asked Ross whether this is a good idea, and Ross > >> agreed. Once comments are received, last call. > >> Adrian> OK, but this is not an indefinite consultation. We > >> want to be able to move ahead and complete the I-D > >> relatively soon. > >> > >> We have contacted IPSphere and RA WG of IPSphere should > >> provide us some feed-back by > >> mid-October. I have copied Tom Walsh and Christian Jacquenet > >> (chair of the RAWG) IPSphere. > >> > >> Thanks. > >> > >> JP. > >> >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Sep 19 08:08:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXyLC-0003tm-Hd; Wed, 19 Sep 2007 08:07:38 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IXw8B-0005WU-O6 for pce-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 05:46:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXw8B-0005WM-7E; Wed, 19 Sep 2007 05:46:03 -0400 Received: from exprod7og60.obsmtp.com ([64.18.2.175]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXw8A-0002sx-Qa; Wed, 19 Sep 2007 05:46:03 -0400 Received: from source ([66.129.224.36]) by exprod7ob60.obsmtp.com ([64.18.6.12]) with SMTP; Wed, 19 Sep 2007 02:45:51 PDT Received: from [172.26.200.8] ([172.26.200.8]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 02:45:56 -0700 Message-ID: <46F0EFD2.7020801@juniper.net> Date: Wed, 19 Sep 2007 11:45:54 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel References: <05da01c7f64d$6e7dc780$3901850a@your029b8cecfe> In-Reply-To: <05da01c7f64d$6e7dc780$3901850a@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2007 09:45:56.0765 (UTC) FILETIME=[E0915CD0:01C7FAA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Wed, 19 Sep 2007 08:07:37 -0400 Cc: pce@ietf.org, isis-wg@ietf.org Subject: [Pce] Re: [Isis-wg] Please comment on draft-ietf-pce-disco-proto-isis-07.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org no comment - looks good to me - /hannes Adrian Farrel wrote: > Hi, > > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-07.txt > has recently been posted. The last couple of revisions addressed > comments raised by the IESG and by the IGP working group chairs, etc. > > This is a call to you for a further review of the I-D. > > We'll run with a two week deadline to 28th September. > > Many thanks, > Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Sep 21 13:15:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm6V-0000O0-Ol; Fri, 21 Sep 2007 13:15:47 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IYm6I-000070-8d for pce-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 13:15:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm6H-0008Vh-Kn; Fri, 21 Sep 2007 13:15:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYm6H-0002lv-1L; Fri, 21 Sep 2007 13:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id CE4E82AC76; Fri, 21 Sep 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IYm5m-0006q6-5z; Fri, 21 Sep 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Sep 2007 13:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-frwk-05.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-ietf-pce-inter-layer-frwk-05.txt Pages : 1 Date : 2007-9-21 A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-inter-layer-frwk-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-inter-layer-frwk-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-21124911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-inter-layer-frwk-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-frwk-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-21124911.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Fri Sep 21 14:15:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYn1u-0003Lh-VQ; Fri, 21 Sep 2007 14:15:07 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IYn1s-0003Kt-5w for pce-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 14:15:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYn1r-0003KZ-OK; Fri, 21 Sep 2007 14:15:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYn1r-0005Jd-3R; Fri, 21 Sep 2007 14:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DD8212AC6E; Fri, 21 Sep 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IYn1q-00014X-8d; Fri, 21 Sep 2007 14:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Sep 2007 14:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-monitoring-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : A set of monitoring tools for Path Computation Element based Architecture Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-monitoring-00.txt Pages : 20 Date : 2007-9-21 A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). In PCE-based environments it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential resource contention states, statistics in term of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-monitoring-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-monitoring-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-21130728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-monitoring-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-monitoring-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-21130728.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Fri Sep 21 17:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYqCi-0005FT-5o; Fri, 21 Sep 2007 17:38:28 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IYqCg-0005FH-Rm for pce-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 17:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYqCg-0005F9-IE for pce@ietf.org; Fri, 21 Sep 2007 17:38:26 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYqCa-0007wv-CB for pce@ietf.org; Fri, 21 Sep 2007 17:38:26 -0400 X-IronPort-AV: E=Sophos;i="4.20,285,1186372800"; d="scan'208";a="71755091" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Sep 2007 17:38:05 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8LLc5kI006426; Fri, 21 Sep 2007 17:38:05 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8LLbeYw003943; Fri, 21 Sep 2007 21:38:05 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 17:37:57 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 17:37:57 -0400 In-Reply-To: <07ac01c7f25d$c1b20c20$0302a8c0@your029b8cecfe> References: <014401c7e6b3$163d5080$3407a8c0@your029b8cecfe> <042201c7f151$85395300$0302a8c0@your029b8cecfe> <053201c7f17d$559dcf00$0302a8c0@your029b8cecfe> <07ac01c7f25d$c1b20c20$0302a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Question about PCEP Keepalive Date: Fri, 21 Sep 2007 17:37:15 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Sep 2007 21:37:57.0271 (UTC) FILETIME=[ACCCC270:01C7FC97] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5933; t=1190410685; x=1191274685; 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]=20Question=20about=20PCEP=20Keepalive |Sender:=20 |To:=20Adrian=20Farrel=20; bh=u68BaEqZpJUoUyOvvoUfxSn01LDEDMGIuo+rBZJ24HE=; b=FoEKhzLI9pBmrmspEBdsOZ52rYk/P7oUtvwAgYyX10l8K9nFCl5b99R0a/XIFRQMSD8jH1Lg gvaCX3H2JHImFsx/fwQH0BaU81Yoeyi9EE9CfrpaHcqA9laWOmPQngSY; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, I think that we all agree that the end result is identical since we give the opportunity for the PCEP peer to negotiate parameters during the session set up. What you're saying Adrian is that you find more natural for the PCC to "impose" to the PCE the frequency at which the PCE should send KA to the PCC for the PCC to get the failure detection time that it needs. The reason why we choose the other way around is mainly driven by the fact that we found not very natural to define a protocol where the PCC "imposes" something to the PCE because it does not know the PCE's load (number of already active PCEP sessions) and what it can afford to do in term of KA frequency. The PCE could refuse but then we're back to the negotiation mode. By contrast, with this mode, the sender who knows what it can afford to in term of KA frequency is the one that decides of the frequency. In some very rare mode, this may not be acceptable and there might be a round of negotiation during session establishment. And of course, the PCC will make use of timer to resend its request in the absence of reply within some period of time. The Keepalive is just there to detect a PCE failure when the IGP discovery is not used or when the PCE process failure does not trigger an IGP notification (used as a safeguard). On the other comment (multiplier) the same thing apply. We want for A to able to decide of the KA frequency but also the Deadtimer that B should use "If you do not hear from me after the expiration of the DeadTimer, you can declare the session down" because again A knows what it can guarantee for the DeadTimer not B and this may greatly vary depending on the platform. In other words, both modes have their own pros and cons, but I wanted to shed some light on why we chose that approach. Are we in sync ? Cheers. JP. On Sep 8, 2007, at 5:18 PM, Adrian Farrel wrote: >>> You seem to be saying that the responder to an Open can use a >>> PCErr to define how often it wants to receive a Keepalive. >>> >>> To me this is back-to-front and is likely to require additional >>> message exchanges. That is, if the PCE is configured to send >>> infrequent Keepalives (this is likely, because the default >>> should be to keep the Keepalive traffic low), the PCC must >>> reject the Open message causing an extra message exchange. >>> >>> If the Open message says how often the sender wants to receive >>> Keepalives, then there is no negotiation to be performed. >>> >>> I think this is more natural. >>> >>> Note that I think it is a Good Thing (TM) that Hellos can be uni- >>> directional and/or have very different timeouts in opposite >>> directions. >> >> Just to shed more light here ... >> You could indeed reverse the logic but this would be equivalent to >> what >> we have and in many cases it is more logical for the PCC to >> indicate the >> frequency at which it will send KA rather then requesting the PCE >> to send KA at a certain frequency (there are circumstances in >> which it is >> not desirable to proceed this way: the PCE may have a high number >> of PCEP sessions opened, may just not want to dedicate too much >> resources sending hellos because the PCC wants to, ...). Note that >> it is quite usual to proceed with that logic (OSPF, ...). And as >> we said, there is a possibility for the PCE to request different >> parameters >> during PCEP negotiation. >> >> Make sense ? > > Not sure :-( > > I think that the keepalive function is at the request of the > speaker that wants to determine whether the session is alive. This > is valuable to the PCC because it helps it select a PCE to which to > send a PCReq. It is much less valuable for a PCE, but might be used > to allow the PCE to discard dead sessions. > > So, the PCE wants to be able to say to the PCC: "Don't bother > sending me KA." Or maybe: "Only send me KA every 10 minutes". After > all, the PCE does not want to be swamped with KA messages. Thus, it > is important to give the PCE control of how often the PCC sends KA. > > JL is right that this *can* be achieved using the Open from the PCC > to propose the KA transmission frequency used by the PCC, followed > by a PCErr from the PCE to "negotiate" the KA frequency, followed > by a new Open from the PCC with the revised KA frequency. This is > functional, but excessive and not very clever! The PCC does not > care what KA frequency it uses so long as it is: > - acceptable for the PCE (that needs to receive the messages) > - not going to kill the PCC's CPU > So it is *far* more natural to allow the PCE to request the PCC's > KA transmission timer on the PCE's Open message, reserving the > PCErr for the unusual case. > > In the other direction, the same thing applies. It seems that you > want the PCE to simply announce its KA retransmission time, but > this isn't good enough. A PCC that needs to know about session > failures in a hurry will want a more rapid KA time and should be > allowed to request it up front, rather than negotiate it using an > error message. > > The comparison with OSPF is a little ambiguous. The OSPF Hello > message contains both the Hello Interval (how often the router will > retransmit Hellos) and the Router Dead Interval (how soon the > router will declare the adjacency dead if it does not receive a > Hello - or another message). A router is expected to modify is own > Hello Interval according to the received Router Dead Interval - > that is, it is expected to behave as I suggest, not as you suggest. > > Cheers, > Adrian > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Sep 24 12:11:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZqWW-0001z5-LN; Mon, 24 Sep 2007 12:11:04 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IZqWV-0001rt-Ge for pce-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 12:11:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZqWV-0001GJ-6y; Mon, 24 Sep 2007 12:11:03 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZqWF-00049i-Qk; Mon, 24 Sep 2007 12:10:55 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1IZqVp-0007im-Ga; Mon, 24 Sep 2007 16:10:21 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Sep 2007 17:10:21 +0100 Message-ID: <031301c7fec5$673e5860$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: , , Date: Mon, 24 Sep 2007 17:10:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 Sep 2007 16:10:21.0174 (UTC) FILETIME=[6817A160:01C7FEC5] X-Originating-Rutherford-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [Pce] Deployment of the Internet-Draft Submission Tool X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, Fed up with waiting one or two days for your I-D submissions to be posted? The new tool below seems to work fine. The only things to be aware of are: - It checks for nits - It requires that you include creation and expiry stamps such as Created: September 24, 2007 Expires: March 24, 2008 - If you want to fix the nits yourself, you should cancel the submission and come back later. Cheers, Adrian -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat@ietf.org] Sent: Wednesday, September 19, 2007 9:32 PM To: IETF Announcement list Cc: wgchairs@ietf.org; iesg@ietf.org Subject: Deployment of the Internet-Draft Submission Tool The IETF Secretariat is pleased to announce the deployment of the Internet-Draft Submission Tool (IDST)-Phase I. The IDST is a Web-based application that will allow an IETF participant to submit an Internet-Draft online, obtain approval to post the draft (if necessary), and make the draft immediately available to the community on the IETF Web site without the assistance of the Secretariat (in most cases). The URL for the IDST is: https://datatracker.ietf.org/idst/upload.cgi The URL for instructions for using the IDST is: http://www.ietf.org/idsubmit_instructions.html Although it will still be possible to submit your drafts by e-mail (i.e., by sending them to internet-drafts@ietf.org), the tool is available for use effective immediately, and we encourage you to submit your drafts via the tool starting today. If you have any questions about using the tool or wish to report a bug, then please send a message to idst-developers@ietf.org. Enjoy!! The IETF Secretariat _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Sep 24 16:15:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuKe-0003Tw-PP; Mon, 24 Sep 2007 16:15:04 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IZuKd-0003Tk-Bc for pce-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 16:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuKd-0003Tc-1n; Mon, 24 Sep 2007 16:15:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZuKb-00043m-U6; Mon, 24 Sep 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C07FC328D1; Mon, 24 Sep 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IZuKb-0004lP-Ln; Mon, 24 Sep 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Sep 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-isis-08.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-isis-08.txt Pages : 16 Date : 2007-9-24 There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-isis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-24154824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-isis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-24154824.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Mon Sep 24 16:35:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZud1-0004nQ-22; Mon, 24 Sep 2007 16:34:03 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IZucz-0004kc-76 for pce-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 16:34:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZucy-0004gh-Mn; Mon, 24 Sep 2007 16:34:00 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZucy-00074G-2w; Mon, 24 Sep 2007 16:34:00 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 65DF12AC81; Mon, 24 Sep 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IZuKb-0004lV-NN; Mon, 24 Sep 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Sep 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-08.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : OSPF Protocol Extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-ospf-08.txt Pages : 19 Date : 2007-9-24 There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-ospf-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-24155127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-ospf-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-24155127.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue Sep 25 04:36:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia5t8-00062n-FW; Tue, 25 Sep 2007 04:35:26 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1Ia5t7-00062h-03 for pce-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 04:35:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia5t6-00062W-MT for pce@ietf.org; Tue, 25 Sep 2007 04:35:24 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia5t6-0008Ba-BN for pce@ietf.org; Tue, 25 Sep 2007 04:35:24 -0400 Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1Ia5t5-0006HR-5x for pce@ietf.org; Tue, 25 Sep 2007 08:35:23 +0000 Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 09:35:22 +0100 Message-ID: <03b401c7ff4f$020dda30$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Tue, 25 Sep 2007 09:35:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 25 Sep 2007 08:35:22.0619 (UTC) FILETIME=[034C74B0:01C7FF4F] X-Originating-Pythagoras-IP: [88.96.235.138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Ross Callon Subject: [Pce] New versions of OSPF and IS-IS Discovery drafts X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-08.txt and http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-08.txt have been posted. These new revisions address various comments made during IESG review including comments received from the OSPF and ISIS working groups and from several ADs. Because the changes are not purely editorial we will run a further one week last call starting now and ending at 12 noon GMT on 2nd October. To see the details, I recommend using http://www1.tools.ietf.org/rfcdiff If you don't have archived copies of the previous versions, I recommend http://www.watersprings.org/ Please send your questions or issues to the list. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 25 09:01:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaA1u-0001kL-SH; Tue, 25 Sep 2007 09:00:46 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IaA1s-0001jq-Mw for pce-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 09:00:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaA1s-0001jh-64; Tue, 25 Sep 2007 09:00:44 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaA1r-0007C7-9I; Tue, 25 Sep 2007 09:00:44 -0400 X-IronPort-AV: E=Sophos;i="4.20,295,1186372800"; d="scan'208,217";a="132934483" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Sep 2007 09:00:38 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8PD0g1e017627; Tue, 25 Sep 2007 09:00:42 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8PD0UV8020510; Tue, 25 Sep 2007 13:00:42 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 09:00:31 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 09:00:29 -0400 In-Reply-To: <1189805794.46eafee2b6808@www.imp.polymtl.ca> References: <05da01c7f64d$6e7dc780$3901850a@your029b8cecfe> <1189805794.46eafee2b6808@www.imp.polymtl.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: JP Vasseur Subject: Re: [Pce] Please comment on draft-ietf-pce-disco-proto-isis-07.txt Date: Tue, 25 Sep 2007 08:59:48 -0400 To: Meral Shirazipour X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Sep 2007 13:00:30.0043 (UTC) FILETIME=[0CDCBAB0:01C7FF74] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15551; t=1190725242; x=1191589242; 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]=20Please=20comment=20on=20draft-ietf-pce-disco- proto-isis-07.txt |Sender:=20 |To:=20Meral=20Shirazipour=20; bh=rRxxM5gZ52YqwW36FlvXf1sUOA64P9E4kKlw7eqRlmE=; b=hxPO7UgEL8Yl6Cbnr3U/fCvVVKv/ygvAq1MzCHEkYPCk7llfx2qC7k7X96aNc7TPN179osWF MNs8arj+2dOyyoWtf406rALwtTXh26l8u0mRwcRxE+i8h4BfEpi+M35Z; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: isis-wg@ietf.org, Jean-Philippe Vasseur , pce@ietf.org, Acee Lindem , Abhay Roy X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1536056058==" Errors-To: pce-bounces@lists.ietf.org --===============1536056058== Content-Type: multipart/alternative; boundary=Apple-Mail-269--182892764 --Apple-Mail-269--182892764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi, Some concerns were expressed by several individuals, and OSPF WG chairs about the potential size of the PCED and more recently issues were raised during IESG review because of the dynamic nature of the CONGESTION TLV carried within the PCED TLV. So the agreement we had was to: 1) Indicate in the document that no further sub-TLV will be added in the future. Should there be a need to advertise more PCE capability, this =20= can still be part of the PCEP session establishment phase. *If* at some =20 point, there is a need to use the IGP to advertise more data, then this =20 should be done using the GENINFO TLV defined draft-ginsberg-isis-genapp potentially using a different Is-IS instance and by using a new Opaque LSA. 2) Remove the CONGESTION TLV from both documents. The updated documents (rev 08) have just been posted and account for these changes along with other comments that we received. Thanks. JP. On Sep 14, 2007, at 5:36 PM, Meral Shirazipour wrote: > Hi, > In draft draft-ietf-pce-disco-proto-isis-07 Section 4 Page 7, =20 > it is > mentioned: > =93 > No additional sub-TLVs will be added to the PCED TLV in the future. =20= > If a future > application requires advertising additional PCE information in IS-=20 > IS, this will > not be carried in the CAPABILITY TLV. > =93 > -Is there a technical reasoning behind this decision? > > -I would also change the last two words :=94 CAPABILITY TLV =93 to = =93IS-=20 > IS Router > Capability TLV ([IS-IS-CAP])=94 to avoid any confusion with the PCE-=20= > CAP-FLAGS > sub-TLV :) > > > > In draft draft-ietf-pce-disco-proto-ospf-07 Section 4 Page 7, =20 > it is > mentioned: > =93 > No additional sub-TLVs will be added to the PCED TLV in the future. =20= > If a future > application requires advertising additional PCE information in =20 > OSPF, this will > not be carried in the Router Information LSA. > =94 > -Same question here. > > > Warm Regards, > Meral > > > > > > > > Selon Adrian Farrel : > >> Hi, >> >> http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-=20 >> isis-07.txt >> has recently been posted. The last couple of revisions addressed =20 >> comments >> raised by the IESG and by the IGP working group chairs, etc. >> >> This is a call to you for a further review of the I-D. >> >> We'll run with a two week deadline to 28th September. >> >> Many thanks, >> Adrian >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-269--182892764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi,

Some concerns were expressed = by several individuals,
and OSPF WG chairs about the potential size of the PCED = and more
recently issues were raised during IESG review because of = the dynamic
nature of the CONGESTION TLV carried within the PCED = TLV.

So the agreement we had was = to:
1) = Indicate in the document that no further sub-TLV will be added in = the=A0
future. Should there be a need to advertise more PCE = capability, this can
still be part of the PCEP session establishment phase. = *If* at some point,
there is a need to use the IGP to advertise more data, = then this should be
done using the GENINFO TLV = defined=A0draft-ginsberg-isis-genapp=A0
potentially using a different = Is-IS instance and by using a new
Opaque = LSA.
2) = Remove the CONGESTION TLV from both documents.=A0

The updated documents (rev 08) = have just been posted and account for=A0
these changes along with other = comments that we received.

Thanks.

JP.
=

On Sep 14, 2007, at 5:36 PM, Meral Shirazipour = wrote:

Hi,
=A0 =A0 In draft = draft-ietf-pce-disco-proto-isis-07 Section 4 Page 7, it is
mentioned:
=93
No additional sub-TLVs will be added to the PCED TLV = in the future. If a future
application = requires advertising additional PCE information in IS-IS, this = will
not be carried in the CAPABILITY = TLV.
=93
-Is = there a technical reasoning behind this decision?

-I would = also change the last two words :=94 CAPABILITY TLV =93 to =93IS-IS = Router
Capability TLV ([IS-IS-CAP])=94 = to avoid any confusion with the PCE-CAP-FLAGS
sub-TLV :)



=A0 =A0 In draft = draft-ietf-pce-disco-proto-ospf-07 Section 4 Page 7, it is
mentioned:
=93
No additional sub-TLVs will be added to the PCED TLV = in the future. If a future
application = requires advertising additional PCE information in OSPF, this = will
not be carried in the Router = Information LSA.
=94
-Same = question here.


Warm = Regards,
Meral







Selon Adrian Farrel <adrian@olddog.co.uk>:

Hi,

has recently been posted. The = last couple of revisions addressed comments
raised = by the IESG and by the IGP working group chairs, etc.

This is = a call to you for a further review of the I-D.

We'll = run with a two week deadline to 28th September.

Many = thanks,
Adrian




Pce mailing list






Pce mailing list
=

= --Apple-Mail-269--182892764-- --===============1536056058== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1536056058==-- From pce-bounces@lists.ietf.org Tue Sep 25 10:31:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaBQK-0005oX-Vz; Tue, 25 Sep 2007 10:30:05 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IaBQI-0005dr-RB for pce-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 10:30:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaBQI-0005a1-Bi; Tue, 25 Sep 2007 10:30:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaBQH-0006v3-VO; Tue, 25 Sep 2007 10:30:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D87C526E92; Tue, 25 Sep 2007 14:30:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IaBQH-0006RC-PR; Tue, 25 Sep 2007 10:30:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 25 Sep 2007 10:30:01 -0400 X-Spam-Score: -0.5 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pce@ietf.org Subject: [Pce] I-D Action:draft-ietf-pce-tc-mib-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Definitions of Textual Conventions for Path Computation Element Author(s) : E. Stephan Filename : draft-ietf-pce-tc-mib-02.txt Pages : 8 Date : 2007-09-25 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-tc-mib-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-tc-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-tc-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-25102802.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-tc-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-tc-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-25102802.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue Sep 25 10:36:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaBVw-0006Zd-JV; Tue, 25 Sep 2007 10:35:52 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IaBOa-000125-AA for pce-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 10:28:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaBOZ-0000zV-V0 for pce@ietf.org; Tue, 25 Sep 2007 10:28:15 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaBOZ-0001AS-MG for pce@ietf.org; Tue, 25 Sep 2007 10:28:15 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 609FF175AD; Tue, 25 Sep 2007 14:28:05 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IaBOO-00049q-T5; Tue, 25 Sep 2007 10:28:04 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: emile.stephan@orange-ftgroup.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 25 Sep 2007 10:28:04 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Tue, 25 Sep 2007 10:35:50 -0400 Cc: pce@ietf.org Subject: [Pce] New Version Notification for draft-ietf-pce-tc-mib-02 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org A new version of I-D, draft-ietf-pce-tc-mib-02.txt has been successfuly submitted by Emile Stephan and posted to the IETF repository. Filename: draft-ietf-pce-tc-mib Revision: 02 Title: Definitions of Textual Conventions for Path Computation Element Creation_date: 2007-09-25 WG ID: pce Number_of_pages: 8 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. The IETF Secretariat. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 25 11:58:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCnQ-0002sb-GW; Tue, 25 Sep 2007 11:58:00 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IaCG9-00013H-Jm for pce-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 11:23:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCG9-00011w-7i; Tue, 25 Sep 2007 11:23:37 -0400 Received: from exprod7og52.obsmtp.com ([64.18.2.159]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaCG4-0002ZH-Jh; Tue, 25 Sep 2007 11:23:33 -0400 Received: from source ([66.129.224.36]) by exprod7ob52.obsmtp.com ([64.18.6.12]) with SMTP; Tue, 25 Sep 2007 08:23:18 PDT Received: from [172.26.200.79] ([172.26.200.79]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 08:23:18 -0700 Message-ID: <46F927E2.3030301@juniper.net> Date: Tue, 25 Sep 2007 17:23:14 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Isis-wg] Re: [Pce] Please comment on draft-ietf-pce-disco-proto-isis-07.txt References: <05da01c7f64d$6e7dc780$3901850a@your029b8cecfe> <1189805794.46eafee2b6808@www.imp.polymtl.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Sep 2007 15:23:18.0458 (UTC) FILETIME=[000919A0:01C7FF88] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-Mailman-Approved-At: Tue, 25 Sep 2007 11:57:59 -0400 Cc: isis-wg@ietf.org, Jean-Philippe Vasseur , pce@ietf.org, Acee Lindem , Abhay Roy X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi jp, agreed as far as pce is concerned, one comment on the *If* section - i do not think that replacing a bloated TLV with another bloated TLV [genapp] will buy us anything. i.e. the size is not getting smaller ;-) [genapp] is primarily a vehicle for not running out of TLV codepoints for 'per-application' use. Given that the pced TLV is well structured and has a proper support for TLV nesting there is no need to use [genapp]. so at best a "may" is appropriate, certainly no "should". /hannes JP Vasseur wrote: > Hi, > > Some concerns were expressed by several individuals, > and OSPF WG chairs about the potential size of the PCED and more > recently issues were raised during IESG review because of the dynamic > nature of the CONGESTION TLV carried within the PCED TLV. > > So the agreement we had was to: > 1) Indicate in the document that no further sub-TLV will be added in the > future. Should there be a need to advertise more PCE capability, this can > still be part of the PCEP session establishment phase. *If* at some point, > there is a need to use the IGP to advertise more data, then this should be > done using the GENINFO TLV defined draft-ginsberg-isis-genapp > potentially using a different Is-IS instance and by using a new > Opaque LSA. > 2) Remove the CONGESTION TLV from both documents. > > The updated documents (rev 08) have just been posted and account for > these changes along with other comments that we received. > > Thanks. > > JP. > > On Sep 14, 2007, at 5:36 PM, Meral Shirazipour wrote: > >> Hi, >> In draft draft-ietf-pce-disco-proto-isis-07 Section 4 Page 7, it is >> mentioned: >> “ >> No additional sub-TLVs will be added to the PCED TLV in the future. If >> a future >> application requires advertising additional PCE information in IS-IS, >> this will >> not be carried in the CAPABILITY TLV. >> “ >> -Is there a technical reasoning behind this decision? >> >> -I would also change the last two words :” CAPABILITY TLV “ to “IS-IS >> Router >> Capability TLV ([IS-IS-CAP])” to avoid any confusion with the >> PCE-CAP-FLAGS >> sub-TLV :) >> >> >> >> In draft draft-ietf-pce-disco-proto-ospf-07 Section 4 Page 7, it is >> mentioned: >> “ >> No additional sub-TLVs will be added to the PCED TLV in the future. If >> a future >> application requires advertising additional PCE information in OSPF, >> this will >> not be carried in the Router Information LSA. >> ” >> -Same question here. >> >> >> Warm Regards, >> Meral >> >> >> >> >> >> >> >> Selon Adrian Farrel >: >> >>> Hi, >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-07.txt >>> has recently been posted. The last couple of revisions addressed comments >>> raised by the IESG and by the IGP working group chairs, etc. >>> >>> This is a call to you for a further review of the I-D. >>> >>> We'll run with a two week deadline to 28th September. >>> >>> Many thanks, >>> Adrian >>> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> >> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Sep 26 19:43:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagVq-00037v-G1; Wed, 26 Sep 2007 19:41:50 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IagVp-00037j-Dz for pce-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 19:41:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagVp-00031V-37 for pce@ietf.org; Wed, 26 Sep 2007 19:41:49 -0400 Received: from pro.abac.com ([66.226.64.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IagVj-0003Pe-CH for pce@ietf.org; Wed, 26 Sep 2007 19:41:43 -0400 Received: from [10.71.1.179] (72-255-26-41.client.stsn.net [72.255.26.41]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id l8QNfXB9024313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2007 16:41:37 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <46FAEE2C.5040008@grotto-networking.com> Date: Wed, 26 Sep 2007 16:41:32 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp , pce@ietf.org X-Spam-Score: 0.101 (HTML_MESSAGE) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Subject: [Pce] Some key issues with Wavelength Switched Optical Networks... X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1836027655==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1836027655== Content-Type: multipart/alternative; boundary="------------090500030104070206070906" This is a multi-part message in MIME format. --------------090500030104070206070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up. (a) The draft brings up models for the following WDM network elements: 1. WDM links 2. Optical transmitters 3. Wavelength Converters and OEO regenerators 4. ROADMs, FOADMs, optical splitters and combiners. For items (3) and (4) we are taking the modeling lead rather than some other SDO. And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS). (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols: 1. A single PCE computing both the path and wavelength 2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment 3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects) Do we really need all three models? (c) G.709 includes the Optical Multiplex Section and Optical Channels. RFC4238 was aimed at GMPLS extensions for G.709 (Optical Transport Network) control. Weren't we finished with all this optical stuff years ago? I'd like to think the draft answers some of these questions. I also think that network element models and the process models are important enough to warrant this separate framework document. Your opinions are solicited. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090500030104070206070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.

(a) The draft brings up models for the following WDM network elements:
  1. WDM links
  2. Optical transmitters
  3. Wavelength Converters and OEO regenerators
  4. ROADMs, FOADMs, optical splitters and combiners.
    For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).

(b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:
  1. A single PCE computing both the path and wavelength
  2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment
  3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects)
    Do we really need all three models?

(c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?

I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.

Regards

Greg B.
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------090500030104070206070906-- --===============1836027655== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1836027655==-- From pce-bounces@lists.ietf.org Thu Sep 27 16:01:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazWO-0007Hi-CD; Thu, 27 Sep 2007 15:59:40 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IazWN-0007HO-Nu for pce-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 15:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazWN-0007H7-Ci for pce@ietf.org; Thu, 27 Sep 2007 15:59:39 -0400 Received: from mail.advaoptical.de ([213.70.90.131] helo=mail.advaoptical.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IazWG-0000yJ-QG for pce@ietf.org; Thu, 27 Sep 2007 15:59:39 -0400 Received: from muc-srv-mimesweeper.advaoptical.com (10.200.0.15) by mail.advaoptical.com (10.200.0.20) with Microsoft SMTP Server id 8.0.685.24; Thu, 27 Sep 2007 21:59:40 +0200 Received: from muc-srv-mail.advaoptical.com (unverified) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 27 Sep 2007 22:00:08 +0200 Received: from atl-srv-mail.atl.advaoptical.com ([172.16.5.25]) by muc-srv-mail.advaoptical.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 21:59:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Some key issues with Wavelength Switched Optical Networks... Date: Thu, 27 Sep 2007 15:59:18 -0400 Message-ID: In-Reply-To: <46FAEE2C.5040008@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Some key issues with Wavelength Switched Optical Networks... Thread-Index: AcgAl4iRkuu0/qLYRTyGkiYsAOg/5QApn0XA References: <46FAEE2C.5040008@grotto-networking.com> From: Igor Bryskin To: "Greg Bernstein" , "ccamp" , X-OriginalArrivalTime: 27 Sep 2007 19:59:22.0044 (UTC) FILETIME=[E5873FC0:01C80140] X-Spam-Score: 0.0 (/) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0795690140==" Errors-To: pce-bounces@lists.ietf.org --===============0795690140== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80140.E42E4336" ------_=_NextPart_001_01C80140.E42E4336 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, =20 I believe the draft is very useful. =20 I have a couple of questions comments: =20 1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network=20 Optimization =20 How the problem of grooming of higher layer network traffic over optical trails is any different from the problem of traffic grooming in TDM (e.g. VC12 over VC4)? I mean this is a general problem of inter-layer relationship. I suggest moving all higher layer network considerations out of scope of the draft and focusing on specifics of the OCh layer. =20 2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft. =20 Cheers, Igor =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Wednesday, September 26, 2007 7:42 PM To: ccamp; pce@ietf.org Subject: [Pce] Some key issues with Wavelength Switched Optical Networks... =20 Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.=20 (a) The draft brings up models for the following WDM network elements: 1. WDM links 2. Optical transmitters 3. Wavelength Converters and OEO regenerators 4. ROADMs, FOADMs, optical splitters and combiners. For items (3) and (4) we are taking the modeling lead rather than some other SDO. And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS). (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols: 1. A single PCE computing both the path and wavelength 2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment 3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects) Do we really need all three models? (c) G.709 includes the Optical Multiplex Section and Optical Channels. RFC4238 was aimed at GMPLS extensions for G.709 (Optical Transport Network) control. Weren't we finished with all this optical stuff years ago? I'd like to think the draft answers some of these questions. I also think that network element models and the process models are important enough to warrant this separate framework document. Your opinions are solicited. Regards Greg B. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =20 ------_=_NextPart_001_01C80140.E42E4336 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg,

 

I believe the draft is very = useful.

 

I have a couple of questions = comments:

 

1. Section : 4.4. Traffic Grooming: Combining WSON and =
Higher Layer Network

   Optimization

 

How the problem of grooming of = higher layer network traffic over optical trails is any different from the = problem of traffic grooming in TDM (e.g. VC12 over VC4)? I mean this is a general = problem of inter-layer relationship. I suggest moving all higher layer network considerations out of scope of the draft and focusing on specifics of = the OCh layer.

 

2. Considering wavelength = conversion inevitably brings to the problem of looped paths, which is a completely new ball = game in path computation, and I am surprised that the issue was never mentioned = in the draft.

 

Cheers,

=

Igor

 

From: Greg Bernstein [mailto:gregb@grotto-networking.com] =
Sent: Wednesday, = September 26, 2007 7:42 PM
To: ccamp; = pce@ietf.org
Subject: [Pce] Some key = issues with Wavelength Switched Optical Networks...

 

Hi folks, I haven't seen too many comments on = our draft "Framework for GMPLS and PCE Control of Wavelength Switched = Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that = the draft brings up.

(a) The draft brings up models for the following WDM network = elements:

  1. WDM links
  2. Optical = transmitters
  3. Wavelength Converters and OEO = regenerators
  4. ROADMs, FOADMs, optical splitters and = combiners.

    For items (3) and (4) we = are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model = (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, = MPLS).

(b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE = protocols:

  1. A single PCE computing both the path and wavelength
  2. Two distinct PCEs, where one computes = the path, and a different PCE computes the wavelength = assignment
  3. A PCE computes the path and wavelength = assignment is accomplished in a distributed fashion via signaling (e.g., using = label set objects)

    Do we really need all = three models?

(c) G.709 includes the Optical Multiplex Section and Optical = Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff = years ago?

I'd like to think the draft answers some of these questions.  I = also think that network element models and the process models are important enough = to warrant this separate framework document.  Your opinions are = solicited.

Regards

Greg B.

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) =
573-2237
 
------_=_NextPart_001_01C80140.E42E4336-- --===============0795690140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0795690140==-- From pce-bounces@lists.ietf.org Thu Sep 27 18:37:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib1xF-0002GM-92; Thu, 27 Sep 2007 18:35:33 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1Ib1xE-0002G6-0U for pce-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 18:35:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib1xD-0002Fy-KF for pce@ietf.org; Thu, 27 Sep 2007 18:35:31 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib1xC-0000Zb-AY for pce@ietf.org; Thu, 27 Sep 2007 18:35:31 -0400 X-IronPort-AV: E=Sophos;i="4.21,205,1188770400"; d="scan'208,217";a="154359577" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Sep 2007 00:35:28 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8RMZRPh023440; Fri, 28 Sep 2007 00:35:27 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8RMZRWo018762; Thu, 27 Sep 2007 22:35:27 GMT Received: from xmb-ams-338.cisco.com ([144.254.231.83]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 00:35:27 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Pce] Some key issues with Wavelength Switched Optical Networks... Date: Fri, 28 Sep 2007 00:36:52 +0200 Message-ID: <1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisco.com> In-Reply-To: <46FAEE2C.5040008@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Some key issues with Wavelength Switched Optical Networks... Thread-Index: AcgAl5KnD0dbOEQxQX+EILfgiGPP2AAvoJ3A From: "Giovanni Martinelli (giomarti)" To: "Greg Bernstein" , "ccamp" , X-OriginalArrivalTime: 27 Sep 2007 22:35:27.0093 (UTC) FILETIME=[B3885250:01C80156] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12905; t=1190932527; x=1191796527; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20=22Giovanni=20Martinelli=20(giomarti)=22=20 |Subject:=20RE=3A=20[Pce]=20Some=20key=20issues=20with=20Wavelength=20Swi tched=20Optical=20Networks... |Sender:=20; bh=DVSVM/lyQYCVwvpXDNQvzMD7PDXvhPJ3F+kbzoEhFv8=; b=RiTZRfNKJeM8Wya4YGaAZCDzSqMsjswHoSEQlpz1f8IuKENELSo5qMGQKS00VwQaWic6Nwzu wevg9lvRVaR1WCJJcnIMVz4I2GzPNQmCmztuSrhvJHlbl4IxH1A4WfK7; Authentication-Results: ams-dkim-1; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0212693719==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0212693719== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80156.B32B3353" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80156.B32B3353 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, =20 Sorry for the delay in replying. I'm working on this topic since a while = so yes, it's interesting. Before going on specific issue I would have = some question/clarification regarding the draft itself.=20 =20 =20 * Within Abstract and the following. You don't talk about Optical Cross Connects (OXC) is something missing = or understated somewhere? =20 =20 * Section 3.1 where you state:=20 "A fixed mapping between the=20 GMPLS label space and these ITU-T WDM grids as proposed in [Otani] " Does it implies a sort of network level label space? How relate with = usual local label significance? =20 =20 * Section 3.4 Wavelength Converters=20 "Current or envisioned contexts for wavelength converters are : ..." Could we think to a description/model for wavelength converter that is = technology agnostic? Simply something like: full conversion capability, = partial conversion capability with some constrains, and may be others. =20 =20 * Section 3.4. the following:=20 "4. Wavelength converters that are O-E-O based will have a restriction=20 based on the modulation format and transmission speed"=20 Not clear to me the type of restriction here when OEO happens... = probably I'm missing what you mean here. =20 =20 * Section 4.1 when you talk about Lightpath temporal characteristics: "Lightpath connection duration has typically been thought of as=20 approximately three time frames: "=20 and the following you define: dynamics, pseudo-static, static. Why there's a need of this classification? When you us Short/long is = compared to what? =20 =20 minor typo on your mail below: point (c) rfc4328 (not 4238) right? =20 Thanks, Giovanni =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: gioved=EC 27 settembre 2007 1.42 To: ccamp; pce@ietf.org Subject: [Pce] Some key issues with Wavelength Switched Optical = Networks... =09 =09 Hi folks, I haven't seen too many comments on our draft "Framework for = GMPLS and PCE Control of Wavelength Switched Optical Networks" ( = http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit= ched-01.txt). So I figured I'd point out some potentially controversial = issues that the draft brings up.=20 =09 (a) The draft brings up models for the following WDM network elements: =09 1. WDM links=20 2. Optical transmitters =09 3. Wavelength Converters and OEO regenerators=20 4. ROADMs, FOADMs, optical splitters and combiners.=20 For items (3) and (4) we are taking the modeling lead rather than = some other SDO. And for ROADMs, in particular, we going beyond the = classic ITU-T "fabric" model (M.3100) which has been the mainstay of any = connection oriented switch (TDM, ATM, MPLS). =09 (b) The draft brings up three (not one, not two, but three) different = computational models for RWA which can impact GMPLS and PCE protocols: =09 1. A single PCE computing both the path and wavelength=20 2. Two distinct PCEs, where one computes the path, and a different PCE = computes the wavelength assignment=20 3. A PCE computes the path and wavelength assignment is accomplished in = a distributed fashion via signaling (e.g., using label set objects)=20 Do we really need all three models? =09 (c) G.709 includes the Optical Multiplex Section and Optical Channels. = RFC4238 was aimed at GMPLS extensions for G.709 (Optical Transport = Network) control. Weren't we finished with all this optical stuff years = ago? =09 I'd like to think the draft answers some of these questions. I also = think that network element models and the process models are important = enough to warrant this separate framework document. Your opinions are = solicited. =09 Regards =09 Greg B. =09 --=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 ------_=_NextPart_001_01C80156.B32B3353 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi = Greg,
 
Sorry for the=20 delay in replying. I'm working on this topic since a while so yes, it's=20 interesting. Before going on specific issue I would have some=20 question/clarification regarding the draft itself.
 
 
* Within = Abstract and=20 the following.
You = don't talk about=20 Optical Cross Connects (OXC) is something missing or understated=20 somewhere?
 
 
* = Section 3.1=20 where you state:
"A = fixed mapping=20 between the
GMPLS = label space and=20 these ITU-T WDM grids as proposed in [Otani] "
Does it = implies a sort=20 of network level label space? How relate with usual local label=20 significance?
 
 
* = Section 3.4=20 Wavelength Converters
"Current = or envisioned=20 contexts for wavelength converters are : ..."
Could = we think to a description/model for = wavelength=20 converter that is technology agnostic? Simply=20 something like: full conversion capability, partial conversion = capability=20 with some constrains, and may be others.
 
 
* = Section 3.4. the=20 following:
"4. Wavelength=20 converters that are O-E-O based will have a restriction =
based on the=20 modulation format and transmission speed"
Not = clear to me the type=20 of restriction here when OEO happens... probably I'm missing what you = mean=20 here.
 
 
* = Section 4.1 when you=20 talk about Lightpath temporal characteristics:
"Lightpath=20 connection duration has typically been thought of as =
approximately=20 three time frames: "
and the = following you=20 define: dynamics, pseudo-static, static.
Why = there=92s a need of=20 this classification? When you us Short/long is compared to = what?
 
 
minor typo on your mail below: point (c) rfc4328 (not 4238)=20 right?
 
Thanks,
Giovanni


 

From: Greg Bernstein=20 [mailto:gregb@grotto-networking.com]
Sent: gioved=EC 27 = settembre=20 2007 1.42
To: ccamp; pce@ietf.org
Subject: [Pce] = Some key=20 issues with Wavelength Switched Optical = Networks...

Hi folks, I haven't seen too many comments on our draft = "Framework=20 for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( = http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-01.txt).=20 So I figured I'd point out some potentially controversial issues that = the=20 draft brings up.

(a) The draft brings up models for the = following WDM=20 network elements:
  1. WDM links=20
  2. Optical transmitters
  3. Wavelength Converters and OEO regenerators=20
  4. ROADMs, FOADMs, optical splitters and combiners.=20
    For items (3) and (4) we are taking the = modeling=20 lead rather than some other SDO.  And for ROADMs, in particular, = we going=20 beyond the classic ITU-T "fabric" model (M.3100) which has been the = mainstay=20 of any connection oriented switch (TDM, ATM, MPLS).

(b) The = draft=20 brings up three (not one, not two, but three) different computational = models=20 for RWA which can impact GMPLS and PCE protocols:
  1. A single PCE computing both the path and wavelength=20
  2. Two distinct PCEs, where one computes the path, and a different = PCE=20 computes the wavelength assignment=20
  3. A PCE computes the path and wavelength assignment is = accomplished in a=20 distributed fashion via signaling (e.g., using label set objects)=20
    Do we really need all three = models?

(c)=20 G.709 includes the Optical Multiplex Section and Optical = Channels. =20 RFC4238 was aimed at GMPLS extensions for G.709  (Optical = Transport=20 Network) control.  Weren't we finished with all this optical = stuff years=20 ago?

I'd like to think the draft answers some of these = questions. =20 I also think that network element models and the process models are = important=20 enough to warrant this separate framework document.  Your = opinions are=20 solicited.

Regards

Greg B.
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
------_=_NextPart_001_01C80156.B32B3353-- --===============0212693719== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0212693719==-- From pce-bounces@lists.ietf.org Fri Sep 28 15:11:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLF9-0001ZK-BO; Fri, 28 Sep 2007 15:11:19 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IbLF7-0001KP-An for pce-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 15:11:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLF6-0000ry-Ua for pce@ietf.org; Fri, 28 Sep 2007 15:11:17 -0400 Received: from pro.abac.com ([66.226.64.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbLF3-00014b-IP for pce@ietf.org; Fri, 28 Sep 2007 15:11:14 -0400 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id l8SJAoPg037228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 12:10:54 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <46FD51B9.9060909@grotto-networking.com> Date: Fri, 28 Sep 2007 12:10:49 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Igor Bryskin Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... References: <46FAEE2C.5040008@grotto-networking.com> In-Reply-To: X-Spam-Score: 1.611 (HTML_MESSAGE,RCVD_IN_PBL,RDNS_DYNAMIC,URIBL_RHS_DOB) X-Spam-Score: 0.0 (/) X-Scan-Signature: 563af5038a5e1dade28c8affc0fff375 Cc: ccamp , pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0468617018==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0468617018== Content-Type: multipart/alternative; boundary="------------090301070903080006080809" This is a multi-part message in MIME format. --------------090301070903080006080809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Igor, see comments below. Igor Bryskin wrote: > > Greg, > > > > I believe the draft is very useful. > --> Thanks! > > > > I have a couple of questions comments: > > > > 1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network > > Optimization > > > > How the problem of grooming of higher layer network traffic over > optical trails is any different from the problem of traffic grooming > in TDM (e.g. VC12 over VC4)? I mean this is a general problem of > inter-layer relationship. I suggest moving all higher layer network > considerations out of scope of the draft and focusing on specifics of > the OCh layer. > --> Some of my co-authors agree with you on moving this section out. The reason that I put it in was that the optical "Traffic Grooming" problem has received a fair amount of attention in the research and general technical literature and is also a driver for the use of ROADMs (optical bypass). I guess in general we've got the following inter-related problems: (a) virtual network topology design, (b) lower layer connection routing, (c) higher layer flow routing. In our case (b) is the RWA problem, which is fairly difficult in its own right. I guess I should look closely at the MLN/MRN work and see if a specific example that includes RWA is mentioned. If so then I'd feel fine removing this section from the document. > > > > 2. Considering wavelength conversion inevitably brings to the problem > of looped paths, which is a completely new ball game in path > computation, and I am surprised that the issue was never mentioned in > the draft. > --> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode? Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows. Was there some general looping concerns already published for GMPLS with respect to circuits? > > > > Cheers, > > Igor > > > > ------------------------------------------------------------------------ > > *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] > *Sent:* Wednesday, September 26, 2007 7:42 PM > *To:* ccamp; pce@ietf.org > *Subject:* [Pce] Some key issues with Wavelength Switched Optical > Networks... > > > > Hi folks, I haven't seen too many comments on our draft "Framework for > GMPLS and PCE Control of Wavelength Switched Optical Networks" ( > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). > So I figured I'd point out some potentially controversial issues that > the draft brings up. > > (a) The draft brings up models for the following WDM network elements: > > 1. WDM links > 2. Optical transmitters > 3. Wavelength Converters and OEO regenerators > 4. ROADMs, FOADMs, optical splitters and combiners. > > For items (3) and (4) we are taking the modeling lead rather than > some other SDO. And for ROADMs, in particular, we going beyond the > classic ITU-T "fabric" model (M.3100) which has been the mainstay of > any connection oriented switch (TDM, ATM, MPLS). > > (b) The draft brings up three (not one, not two, but three) different > computational models for RWA which can impact GMPLS and PCE protocols: > > 1. A single PCE computing both the path and wavelength > 2. Two distinct PCEs, where one computes the path, and a different > PCE computes the wavelength assignment > 3. A PCE computes the path and wavelength assignment is > accomplished in a distributed fashion via signaling (e.g., using > label set objects) > > Do we really need all three models? > > (c) G.709 includes the Optical Multiplex Section and Optical > Channels. RFC4238 was aimed at GMPLS extensions for G.709 (Optical > Transport Network) control. Weren't we finished with all this optical > stuff years ago? > > I'd like to think the draft answers some of these questions. I also > think that network element models and the process models are important > enough to warrant this separate framework document. Your opinions are > solicited. > > Regards > > Greg B. > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090301070903080006080809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Igor, see comments below.

Igor Bryskin wrote:

Greg,

 

I believe the draft is very useful.

--> Thanks!

 

I have a couple of questions comments:

 

1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network

   Optimization

 

How the problem of grooming of higher layer network traffic over optical trails is any different from the problem of traffic grooming in TDM (e.g. VC12 over VC4)? I mean this is a general problem of inter-layer relationship. I suggest moving all higher layer network considerations out of scope of the draft and focusing on specifics of the OCh layer.

--> Some of my co-authors agree with you on moving this section out.  The reason that I put it in was that the optical "Traffic Grooming" problem has received a fair amount of attention in the research and general technical literature and is also a driver for the use of ROADMs (optical bypass).  I guess in general we've got the following inter-related problems: (a) virtual network topology design, (b) lower layer connection routing, (c) higher layer flow routing. In our case (b) is the RWA problem, which is fairly difficult in its own right. I guess I should look closely at the MLN/MRN work and see if a specific example that includes RWA is mentioned.  If so then I'd feel fine removing this section from the document.

 

2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft.

--> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode?  Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows.  Was there some general looping concerns already published for GMPLS with respect to circuits? 

 

Cheers,

Igor

 

From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Wednesday, September 26, 2007 7:42 PM
To: ccamp; pce@ietf.org
Subject: [Pce] Some key issues with Wavelength Switched Optical Networks...

 

Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.

(a) The draft brings up models for the following WDM network elements:

  1. WDM links
  2. Optical transmitters
  3. Wavelength Converters and OEO regenerators
  4. ROADMs, FOADMs, optical splitters and combiners.

    For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).

(b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:

  1. A single PCE computing both the path and wavelength
  2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment
  3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects)

    Do we really need all three models?

(c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?

I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.

Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------090301070903080006080809-- --===============0468617018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0468617018==-- From pce-bounces@lists.ietf.org Fri Sep 28 15:47:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLnm-0005sM-6K; Fri, 28 Sep 2007 15:47:06 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IbLnl-0005sH-Jn for pce-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 15:47:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLnl-0005s8-9P for pce@ietf.org; Fri, 28 Sep 2007 15:47:05 -0400 Received: from pro.abac.com ([66.226.64.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbLne-00035R-JQ for pce@ietf.org; Fri, 28 Sep 2007 15:47:05 -0400 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id l8SJkWZm061808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 12:46:35 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <46FD5A18.2080505@grotto-networking.com> Date: Fri, 28 Sep 2007 12:46:32 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Giovanni Martinelli (giomarti)" Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... References: <1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisco.com> In-Reply-To: <1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisco.com> X-Spam-Score: 1.611 (HTML_MESSAGE,RCVD_IN_PBL,RDNS_DYNAMIC,URIBL_RHS_DOB) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2f46977da373544777a750d5247d6ccc Cc: ccamp , pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2087866122==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2087866122== Content-Type: multipart/alternative; boundary="------------030001070104060803010707" This is a multi-part message in MIME format. --------------030001070104060803010707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by pro.abac.com id l8SJkWZm061808 Hi Giovanni, thanks for the close read. Looks like you caught some=20 problems with the text. See below for comments. Giovanni Martinelli (giomarti) wrote: > Hi Greg, > =20 > Sorry for the delay in replying. I'm working on this topic since a=20 > while so yes, it's interesting. Before going on specific issue I would=20 > have some question/clarification regarding the draft itself. > =20 > =20 > * Within Abstract and the following. > You don't talk about Optical Cross Connects (OXC) is something missing=20 > or understated somewhere? -->Whoops. We were trying to find a more general term to include both=20 ROADM (usually a highly asymmetric fabric) and an OXC (a completely=20 symmetric fabric, e.g., any ingress to any egress), but we seemed to=20 have gone with using the ROADM terminology to include both cases. =20 Talked with some equipment makers that planned/make "switches" that=20 seemed to incorporate both so we made sure the model could deal with=20 both sparse and dense potential connectivity. Diego had some terminology=20 ideas but lately his e-mails have been bouncing back to me. Any=20 suggestions are appreciated, but we are including both ROADM and OXCs. > =20 > =20 > * Section 3.1 where you state: > "A fixed mapping between the > GMPLS label space and these ITU-T WDM grids as proposed in [Otani] " > Does it implies a sort of network level label space? How relate with=20 > usual local label significance? --> This mapping gives a mapping between labels and wavelengths/lambda,=20 just like in the SONET/SDH case we mapped the ITU-T G.707 "S, U, K, L, M=20 " identification of SDH time slots to a label format in RFC4606 and=20 again this was done in RFC4328 to map G.709 digital wrapper time slot=20 identification into a technology specific label format. In RFC3471 for=20 lambda switching we just get a 32 bit integer with no meaning attached.=20 Every network and every node could potentially map labels to lambdas in=20 a different way. In [Otani] they are following the RFC4606 and RFC4328=20 lead and using the ITU-T DWDM and CWDM lambda grid standards to give a=20 fixed association between labels and lambdas just like between labels=20 and TDM time slots in the SDH/ODU case. This doesn't change the local significance of labels. In the wavelength=20 switched optical case that is influenced by the presence or absence of=20 wavelength converters. > =20 > =20 > * Section 3.4 Wavelength Converters > "Current or envisioned contexts for wavelength converters are : ..." > Could we think to a description/model for wavelength converter that is=20 > technology agnostic? Simply something like: full conversion=20 > capability, partial conversion capability with some constrains, and=20 > may be others. --> The difference, between the all optical techniques and the OEO based=20 techniques makes that difficult. > =20 > =20 > * Section 3.4. the following: > "4. Wavelength converters that are O-E-O based will have a restriction > based on the modulation format and transmission speed" > Not clear to me the type of restriction here when OEO happens...=20 > probably I'm missing what you mean here. --> For example a typical O-E-O based wavelength converter would be=20 build around a 3R regenerator with a tunable laser. A 3R regenerator=20 cares about the modulation type say NRZ or RZ (and which flavor), and=20 the symbol rate since its also doing retiming. An all optical wavelength=20 converter will be fairly independent of these issues (except when we=20 look at impairment factors). Hence the OEO wavelength is going to be=20 more signal specific than the all optical. > =20 > =20 > * Section 4.1 when you talk about Lightpath temporal characteristics: > "Lightpath connection duration has typically been thought of as > approximately three time frames: " > and the following you define: dynamics, pseudo-static, static. > Why there's a need of this classification? When you us Short/long is=20 > compared to what? --> In most of the research literature and in optimization practice=20 different techniques are typically used in the dynamic versus static (or=20 psuedo static cases). In MPLS there is minimum interference routing=20 optimization techniques for the dynamic case. For the static case I=20 could apply multi-commodity flow optimization techniques to a batch of=20 connections. In the RWA literature there is a similar differentiation. =20 Exactly what information could be sent to help PCE differentiate I'm not=20 sure. In the case of static, batch optimization we can just use the=20 existing concurrent optimization hooks in PCE. For an individual=20 lightpath request it seemed that it would be helpful to know how long=20 the connection would last so we'd know how much computational effort we=20 might want to put into optimize it. > =20 > =20 > minor typo on your mail below: point (c) rfc4328 (not 4238) right? --> Yes. The G.709 signaling extensions RFC. > =20 > Thanks, > Giovanni > > > =20 > > -------------------------------------------------------------------= ----- > *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] > *Sent:* gioved=EC 27 settembre 2007 1.42 > *To:* ccamp; pce@ietf.org > *Subject:* [Pce] Some key issues with Wavelength Switched Optical > Networks... > > Hi folks, I haven't seen too many comments on our draft "Framework > for GMPLS and PCE Control of Wavelength Switched Optical Networks" > ( > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelengt= h-switched-01.txt). > So I figured I'd point out some potentially controversial issues > that the draft brings up. > > (a) The draft brings up models for the following WDM network elemen= ts: > > 1. WDM links > 2. Optical transmitters > 3. Wavelength Converters and OEO regenerators > 4. ROADMs, FOADMs, optical splitters and combiners. > > For items (3) and (4) we are taking the modeling lead rather > than some other SDO. And for ROADMs, in particular, we going > beyond the classic ITU-T "fabric" model (M.3100) which has been > the mainstay of any connection oriented switch (TDM, ATM, MPLS). > > (b) The draft brings up three (not one, not two, but three) > different computational models for RWA which can impact GMPLS and > PCE protocols: > > 1. A single PCE computing both the path and wavelength > 2. Two distinct PCEs, where one computes the path, and a > different PCE computes the wavelength assignment > 3. A PCE computes the path and wavelength assignment is > accomplished in a distributed fashion via signaling (e.g., > using label set objects) > > Do we really need all three models? > > (c) G.709 includes the Optical Multiplex Section and Optical > Channels. RFC4238 was aimed at GMPLS extensions for G.709=20 > (Optical Transport Network) control. Weren't we finished with all > this optical stuff years ago? > > I'd like to think the draft answers some of these questions. I > also think that network element models and the process models are > important enough to warrant this separate framework document.=20 > Your opinions are solicited. > > Regards > > Greg B. > > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > =20 > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------030001070104060803010707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Giovanni, thanks for the close read.  Looks like you caught some problems with the text.  See below for comments.

Giovanni Martinelli (giomarti) wrote:
Hi Greg,
 
Sorry for the delay in replying. I'm working on this topic since a while so yes, it's interesting. Before going on specific issue I would have some question/clarification regarding the draft itself.
 
 
* Within Abstract and the following.
You don't talk about Optical Cross Connects (OXC) is something missing or understated somewhere?
-->Whoops.  We were trying to find a more general term to include both ROADM (usually a highly asymmetric fabric) and an OXC (a completely symmetric fabric, e.g., any ingress to any egress), but we seemed to have gone with using the ROADM terminology to include both cases.  Talked with some equipment makers that planned/make "switches" that seemed to incorporate both so we made sure the model could deal with both sparse and dense potential connectivity. Diego had some terminology ideas but lately his e-mails have been bouncing back to me.  Any suggestions are appreciated, but we are including both ROADM and OXCs.
 
 
* Section 3.1 where you state:
"A fixed mapping between the
GMPLS label space and these ITU-T WDM grids as proposed in [Otani] "
Does it implies a sort of network level label space? How relate with usual local label significance?
--> This mapping gives a mapping between labels and wavelengths/lambda, just like in the SONET/SDH case we mapped the ITU-T G.707 "S, U, K, L, M " identification of SDH time slots to a label format in RFC4606 and again this was done in RFC4328 to map G.709 digital wrapper time slot identification into a technology specific label format.  In RFC3471 for lambda switching we just get a 32 bit integer with no meaning attached. Every network and every node could potentially map labels to lambdas in a different way. In [Otani] they are following the RFC4606 and RFC4328 lead and using the ITU-T DWDM and CWDM lambda grid standards to give a fixed association between labels and lambdas just like between labels and TDM time slots in the SDH/ODU case.

This doesn't change the local significance of labels. In the wavelength switched optical case that is influenced by the presence or absence of wavelength converters.
 
 
* Section 3.4 Wavelength Converters
"Current or envisioned contexts for wavelength converters are : ..."
Could we think to a description/model for wavelength converter that is technology agnostic? Simply something like: full conversion capability, partial conversion capability with some constrains, and may be others.
--> The difference, between the all optical techniques and the OEO based techniques makes that difficult.
 
 
* Section 3.4. the following:
"4. Wavelength converters that are O-E-O based will have a restriction
based on the modulation format and transmission speed"
Not clear to me the type of restriction here when OEO happens... probably I'm missing what you mean here.
--> For example a typical O-E-O based wavelength converter would be build around a 3R regenerator with a tunable laser. A 3R regenerator cares about the modulation type say NRZ or RZ (and which flavor), and the symbol rate since its also doing retiming. An all optical wavelength converter will be fairly independent of these issues (except when we look at impairment factors). Hence the OEO wavelength is going to be more signal specific than the all optical.
 
 
* Section 4.1 when you talk about Lightpath temporal characteristics:
"Lightpath connection duration has typically been thought of as
approximately three time frames: "
and the following you define: dynamics, pseudo-static, static.
Why there’s a need of this classification? When you us Short/long is compared to what?
--> In most of the research literature and in optimization practice different techniques are typically used in the dynamic versus static (or psuedo static cases).  In MPLS there is minimum interference routing optimization techniques for the dynamic case. For the static case I could apply multi-commodity flow optimization techniques to a batch of connections.  In the RWA literature there is a similar differentiation.  Exactly what information could be sent to help PCE differentiate I'm not sure. In the case of static, batch optimization we can just use the existing concurrent optimization hooks in PCE. For an individual lightpath request it seemed that it would be helpful to know how long the connection would last so we'd know how much computational effort we might want to put into optimize it.
 
 
minor typo on your mail below: point (c) rfc4328 (not 4238) right?
--> Yes.  The G.709 signaling extensions RFC.
 
Thanks,
Giovanni


 

From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: giovedì 27 settembre 2007 1.42
To: ccamp; pce@ietf.org
Subject: [Pce] Some key issues with Wavelength Switched Optical Networks...

Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.

(a) The draft brings up models for the following WDM network elements:
  1. WDM links
  2. Optical transmitters
  3. Wavelength Converters and OEO regenerators
  4. ROADMs, FOADMs, optical splitters and combiners.
    For items (3) and (4) we are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS).

(b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols:
  1. A single PCE computing both the path and wavelength
  2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment
  3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects)
    Do we really need all three models?

(c) G.709 includes the Optical Multiplex Section and Optical Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff years ago?

I'd like to think the draft answers some of these questions.  I also think that network element models and the process models are important enough to warrant this separate framework document.  Your opinions are solicited.

Regards

Greg B.
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

    

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------030001070104060803010707-- --===============2087866122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============2087866122==-- From pce-bounces@lists.ietf.org Fri Sep 28 16:12:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbMBL-00044k-ES; Fri, 28 Sep 2007 16:11:27 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IbMBJ-000415-MG for pce-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 16:11:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbMBJ-00040x-8e for pce@ietf.org; Fri, 28 Sep 2007 16:11:25 -0400 Received: from mail.advaoptical.de ([213.70.90.131] helo=mail.advaoptical.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbMBH-0002w1-KX for pce@ietf.org; Fri, 28 Sep 2007 16:11:25 -0400 Received: from muc-srv-mimesweeper.advaoptical.com (10.200.0.15) by mail.advaoptical.com (10.200.0.20) with Microsoft SMTP Server id 8.0.685.24; Fri, 28 Sep 2007 22:11:35 +0200 Received: from muc-srv-mail2.advaoptical.com (unverified) by muc-srv-mimesweeper.advaoptical.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 28 Sep 2007 22:10:58 +0200 Received: from atl-srv-mail.atl.advaoptical.com ([172.16.5.25]) by muc-srv-mail2.advaoptical.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 22:11:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Some key issues with Wavelength Switched Optical Networks... Date: Fri, 28 Sep 2007 16:11:12 -0400 Message-ID: In-Reply-To: <46FD51B9.9060909@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Some key issues with Wavelength Switched Optical Networks... Thread-Index: AcgCA1dvw3c3kl7vQXqfS5lx9vWYVwABtRbQ References: <46FAEE2C.5040008@grotto-networking.com> <46FD51B9.9060909@grotto-networking.com> From: Igor Bryskin To: "Greg Bernstein" X-OriginalArrivalTime: 28 Sep 2007 20:11:16.0770 (UTC) FILETIME=[B9F38820:01C8020B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3dfe8a7b5ea10ae7aba70754d4a234d0 Cc: ccamp , pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1947164522==" Errors-To: pce-bounces@lists.ietf.org --===============1947164522== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8020B.B7FCF8E2" ------_=_NextPart_001_01C8020B.B7FCF8E2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, =20 Please, see in line. =20 Igor =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Friday, September 28, 2007 3:11 PM To: Igor Bryskin Cc: ccamp; pce@ietf.org Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... =20 Hi Igor, see comments below. Igor Bryskin wrote:=20 Greg, =20 I believe the draft is very useful. --> Thanks! =20 I have a couple of questions comments: =20 1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Network=20 Optimization =20 How the problem of grooming of higher layer network traffic over optical trails is any different from the problem of traffic grooming in TDM (e.g. VC12 over VC4)? I mean this is a general problem of inter-layer relationship. I suggest moving all higher layer network considerations out of scope of the draft and focusing on specifics of the OCh layer. =3D=3D> Some of my co-authors agree with you on moving this section = out. The reason that I put it in was that the optical "Traffic Grooming" problem has received a fair amount of attention in the research and general technical literature and is also a driver for the use of ROADMs (optical bypass). I guess in general we've got the following inter-related problems: (a) virtual network topology design, (b) lower layer connection routing, (c) higher layer flow routing. In our case (b) is the RWA problem, which is fairly difficult in its own right. I guess I should look closely at the MLN/MRN work and see if a specific example that includes RWA is mentioned. If so then I'd feel fine removing this section from the document. =20 IB>> Ok =20 2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft. --> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode? Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows. Was there some general looping concerns already published for GMPLS with respect to circuits? =20 =20 IB>> There is a profound difference. I am not talking here about accidental looping, rather about deliberate looping: if some nodes can perform wavelength conversion while others can not, then you will want to route the connection to one or several conversion points and after that get it back on the main path. In other words you will deliberately request, say, a PCE to produce looped path, and then GMPLS RSVP-TE to signal looped path, which is completely out of normal paradigm of work for both PCE and RSVP. =20 Cheers,=20 Igor =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Wednesday, September 26, 2007 7:42 PM To: ccamp; pce@ietf.org Subject: [Pce] Some key issues with Wavelength Switched Optical Networks... =20 Hi folks, I haven't seen too many comments on our draft "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-01.txt). So I figured I'd point out some potentially controversial issues that the draft brings up.=20 (a) The draft brings up models for the following WDM network elements: 1. WDM links 2. Optical transmitters 3. Wavelength Converters and OEO regenerators 4. ROADMs, FOADMs, optical splitters and combiners. For items (3) and (4) we are taking the modeling lead rather than some other SDO. And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, MPLS). (b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE protocols: 1. A single PCE computing both the path and wavelength 2. Two distinct PCEs, where one computes the path, and a different PCE computes the wavelength assignment 3. A PCE computes the path and wavelength assignment is accomplished in a distributed fashion via signaling (e.g., using label set objects) Do we really need all three models? (c) G.709 includes the Optical Multiplex Section and Optical Channels. RFC4238 was aimed at GMPLS extensions for G.709 (Optical Transport Network) control. Weren't we finished with all this optical stuff years ago? I'd like to think the draft answers some of these questions. I also think that network element models and the process models are important enough to warrant this separate framework document. Your opinions are solicited. Regards Greg B. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =20 ------_=_NextPart_001_01C8020B.B7FCF8E2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Greg,

 

Please, see in = line.

 

Igor

 

From: Greg Bernstein [mailto:gregb@grotto-networking.com] =
Sent: Friday, September = 28, 2007 3:11 PM
To: Igor Bryskin
Cc: ccamp; = pce@ietf.org
Subject: Re: [Pce] Some = key issues with Wavelength Switched Optical Networks...

 

Hi Igor, see comments below.

Igor Bryskin wrote: =

Greg,

 

I believe the draft is very = useful.

--> Thanks!

 

I have a couple of questions = comments:

 

1. Section : 4.4. Traffic Grooming: Combining WSON and =
Higher Layer Network

   Optimization

 

How the problem of grooming of = higher layer network traffic over optical trails is any different from the = problem of traffic grooming in TDM (e.g. VC12 over VC4)? I mean this is a general = problem of inter-layer relationship. I suggest moving all higher layer network considerations out of scope of the draft and focusing on specifics of = the OCh layer.

è   Some of my co-authors agree with you on moving this section out.  The = reason that I put it in was that the optical "Traffic Grooming" = problem has received a fair amount of attention in the research and general = technical literature and is also a driver for the use of ROADMs (optical = bypass).  I guess in general we've got the following inter-related problems: (a) = virtual network topology design, (b) lower layer connection routing, (c) higher = layer flow routing. In our case (b) is the RWA problem, which is fairly = difficult in its own right. I guess I should look closely at the MLN/MRN work and see = if a specific example that includes RWA is mentioned.  If so then I'd = feel fine removing this section from the document.

 

=

IB>> Ok

 

2. Considering wavelength = conversion inevitably brings to the problem of looped paths, which is a completely = new ball game in path computation, and I am surprised that the issue was = never mentioned in the draft.

--> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode?  Also in these two circuit cases (TDM, and optical) = do we have the same danger as in the packet case where looping traffic can = greatly degrade other flows.  Was there some general looping concerns = already published for GMPLS with respect to circuits? 

 

IB>> There is a profound = difference. I am not talking here about accidental looping, rather about deliberate looping: if some nodes can perform wavelength conversion while others = can not, then you will want to route the connection to one or several conversion = points and after that get it back on the main path. In other words you will deliberately request, say, a PCE to produce looped path, and then GMPLS = RSVP-TE to signal looped path, which is completely out of normal paradigm of = work for both PCE and RSVP.

 

Cheers, =

Igor

 

From: Greg Bernstein [mailto:gregb@grotto-networkin= g.com]
Sent: Wednesday, = September 26, 2007 7:42 PM
To: ccamp; pce@ietf.org
Subject: [Pce] Some key = issues with Wavelength Switched Optical = Networks...

 

Hi folks, I haven't seen too many comments on = our draft "Framework for GMPLS and PCE Control of Wavelength Switched = Optical Networks" ( http://www.ietf.org/internet-drafts/draft-bernstei= n-ccamp-wavelength-switched-01.txt). So I figured I'd point out some potentially controversial issues that = the draft brings up.

(a) The draft brings up models for the following WDM network = elements:

  1. WDM = links
  2. Optical = transmitters
  3. Wavelength Converters and OEO = regenerators
  4. ROADMs, = FOADMs, optical splitters and = combiners.

    For items (3) and (4) we = are taking the modeling lead rather than some other SDO.  And for ROADMs, in particular, we going beyond the classic ITU-T "fabric" model = (M.3100) which has been the mainstay of any connection oriented switch (TDM, ATM, = MPLS).

(b) The draft brings up three (not one, not two, but three) different computational models for RWA which can impact GMPLS and PCE = protocols:

  1. A single = PCE computing both the path and = wavelength
  2. Two = distinct PCEs, where one computes the path, and a different PCE computes the = wavelength assignment
  3. A PCE = computes the path and wavelength assignment is accomplished in a distributed = fashion via signaling (e.g., using label set = objects)

    Do we really need all = three models?

(c) G.709 includes the Optical Multiplex Section and Optical = Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical Transport Network) control.  Weren't we finished with all this optical stuff = years ago?

I'd like to think the draft answers some of these questions.  I = also think that network element models and the process models are important enough = to warrant this separate framework document.  Your opinions are = solicited.

Regards

Greg B.


-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) =
573-2237
 










-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) =
573-2237
 
------_=_NextPart_001_01C8020B.B7FCF8E2-- --===============1947164522== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1947164522==-- From pce-bounces@lists.ietf.org Fri Sep 28 17:44:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNct-0000gZ-Gy; Fri, 28 Sep 2007 17:43:59 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IbNcr-0000eV-Qf for pce-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 17:43:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNcp-0000NJ-NN for pce@ietf.org; Fri, 28 Sep 2007 17:43:57 -0400 Received: from pro.abac.com ([66.226.64.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbNcj-0000DN-RZ for pce@ietf.org; Fri, 28 Sep 2007 17:43:50 -0400 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id l8SLhcqN035748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 14:43:41 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <46FD7589.10505@grotto-networking.com> Date: Fri, 28 Sep 2007 14:43:37 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Igor Bryskin Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks... References: <46FAEE2C.5040008@grotto-networking.com> <46FD51B9.9060909@grotto-networking.com> In-Reply-To: X-Spam-Score: 0.71 (HTML_MESSAGE,RCVD_IN_PBL,RDNS_DYNAMIC) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: ccamp , pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1771764113==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1771764113== Content-Type: multipart/alternative; boundary="------------060109060902070806000707" This is a multi-part message in MIME format. --------------060109060902070806000707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Very good catch Igor. See in line. Igor Bryskin wrote: > --snip-- > > > > > > 2. Considering wavelength conversion inevitably brings to the problem > of looped paths, which is a completely new ball game in path > computation, and I am surprised that the issue was never mentioned in > the draft. > > --> How is this different from the "looping" that can occur with a TDM > multiplexer in a drop and continue mode? Also in these two circuit > cases (TDM, and optical) do we have the same danger as in the packet > case where looping traffic can greatly degrade other flows. Was there > some general looping concerns already published for GMPLS with respect > to circuits? > > > > IB>> There is a profound difference. I am not talking here about > accidental looping, rather about deliberate looping: if some nodes can > perform wavelength conversion while others can not, then you will want > to route the connection to one or several conversion points and after > that get it back on the main path. In other words you will > deliberately request, say, a PCE to produce looped path, and then > GMPLS RSVP-TE to signal looped path, which is completely out of normal > paradigm of work for both PCE and RSVP. > --> I thought you were worried about accidental loops. I didn't even consider what you are talking about "looping", but would RSVP processing get fouled up? It sure looks like a loop at the "node" level. In the ERO the "node" subobject (IP4, IP6, AS) could definitely be repeated, but with a different "Label ERO" subobject appended. This is definitely something somebody would not to in the MPLS or TDM case. I'll be sure to add it as an important difference in the next revision. Thanks! > > > > Cheers, > > Igor > > > > ------------------------------------------------------------------------ --snip-- -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------060109060902070806000707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Very good catch Igor. See in line.

Igor Bryskin wrote:
--snip--



 

2. Considering wavelength conversion inevitably brings to the problem of looped paths, which is a completely new ball game in path computation, and I am surprised that the issue was never mentioned in the draft.

--> How is this different from the "looping" that can occur with a TDM multiplexer in a drop and continue mode?  Also in these two circuit cases (TDM, and optical) do we have the same danger as in the packet case where looping traffic can greatly degrade other flows.  Was there some general looping concerns already published for GMPLS with respect to circuits? 

 

IB>> There is a profound difference. I am not talking here about accidental looping, rather about deliberate looping: if some nodes can perform wavelength conversion while others can not, then you will want to route the connection to one or several conversion points and after that get it back on the main path. In other words you will deliberately request, say, a PCE to produce looped path, and then GMPLS RSVP-TE to signal looped path, which is completely out of normal paradigm of work for both PCE and RSVP.

--> I thought you were worried about accidental loops.  I didn't even consider what you are talking about "looping", but would RSVP processing get fouled up? It sure looks like a loop at the "node" level.
In the ERO the "node" subobject (IP4, IP6, AS) could definitely be repeated, but with a different "Label ERO" subobject appended. This is definitely something somebody would not to in the MPLS or TDM case.  I'll be sure to add it as an important difference in the next revision. Thanks!

 

Cheers,

Igor

 

--snip--
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------060109060902070806000707-- --===============1771764113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1771764113==--