From pce-bounces@lists.ietf.org Wed May 02 15:50: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 1HjKqW-0008SR-SF; Wed, 02 May 2007 15:50:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKqP-0008F7-C2; Wed, 02 May 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HjKqP-0002SH-18; Wed, 02 May 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id EDDEC2AC77; Wed, 2 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HjKpu-0005jR-O9; Wed, 02 May 2007 15:50: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, 02 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-path-key-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 : 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-00.txt Pages : Date : 2007-5-2 Multiprotocol Label Switching (MPLS) 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 (ASs), 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 ASs 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 LSP 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 (RSVP) explicit route object. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-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-path-key-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-path-key-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-5-2114942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-path-key-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-path-key-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-2114942.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 May 02 19:06: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 1HjNu1-0004sz-IJ; Wed, 02 May 2007 19:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjNtz-0004sj-Ia; Wed, 02 May 2007 19:06:27 -0400 Received: from mga07.intel.com ([143.182.124.22] helo=azsmga101.ch.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjNty-000469-5E; Wed, 02 May 2007 19:06:26 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 02 May 2007 16:06:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.14,482,1170662400"; d="txt'208?scan'208,208";a="223382822" Received: from fmsmsxpoc001.fm.intel.com (HELO fmsmsxpoc001.amr.corp.intel.com) ([132.233.49.22]) by azsmga001.ch.intel.com with ESMTP; 02 May 2007 16:06:23 -0700 Received: from fmsmsx334.amr.corp.intel.com (132.233.42.1) by fmsmsxpoc001.amr.corp.intel.com (132.233.49.22) with Microsoft SMTP Server id 8.0.685.24; Wed, 2 May 2007 15:32:43 -0700 Received: from fmsmsx413.amr.corp.intel.com ([10.19.19.5]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 15:06:02 -0700 Received: from mail pickup service by fmsmsx413.amr.corp.intel.com with Microsoft SMTPSVC; Wed, 2 May 2007 15:06:01 -0700 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmsx413.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 12:53:01 -0700 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 12:53:00 -0700 Received: from e4.ny.us.ibm.com (HELO fmsmga101.fm.intel.com) ([32.97.182.144]) by fmsmga001-1.fm.intel.com with ESMTP; 02 May 2007 12:52:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFiJOEacmhCRkmdsb2JhbACBZI00ewIBAQcOBQgd X-IronPort-AV: E=Sophos;i="4.14,482,1170662400"; d="txt'208?scan'208,208";a="222282166" Received: from odin.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by mga01.intel.com with ESMTP; 02 May 2007 12:52:35 -0700 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKqV-0008M2-3w; Wed, 02 May 2007 15:50:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKqP-0008F7-C2; Wed, 02 May 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HjKqP-0002SH-18; Wed, 02 May 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id EDDEC2AC77; Wed, 2 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HjKpu-0005jR-O9; Wed, 02 May 2007 15:50:02 -0400 Content-Type: multipart/mixed; boundary="NextPart" MIME-Version: 1.0 To: i-d-announce@ietf.org From: Message-ID: Date: Wed, 2 May 2007 15:50:02 -0400 X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 02 May 2007 19:53:00.0645 (UTC) FILETIME=[7D0F6150:01C78CF3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-path-key-00.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 Content-Type: text/plain 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-00.txt Pages : Date : 2007-5-2 Multiprotocol Label Switching (MPLS) 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 (ASs), 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 ASs 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 LSP 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 (RSVP) explicit route object. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-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-path-key-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-path-key-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-5-2114942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-path-key-00.txt --OtherAccess Content-Type: message/external-body; name="draft-ietf-pce-path-key-00.txt"; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-Type: text/plain Content-ID: <2007-5-2114942.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 Thu May 03 18:50: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 1Hjk8M-0006U9-Vv; Thu, 03 May 2007 18:50:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjk89-00062R-6C; Thu, 03 May 2007 18:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hjk88-0004O5-RW; Thu, 03 May 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AAA0817623; Thu, 3 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hjk7e-000629-BJ; Thu, 03 May 2007 18:50: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: Thu, 03 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-isis-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : IS-IS protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-isis-04.txt Pages : 19 Date : 2007-5-3 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-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-isis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-3163703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-isis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-3163703.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 May 03 18:50: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 1Hjk8M-0006Sv-8E; Thu, 03 May 2007 18:50:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjk89-00062Q-4K; Thu, 03 May 2007 18:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hjk88-0004O4-Pa; Thu, 03 May 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8A07D2AC79; Thu, 3 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hjk7e-000626-Ak; Thu, 03 May 2007 18:50: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: Thu, 03 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : OSPF protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-ospf-04.txt Pages : 22 Date : 2007-5-3 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-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-ospf-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-3163453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-ospf-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-3163453.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 May 03 18:50: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 1Hjk8M-0006U9-Vv; Thu, 03 May 2007 18:50:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjk89-00062R-6C; Thu, 03 May 2007 18:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hjk88-0004O5-RW; Thu, 03 May 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AAA0817623; Thu, 3 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hjk7e-000629-BJ; Thu, 03 May 2007 18:50: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: Thu, 03 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-isis-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : IS-IS protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-isis-04.txt Pages : 19 Date : 2007-5-3 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-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-isis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-3163703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-isis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-3163703.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 May 03 18:50: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 1Hjk8M-0006Sv-8E; Thu, 03 May 2007 18:50:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjk89-00062Q-4K; Thu, 03 May 2007 18:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hjk88-0004O4-Pa; Thu, 03 May 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8A07D2AC79; Thu, 3 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hjk7e-000626-Ak; Thu, 03 May 2007 18:50: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: Thu, 03 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : OSPF protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-ospf-04.txt Pages : 22 Date : 2007-5-3 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-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-ospf-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-3163453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-ospf-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-3163453.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 May 07 19:35: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 1HlCjT-0004I3-0Z; Mon, 07 May 2007 19:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlCjR-0004Ht-EN for pce@ietf.org; Mon, 07 May 2007 19:35:05 -0400 Received: from davinci.fing.edu.uy ([164.73.32.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlCjN-0006Rq-U1 for pce@ietf.org; Mon, 07 May 2007 19:35:05 -0400 Received: from filemon (filemon.fing.edu.uy [164.73.36.117]) by davinci.fing.edu.uy with SMTP id l47NYxuE015789; Mon, 7 May 2007 20:34:59 -0300 (UYT) Message-ID: <026d01c79100$517afa70$010aa8c0@fing.edu.uy> From: =?iso-8859-1?Q?Mart=EDn_Germ=E1n_-_INCO?= To: Subject: [Pce] Comments on PCEP implementation Date: Mon, 7 May 2007 20:34:49 -0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2826 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Mon, 07 May 2007 20:35:00 -0300 (UYT) X-Spam-Score: -2.101 () AWL,BAYES_00,HTML_70_80,HTML_MESSAGE X-Scanned-By: MIMEDefang 2.58 on 164.73.32.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 71427903e4ce43cf4879c36ef9c04bc1 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="===============0519235365==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0519235365== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0268_01C790E7.2884B7A0" This is a multi-part message in MIME format. ------=_NextPart_000_0268_01C790E7.2884B7A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We've been following the WG since the early BOF in 2005. We proposed a=20 management interface for the PCE Architecture before Paris meeting in=20 2005: http://www.potaroo.net/ietf/idref/draft-grampin-pce-mgmnt-if/ Now we're finishing an implementation of PCEP (complete except from=20 notifications), a PCC and a PCE. Some doubts has arisen in the=20 development process, which we would like to share with the WG. They're=20 listed hereafter: =3D=3D=3D =20 General edit: In some body format the bits are group by 10 but in others are group by = 8 (or bytes). We think it is better to group in all body formats the = bits by 8 (or bytes). For example: Figure 21 and Figure 22. =20 It doesn't say something like "Unassigned bits are considered as = reserved and MUST be set to zero on transmission" when speaking of the = Flags in several sections (e.g.: section 7.10). =20 =3D=3D=3D =20 In section 4.2.6: "In case of TCP connection failure, the PCEP session is immediately = terminated." But in section 5 says: ".it may be desirable to systematically open and close the TCP = connection for each PCEP request (for instance when sending a path = computation request is a rare event)." We think that these 2 sentences are in contradiction, because every time = you close a TCP connection, according to the first you close the PCEP = session. So, when you open the TCP connection again, you need to open = the PCEP session to. =20 =3D=3D=3D =20 In section 6.4: ". the RP and the END-POINTS objects (see section Section 7)." section = is twice. =20 =3D=3D=3D =20 In section 6.4: Says "The special case of two BANDWIDTH objects is discussed in details = in Section 7.6." but the BNF permits only one. =20 =3D=3D=3D =20 In section 6.5: "If the path computation request can be satisfied (the PCE finds a set = of path(s) that satisfy the set of constraint(s)), the set of computed = path(s) specified by means of ERO object(s) is inserted in the PCRep = message. The ERO object is defined in Section 7.8." In "ERO object" object is twice (it happens twice). The BNF allowed a NO-PATH with a ERO. If there's no path possible there = isn't a ERO. =20 =3D=3D=3D =20 In section 6.6: " :=3D=3D and :=3D " The "[" and "]" are missing before and = , and after and = . =20 =3D=3D=3D =20 In section 6.8: "The Message-Type field of the PCEP common header for the Open message = is set to 7 (To be confirmed by IANA)." It should say "Close message" = instead of "Open message". =20 "The Close message MUST contain exactly one CLOSE object (see Section = 6.8)." This reference is little recursive. =20 =3D=3D=3D =20 In section 7.2: "SID (PCEP session-ID - 8 bits): specifies a 2 octet." We think it = should say 1 octet. =20 =3D=3D=3D =20 In section 7.3: "The P flag of the RP object MUST be set in PCReq and PCReq" It should = say "...in PCReq and PCRep". =20 =3D=3D=3D =20 In section 7.3.1: "Reserved (8 bits): ." In the body format there are 10 bits for = Reserved. "Flags: 18 bits" In the body format there are 22 bits for Flags. =20 =3D=3D=3D =20 In section 7.4: "Reserved: ." It doesn't say the number of Reserved bits (16 bits). "The only TLV currently defined is the NO-PATH-VECTOR TLV defined = below." It should say "above". =20 =3D=3D=3D =20 In section 7.7: It doesn't say how many bits are Flags. =20 =3D=3D=3D =20 In section 7.10: "Reserved (8 bits):" In the body format there are 10 bits for Reserved. =20 =3D=3D=3D =20 In section 7.11: It says "IRO object" (again repeating object) four times in the section. At this point, we'd like to say that we agree we the ones that suggest = that the XRO should be included in this draft, mainly for 3 reasons: = it's a useful, very used (it's a common constraint in a request) and = easy to compute constraint. =20 =3D=3D=3D =20 In section: 7.12.1: "(since PCEP allows for the bundling of multiple path computation = requests within a single PCRep message)" it should say "PCReq" instead = of "PCRep". =20 =3D=3D=3D =20 In section 7.12.2: "Flags: ." It doesn't say the number of Flag bits (24 bits). =20 =3D=3D=3D =20 In section 7.13: "Flags: ." It doesn't say the number of Flag bits (8 bits). =20 =3D=3D=3D =20 In section 7.15: "Reserved: ." It doesn't say the number of Reserved bits (20 bits). "Flags: ." It doesn't say the number of Flag bits (4 bits). =20 =3D=3D=3D =20 In section 7.16: "Reason (4 bits): ." In the body format there are 8 bits for Reason. "Reserved: ." It doesn't say the number of Reserved bits (16 bits). "Flags (4 bits): ." In the body format there are 8 bits for Flags. The reason value 3 ("PCEP session characteristics negotiation failure") = is never used, because you send an Error message with an ERROR object = with Error-Type =3D 1and corresponding Error-Value. =20 =3D=3D=3D =20 In section 9.5: "Error-value=3D2: RRO object missing for a reoptimization request (R bit = of the RP object set)", repeats object. =20 =3D=3D=3D =20 In section 10: We think that the variables used to "control" TCP connection (e.g.: = TCPConnect) are useless, along with the paragraph "It is expected that = an implementation.", because you rely the transport on TCP, or is matter = of PCEP to specify how TCP should work? The item "Starts the KeepWait timer" in the Idle and TCPPending state = are useless, because you never wait for them, the timer that matters is = OpenWait. In the UP State, says "If the system detects that the PCEP peer tries to = setup a second TCP connection, it stops the TCP connection establishment = and sends a PCErr with Error-Type=3D10.", the Error-Type should be 9. = The PCEP peer never expect this message when attempting to established a = PCEP session, sending this message causes that the peer sends an Error = message back. =20 =3D=3D=3D Best regards, Alberto, Mart=EDn & Eduardo ------=_NextPart_000_0268_01C790E7.2884B7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
We've been following the WG = since the early=20 BOF in 2005. We proposed a
management interface for the PCE = Architecture=20 before Paris meeting in
2005: http://www.potaroo.net/ietf/idref/draft-grampin-pce-mgmnt-if/

Now we're finishing an implementation of PCEP = (complete except=20 from
notifications), a PCC and a PCE. Some doubts has arisen in the=20
development process, which we would like to share with the WG. = They're=20
listed hereafter:

=3D=3D=3D

 

General = edit:

In some body format the = bits are=20 group by 10 but in others are group by 8 (or bytes). We think it is = better to=20 group in all body formats the bits by 8 (or bytes). For example: Figure = 21 and=20 Figure 22.

 

It doesn=92t say something = like=20 =93Unassigned bits are considered as reserved and MUST be set to zero on = transmission=94 when speaking of the Flags in several sections (e.g.: = section=20 7.10).

 

=3D=3D=3D

 

In section=20 4.2.6:

=93In case of TCP = connection failure,=20 the PCEP session is immediately terminated.=94

But in section 5=20 says:

=93=85it may be desirable = to=20 systematically open and close the TCP connection for each PCEP request = (for=20 instance when sending a path computation request is a rare=20 event).=94

We think that these 2 = sentences are=20 in contradiction, because every time you close a TCP connection, = according to=20 the first you close the PCEP session. So, when you open the TCP = connection=20 again, you need to open the PCEP session to.

 

=3D=3D=3D

 

In section=20 6.4:

=93=85 the RP and the = END-POINTS objects=20 (see section Section 7).=94 section is twice.

 

=3D=3D=3D

 

In section=20 6.4:

Says =93The special case = of two=20 BANDWIDTH objects is discussed in details in Section 7.6.=94 but the BNF = permits=20 only one.

 

=3D=3D=3D

 

In section=20 6.5:

=93If the path computation = request can=20 be satisfied (the PCE finds a set of path(s) that satisfy the set of=20 constraint(s)), the set of computed path(s) specified by means of ERO = object(s)=20 is inserted in the PCRep message. The ERO object is defined in Section=20 7.8.=94

In =93ERO object=94 object = is twice (it=20 happens twice).

The BNF allowed a NO-PATH = with a=20 ERO. If there's no path possible there isn't a = ERO.

 

=3D=3D=3D

 

In section=20 6.6:

=93<request-id-list> = :=3D=3D=20 <RP><request-id-list> and

<notification-list> = :=3D=20 <NOTIFICATION><notification-list>=94

The =93[=94 and =93]=94 = are missing before=20 <request-id-list> and <notification-list>, and after=20 <request-id-list> and = <notification-list>.

 

=3D=3D=3D

 

In section=20 6.8:

=93The Message-Type field = of the PCEP=20 common header for the Open message is set to 7 (To be confirmed by = IANA).=94 It=20 should say =93Close message=94 instead of =93Open = message=94.

 

=93The Close message MUST = contain=20 exactly one CLOSE object (see Section 6.8).=94

This reference is little=20 recursive.

 

=3D=3D=3D

 

In section=20 7.2:

=93SID (PCEP session-ID - = 8 bits):=20 specifies a 2 octet=85=94 We think it should say 1 = octet.

 

=3D=3D=3D

 

In section=20 7.3:

=93The P flag of the RP = object MUST be=20 set in PCReq and PCReq=94 It should say =93...in PCReq and=20 PCRep=94.

 

=3D=3D=3D

 

In section=20 7.3.1:

=93Reserved (8 bits): = =85=94 In the body=20 format there are 10 bits for Reserved.

=93Flags: 18 bits=94 In = the body format=20 there are 22 bits for Flags.

 

=3D=3D=3D

 

In section=20 7.4:

=93Reserved: =85=94 It = doesn=92t say the=20 number of Reserved bits (16 bits).

=93The only TLV currently = defined is=20 the NO-PATH-VECTOR TLV defined below.=94 It should say=20 =93above=94.

 

=3D=3D=3D

 

In section=20 7.7:

It doesn=92t say how many = bits are=20 Flags.

 

=3D=3D=3D

 

In section=20 7.10:

 =93Reserved (8 bits):=94 In the = body format=20 there are 10 bits for Reserved.

 

=3D=3D=3D

 

In section=20 7.11:

It says =93IRO object=94 = (again=20 repeating object) four times in the section.

At this point, we=92d like = to say that=20 we agree we the ones that suggest that the XRO should be included in = this draft,=20 mainly for 3 reasons: it=92s a useful, very used (it=92s a common = constraint in a=20 request) and easy to compute constraint.

 

=3D=3D=3D

 

In section:=20 7.12.1:

=93(since PCEP allows for = the bundling=20 of multiple path computation requests within a single PCRep message)=94 = it should=20 say =93PCReq=94 instead of =93PCRep=94.

 

=3D=3D=3D

 

In section=20 7.12.2:

=93Flags: =85=94 It = doesn=92t say the number=20 of Flag bits (24 bits).

 

=3D=3D=3D

 

In section=20 7.13:

=93Flags: =85=94 It = doesn=92t say the number=20 of Flag bits (8 bits).

 

=3D=3D=3D

 

In section=20 7.15:

=93Reserved: =85=94 It = doesn=92t say the=20 number of Reserved bits (20 bits).

=93Flags: =85=94 It = doesn=92t say the number=20 of Flag bits (4 bits).

 

=3D=3D=3D

 

In section=20 7.16:

=93Reason (4 bits): =85=94 = In the body=20 format there are 8 bits for Reason.

=93Reserved: =85=94 It = doesn=92t say the=20 number of Reserved bits (16 bits).

=93Flags (4 bits): =85=94 = In the body=20 format there are 8 bits for Flags.

The reason value 3 = (=93PCEP session=20 characteristics negotiation failure=94) is never used, because you send = an Error=20 message with an ERROR object with Error-Type =3D 1and corresponding=20 Error-Value.

 

=3D=3D=3D

 

In section=20 9.5:

=93Error-value=3D2: RRO = object missing=20 for a reoptimization request (R bit of the RP object set)=94, repeats=20 object.

 

=3D=3D=3D

 

In section = 10:

We think that the = variables used to=20 =93control=94 TCP connection (e.g.: TCPConnect) are useless, along with = the=20 paragraph =93It is expected that an implementation=85=94, because you = rely the=20 transport on TCP, or is matter of PCEP to specify how TCP should=20 work?

The item =93Starts the = KeepWait timer=94=20 in the Idle and TCPPending state are useless, because you never wait for = them,=20 the timer that matters is OpenWait.

In the UP State, says = =93If the system=20 detects that the PCEP peer tries to setup a second TCP connection, it = stops the=20 TCP connection establishment and sends a PCErr with Error-Type=3D10.=94, = the=20 Error-Type should be 9. The PCEP peer never expect this message when = attempting=20 to established a PCEP session, sending this message causes that the peer = sends=20 an Error message back.

 

=3D=3D=3D



Best=20 regards,
Alberto, Mart=EDn & Eduardo
------=_NextPart_000_0268_01C790E7.2884B7A0-- --===============0519235365== 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 --===============0519235365==-- From pce-bounces@lists.ietf.org Tue May 08 09:39:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlPuD-0006J6-Un; Tue, 08 May 2007 09:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlPuC-0006EK-2c for pce@lists.ietf.org; Tue, 08 May 2007 09:39:04 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HlPuA-0003Au-KH for pce@lists.ietf.org; Tue, 08 May 2007 09:39:04 -0400 Received: (qmail 29195 invoked by uid 0); 8 May 2007 13:39:01 -0000 Received: from 192.35.17.30 by www137.gmx.net with HTTP; Tue, 08 May 2007 15:39:01 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 May 2007 15:39:01 +0200 From: _den@gmx.de Message-ID: <20070508133901.89170@gmx.net> MIME-Version: 1.0 To: pce@lists.ietf.org X-Authenticated: #19887475 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/fRNdSmMffcBReiosMHEAOwVsbADI3oxhBfAZicR qs/sdN6Ztppl92iJDkBSqKxfXtWBuQyFhGAg== Content-Transfer-Encoding: 7bit X-GMX-UID: EAwpKacaMydhZiQgRWtl39tjaGRhZtph X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Pce] Comments on PCEP implementation X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hello, I also implementing PCEP protocol. Your notices to the current draft are very interesting. For me was the most interesting question with 2 BANDWIDTH objects. If I assume, that the BNF Notation should be correct... Could it be possible that these 2 objects are in the different 's? (Perhaps not, because of Request-ID-Number in RP object... ok, forget it) Have you already imlemented the 1) TLV(s) in the LSPA object and 2) Label-subobjects for ERO and RRO? If yes, could you say me please, where can i find the formats for them. Thanks -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue May 08 10:50: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 1HlR1P-0004rN-5s; Tue, 08 May 2007 10:50:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlR1N-0004rA-73 for pce@lists.ietf.org; Tue, 08 May 2007 10:50:33 -0400 Received: from davinci.fing.edu.uy ([164.73.32.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlR1K-0003an-IM for pce@lists.ietf.org; Tue, 08 May 2007 10:50:33 -0400 Received: from filemon (filemon.fing.edu.uy [164.73.36.117]) by davinci.fing.edu.uy with SMTP id l48EoLEP006074; Tue, 8 May 2007 11:50:21 -0300 (UYT) Message-ID: <009901c79180$31e28a40$010aa8c0@fing.edu.uy> From: "Alberto Castro - INCO" To: <_den@gmx.de>, References: <20070508133901.89170@gmx.net> Subject: Re: [Pce] Comments on PCEP implementation Date: Tue, 8 May 2007 11:49:58 -0300 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.3790.2826 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Tue, 08 May 2007 11:50:22 -0300 (UYT) X-Spam-Score: -2.276 () AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 164.73.32.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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, The TLV(s) for the LSPA object are defined in RFC 4420, and the Label-subobjects for ERO are defined in RFC 3473 and the Label-subobjects for RRO are defined in RFC 3209 and extended in RFC 3473. Regards, Alberto. ----- Original Message ----- From: <_den@gmx.de> To: Sent: Tuesday, May 08, 2007 10:39 AM Subject: [Pce] Comments on PCEP implementation > Hello, > > I also implementing PCEP protocol. Your notices to the current draft are > very interesting. > For me was the most interesting question with 2 BANDWIDTH objects. > If I assume, that the BNF Notation should be correct... > Could it be possible that these 2 objects are in the different > 's? > (Perhaps not, because of Request-ID-Number in RP object... ok, forget it) > > Have you already imlemented the > 1) TLV(s) in the LSPA object and > 2) Label-subobjects for ERO and RRO? > > If yes, could you say me please, where can i find the formats for them. > > Thanks > > -- > "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... > Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue May 08 17:57:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXgu-0005PQ-0W; Tue, 08 May 2007 17:57:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXgs-0005PG-M1 for pce@lists.ietf.org; Tue, 08 May 2007 17:57:50 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlXgr-0004Zg-9E for pce@lists.ietf.org; Tue, 08 May 2007 17:57:50 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 23:57: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Comments on PCEP implementation Date: Tue, 8 May 2007 23:57:32 +0200 Message-ID: In-Reply-To: <20070508133901.89170@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on PCEP implementation Thread-Index: AceRdkUqRw/eKY2zQaeg48FSVeNfdgARVMJw References: <20070508133901.89170@gmx.net> From: "LE ROUX Jean-Louis RD-CORE-LAN" To: <_den@gmx.de>, X-OriginalArrivalTime: 08 May 2007 21:57:39.0441 (UTC) FILETIME=[E53F9610:01C791BB] 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 Hi Den,=20 > -----Message d'origine----- > De : _den@gmx.de [mailto:_den@gmx.de]=20 > Envoy=E9 : mardi 8 mai 2007 15:39 > =C0 : pce@lists.ietf.org > Objet : [Pce] Comments on PCEP implementation >=20 > Hello, >=20 > I also implementing PCEP protocol. Your notices to the=20 > current draft are very interesting. > For me was the most interesting question with 2 BANDWIDTH objects. > If I assume, that the BNF Notation should be correct... Actually the BNF is wrong, there can be two bandwidth objects, this is = used during reoptimization to indicate the old a new bandwidths. The BNF will be updated. Regards JL > Could it be possible that these 2 objects are in the=20 > different 's? > (Perhaps not, because of Request-ID-Number in RP object...=20 > ok, forget it) >=20 > Have you already imlemented the > 1) TLV(s) in the LSPA object and > 2) Label-subobjects for ERO and RRO? >=20 > If yes, could you say me please, where can i find the formats=20 > for them. >=20 > Thanks >=20 > -- > "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... > Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail >=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 Tue May 08 18:50:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYVj-0001KX-SN; Tue, 08 May 2007 18:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYVP-00089r-7b; Tue, 08 May 2007 18:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlYVO-0002Xy-QY; Tue, 08 May 2007 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8916D26EB2; Tue, 8 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlYVO-0002F6-BZ; Tue, 08 May 2007 18:50: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, 08 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-isis-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 : IS-IS protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-isis-05.txt Pages : 19 Date : 2007-5-8 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-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-disco-proto-isis-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-disco-proto-isis-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-5-8151125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-isis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-8151125.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 May 08 18:50: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 1HlYWD-0002AW-Ie; Tue, 08 May 2007 18:50:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYVu-0001kj-2x; Tue, 08 May 2007 18:50:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HlYVs-0007t4-P2; Tue, 08 May 2007 18:50:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 91A342ACA3; Tue, 8 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlYVO-0002F3-Ay; Tue, 08 May 2007 18:50: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, 08 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-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 : OSPF protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-ospf-05.txt Pages : 22 Date : 2007-5-8 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-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-disco-proto-ospf-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-disco-proto-ospf-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-5-8150957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-ospf-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-8150957.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 May 09 05:37: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 1Hlibt-0000F1-27; Wed, 09 May 2007 05:37:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlibr-0000Es-Gj; Wed, 09 May 2007 05:37:23 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlibq-0004PB-NM; Wed, 09 May 2007 05:37:23 -0400 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1Hlibp-0002r1-K1; Wed, 09 May 2007 09:37:21 +0000 Received: from your029b8cecfe ([217.158.132.37] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 May 2007 10:37:19 +0100 Message-ID: <0bc001c7921d$825824b0$61fadf0a@your029b8cecfe> From: "Adrian Farrel" To: "Ross Callon" Date: Wed, 9 May 2007 10:30:19 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 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: 09 May 2007 09:37:20.0139 (UTC) FILETIME=[A3B1BDB0:01C7921D] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: pce@ietf.org, WG Milestone Tracker , dward@cisco.com Subject: [Pce] Please publish draft-ietf-pce-disco-proto-isis-05.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 Please publish draft-ietf-pce-disco-proto-isis-05.txt as a Standards Track RFC. Please note that this document has a dependency on draft-ietf-pce-disco-proto-ospf-05.txt. The two documents may be progressed in parallel, or the OSPF document may be progressed ahead of this one. Here is the Document Shepherd write-up. >(1.a) Who is the Document Shepherd for this document? Adrian Farrel > Has the Document Shepherd personally reviewed this version > of the document and, in particular, does he or she believe > this version is ready for forwarding to the IESG for > publication? Yes >(1.b) Has the document had adequate review both from key WG > members and from key non-WG members? Yes. Cross-review to IS-IS WG held with significant input received. > Does the Document Shepherd have any concerns about the > depth or breadth of the reviews that have been performed? No concerns. >(1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar > with AAA, internationalization or XML? No concerns. >(1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area > Director and/or the IESG should be aware of? For example, > perhaps he or she is uncomfortable with certain parts of > the document, or has concerns whether there really is a > need for it. In any event, if the WG has discussed those > issues and has indicated that it still wishes to advance > the document, detail those concerns here. No concerns. > Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion > on this issue. None has been filed. >(1.e) How solid is the WG consensus behind this document? Does > it represent the strong concurrence of a few individuals, > with others being silent, or does the WG as a whole > understand and agree with it? WG agrees. >(1.f) Has anyone threatened an appeal or otherwise indicated > extreme discontent? If so, please summarise the areas of > conflict in separate email messages to the Responsible Area > Director. (It should be in a separate email because this > questionnaire is entered into the ID Tracker.) No. >(1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks > are not enough; this check needs to be thorough. Yes. > Has the document met all formal review criteria it needs > to, such as the MIB Doctor, media type and URI type > reviews? Yes. >(1.h) Has the document split its references into normative and > informative? Yes. > Are there normative references to documents that > are not ready for advancement or are otherwise in an > unclear state? If such normative references exist, what is > the strategy for their completion? There is a normative reference to draft-ietf-isis-caps that is in the RFC Editor Queue. As noted above, there is a normative reference to pce-disco-proto-ospf-05.txt. That document is advancing for publication at the same time. > Are there normative references that are downward > references, as described in [RFC3967]? If so, list these > downward references to support the Area Director in the > Last Call procedure for them [RFC3967]. There are downrefs as common for new IS-IS Standards Track documents. Those listed are: [ISO] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO DP 10589, February 1990. [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. [RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003. It is believed that the first of these is commonly referenced as normative without any issue as it is a stable, external document. It is believed that ISIS WG action is under way to promote RFCs 3567 and 3784 to Standards Track. >(1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the > body of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? > If the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. IANA section is correct. IANA allocation is dependent on the registries created for draft-ietf-isis-caps that is in the RFC Editor Queue. Identification of the registries is, therefore, necessarily slightly ambiguous. Note that the IANA registries are, in part, common with pce-disco-proto-ospf-05.txt. That document is advancing for publication at the same time. > If the document describes an Expert Review process has > Shepherd conferred with the Responsible Area Director so > that the IESG can appoint the needed Expert during the IESG > Evaluation? None required. >(1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly > in an automated checker? Not applicable. >(1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The > approval announcement contains the following sections: > Technical Summary 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. > Working Group Summary The Working Group had consensus on this document. > Document Quality It is currently unclear whether these protocol extensions have been implemented. Note, however, that the protocol procedures are identical to those in draft-ietf-pce-disco-proto-ospf-05.txt that have been implemented. > Personnel > > Who is the Document Shepherd for this document? Adrian Farrel > Who is the Responsible Area Director(s)? Ross Callon, David Ward. > Is an IANA expert needed? No. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 09 05:37:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hliby-0000I3-9a; Wed, 09 May 2007 05:37:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlibw-0000Fv-VA; Wed, 09 May 2007 05:37:28 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlibw-0004Tw-CZ; Wed, 09 May 2007 05:37:28 -0400 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1Hlibv-0002vO-Oo; Wed, 09 May 2007 09:37:27 +0000 Received: from your029b8cecfe ([217.158.132.37] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 May 2007 10:37:26 +0100 Message-ID: <0bc101c7921d$836cc900$61fadf0a@your029b8cecfe> From: "Adrian Farrel" To: "Ross Callon" Date: Wed, 9 May 2007 10:30:32 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 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: 09 May 2007 09:37:26.0670 (UTC) FILETIME=[A7964AE0:01C7921D] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: pce@ietf.org, WG Milestone Tracker , dward@cisco.com Subject: [Pce] Please publish draft-ietf-pce-disco-proto-ospf-05.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 Please publish draft-ietf-pce-disco-proto-ospf-05.txt as a Standards Track RFC. Here is the Document Shepherd write-up. >(1.a) Who is the Document Shepherd for this document? Adrian Farrel > Has the Document Shepherd personally reviewed this version > of the document and, in particular, does he or she believe > this version is ready for forwarding to the IESG for > publication? Yes >(1.b) Has the document had adequate review both from key WG > members and from key non-WG members? Yes. Cross-review to OSPF WG held. > Does the Document Shepherd have any concerns about the > depth or breadth of the reviews that have been performed? No concerns. >(1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar > with AAA, internationalization or XML? No concerns. >(1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area > Director and/or the IESG should be aware of? For example, > perhaps he or she is uncomfortable with certain parts of > the document, or has concerns whether there really is a > need for it. In any event, if the WG has discussed those > issues and has indicated that it still wishes to advance > the document, detail those concerns here. No concerns. > Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion > on this issue. None has been filed. >(1.e) How solid is the WG consensus behind this document? Does > it represent the strong concurrence of a few individuals, > with others being silent, or does the WG as a whole > understand and agree with it? WG agrees. >(1.f) Has anyone threatened an appeal or otherwise indicated > extreme discontent? If so, please summarise the areas of > conflict in separate email messages to the Responsible Area > Director. (It should be in a separate email because this > questionnaire is entered into the ID Tracker.) No. >(1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks > are not enough; this check needs to be thorough. Yes. > Has the document met all formal review criteria it needs > to, such as the MIB Doctor, media type and URI type > reviews? Yes. >(1.h) Has the document split its references into normative and > informative? Yes. > Are there normative references to documents that > are not ready for advancement or are otherwise in an > unclear state? If such normative references exist, what is > the strategy for their completion? There is a normative reference to draft-ietf-ospf-cap that is in the RFC Editor Queue. > Are there normative references that are downward > references, as described in [RFC3967]? If so, list these > downward references to support the Area Director in the > Last Call procedure for them [RFC3967]. No. >(1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the > body of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? > If the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. IANA section is correct. IANA allocation is dependent on the registries created for draft-ietf-ospf-cap that is in the RFC Editor Queue. Identification of the registries is, therefore, necessarily slightly ambiguous. > If the document describes an Expert Review process has > Shepherd conferred with the Responsible Area Director so > that the IESG can appoint the needed Expert during the IESG > Evaluation? None required. >(1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly > in an automated checker? Not applicable. >(1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The > approval announcement contains the following sections: > Technical Summary 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. > Working Group Summary The Working Group had consensus on this document. > Document Quality The protocol extensions have been implemented multiple times. > Personnel > > Who is the Document Shepherd for this document? Adrian Farrel > Who is the Responsible Area Director(s)? Ross Callon, David Ward. > Is an IANA expert needed? No. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 09 08:08: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 1Hlky0-0008N1-UW; Wed, 09 May 2007 08:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXcT-0004LA-3q for pce@ietf.org; Tue, 08 May 2007 17:53:17 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlXc8-0001a4-Pj for pce@ietf.org; Tue, 08 May 2007 17:53:00 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 23:52:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Comments on PCEP implementation Date: Tue, 8 May 2007 23:51:54 +0200 Message-ID: In-Reply-To: <026d01c79100$517afa70$010aa8c0@fing.edu.uy> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on PCEP implementation Thread-Index: AceRAGPJlSTMQbYeQ2eMRfNzqQdw4wAsIaGA References: <026d01c79100$517afa70$010aa8c0@fing.edu.uy> From: "LE ROUX Jean-Louis RD-CORE-LAN" To: =?iso-8859-1?Q?Mart=EDn_Germ=E1n_-_INCO?= , X-OriginalArrivalTime: 08 May 2007 21:52:55.0316 (UTC) FILETIME=[3BE58D40:01C791BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e975ceb8121205cf12ffa969a78dd570 X-Mailman-Approved-At: Wed, 09 May 2007 08:08:23 -0400 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="===============0012732424==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0012732424== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C791BB.3B724773" This is a multi-part message in MIME format. ------_=_NextPart_001_01C791BB.3B724773 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Martin =20 Thanks for the comments, =20 Please see inline, ________________________________ De : Mart=EDn Germ=E1n - INCO [mailto:mgerman@fing.edu.uy]=20 Envoy=E9 : mardi 8 mai 2007 01:35 =C0 : pce@ietf.org Objet : [Pce] Comments on PCEP implementation =09 =09 Hi, We've been following the WG since the early BOF in 2005. We proposed a=20 management interface for the PCE Architecture before Paris meeting in=20 2005: http://www.potaroo.net/ietf/idref/draft-grampin-pce-mgmnt-if/ =09 Now we're finishing an implementation of PCEP (complete except from=20 notifications), a PCC and a PCE. Some doubts has arisen in the=20 development process, which we would like to share with the WG. They're=20 listed hereafter: =09 =09 =3D=3D=3D =20 General edit: In some body format the bits are group by 10 but in others are group by = 8 (or bytes). We think it is better to group in all body formats the = bits by 8 (or bytes). For example: Figure 21 and Figure 22.=20 =20 Good catch, you are right, this will be updated in next revision=20 =20 It doesn't say something like "Unassigned bits are considered as = reserved and MUST be set to zero on transmission" when speaking of the = Flags in several sections (e.g.: section 7.10).=20 =20 OK=20 =20 =3D=3D=3D =20 In section 4.2.6: "In case of TCP connection failure, the PCEP session is immediately = terminated." But in section 5 says: "...it may be desirable to systematically open and close the TCP = connection for each PCEP request (for instance when sending a path = computation request is a rare event)." We think that these 2 sentences are in contradiction, because every = time you close a TCP connection, according to the first you close the = PCEP session. So, when you open the TCP connection again, you need to = open the PCEP session to.=20 =20 Yes the wording is bad, this text corresponds to an old version of the = draft where the notion of PCEP session was not defined.=20 This actualy applies to the PCEP session and not the TCP connection. We = wil update (replace TCP connection by PCEP session in section 5.) =20 =20 =20 =3D=3D=3D =20 In section 6.4: "... the RP and the END-POINTS objects (see section Section 7)." = section is twice.=20 =20 OK=20 =20 =3D=3D=3D =20 In section 6.4: Says "The special case of two BANDWIDTH objects is discussed in details = in Section 7.6." but the BNF permits only one.=20 =20 OK will be updated=20 =20 =3D=3D=3D =20 In section 6.5: "If the path computation request can be satisfied (the PCE finds a set = of path(s) that satisfy the set of constraint(s)), the set of computed = path(s) specified by means of ERO object(s) is inserted in the PCRep = message. The ERO object is defined in Section 7.8." In "ERO object" object is twice (it happens twice).=20 =20 Right, =20 The BNF allowed a NO-PATH with a ERO. If there's no path possible there = isn't a ERO.=20 =20 I agree, but we may want to account for less constrained path = procedures that will be defined in a separate draft. You may have the = ERO of a less constrained path even if there is a NO-PATH object.=20 =20 =3D=3D=3D =20 In section 6.6: " :=3D=3D and :=3D " The "[" and "]" are missing before and = , and after and = . =20 Right =20 =3D=3D=3D =20 In section 6.8: "The Message-Type field of the PCEP common header for the Open message = is set to 7 (To be confirmed by IANA)." It should say "Close message" = instead of "Open message".=20 =20 Right=20 =20 "The Close message MUST contain exactly one CLOSE object (see Section = 6.8)." This reference is little recursive.=20 =20 Right !=20 =20 =3D=3D=3D =20 In section 7.2: "SID (PCEP session-ID - 8 bits): specifies a 2 octet..." We think it = should say 1 octet.=20 =20 Yes=20 =20 =3D=3D=3D =20 In section 7.3: "The P flag of the RP object MUST be set in PCReq and PCReq" It should = say "...in PCReq and PCRep".=20 =20 Right=20 =20 =3D=3D=3D =20 In section 7.3.1: "Reserved (8 bits): ..." In the body format there are 10 bits for = Reserved.=20 =20 Yes will be updated to 8 bits in the body format =20 "Flags: 18 bits" In the body format there are 22 bits for Flags.=20 =20 Right, and this will be actually updated to 24 bits.=20 =20 =3D=3D=3D =20 In section 7.4: "Reserved: ..." It doesn't say the number of Reserved bits (16 bits).=20 =20 OK =20 "The only TLV currently defined is the NO-PATH-VECTOR TLV defined = below." It should say "above".=20 =20 OK=20 =20 =3D=3D=3D =20 In section 7.7: It doesn't say how many bits are Flags.=20 =20 8 bits, will be added.=20 =20 =3D=3D=3D =20 In section 7.10: "Reserved (8 bits):" In the body format there are 10 bits for = Reserved.=20 =20 OK will be updated to 8 bits in the body=20 =20 =3D=3D=3D =20 In section 7.11: It says "IRO object" (again repeating object) four times in the = section.=20 =20 OK =20 At this point, we'd like to say that we agree we the ones that suggest = that the XRO should be included in this draft, mainly for 3 reasons: = it's a useful, very used (it's a common constraint in a request) and = easy to compute constraint.=20 =20 there are many other "easy" constraints that could be added. At some = point in time we need to stop augmenting the base spec...=20 =20 =3D=3D=3D =20 In section: 7.12.1: "(since PCEP allows for the bundling of multiple path computation = requests within a single PCRep message)" it should say "PCReq" instead = of "PCRep".=20 =20 Right,=20 =20 =3D=3D=3D =20 In section 7.12.2: "Flags: ..." It doesn't say the number of Flag bits (24 bits).=20 =20 right, =20 =20 =3D=3D=3D =20 In section 7.13: "Flags: ..." It doesn't say the number of Flag bits (8 bits).=20 =20 right,=20 =20 =3D=3D=3D =20 In section 7.15: "Reserved: ..." It doesn't say the number of Reserved bits (20 bits). "Flags: ..." It doesn't say the number of Flag bits (4 bits).=20 =20 OK=20 =20 =3D=3D=3D =20 In section 7.16: "Reason (4 bits): ..." In the body format there are 8 bits for Reason. "Reserved: ..." It doesn't say the number of Reserved bits (16 bits). "Flags (4 bits): ..." In the body format there are 8 bits for Flags.=20 =20 OK this will be updated=20 =20 The reason value 3 ("PCEP session characteristics negotiation failure") = is never used, because you send an Error message with an ERROR object = with Error-Type =3D 1and corresponding Error-Value.=20 =20 You are right this will be removed =20 =20 =20 =3D=3D=3D =20 In section 9.5: "Error-value=3D2: RRO object missing for a reoptimization request (R = bit of the RP object set)", repeats object.=20 =20 OK=20 =20 =3D=3D=3D =20 In section 10: We think that the variables used to "control" TCP connection (e.g.: = TCPConnect) are useless, along with the paragraph "It is expected that = an implementation...", because you rely the transport on TCP, or is = matter of PCEP to specify how TCP should work?=20 =20 Maybe the naming is confusing, these are definitely not TCP variables = but PCEP variables. We may rename them ConnectWait, ConnectRetry and = MaxConnectRetry. But note that these variables must be discussed here, this is an = application issue, not a TCP issue (see the same approach in RFC 1771 = for instance). =20 The item "Starts the KeepWait timer" in the Idle and TCPPending state = are useless, because you never wait for them, the timer that matters is = OpenWait.=20 =20 right, =20 In the UP State, says "If the system detects that the PCEP peer tries = to setup a second TCP connection, it stops the TCP connection = establishment and sends a PCErr with Error-Type=3D10.", the Error-Type = should be 9. The PCEP peer never expect this message when attempting to = established a PCEP session, sending this message causes that the peer = sends an Error message back.=20 =20 Good catch, we should remove it. =20 =3D=3D=3D =20 Thanks a lot for these really useful comments=20 =20 Best Regards =20 JL=20 =09 Best regards, Alberto, Mart=EDn & Eduardo ------_=_NextPart_001_01C791BB.3B724773 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Martin
 
Thanks for the comments,
 
Please see inline,

De : Mart=EDn Germ=E1n - INCO = [mailto:mgerman@fing.edu.uy]
Envoy=E9 : mardi 8 mai = 2007=20 01:35
=C0 : pce@ietf.org
Objet : [Pce] = Comments on=20 PCEP implementation

Hi,
We've been following the WG = since the=20 early BOF in 2005. We proposed a
management interface for the PCE=20 Architecture before Paris meeting in
2005: http://www.potaroo.net/ietf/idref/draft-grampin-pce-mgmnt-if/

Now we're finishing an implementation of PCEP = (complete=20 except from
notifications), a PCC and a PCE. Some doubts has = arisen in the=20
development process, which we would like to share with the WG. = They're=20
listed hereafter:

=3D=3D=3D

 

General=20 edit:

In some body format the = bits are=20 group by 10 but in others are group by 8 (or bytes). We think it is = better to=20 group in all body formats the bits by 8 (or bytes). For example: = Figure 21 and=20 Figure 22. 

 

Good catch, you = are right,=20 this will be updated in=20 next revision 

 

It doesn=92t say = something like=20 =93Unassigned bits are considered as reserved and MUST be set to zero = on=20 transmission=94 when speaking of the Flags in several sections (e.g.: = section=20 7.10). 

 

OK 

 

=3D=3D=3D

 

In section=20 4.2.6:

=93In case of TCP = connection=20 failure, the PCEP session is immediately = terminated.=94

But in section 5=20 says:

=93=85it may be = desirable to=20 systematically open and close the TCP connection for each PCEP request = (for=20 instance when sending a path computation request is a rare=20 event).=94

We think that these 2 = sentences=20 are in contradiction, because every time you close a TCP connection, = according=20 to the first you close the PCEP session. So, when you open the TCP = connection=20 again, you need to open the PCEP session to. 

 

Yes the wording is = bad, this=20 text corresponds to an old version of the draft where the notion of = PCEP=20 session was not defined. 

This actualy applies = to the PCEP=20 session and not the TCP connection. We wil update (replace TCP = connection by=20 PCEP session in section 5.)

 

 

 

=3D=3D=3D

 

In section=20 6.4:

=93=85 the RP and the = END-POINTS=20 objects (see section Section 7).=94 section is twice. 

 

OK 

 

=3D=3D=3D

 

In section=20 6.4:

Says =93The special case = of two=20 BANDWIDTH objects is discussed in details in Section 7.6.=94 but the = BNF permits=20 only one. 

 

OK will be=20 updated 

 

=3D=3D=3D

 

In section=20 6.5:

=93If the path = computation request=20 can be satisfied (the PCE finds a set of path(s) that satisfy the set = of=20 constraint(s)), the set of computed path(s) specified by means of ERO=20 object(s) is inserted in the PCRep message. The ERO object is defined = in=20 Section 7.8.=94

In =93ERO object=94 = object is twice=20 (it happens twice). 

 

Right,

 

The BNF allowed a = NO-PATH with a=20 ERO. If there's no path possible there isn't a ERO. 

 

I agree, but we may = want to=20 account for less constrained path procedures that will be=20 defined in a separate draft. You may have the ERO of a less=20 constrained path even if there

is a NO-PATH=20 object. 

 

=3D=3D=3D

 

In section=20 6.6:

=93<request-id-list> :=3D=3D=20 <RP><request-id-list> and

<notification-list> :=3D=20 <NOTIFICATION><notification-list>=94

The =93[=94 and =93]=94 = are missing before=20 <request-id-list> and <notification-list>, and after=20 <request-id-list> and = <notification-list>.

 

Right

 

=3D=3D=3D

 

In section=20 6.8:

=93The Message-Type = field of the=20 PCEP common header for the Open message is set to 7 (To be confirmed = by=20 IANA).=94 It should say =93Close message=94 instead of =93Open = message=94. 

 

Right 

 

=93The Close message = MUST contain=20 exactly one CLOSE object (see Section 6.8).=94

This reference is little = recursive. 

 

Right ! 

 

=3D=3D=3D

 

In section=20 7.2:

=93SID (PCEP session-ID = - 8 bits):=20 specifies a 2 octet=85=94 We think it should say 1 octet. 

 

Yes 

 

=3D=3D=3D

 

In section=20 7.3:

=93The P flag of the RP = object MUST=20 be set in PCReq and PCReq=94 It should say =93...in PCReq and = PCRep=94. 

 

Right 

 

=3D=3D=3D

 

In section=20 7.3.1:

=93Reserved (8 bits): = =85=94 In the body=20 format there are 10 bits for Reserved. 

 

Yes will be updated = to 8 bits in=20 the body format

 

=93Flags: 18 bits=94 In = the body=20 format there are 22 bits for Flags. 

 

Right, and this will = be actually=20 updated to 24 bits. 

 

=3D=3D=3D

 

In section=20 7.4:

=93Reserved: =85=94 It = doesn=92t say the=20 number of Reserved bits (16 bits). 

 

OK

 

=93The only TLV = currently defined is=20 the NO-PATH-VECTOR TLV defined below.=94 It should say = =93above=94. 

 

OK 

 

=3D=3D=3D

 

In section=20 7.7:

It doesn=92t say how = many bits are=20 Flags. 

 

8 bits, will be=20 added. 

 

=3D=3D=3D

 

In section=20 7.10:

 =93Reserved (8 bits):=94 In = the body format=20 there are 10 bits for Reserved. 

 

OK will be updated to = 8 bits in=20 the body 

 

=3D=3D=3D

 

In section=20 7.11:

It says =93IRO object=94 = (again=20 repeating object) four times in the section. 

 

OK

 

At this point, we=92d = like to say=20 that we agree we the ones that suggest that the XRO should be included = in this=20 draft, mainly for 3 reasons: it=92s a useful, very used (it=92s a = common=20 constraint in a request) and easy to compute constraint. 

 

there are many other = "easy"=20 constraints that could be added. At some point in time we need to stop = augmenting the base spec...

 

=3D=3D=3D

 

In section:=20 7.12.1:

=93(since PCEP allows = for the=20 bundling of multiple path computation requests within a single PCRep = message)=94=20 it should say =93PCReq=94 instead of =93PCRep=94. 

 

Right, 

 

=3D=3D=3D

 

In section=20 7.12.2:

=93Flags: =85=94 It = doesn=92t say the=20 number of Flag bits (24 bits). 

 

right,=20  

 

=3D=3D=3D

 

In section=20 7.13:

=93Flags: =85=94 It = doesn=92t say the=20 number of Flag bits (8 bits). 

 

right, 

 

=3D=3D=3D

 

In section=20 7.15:

=93Reserved: =85=94 It = doesn=92t say the=20 number of Reserved bits (20 bits).

=93Flags: =85=94 It = doesn=92t say the=20 number of Flag bits (4 bits). 

 

OK 

 

=3D=3D=3D

 

In section=20 7.16:

=93Reason (4 bits): = =85=94 In the body=20 format there are 8 bits for Reason.

=93Reserved: =85=94 It = doesn=92t say the=20 number of Reserved bits (16 bits).

=93Flags (4 bits): = =85=94 In the body=20 format there are 8 bits for Flags. 

 

OK this will be=20 updated 

 

The reason value 3 = (=93PCEP session=20 characteristics negotiation failure=94) is never used, because you = send an Error=20 message with an ERROR object with Error-Type =3D 1and corresponding=20 Error-Value. 

 

You are right this = will be=20 removed

 

 

 

=3D=3D=3D

 

In section=20 9.5:

=93Error-value=3D2: RRO = object missing=20 for a reoptimization request (R bit of the RP object set)=94, repeats=20 object. 

 

OK 

 

=3D=3D=3D

 

In section=20 10:

We think that the = variables used=20 to =93control=94 TCP connection (e.g.: TCPConnect) are useless, along = with the=20 paragraph =93It is expected that an implementation=85=94, because you = rely the=20 transport on TCP, or is matter of PCEP to specify how TCP should = work? 

 

Maybe the naming is = confusing,=20 these are definitely not TCP variables but PCEP variables. We may = rename them=20 ConnectWait, ConnectRetry and = MaxConnectRetry.

But note that these = variables=20 must be discussed here, this is an application issue, not a TCP issue = (see the=20 same approach in RFC 1771 for instance).

 

The item =93Starts the = KeepWait=20 timer=94 in the Idle and TCPPending state are useless, because you = never wait=20 for them, the timer that matters is OpenWait. 

 

right,

 

In the UP State, says = =93If the=20 system detects that the PCEP peer tries to setup a second TCP = connection, it=20 stops the TCP connection establishment and sends a PCErr with = Error-Type=3D10.=94,=20 the Error-Type should be 9. The PCEP peer never expect this message = when=20 attempting to established a PCEP session, sending this message causes = that the=20 peer sends an Error message back. 

 

Good catch, = we should remove=20 it.

 

=3D=3D=3D

 
Thanks a lot for these really useful = comments 
 
Best=20 Regards
 
JL 

Best=20 regards,
Alberto, Mart=EDn &=20 Eduardo
------_=_NextPart_001_01C791BB.3B724773-- --===============0012732424== 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 --===============0012732424==-- From pce-bounces@lists.ietf.org Wed May 09 20:58: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 1Hlwzc-0001ix-VU; Wed, 09 May 2007 20:58:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlwzb-0001gT-A1 for pce@ietf.org; Wed, 09 May 2007 20:58:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlwza-0003GC-MH for pce@ietf.org; Wed, 09 May 2007 20:58:51 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 May 2007 20:58:50 -0400 X-IronPort-AV: i="4.14,512,1170651600"; d="scan'208,217"; a="59852410:sNHT98276122" 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 l4A0won1003246; Wed, 9 May 2007 20:58:50 -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 l4A0wnlG000081; Thu, 10 May 2007 00:58:49 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); Wed, 9 May 2007 20:58:49 -0400 Received: from [10.86.104.185] ([10.86.104.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 20:58:47 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: Young Lee , LE ROUX Jean-Louis RD-CORE-LAN , Eiji Oki , Daniel King , pce@ietf.org Message-Id: From: JP Vasseur Date: Wed, 9 May 2007 20:58:44 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 May 2007 00:58:47.0989 (UTC) FILETIME=[5DD22650:01C7929E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16401; t=1178758730; x=1179622730; 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:=20Comments=20on=20draft-lee-pce-global-concurrent-optimization- 03.txt |Sender:=20 |To:=20Young=20Lee=20, =0A=20=20=20=20=20=20=20=20LE=20RO UX=20Jean-Louis=20RD-CORE-LAN=20, =0A= 20=20=20=20=20=20=20=20Eiji=20Oki=20, =0A=20=20=20= 20=20=20=20=20Daniel=20King=20, =20pce@ietf. org; bh=YmZ1mxbhxoOe2D8KPWBqumjR6Np2DMno9+wZ93xscJU=; b=TQgUIo4bUi8IjmVbtljUkNtfqdTDDMXWhu00g2bAGrpLg2ICey6oMVNsmN400MNNqa2cFPPY XFp5R73r+BpvpxGeitNmVhRpLI9KuFSZX6VICPfl/8iVcqby6DlM4sKo; 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: 10d2fdecab7a7fa796e06e001d026c91 Cc: Subject: [Pce] Comments on draft-lee-pce-global-concurrent-optimization-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0216875676==" Errors-To: pce-bounces@lists.ietf.org --===============0216875676== Content-Type: multipart/alternative; boundary=Apple-Mail-35-735544867 --Apple-Mail-35-735544867 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, The authors requested the WG to adopt draft-lee-pce-global-concurrent- optimization-03.txt as a PCE WG document but before pooling the list, I'd like to make a few comments/requests: This solution is indeed compliant with RFC4655 and as pointed out in the ID, PCEP already supports synchronized path computation requests through the use of the SVEC object. 1) The PCEP extensions defined in this document are quite reasonable and do not substantially overload the protocol itself. That being said, the exchange of a substantially large amount of data will unavoidably stress the machinery in a significant way. Scalability of solutions trying to achieve global optimization have been discussed in length so I won't propose to re-open a fairly old debate but it is well-understood that such solutions do not scale well and the major bottleneck is not just the path computation itself but the bulk of data that must be exchanged, synchronization issues, failures during reoptimization and so on. Thus I'd suggest to add some applicability section to this ID that would discuss the context in which such solution would apply (e.g. network with thousands of packet LSPs (hopefully not!), optical LSPs with a few hundreds of LSPs with multi- constraints optimization problems where bandwidth fragmentation is a real issue because of a limited number of discrete bandwidth values). 2) It is also envisioned that network operators might require a global concurrent path computation in the event of catastrophic network failures, where a set of TE LSPs need to be optimally rerouted in real-time. I do not think that such model could be used for "real-time" rerouting. 3) The main focus of this document is to highlight the PCC-PCE communication needs in support of a concurrent path computation application and to define protocol extensions to meet those needs. You may want to stress the fact that in your ID the PCC is an NMS system and this is key. Indeed, one can define models where the PCCs are LSRs and the PCE is used to provide globally optimal solutions ... Such models suffers from drastic scalability and robustness issues. 4) Green field: not sure to buy this argument since as soon as the TE LSPs are set up, the network is no longer in this green field state 5) Note that sequential re- optimization of such TE LSPs is unlikely to produce substantial improvements in overall network optimization except in very sparsely utilized networks. Well, that DEPENDS ! I could show you distributed algorithms where sequential reoptimization allows for a significant improvements. I would suggest to remove that statement. 6) A Multi-Session Indicator: I'm not exactly sure that we should overload the machinery even more w/o more experience on how such feature could actually help. May I suggest to potentially add it in a second phase? 7) A word of cautious here During a reoptimization it may be required to move a LSP several times so as to avoid traffic disruption. The response message must allow indicating the path sequence for each request. We all know that in some cases, traffic disruption may be avoided thanks to a multi-step rerouting approach where some TE LSP may be rerouted N times. This is another example where such model may have significant impact on the network and even when traffic disruption can be avoided, there is still an impact in term of control plane, traffic shift (=> jitter) although this can be another constraint taken in to account when computing the various rerouting steps. For example, would you want to add a paragraph listing the drawbacks of such approach (e.g. trade-off between optimization gain and network impact, ....) ? 8) Objective functions should be moved to PCEP, as discussed. 9) LSP ordering is always requested by the PCC but it might be desirable to have the PCE indicating whether ordering is in fact required or not. For example, the NMS could send a reoptimization request to which the PCE would reply with a ordered or non-ordered set of computed paths. Thanks. JP. --Apple-Mail-35-735544867 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hi,

The authors = requested the WG to adopt = draft-lee-pce-global-concurrent-optimization-03.txt as a PCE WG document = but before pooling the list, I'd like to make a few = comments/requests:

This solution is indeed compliant with RFC4655 and = as pointed out in the ID, PCEP already supports synchronized path = computation requests through the use of the SVEC object.

1) The PCEP = extensions defined in this document are quite reasonable and do not = substantially overload the protocol itself. That being said, the = exchange of a=A0substantially large amount of data will unavoidably = stress the machinery in a significant way. Scalability of solutions = trying to achieve global optimization have been discussed in length so I = won't propose to re-open a fairly old debate but it is well-understood = that such solutions do not scale well and the major=A0bottleneck is not = just the path computation itself but the bulk of data that must be = exchanged, synchronization issues, failures during reoptimization and so = on.=A0Thus I'd suggest to add some applicability section to this ID that = would discuss the context in which such solution would apply (e.g. = network with thousands of packet LSPs (hopefully not!), optical LSPs = with a few hundreds of LSPs with multi-constraints optimization problems = where bandwidth fragmentation is a real issue because of a limited = number of discrete bandwidth values).

2)

=A0 =A0It = is also envisioned that network operators might
=A0=A0 require a global concurrent path = computation in the event of
=A0=A0 = catastrophic network failures, where a set of TE LSPs need to = be
=A0=A0 optimally rerouted in = real-time.

I do not think that such model could be used for = "real-time" rerouting.

3)

=A0 =A0The main = focus of this document is to highlight the PCC-PCE
=A0=A0 communication needs in support of a = concurrent path computation
=A0=A0 = application and to define protocol extensions to meet those = needs.

You may want to stress the fact that in your ID the = PCC is an NMS system and this is key. Indeed, one can define models = where the PCCs are LSRs and the PCE is used to provide globally optimal = solutions ... Such models suffers from drastic scalability and = robustness issues.

4)=A0Green field: not sure to buy this argument = since as soon as the TE LSPs are set up, the network is no longer in = this green field state

5)

=A0 =A0Note that sequential re-
=A0=A0 optimization of such TE LSPs is unlikely = to produce substantial
=A0=A0 = improvements in overall network optimization except in very = sparsely
=A0=A0 utilized = networks.

Well, that DEPENDS ! I could show you distributed = algorithms where sequential reoptimization allows for a significant = improvements. I would suggest to remove that statement.

6)=A0A = Multi-Session Indicator: I'm not exactly sure that we should overload = the machinery even more w/o more experience on how such feature could = actually help. May I suggest to potentially add it in a second = phase?

7)=A0A word of cautious here

=A0 =A0=A0 =A0=A0 =A0During a = reoptimization it may be required to move a LSP
=A0 =A0 =A0 =A0=A0 several times so as to avoid = traffic disruption.=A0 The response
=A0 =A0= =A0 =A0=A0 message must allow indicating the path sequence for = each
=A0 =A0 =A0 =A0=A0 = request.

We all know that in some cases, traffic disruption = may be avoided thanks to a multi-step rerouting approach where some TE = LSP may be rerouted N times. This is another example where such model = may have significant impact on the network and even when traffic = disruption can be avoided, there is still an impact in term of control = plane, traffic shift (=3D> jitter) although this can be another = constraint taken in to account when computing the various rerouting = steps.=A0For example, would you want to add a paragraph listing the = drawbacks of such approach (e.g. trade-off between=A0optimization gain = and network impact, ....) ?

8) Objective functions should be moved to PCEP, as = discussed.

9) LSP ordering is always requested by the PCC but = it might be desirable to have the PCE indicating whether ordering is in = fact required or not. For example, the NMS could send a reoptimization = request to which the PCE would reply with a ordered or non-ordered set = of computed paths.

Thanks.

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmATR-0002Ak-Qq; Thu, 10 May 2007 11:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmATP-0002Ac-Rt for pce@lists.ietf.org; Thu, 10 May 2007 11:22:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HmATO-00047K-E1 for pce@lists.ietf.org; Thu, 10 May 2007 11:22:31 -0400 Received: (qmail 450 invoked by uid 0); 10 May 2007 15:22:29 -0000 Received: from 192.35.17.21 by www019.gmx.net with HTTP; Thu, 10 May 2007 17:22:29 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 10 May 2007 17:22:29 +0200 From: _den@gmx.de Message-ID: <20070510152229.319070@gmx.net> MIME-Version: 1.0 To: pce@lists.ietf.org X-Authenticated: #19887475 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+RVkhu2CuR4nt7dyNfNEufkk6fOAsVYs5nJsN49A O2otHzO2h4RKOlYZW4716DPUVBJ3b7e/eQrw== Content-Transfer-Encoding: 8bit X-GMX-UID: jQpwcsk1X1V6FUcYQ2ByGYp/SDc4NEw3 X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Pce] Description of OpenWait state 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 found one part of description of OpenWait state in section 10 not correct. "If no errors are detected, PCEP increments the OpenRetry variable." This part seems to be in contradiction to the definition of the OpenRetry variable at the beginning of section 10. This variable should be incremented after it was determined whether the session characteristics are acceptable or not. Best Regards -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 10 13:29:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmCSO-0001xu-8M; Thu, 10 May 2007 13:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmCSN-0001xo-6V for pce@lists.ietf.org; Thu, 10 May 2007 13:29:35 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmCSH-0005G0-UZ for pce@lists.ietf.org; Thu, 10 May 2007 13:29:35 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 19:29:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Description of OpenWait state Date: Thu, 10 May 2007 19:29:18 +0200 Message-ID: In-Reply-To: <20070510152229.319070@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Description of OpenWait state Thread-Index: AceTFxOWdwGzuUc1T9SArWTvWqseXwADQBYg References: <20070510152229.319070@gmx.net> From: "LE ROUX Jean-Louis RD-CORE-LAN" To: <_den@gmx.de>, X-OriginalArrivalTime: 10 May 2007 17:29:20.0873 (UTC) FILETIME=[BE948D90:01C79328] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Den Good catch, we will update. Thanks. JL > -----Message d'origine----- > De : _den@gmx.de [mailto:_den@gmx.de]=20 > Envoy=E9 : jeudi 10 mai 2007 17:22 > =C0 : pce@lists.ietf.org > Objet : [Pce] Description of OpenWait state >=20 > Hi, >=20 > I found one part of description of OpenWait state in section=20 > 10 not correct. >=20 > "If no errors are detected, PCEP increments the OpenRetry variable." >=20 > This part seems to be in contradiction to the definition of=20 > the OpenRetry variable at the beginning of section 10. This=20 > variable should be incremented after it was determined=20 > whether the session characteristics are acceptable or not. >=20 > Best Regards > -- > Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt? > Der kanns mit allen: http://www.gmx.net/de/go/multimessenger >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 10 16:11:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEz7-00073t-HM; Thu, 10 May 2007 16:11:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEz5-00073o-VB for pce@ietf.org; Thu, 10 May 2007 16:11:31 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmEyz-0002Ad-Ob for pce@ietf.org; Thu, 10 May 2007 16:11:31 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHU00C22DF0I7@usaga01-in.huawei.com> for pce@ietf.org; Thu, 10 May 2007 13:11:25 -0700 (PDT) Received: from Lee736821 ([10.124.12.82]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JHU008D8DEXWQ@usaga01-in.huawei.com> for pce@ietf.org; Thu, 10 May 2007 13:11:24 -0700 (PDT) Date: Thu, 10 May 2007 15:11:21 -0500 From: Young Lee To: 'JP Vasseur' , 'Adrian Farrel' , pce@ietf.org Message-id: <001b01c7933f$605f27a0$520c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AceTHEnO5ANo69SiRs2TURdRucfYsAAGLryA X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: Subject: [Pce] FW: Pce Digest, Vol 33, Issue 7 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, Thanks for your valuable comments and suggestions. I believe all of your comments and concerns have been carefully looked at and clarified. Please see inline for our response. Best Regards, Young -----Original Message----- From: pce-request@lists.ietf.org [mailto:pce-request@lists.ietf.org] Sent: Thursday, May 10, 2007 11:00 AM To: pce@lists.ietf.org Subject: Pce Digest, Vol 33, Issue 7 Send Pce mailing list submissions to pce@lists.ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/pce or, via email, send a message with subject or body 'help' to pce-request@lists.ietf.org You can reach the person managing the list at pce-owner@lists.ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Pce digest..." Today's Topics: 1. Comments on draft-lee-pce-global-concurrent-optimization-03.txt (JP Vasseur) 2. Description of OpenWait state (_den@gmx.de) ---------------------------------------------------------------------- Message: 1 Date: Wed, 9 May 2007 20:58:44 -0400 From: JP Vasseur Subject: [Pce] Comments on draft-lee-pce-global-concurrent-optimization-03.txt To: Young Lee , LE ROUX Jean-Louis RD-CORE-LAN , Eiji Oki , Daniel King , pce@ietf.org Message-ID: Content-Type: text/plain; charset="us-ascii" Hi, The authors requested the WG to adopt draft-lee-pce-global-concurrent- optimization-03.txt as a PCE WG document but before pooling the list, I'd like to make a few comments/requests: This solution is indeed compliant with RFC4655 and as pointed out in the ID, PCEP already supports synchronized path computation requests through the use of the SVEC object. 1) The PCEP extensions defined in this document are quite reasonable and do not substantially overload the protocol itself. That being said, the exchange of a substantially large amount of data will unavoidably stress the machinery in a significant way. Scalability of solutions trying to achieve global optimization have been discussed in length so I won't propose to re-open a fairly old debate but it is well-understood that such solutions do not scale well and the major bottleneck is not just the path computation itself but the bulk of data that must be exchanged, synchronization issues, failures during reoptimization and so on. Thus I'd suggest to add some applicability section to this ID that would discuss the context in which such solution would apply (e.g. network with thousands of packet LSPs (hopefully not!), optical LSPs with a few hundreds of LSPs with multi- constraints optimization problems where bandwidth fragmentation is a real issue because of a limited number of discrete bandwidth values). >> We can add applicability section to elaborate this request. We can indicate that this mechanism applies specifically to GMPLS optical networks with a few hundreds of LSPs. 2) It is also envisioned that network operators might require a global concurrent path computation in the event of catastrophic network failures, where a set of TE LSPs need to be optimally rerouted in real-time. I do not think that such model could be used for "real-time" rerouting. >> I agree with you. We can remove this statement. 3) The main focus of this document is to highlight the PCC-PCE communication needs in support of a concurrent path computation application and to define protocol extensions to meet those needs. You may want to stress the fact that in your ID the PCC is an NMS system and this is key. Indeed, one can define models where the PCCs are LSRs and the PCE is used to provide globally optimal solutions ... Such models suffers from drastic scalability and robustness issues. >> The PCE GCO is primarily an NMS based solution. In section 3.3 (Application of PCE architecture) of the current draft clearly spells out that GCO is NMS based solution. With GCO, a PCC has to know all LSP requests, hence this cannot be a LSR. 4) Green field: not sure to buy this argument since as soon as the TE LSPs are set up, the network is no longer in this green field state >> OK. The main use of GCO application is re-optimization of an existing network. 5) Note that sequential re- optimization of such TE LSPs is unlikely to produce substantial improvements in overall network optimization except in very sparsely utilized networks. Well, that DEPENDS ! I could show you distributed algorithms where sequential reoptimization allows for a significant improvements. I would suggest to remove that statement. >> Yes, it actually depends on the topology, the traffic matrix, the online algorithm used, etc. We will delete this statement. 6) A Multi-Session Indicator: I'm not exactly sure that we should overload the machinery even more w/o more experience on how such feature could actually help. May I suggest to potentially add it in a second phase? >> OK. We can move this feature to a second phase. 7) A word of cautious here During a reoptimization it may be required to move a LSP several times so as to avoid traffic disruption. The response message must allow indicating the path sequence for each request. We all know that in some cases, traffic disruption may be avoided thanks to a multi-step rerouting approach where some TE LSP may be rerouted N times. This is another example where such model may have significant impact on the network and even when traffic disruption can be avoided, there is still an impact in term of control plane, traffic shift (=> jitter) although this can be another constraint taken in to account when computing the various rerouting steps. For example, would you want to add a paragraph listing the drawbacks of such approach (e.g. trade-off between optimization gain and network impact, ....) ? >> We can add a paragraph to indicate the potential impact by this feature. By the way the trade-off is not optimization vs. network impact. It is traffic disruption vs. network impact. If we want to avoid traffic disruption, we need this multiple rerouting, which is the price to pay at the expense of network impact. 8) Objective functions should be moved to PCEP, as discussed. >> Just for clarification, in Prague, it was agreed with Jerry and the authors of the PCE-OF draft that all the objective functions listed in 4657 will be defined in the PCE-OF draft provided that PCE-OF draft would be adopted as WG doc. It was also agreed that any new application driven objective functions will be defined in the application draft via the OF code point mechanism specified in PCE-OF draft. This includes the following Objective Functions from 4657: Extract from 4657 section 5.1.17: Also, the PCECP MUST support at least the following "synchronized" objective functions: - Minimize aggregate bandwidth consumption on all links - Maximize the residual bandwidth on the most loaded link - Minimize the cumulative cost of a set of diverse paths in GCO we defined 3 OF 1 Minimize the sum of all TE LSP costs (min cost) 2 Maximize the residual bandwidth on the most loaded link 3 Evenly allocate the network load to achieve the most uniform link utilization across all links* Actually function 2 is listed in 4657 and will have to be moved to the OF draft. Other functions (1 and 3) are not listed in 4657 and should stay in the GCO draft. 9) LSP ordering is always requested by the PCC but it might be desirable to have the PCE indicating whether ordering is in fact required or not. For example, the NMS could send a reoptimization request to which the PCE would reply with a ordered or non-ordered set of computed paths. >> Yes, we can accommodate your request in the new version. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce End of Pce Digest, Vol 33, Issue 7 ********************************** _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu May 10 17:22: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 1HmG5x-0005rr-7z; Thu, 10 May 2007 17:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmG5v-0005ou-Jr for pce@ietf.org; Thu, 10 May 2007 17:22:39 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmG5u-0002VL-QK for pce@ietf.org; Thu, 10 May 2007 17:22:39 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 10 May 2007 14:22:39 -0700 X-IronPort-AV: i="4.14,519,1170662400"; d="scan'208"; a="420796211:sNHT61558014" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4ALMcME011410; Thu, 10 May 2007 14:22:38 -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 l4ALMGx3012917; Thu, 10 May 2007 21:22:33 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, 10 May 2007 17:22:16 -0400 Received: from [10.86.104.185] ([10.86.104.185]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 17:22:15 -0400 In-Reply-To: <001b01c7933f$605f27a0$520c7c0a@china.huawei.com> References: <001b01c7933f$605f27a0$520c7c0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C05F8AA-1A9E-4130-8A25-1FE88ADE8576@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 10 May 2007 17:22:10 -0400 To: Young Lee X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 May 2007 21:22:16.0029 (UTC) FILETIME=[486C20D0:01C79349] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10180; t=1178832158; x=1179696158; c=relaxed/simple; s=sjdkim7002; 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=20Pce=20Digest,=20Vol=2033,=20Issue=207 |Sender:=20; bh=5AcijH6h3+wVaGbT4mbGsAqchro77JZ3YsbvFUrjVG8=; b=h32/G8Q9oZev4V4ggca3icP2bPHXLQSin2yRBWJpdZX6KzHaFLf6TuiZwbdChlSKpbuFGPtJ 6YU3bATEJQi6ZUNYOId15ZkRILlp7h+m0x3I3VAwe/Iy7gewjt5wdjPB; Authentication-Results: sj-dkim-7; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: pce@ietf.org Subject: [Pce] Re: Pce Digest, Vol 33, Issue 7 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, On May 10, 2007, at 4:11 PM, Young Lee wrote: > Hi J-P, > > Thanks for your valuable comments and suggestions. I believe all of > your > comments and concerns have been carefully looked at and clarified. Thanks for addressing my comments - see in line, > Please > see inline for our response. > > Best Regards, > > Young > > -----Original Message----- > From: pce-request@lists.ietf.org [mailto:pce-request@lists.ietf.org] > Sent: Thursday, May 10, 2007 11:00 AM > To: pce@lists.ietf.org > Subject: Pce Digest, Vol 33, Issue 7 > > Send Pce mailing list submissions to > pce@lists.ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/pce > or, via email, send a message with subject or body 'help' to > pce-request@lists.ietf.org > > You can reach the person managing the list at > pce-owner@lists.ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pce digest..." > > > Today's Topics: > > 1. Comments on > draft-lee-pce-global-concurrent-optimization-03.txt (JP Vasseur) > 2. Description of OpenWait state (_den@gmx.de) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 May 2007 20:58:44 -0400 > From: JP Vasseur > Subject: [Pce] Comments on > draft-lee-pce-global-concurrent-optimization-03.txt > To: Young Lee , LE ROUX Jean-Louis RD-CORE-LAN > , Eiji Oki > , Daniel King > , > pce@ietf.org > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi, > > The authors requested the WG to adopt draft-lee-pce-global-concurrent- > optimization-03.txt as a PCE WG document but before pooling the list, > I'd like to make a few comments/requests: > > This solution is indeed compliant with RFC4655 and as pointed out in > the ID, PCEP already supports synchronized path computation requests > through the use of the SVEC object. > > 1) The PCEP extensions defined in this document are quite reasonable > and do not substantially overload the protocol itself. That being > said, the exchange of a substantially large amount of data will > unavoidably stress the machinery in a significant way. Scalability of > solutions trying to achieve global optimization have been discussed > in length so I won't propose to re-open a fairly old debate but it is > well-understood that such solutions do not scale well and the major > bottleneck is not just the path computation itself but the bulk of > data that must be exchanged, synchronization issues, failures during > reoptimization and so on. Thus I'd suggest to add some applicability > section to this ID that would discuss the context in which such > solution would apply (e.g. network with thousands of packet LSPs > (hopefully not!), optical LSPs with a few hundreds of LSPs with multi- > constraints optimization problems where bandwidth fragmentation is a > real issue because of a limited number of discrete bandwidth values). > >>> We can add applicability section to elaborate this request. We can > indicate that this mechanism applies specifically to GMPLS optical > networks > with a few hundreds of LSPs. OK Thanks. > > 2) > > It is also envisioned that network operators might > require a global concurrent path computation in the event of > catastrophic network failures, where a set of TE LSPs need to be > optimally rerouted in real-time. > > I do not think that such model could be used for "real-time" > rerouting. > >>> I agree with you. We can remove this statement. OK > > 3) > > The main focus of this document is to highlight the PCC-PCE > communication needs in support of a concurrent path computation > application and to define protocol extensions to meet those needs. > > You may want to stress the fact that in your ID the PCC is an NMS > system and this is key. Indeed, one can define models where the PCCs > are LSRs and the PCE is used to provide globally optimal > solutions ... Such models suffers from drastic scalability and > robustness issues. > >>> The PCE GCO is primarily an NMS based solution. In section 3.3 > (Application of PCE architecture) of the current draft clearly > spells out > that GCO is NMS based solution. With GCO, a PCC has to know all LSP > requests, hence this cannot be a LSR. Well that could be done with PCC=LSR thanks to complex synchronization (which I'm NOT advocating of course) hence my comment. Could you restate in the abstract/Introduction that in your proposal the PCC is indeed an NMS. > > 4) Green field: not sure to buy this argument since as soon as the TE > LSPs are set up, the network is no longer in this green field state > >>> OK. The main use of GCO application is re-optimization of an >>> existing > network. > > 5) > > Note that sequential re- > optimization of such TE LSPs is unlikely to produce substantial > improvements in overall network optimization except in very > sparsely > utilized networks. > > Well, that DEPENDS ! I could show you distributed algorithms where > sequential reoptimization allows for a significant improvements. I > would suggest to remove that statement. > >>> Yes, it actually depends on the topology, the traffic matrix, the >>> online > algorithm used, etc. We will delete this statement. Thanks. > > 6) A Multi-Session Indicator: I'm not exactly sure that we should > overload the machinery even more w/o more experience on how such > feature could actually help. May I suggest to potentially add it in a > second phase? > >>> OK. We can move this feature to a second phase. OK Thanks. > > 7) A word of cautious here > > During a reoptimization it may be required to move a LSP > several times so as to avoid traffic disruption. The > response > message must allow indicating the path sequence for each > request. > > We all know that in some cases, traffic disruption may be avoided > thanks to a multi-step rerouting approach where some TE LSP may be > rerouted N times. This is another example where such model may have > significant impact on the network and even when traffic disruption > can be avoided, there is still an impact in term of control plane, > traffic shift (=> jitter) although this can be another constraint > taken in to account when computing the various rerouting steps. For > example, would you want to add a paragraph listing the drawbacks of > such approach (e.g. trade-off between optimization gain and network > impact, ....) ? > >>> We can add a paragraph to indicate the potential impact by this >>> feature. > By the way the trade-off is not optimization vs. network impact. It is > traffic disruption vs. network impact. If we want to avoid traffic > disruption, we need this multiple rerouting, which is the price to > pay at > the expense of network impact. OK let me restate my comment here: the point I was trying to make is the following: even if the set of TE LSPs can be reoptimized with no traffic loss for example, the need for multiple reroutes has a cost in term of traffic impact (jitter, ...) + control plane stress. It may be worth mentioning that aspect also, this is why I mentioned a trade-off between optimization versus network impact. Indeed, if you can reoptimize the set of TE LSPs in order to reduce the max link utilization by 5% but this requires to reroute two hundreds TE LSPs with on the average 4 reroutes per TE LSP, this may not be a good idea. > > 8) Objective functions should be moved to PCEP, I typed too fast: I indeed meant to refer to the objective function draft, as agreed with Jerry since I was pushing myself for not adding more to PCEP. > as discussed. > >>> Just for clarification, in Prague, it was agreed with Jerry and the > authors of the PCE-OF draft that all the objective functions listed > in 4657 > will be defined in the PCE-OF draft provided that PCE-OF draft > would be > adopted as WG doc. It was also agreed that any new application driven > objective functions will be defined in the application draft via > the OF code > point mechanism specified in PCE-OF draft. > > This includes the following Objective Functions from 4657: > > Extract from 4657 section 5.1.17: > > Also, the PCECP MUST support at least the following "synchronized" > objective functions: > > - Minimize aggregate bandwidth consumption on all links > - Maximize the residual bandwidth on the most loaded link > - Minimize the cumulative cost of a set of diverse paths > > > in GCO we defined 3 OF > > 1 Minimize the sum of all TE LSP costs (min cost) > > 2 Maximize the residual bandwidth on the most loaded > link > > 3 Evenly allocate the network load to achieve the > most uniform link utilization across all links* > > > Actually function 2 is listed in 4657 and will have to be moved to > the OF > draft. Other functions (1 and 3) are not listed in 4657 and should > stay in > the GCO draft. > > > 9) LSP ordering is always requested by the PCC but it might be > desirable to have the PCE indicating whether ordering is in fact > required or not. For example, the NMS could send a reoptimization > request to which the PCE would reply with a ordered or non-ordered > set of computed paths. > >>> Yes, we can accommodate your request in the new version. Good thanks. I'll wait until you respin the ID and then will pool the list. JP. > > Thanks. > > JP. > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > End of Pce Digest, Vol 33, Issue 7 > ********************************** _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri May 11 05:15:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmRDk-0002d7-GT; Fri, 11 May 2007 05:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmRDj-0002d2-CG for pce@ietf.org; Fri, 11 May 2007 05:15:27 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmRDi-0007D9-Fx for pce@ietf.org; Fri, 11 May 2007 05:15:27 -0400 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1HmRDg-0000Rx-3o for pce@ietf.org; Fri, 11 May 2007 09:15:24 +0000 Received: from your029b8cecfe ([217.158.132.35] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 May 2007 10:15:21 +0100 Message-ID: <00a201c793ac$dcfe9bc0$4802010a@your029b8cecfe> From: "Adrian Farrel" To: "JP Vasseur" , "Young Lee" References: <001b01c7933f$605f27a0$520c7c0a@china.huawei.com> <1C05F8AA-1A9E-4130-8A25-1FE88ADE8576@cisco.com> Date: Fri, 11 May 2007 10:13:45 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 11 May 2007 09:15:21.0724 (UTC) FILETIME=[E6AF13C0:01C793AC] X-Originating-Rutherford-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: pce@ietf.org Subject: [Pce] Re: Comments on draft-lee-pce-global-concurrent-optimization-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 [Tidied up from Digest response thread] >>> The authors requested the WG to adopt draft-lee-pce-global- >>> concurrent-optimization-03.txt as a PCE WG document but before >>> pooling the list, >>> I'd like to make a few comments/requests: >>> >>> This solution is indeed compliant with RFC4655 and as pointed out in the >>> ID, PCEP already supports synchronized path computation requests through >>> the use of the SVEC object. >>> >>> 1) The PCEP extensions defined in this document are quite >>> reasonable and do not substantially overload the protocol >>> itself. That being said, the exchange of a substantially large >>> amount of data will unavoidably stress the machinery in a significant >>> way. Scalability of solutions trying to achieve >>> global optimization have been discussed in length so I won't propose to >>> re-open a fairly old debate but it is well-understood >>> that such solutions do not scale well and the major bottleneck is not >>> just the path computation itself but the bulk of data >>> that must be exchanged, synchronization issues, failures during >>> reoptimization and so on. Indeed, the path computation bottle-neck is clearly an algorithmic issue that is out of scope here, and I know some would argue that solutions exist that remove that bottle-neck. I think that the other items listed would valuably be the subject of health warnings in an applicability statement as JP suggests, but it should be noted that this does not limit the applicability based on the network size or the set of LSPs being reoptimized. Rather, it limits the applicability to how the reoptimization is being used and coordinated by a management plane. The difference between a global reoptimization and a bulk re-route are subtle. It may appear that for bulk re-route all existing services have failed and so the worst case is that connectivity is not restored, but in packet networks FRR may be in use, so bulk re-route failures are significant. The applicability in *that* case includes make-before-break to ensure no disruption to traffic. But it is also commonly accepted that restoration or re-route after failure has two problems. The first is system congestion which is at least as bad as global concurrent reoptimization because each LSP-to-be restored is the subject of a PCReq and a PCRep as well as signaling. The second is that the sequential nature of the path computations will almost inevitably lead to blocking. So, while I agree that the gco draft should have a very thorough applicability section that should highlight the potential problems, I don't think that there should be an assumption of non-applicability to specific networks or scenarios. >>> Thus I'd suggest to add some applicability >>> section to this ID that would discuss the context in which such >>> solution would apply (e.g. network with thousands of packet LSPs >>> (hopefully not!), optical LSPs with a few hundreds of LSPs with multi- >>> constraints optimization problems where bandwidth fragmentation is a >>> real issue because of a limited number of discrete bandwidth values). >>> >> We can add applicability section to elaborate this request. We can >> indicate that this mechanism applies specifically to GMPLS optical >> networks with a few hundreds of LSPs. I would be very concerned about that limitation. It is great to hear that you have specific intention to apply this work to optical networks, but I do not see anything in the I-D or what JP said that forces us to constrain the applicability in this way. By all means, cite optical networks with a limited number of nodes as a good example of where you might use this technique, but otherwise, you should structure the applicability section with regard to the potential problems, not the dataplane technology. >>> 2) >>> >>> It is also envisioned that network operators might >>> require a global concurrent path computation in the event of >>> catastrophic network failures, where a set of TE LSPs need to >>> be optimally rerouted in real-time. >>> >>> I do not think that such model could be used for "real-time" rerouting. >>> >> I agree with you. We can remove this statement. Define "real-time". The applicability to the problem space is clear. A well-known set of LSP has been impacted by a network failure. Rather than compute new paths on demand from the head-end LSPs with the consequent resource- contention blocking problems, there may be considerable benefit in computing the paths of the LSPs as a set. (Of course, this assumes the availability of certain information, but an NMS might reasonably have access to this and make the bulk computation request.) Thus, if there is any modification to make, I suggest only deleting "in real-time". >>> 3) >>> >>> The main focus of this document is to highlight the PCC-PCE >>> communication needs in support of a concurrent path computation >>> application and to define protocol extensions to >>> meet those needs. >>> >>> You may want to stress the fact that in your ID the PCC is an NMS >>> system and this is key. Indeed, one can define models where the PCCs are >>> LSRs and the PCE is used to provide globally optimal >>> solutions ... Such models suffers from drastic scalability and >>> robustness issues. >> >> The PCE GCO is primarily an NMS based solution. In section 3.3 >> (Application of PCE architecture) of the current draft clearly spells >> out that GCO is NMS based solution. With GCO, a PCC has >> to know all LSP requests, hence this cannot be a LSR. > > Well that could be done with PCC=LSR thanks to complex synchronization > (which I'm NOT advocating of course) > hence my comment. Could you restate in the abstract/Introduction that in > your proposal the PCC is indeed an NMS. Why would the procedures not be applicable to a head-end LSR requesting bulk reoptimization of the set of LSPs for which it acts as ingress? (I.e. a subset of all LSPs in the system.) We already accept that such an LSR should be allowed to issue individual LSP reoptimization requests. And we already accept that a PCReq may contain multiple computation requests that are 'linked'. So, if JP's request is that an LSR should not issue an optimization request for an LSP for which it is not the head-end, I can see the point. Although I might want to rephrase this because the important question is what use is made of the computation response - that is, if the PCC is unable to make use of the computed path, there is no value in performing the computation. Clearly, NMS is a primary application of this work, but it is not the only application. Another key use would be the VNT Manager component discussed in the multi-layer PCE drafts. >>> 4) Green field: not sure to buy this argument since as soon as >>> the TE LSPs are set up, the network is no longer in this green >>> field state >>> >> OK. The main use of GCO application is re-optimization of an existing >> network. Well, I would be very worried if you deleted the green-field applicability. But I do agree that it should be put lower down the list (although I guess it comes first in the list because it comes first in time). And it should be rephrased, because it is not "reoptimization" since (as JP points out) you can't reoptimize LSPs that don't exist, and once the LSPs do exist it is not a green field. But noting that the draft is titled "PCE Global Concurrent Optimization" not "PCE Global Concurrent Re-optimization" I have zero problem with the existence of this section, and I believe that network planners will want to make use of computation servers to plan the LSPs that they will provision in their network. This might arise either in the green field condition or when rolling out a new customer on top of an existing network. >>> 5) >>> >>> Note that sequential re- >>> optimization of such TE LSPs is unlikely to produce substantial >>> improvements in overall network optimization >>> except in very sparsely utilized networks. >>> >>> Well, that DEPENDS ! I could show you distributed algorithms where >>> sequential reoptimization allows for a significant improvements. I >>> would suggest to remove that statement. Actually, I think that the sequential algorithms that JP refers to are actually *global* reoptimization. That is, they sequence through the set of LSPs making optimization improvements. The fact that the algorithms are distributed is neither here nor there. > Yes, it actually depends on the topology, the traffic matrix, the online > algorithm used, etc. We will delete this statement. So rather than deleting the statement, I suggest qualifying it. Of course, the potential for network-wide gains from reoptimization of LSPs one-by-one is dependent on the network usage and size of the LSPs being reoptimized. But the key point remains: if you only compute the reoptimized path of one LSP at a time, and if you give no consideration to the other LSPs in the network when you do it, you run the risk of significant devaluation of the process. This may be far more visible in networks with a low ratio of potential LSPs per link (such as in an optical network), and far less visible in packet networks with micro-flow LSPs. [SNIP] >>> 7) A word of cautious here >>> >>> During a reoptimization it may be required to move a LSP >>> several times so as to avoid traffic disruption. The >>> response message must allow indicating the path sequence >>> for each request. >> >> We all know that in some cases, traffic disruption may be avoided >> thanks to a multi-step rerouting approach where some TE LSP may be >> rerouted N times. This is another example where such model may have >> significant impact on the network and even when traffic disruption >> can be avoided, there is still an impact in term of control plane, >> traffic shift (=> jitter) although this can be another constraint >> taken in to account when computing the various rerouting steps. For >> example, would you want to add a paragraph listing the drawbacks of >> such approach (e.g. trade-off between optimization gain and network >> impact, ....) ? >> >> We can add a paragraph to indicate the potential impact by this feature. >> By the way the trade-off is not optimization vs. network impact. It >> is traffic disruption vs. network impact. If we want to avoid traffic >> disruption, we need this multiple rerouting, which is the >> price to pay at the expense of network impact. > > OK let me restate my comment here: the point I was trying to make is the > following: even if the set of TE LSPs can be reoptimized with no > traffic loss for example, the need for multiple reroutes has a > cost in term of traffic impact (jitter, ...) + control plane stress. It > may be worth mentioning that aspect also, this is why I mentioned > a trade-off between optimization versus network impact. Indeed, if you can > reoptimize the set of TE LSPs in order to reduce the max link utilization > by 5% but this requires to reroute two hundreds TE LSPs with on the > average 4 reroutes per TE LSP, this may not be a good idea. Well, that would depend, wouldn't it? If the network is unable to place any more LSPs, one might think that retrieving 5% was pretty cool :-) But I *do* think that a paragraph warning about the risks of re-routing LSPs is valuable. It is often assumed that make-before-break is hitless, and it is not. As JP points out, even in packet networks where the re- route can occur between packets, there may be a momentary jitter impact at the point of switch-over. This applies to *all* reoptimization and re-route activities including FRR. So obviously there is a trade-off to be highlighted and put under policy control. Maybe only some LSPs are subject to re-routing - others need to preserve their QoS. And clearly, multiple "shuffling" of LSPs to make space is going to increase the impact on the network. This means both that there should be cost-benefit analysis of the reoptimization, and that such reoptimization is unlikely to be a continuous process. >>> 8) Objective functions should be moved to PCEP, > > I typed too fast: I indeed meant to refer to the objective function > draft, as agreed with Jerry since I was pushing myself for not adding > more to PCEP. [SNIP] JP, are you saying that all objective function definitions should go into the one objective function I-D? Or should that I-D define the functions that we have in hand, create the code point registry, and leave the definition of new objective functions for future I-Ds? But still, the requirements for the objective functions need to stay in the gco draft. So it is just a question of where the objective functions are described in detail. [SNIP] Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri May 11 08:48: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 1HmUY4-0004tv-Ey; Fri, 11 May 2007 08:48:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUO8-0006TY-Jp for pce@ietf.org; Fri, 11 May 2007 08:38:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmUO6-0003n5-4G for pce@ietf.org; Fri, 11 May 2007 08:38:24 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 11 May 2007 05:38:21 -0700 X-IronPort-AV: i="4.14,522,1170662400"; d="scan'208,217"; a="420993314:sNHT189922494" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l4BCcLnL010256; Fri, 11 May 2007 05:38:21 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4BCcBV3000633; Fri, 11 May 2007 12:38:16 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); Fri, 11 May 2007 08:38:11 -0400 Received: from [10.86.104.185] ([10.86.104.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 08:38:08 -0400 In-Reply-To: <00a201c793ac$dcfe9bc0$4802010a@your029b8cecfe> References: <001b01c7933f$605f27a0$520c7c0a@china.huawei.com> <1C05F8AA-1A9E-4130-8A25-1FE88ADE8576@cisco.com> <00a201c793ac$dcfe9bc0$4802010a@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <4CDB6EE0-7679-421C-BDEE-E01BFFFEF5A8@cisco.com> From: JP Vasseur Date: Fri, 11 May 2007 08:38:03 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 11 May 2007 12:38:08.0617 (UTC) FILETIME=[3AB79D90:01C793C9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=66194; t=1178887101; x=1179751101; c=relaxed/simple; s=sjdkim6002; 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=20Comments=20on=20draft-lee-pce-global-concurrent-optim ization-03.txt=20 |Sender:=20; bh=ETQXv56XE7wVz2cK8kR01Iy4tKtztuO9lW75KRsXORA=; b=FSZco9LGAWdJAKJFbV9croT8xjNYjt3xI7iWyWDWEOeUfP5hOqNSZHYYxbaleBHR5mdPZv24 JK/x9CGv0j6Vb3S+kRhNA5b8QhXqv+apEZNbJVo1fhBN69Y+k60OvMQW; Authentication-Results: sj-dkim-6; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 2.0 (++) X-Scan-Signature: b081eb6a5bf2a87d9780cad244b3c5bd X-Mailman-Approved-At: Fri, 11 May 2007 08:48:39 -0400 Cc: pce@ietf.org, Young Lee Subject: [Pce] Re: Comments on draft-lee-pce-global-concurrent-optimization-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1322741776==" Errors-To: pce-bounces@lists.ietf.org --===============1322741776== Content-Type: multipart/alternative; boundary=Apple-Mail-24-863904421 --Apple-Mail-24-863904421 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Adrian, On May 11, 2007, at 5:13 AM, Adrian Farrel wrote: > [Tidied up from Digest response thread] > > > For the matter of that discussion, same here. > >>>> The authors requested the WG to adopt draft-lee-pce-global- >>>> concurrent-optimization-03.txt as a PCE WG document but before >>>> pooling the list, >>> I'd like to make a few comments/requests: >>>> >>>> This solution is indeed compliant with RFC4655 and as pointed >>>> out in the ID, PCEP already supports synchronized path >>>> computation requests through the use of the SVEC object. >>>> >>>> 1) The PCEP extensions defined in this document are quite >>>> reasonable and do not substantially overload the protocol >>>> itself. That being said, the exchange of a substantially large >>>> amount of data will unavoidably stress the machinery in a >>>> significant way. Scalability of solutions trying to achieve >>>> global optimization have been discussed in length so I won't >>>> propose to re-open a fairly old debate but it is well-understood >>>> that such solutions do not scale well and the major bottleneck >>>> is not just the path computation itself but the bulk of data >>>> that must be exchanged, synchronization issues, failures during >>>> reoptimization and so on. > > Indeed, the path computation bottle-neck is clearly an algorithmic > issue that is out of scope here, and I know some would argue that > solutions exist that remove that bottle-neck. > > I think that the other items listed would valuably be the subject of > health warnings in an applicability statement as JP suggests, but it > should be noted that this does not limit the applicability based on > the network size or the set of LSPs being reoptimized. Rather, it > limits the applicability to how the reoptimization is being used and > coordinated by a management plane. > > The difference between a global reoptimization and a bulk re-route > are subtle. It may appear that for bulk re-route all existing > services have failed and so the worst case is that connectivity is > not restored, but in packet networks FRR may be in use, so bulk > re-route failures are significant. The applicability in *that* case > includes make-before-break to ensure no disruption to traffic. > > But it is also commonly accepted that restoration or re-route after > failure has two problems. The first is system congestion which is > at least as bad as global concurrent reoptimization because each > LSP-to-be restored is the subject of a PCReq and a PCRep as well as > signaling. The second is that the sequential nature of the path > computations will almost inevitably lead to blocking. > > So, while I agree that the gco draft should have a very thorough > applicability section that should highlight the potential problems, > I don't think that there should be an assumption of non-applicability > to specific networks or scenarios. Well let's consider the example of a packet networks with 30,000 TE LSPs of which 15% are impact by a single node failure (talking realistic number, as of today), considering that the 4,500 affected TE LSPs have say 50 different head-ends. The question is now whether a centralized """""real- time""""" path computation system could reasonably be used to handle such scenario as opposed to the well-known distributed path computation ? I do agree with you with the blocking issue pointed out above (although there are techniques to reduce that blocking probability), there are many other metrics to consider of course and I'm trying not to re-open the old debate here ;-) But I think that it should be clearly spelled out somewhere that the algorithmic issue is not the only point of possible contention. > > >>>> Thus I'd suggest to add some applicability >>>> section to this ID that would discuss the context in which such >>>> solution would apply (e.g. network with thousands of packet LSPs >>>> (hopefully not!), optical LSPs with a few hundreds of LSPs with >>>> multi- >>>> constraints optimization problems where bandwidth fragmentation >>>> is a >>>> real issue because of a limited number of discrete bandwidth >>>> values). >>>> >>> We can add applicability section to elaborate this request. We can >>> indicate that this mechanism applies specifically to GMPLS >>> optical networks with a few hundreds of LSPs. > > I would be very concerned about that limitation. > It is great to hear that you have specific intention to apply this > work > to optical networks, but I do not see anything in the I-D or what > JP said > that forces us to constrain the applicability in this way. > By all means, cite optical networks with a limited number of nodes > as a > good example of where you might use this technique, but otherwise, you > should structure the applicability section with regard to the > potential > problems, not the dataplane technology. > > >>>> 2) >>>> >>>> It is also envisioned that network operators might >>>> require a global concurrent path computation in the event of >>>> catastrophic network failures, where a set of TE LSPs need to >>>> be optimally rerouted in real-time. >>>> >>>> I do not think that such model could be used for "real-time" >>>> rerouting. >>>> >>> I agree with you. We can remove this statement. > > Define "real-time". > > The applicability to the problem space is clear. A well-known set of > LSP has been impacted by a network failure. Rather than compute new > paths on demand from the head-end LSPs with the consequent resource- > contention blocking problems, there may be considerable benefit in > computing the paths of the LSPs as a set. (Of course, this assumes > the availability of certain information, but an NMS might reasonably > have access to this and make the bulk computation request.) > > Thus, if there is any modification to make, I suggest only deleting > "in real-time". I guess that we can agree on the fact that centralized system provide more qualitative output in term of path quality but are typically fairly slow and not appropriate for "real time" processing. Now of course, we could argue for ever on: * More qualitative: by how much ? * What do we mean by path quality or optimality ? * What does "slow" mean ? We could certainly find scenarios where the delta in term of optimality is fairly negligible and centralized systems are extremely slow, and vice versa. So my point was to not "promote" such system for "real-time" processing. > >>>> 3) >>>> >>>> The main focus of this document is to highlight the PCC-PCE >>>> communication needs in support of a concurrent path >>>> computation application and to define protocol extensions to >>>> meet those needs. >>>> >>>> You may want to stress the fact that in your ID the PCC is an NMS >>>> system and this is key. Indeed, one can define models where the >>>> PCCs are LSRs and the PCE is used to provide globally optimal >>>> solutions ... Such models suffers from drastic scalability and >>>> robustness issues. >>> >>> The PCE GCO is primarily an NMS based solution. In section 3.3 >>> (Application of PCE architecture) of the current draft clearly >>> spells out that GCO is NMS based solution. With GCO, a PCC has >>> to know all LSP requests, hence this cannot be a LSR. >> >> Well that could be done with PCC=LSR thanks to complex >> synchronization (which I'm NOT advocating of course) >> hence my comment. Could you restate in the abstract/Introduction >> that in your proposal the PCC is indeed an NMS. > > Why would the procedures not be applicable to a head-end LSR > requesting bulk reoptimization of the set of LSPs for which it acts > as ingress? (I.e. a subset of all LSPs in the system.) > > We already accept that such an LSR should be allowed to issue > individual LSP reoptimization requests. And we already accept that > a PCReq may contain multiple computation requests that are 'linked'. > > So, if JP's request is that an LSR should not issue an optimization > request for an LSP for which it is not the head-end, I can see the > point. Although I might want to rephrase this because the important > question is what use is made of the computation response - that is, > if the PCC is unable to make use of the computed path, there is no > value in performing the computation. > > Clearly, NMS is a primary application of this work, but it is not > the only application. Another key use would be the VNT Manager > component discussed in the multi-layer PCE drafts. This is an important point, on which we may not 100% agree. If now one want to use this model where each LSR is a PCC so as to globally optimize the path computation of a set of TE LSPs, that clearly requires very significant synchronizations between the PCE and each of those PCCs (which is not the base with synchronized path computation request such as diverse path computations originated by a single LSR). In other words, consider the case where a PCC requires to resize one of its TE LSPs and sends a request to the PCE, which in turn triggers the reroute of hundreds of TE LSPs to satisfy that demand. See the number of synchronizations that this does require between the PCE and all PCCs. And there are many other scenarios where such model could have limitations that the draft should point out. Are we agreeing ? > >>>> 4) Green field: not sure to buy this argument since as soon as >>>> the TE LSPs are set up, the network is no longer in this green >>>> field state >>>> >>> OK. The main use of GCO application is re-optimization of an >>> existing network. > > Well, I would be very worried if you deleted the green-field > applicability. But I do agree that it should be put lower down the > list (although I guess it comes first in the list because it comes > first in time). And it should be rephrased, because it is not > "reoptimization" since (as JP points out) you can't reoptimize LSPs > that don't exist, and once the LSPs do exist it is not a green field. So it is a green field for a very short period of time. > > > But noting that the draft is titled "PCE Global Concurrent > Optimization" not "PCE Global Concurrent Re-optimization" I have zero > problem with the existence of this section, and I believe that > network planners will want to make use of computation servers to plan > the LSPs that they will provision in their network. This might arise > either in the green field condition or when rolling out a new > customer on top of an existing network. > >>>> 5) >>>> >>>> Note that sequential re- >>>> optimization of such TE LSPs is unlikely to produce >>>> substantial improvements in overall network optimization >>>> except in very sparsely utilized networks. >>>> >>>> Well, that DEPENDS ! I could show you distributed algorithms where >>>> sequential reoptimization allows for a significant improvements. I >>>> would suggest to remove that statement. > > Actually, I think that the sequential algorithms that JP refers to > are actually *global* reoptimization. That is, they sequence through > the set of LSPs making optimization improvements. The fact that the > algorithms are distributed is neither here nor there. We keep facing that terminology issue with the word "distributed" where this could apply to the algorithm itself or the fact that path computations may be performed by different engine (e.g. case where each LSR is its own PCE). I was referring to the "unlikely to produce substantial ..." statement. Techniques exist that produce good results with sequential re- optimization, thus my suggestion to delete that statement, or please refine it. > >> Yes, it actually depends on the topology, the traffic matrix, the >> online algorithm used, etc. We will delete this statement. > > So rather than deleting the statement, I suggest qualifying it. > Of course, the potential for network-wide gains from reoptimization > of LSPs one-by-one is dependent on the network usage and size of the > LSPs being reoptimized. But the key point remains: if you only > compute the reoptimized path of one LSP at a time, and if you give > no consideration to the other LSPs in the network when you do it, > you run the risk of significant devaluation of the process. > See it is always difficult to avoid "significant", ... That really depends. For example, dynamic preemption schemes based on LSP size can be designed to get close to the results given by a global CSPF applied by placing TE LSPs in decreasing sizes, which itself can be fairly close to some centralized algorithms. > This may be far more visible in networks with a low ratio of potential > LSPs per link (such as in an optical network), and far less visible in > packet networks with micro-flow LSPs. > Yes unless you use dynamic preemption to avoid blocking issue. You could also use head-end driven dynamic splitters to reduce that ratio. > [SNIP] > >>>> 7) A word of cautious here >>>> >>>> During a reoptimization it may be required to move a LSP >>>> several times so as to avoid traffic disruption. The >>>> response message must allow indicating the path sequence >>>> for each request. >>> >>> We all know that in some cases, traffic disruption may be avoided >>> thanks to a multi-step rerouting approach where some TE LSP may be >>> rerouted N times. This is another example where such model may have >>> significant impact on the network and even when traffic disruption >>> can be avoided, there is still an impact in term of control plane, >>> traffic shift (=> jitter) although this can be another constraint >>> taken in to account when computing the various rerouting steps. For >>> example, would you want to add a paragraph listing the drawbacks of >>> such approach (e.g. trade-off between optimization gain and network >>> impact, ....) ? >>> >>> We can add a paragraph to indicate the potential impact by this >>> feature. >>> By the way the trade-off is not optimization vs. network impact. It >>> is traffic disruption vs. network impact. If we want to avoid >>> traffic disruption, we need this multiple rerouting, which is the >>> price to pay at the expense of network impact. >> >> OK let me restate my comment here: the point I was trying to make >> is the following: even if the set of TE LSPs can be reoptimized >> with no >> traffic loss for example, the need for multiple reroutes has a >> cost in term of traffic impact (jitter, ...) + control plane >> stress. It may be worth mentioning that aspect also, this is why >> I mentioned >> a trade-off between optimization versus network impact. Indeed, if >> you can reoptimize the set of TE LSPs in order to reduce the max >> link utilization by 5% but this requires to reroute two hundreds >> TE LSPs with on the average 4 reroutes per TE LSP, this may not be >> a good idea. > > Well, that would depend, wouldn't it? If the network is unable to > place > any more LSPs, one might think that retrieving 5% was pretty cool :-) Ah I was referring to a reoptimization case (not failure): " if you can reoptimize the set of TE LSPs in order to reduce the max link utilization by 5% ..." > > But I *do* think that a paragraph warning about the risks of re- > routing > LSPs is valuable. It is often assumed that make-before-break is > hitless, > and it is not. That was my point indeed. > As JP points out, even in packet networks where the re- > route can occur between packets, there may be a momentary jitter > impact > at the point of switch-over. + potential control plane stress ! > This applies to *all* reoptimization and > re-route activities including FRR. > > So obviously there is a trade-off to be highlighted and put under > policy control. Maybe only some LSPs are subject to re-routing - > others > need to preserve their QoS. > > And clearly, multiple "shuffling" of LSPs to make space is going to > increase the impact on the network. This means both that there should > be cost-benefit analysis of the reoptimization, and that such > reoptimization is unlikely to be a continuous process. > >>>> 8) Objective functions should be moved to PCEP, >> >> I typed too fast: I indeed meant to refer to the objective >> function draft, as agreed with Jerry since I was pushing myself >> for not adding >> more to PCEP. > > [SNIP] > > JP, are you saying that all objective function definitions should go > into the one objective function I-D? Just the 6 ones defined in RFC4657, not all. > Or should that I-D define the > functions that we have in hand, create the code point registry, and > leave the definition of new objective functions for future I-Ds? > > But still, the requirements for the objective functions need to stay > in the gco draft. So it is just a question of where the objective > functions are described in detail. In sync, Cheers. JP. > > [SNIP] > > Thanks, > Adrian > --Apple-Mail-24-863904421 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Adrian,

On = May 11, 2007, at 5:13 AM, Adrian Farrel wrote:

[Tidied up from Digest response thread]



For the matter of that = discussion, same here.


The authors = requested the WG to adopt draft-lee-pce-global-
concurrent-optimization-03.txt as a PCE WG document = but before
pooling the list, >>> = I'd like to make a few comments/requests:

This solution = is indeed compliant with RFC4655 and as pointed out in the ID, PCEP = already supports synchronized path computation requests through the use = of the SVEC object.
1) The PCEP extensions defined = in this document are quite
reasonable = and do not substantially overload the protocol
itself. That being said, the exchange of a = substantially large
amount of data will = unavoidably stress the machinery in a significant way. Scalability of = solutions trying to achieve
global = optimization have been discussed in length so I won't propose to re-open = a fairly old debate but it is well-understood
that such solutions do not scale well and the major = bottleneck is not just the path computation itself but the bulk of = data
that must be exchanged, = synchronization issues, failures during

Indeed, the path computation = bottle-neck is clearly an algorithmic
issue = that is out of scope here, and I know some would argue that
solutions exist that remove that = bottle-neck.

I think that the other items listed would valuably = be the subject of
health warnings in an = applicability statement as JP suggests, but it
should be noted that this does not limit the = applicability based on
the network size or the set = of LSPs being reoptimized. Rather, it
limits = the applicability to how the reoptimization is being used and
coordinated by a management plane.

The = difference between a global reoptimization and a bulk re-route
are subtle. It may appear that for bulk re-route all = existing
services have failed and so the = worst case is that connectivity is
not restored, = but in packet networks FRR may be in use, so bulk
re-route failures are significant. The applicability = in *that* case
includes make-before-break to = ensure no disruption to traffic.

But it is also commonly accepted = that restoration or re-route after
failure has = two problems. The first is system congestion which is
at least as bad as global concurrent reoptimization = because each
LSP-to-be restored is the = subject of a PCReq and a PCRep as well as
computations will almost = inevitably lead to blocking.

So, while I agree that the gco = draft should have a very thorough
applicability = section that should highlight the potential problems,
I don't think that there should be an assumption of = non-applicability
to specific networks or = scenarios.

Well let's consider the = example of a packet networks with 30,000 TE LSPs of which 15% are impact = by a single
node failure (talking realistic number, as of = today), considering that the 4,500 affected TE LSPs have say 50 = different
head-ends. The question is now whether a centralized = """""real-time""""" path computation system could = reasonably=A0
be used to handle such scenario as opposed to = the well-known distributed path computation ? I do agree with you = with
the blocking issue pointed out above (although there are = techniques to reduce that blocking probability),=A0
there are = many other metrics to consider of course and I'm trying not to = re-open=A0the old debate here ;-)

But I think that it should = be clearly spelled out somewhere that the algorithmic issue is not the = only point of possible
contention.



Thus I'd suggest to add some applicability
section to this ID that would discuss the context in = which such
solution would apply (e.g. = network with thousands of packet LSPs
constraints optimization = problems where bandwidth fragmentation is a
real = issue because of a limited number of discrete bandwidth = values).

=
We can add applicability section = to elaborate this request. We can
indicate that = this mechanism applies specifically to GMPLS optical networks with a few = hundreds of LSPs.

I would = be very concerned about that limitation.
It is = great to hear that you have specific intention to apply this = work
to optical networks, but I do = not see anything in the I-D or what JP said
that = forces us to constrain the applicability in this way.
By all means, cite optical networks with a limited = number of nodes as a
good example of where you = might use this technique, but otherwise, you
should structure the applicability section with = regard to the potential
problems, not = the dataplane technology.


=
2)

=A0 =A0 It is also envisioned = that network operators might
=A0 =A0 require a global = concurrent path computation in the event of
=A0 =A0 catastrophic network = failures, where a set of TE LSPs need to
=A0 =A0 be optimally rerouted in = real-time.

I do not think that such model could be used for = "real-time"=A0 = rerouting.

=
=A0I agree with you. We can = remove this statement.

Define = "real-time".

The applicability to the problem space is clear. A = well-known set of
LSP has been impacted by a = network failure. Rather than compute new
paths on = demand from the head-end LSPs with the consequent resource-
contention blocking problems, there may be = considerable benefit in
computing the = paths of the LSPs as a set. (Of course, this assumes
the availability of certain information, but an NMS = might reasonably
have access to this and make the = bulk computation request.)

Thus, if there is any = modification to make, I suggest only deleting
"in real-time".

I guess that we can agree = on the fact that centralized system provide more qualitative output in = term of path
quality but are typically fairly slow and not = appropriate for "real time" processing. Now of course, we could = argue
for ever on:
* More qualitative: by how much = ?
* What do we mean by path quality or optimality = ?
* What does "slow" mean ?
We could certainly find = scenarios where the delta in term of optimality is fairly negligible and = centralized systems
are extremely slow, and vice = versa.
So my point was to not "promote" such system for = "real-time" processing.


3)
=A0 =A0 The main focus of this = document is to highlight the PCC-PCE
=A0 =A0 communication needs in = support of a concurrent path computation application and to define = protocol extensions to
=A0 =A0 meet those = needs.

You may want to stress the fact that in your ID the = PCC is an NMS
system and this is key. Indeed, = one can define models where the PCCs are LSRs and the PCE is used to = provide globally optimal
solutions ... = Such models suffers from drastic scalability and
robustness issues.

The PCE = GCO is primarily an NMS based solution. In section 3.3
(Application of PCE architecture) of the current = draft clearly=A0 spells out = that GCO is NMS based solution.=A0 = With GCO, a PCC has
to know all = LSP requests, hence this cannot be a LSR.

Well = that could be done with PCC=3DLSR thanks to complex=A0 synchronization (which I'm = NOT advocating of course)
hence my = comment. Could you restate in the abstract/Introduction that in your = proposal the PCC is indeed an NMS.

Why = would the procedures not be applicable to a head-end LSR
requesting bulk reoptimization of the set of LSPs = for which it acts
as ingress? (I.e. a subset of = all LSPs in the system.)

We already accept that such an = LSR should be allowed to issue
individual = LSP reoptimization requests. And we already accept that
a PCReq may contain multiple computation requests = that are 'linked'.
So, if JP's request is that an = LSR should not issue an optimization
request for = an LSP for which it is not the head-end, I can see the
point. Although I might want to rephrase this = because the important
question is what use is = made of the computation response - that is,
if the = PCC is unable to make use of the computed path, there is no
value in performing the computation.

Clearly, = NMS is a primary application of this work, but it is not
the only application. Another key use would be the = VNT Manager
component discussed in the = multi-layer PCE drafts.

This is an important point, = on which we may not 100% agree. If now one want to use this = model
where each LSR is a PCC so as to globally optimize the = path computation of a set of TE LSPs,
that clearly requires = very significant synchronizations between the PCE and each of those = PCCs
(which is not the base with synchronized path computation = request such as diverse path computations
originated by a = single LSR). In other words, consider the case where a PCC requires to = resize one of
its TE LSPs and sends a request to the PCE, = which in turn triggers the reroute of hundreds of TE LSPs
to = satisfy that demand. See the number of synchronizations that this does = require between the PCE and
all PCCs. And there are many other = scenarios where such model could have limitations that the = draft
should point out.

Are we agreeing = ?=A0


4) Green = field: not sure to buy this argument since as soon as
the TE LSPs are set up, the network is no longer in = this green
field state

=A0OK.=A0 The main use of GCO = application is re-optimization of an=A0 existing network.
=
Well, I would be very worried if = you deleted the green-field
list (although I guess it comes = first in the list because it comes
first in = time). And it should be rephrased, because it is not
"reoptimization" since (as JP points out) you can't = reoptimize LSPs
that don't exist, and once the = LSPs do exist it is not a green field.

So it is a green field for = a very short period of time.



But noting = that the draft is titled "PCE Global Concurrent
Optimization" not "PCE Global Concurrent = Re-optimization" I have zero
problem with = the existence of this section, and I believe that
network planners will want to make use of = computation servers to plan
the LSPs that = they will provision in their network. This might arise
either in the green field condition or when rolling = out a new
customer on top of an existing = network.

=
5)

=A0 =A0 Note that sequential = re-
=A0 =A0 optimization of such TE = LSPs is unlikely to produce substantial improvements in overall network = optimization
=A0 =A0 except in very sparsely = utilized networks.
Well, that DEPENDS ! I could = show you distributed algorithms where
would suggest to remove that statement.
=

Actually, I think that the = sequential algorithms that JP refers to
are = actually *global* reoptimization. That is, they sequence = through
the set of LSPs making = optimization improvements. The fact that the
algorithms are distributed is neither here nor = there.

We keep facing that = terminology issue with the word "distributed" where this could apply to = the=A0
algorithm itself or the fact that path computations may = be performed by different engine (e.g. case
where each LSR is = its own PCE). I was referring to the "unlikely to produce substantial = ..." statement.
Techniques exist that produce good results = with sequential re-optimization, thus my suggestion to
delete = that statement, or please refine it.


=
Yes, it actually depends on = the topology, the traffic matrix, the=A0 online algorithm used, etc. = We will delete this statement.

So = rather than deleting the statement, I suggest qualifying it.
Of course, the potential for network-wide gains from = reoptimization
of LSPs one-by-one is dependent = on the network usage and size of the
LSPs being = reoptimized. But the key point remains: if you only
compute the reoptimized path of one LSP at a time, = and if you give
no consideration to the other = LSPs in the network when you do it,
you run the = risk of significant devaluation of the process.


See it is always difficult = to avoid "significant", ... That really depends. For example, dynamic = preemption
schemes based on LSP size can be designed to get = close to the results given by a global
CSPF applied by placing = TE LSPs in decreasing sizes, which itself can be fairly close to some = centralized
algorithms.

This may = be far more visible in networks with a low ratio of potential
LSPs per link (such as in an optical network), and = far less visible in
packet networks with = micro-flow LSPs.
Yes unless you use dynamic = preemption to avoid blocking issue. You could also use = head-end
driven dynamic splitters to reduce that = ratio.

[SNIP]

7) A word of cautious here

=A0 =A0 =A0 =A0 =A0 During a = reoptimization it may be required to move a LSP
=A0 =A0 =A0 =A0 = =A0 several times so as to avoid traffic disruption.=A0 The response message must = allow indicating the path sequence
=A0 =A0 =A0 =A0 =A0 for each = request.
We all know that in some cases, = traffic disruption may be avoided
thanks to a = multi-step rerouting approach where some TE LSP may be
rerouted N times. This is another example where such = model may have
significant impact on the = network and even when traffic disruption
can be = avoided, there is still an impact in term of control plane,
traffic shift (=3D> jitter) although this can be = another constraint
taken in to account when = computing the various rerouting steps. For
example, = would you want to add a paragraph listing the drawbacks of
such approach (e.g. trade-off between optimization = gain and network
impact, ....) ?

We can = add a paragraph to indicate the potential impact by this=A0 feature.
By the way the trade-off is not optimization vs. = network impact. It
is traffic disruption vs. = network impact. If we want to avoid traffic disruption, we need this = multiple rerouting, which is the
price to pay = at the expense of network impact.

OK let = me restate my comment here: the point I was trying to make is=A0 the following: even if the = set of TE LSPs can be reoptimized with no
traffic = loss for example, the need for multiple reroutes has a
cost in term of traffic impact (jitter, ...) + = control plane stress.=A0 It = may be worth mentioning that aspect also, this is why I = mentioned
a trade-off between optimization = versus network impact. Indeed, if you can reoptimize the set of TE LSPs = in order to reduce the max link=A0 = utilization by 5% but this requires to reroute two hundreds TE = LSPs with on the average 4 reroutes per TE LSP, this may not be a good = idea.
Well, that would depend, = wouldn't it? If the network is unable to place
any more LSPs, one might think that retrieving 5% = was pretty cool :-)

Ah I was referring to a reoptimization case = (not failure): "=A0if you can reoptimize the set = of=A0
TE LSPs in order = to reduce the max link=A0 utilization by 5% = ..."


But I *do* = think that a paragraph warning about the risks of re-routing
LSPs is valuable. It is often assumed that = make-before-break is hitless,
and it is = not.

That was my point = indeed.

As JP = points out, even in packet networks where the re-
route can occur between packets, there may be a = momentary jitter impact
at the point = of switch-over.

+=A0 potential control = plane stress !

This applies to *all* reoptimization and
re-route activities including FRR.

So = obviously there is a trade-off to be highlighted and put under
policy control. Maybe only some LSPs are subject to = re-routing - others
need to preserve their = QoS.

And clearly, multiple "shuffling" of LSPs to make = space is going to
increase the impact on the = network. This means both that there should
be = cost-benefit analysis of the reoptimization, and that such
reoptimization is unlikely to be a continuous = process.

=
8) Objective functions should be = moved to PCEP,

I typed too = fast: I indeed meant to refer to the objective function draft, as agreed = with Jerry since I was pushing myself for not adding
more to PCEP.


JP, are you saying that all objective function = definitions should go
into the one objective = function I-D?

Just the 6 ones defined in = RFC4657, not all.

Or should that I-D define the
functions that we have in hand, create the code = point registry, and
leave the definition of new = objective functions for future I-Ds?

But still, the requirements for = the objective functions need to stay
in the gco = draft. So it is just a question of where the objective
functions are described in = detail.

In sync,

Cheers.

JP.


[SNIP]

Thanks,
Adrian


= --Apple-Mail-24-863904421-- --===============1322741776== 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 --===============1322741776==-- From pce-bounces@lists.ietf.org Fri May 11 16:26:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmbgy-0005mG-6S; Fri, 11 May 2007 16:26:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmbgw-0005lp-VZ for pce@ietf.org; Fri, 11 May 2007 16:26:18 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmbgw-0001kt-BU for pce@ietf.org; Fri, 11 May 2007 16:26:18 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHW00MMN8RTJS@usaga01-in.huawei.com> for pce@ietf.org; Fri, 11 May 2007 13:26:18 -0700 (PDT) Received: from Lee736821 ([10.124.12.82]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JHW00IR38RQYT@usaga01-in.huawei.com> for pce@ietf.org; Fri, 11 May 2007 13:26:17 -0700 (PDT) Date: Fri, 11 May 2007 15:26:14 -0500 From: Young Lee In-reply-to: <015101c793d5$59ce06e0$4802010a@your029b8cecfe> To: 'Adrian Farrel' , 'JP Vasseur' Message-id: <001b01c7940a$9f79c550$520c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceT1WhE+evS2S9pTSGxj+E+VpgQ2wAKi6Eg X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: pce@ietf.org Subject: [Pce] RE: Comments on draft-lee-pce-global-concurrent-optimization-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi all, Thanks for your comments and rather intense discussions on various points. Let me recapitulate all the discussion points here before the next version would be updated. (i) Applicability section - The applicability section clearly and thoroughly states the detail scenarios to which GCO can be applied, highlighting potential problems associated with GCO application such as scalability, synchronization, failure impact during re-optimization, etc. - There shouldn't be, however, any assumptions that preclude GCO from the applicability to specific networks or scenarios. (2) "Real-time" lingo. - We will delete "real-time" from the original statement at the minimum. - Add some statement associated with an NMS based approach when a large number of LSPs fails. (3) Is PCC = NMS for GCO application? - We can add "The PCE GCO application is primarily an NMS based solution" in abstract/introduction. - I don't believe we need to say that the PCC for GCO MUST be an NMS. (4) "Green-field" issue - Switch the order in Section 3 such that Re-optimization of an existing network appears before "green-field" application. - Rephrase to add: (i) "Green-field application is a special case when there is no LSP setup. Once the LSPs are setup, it is not a green field." (ii) "The need for green-field application arises when network planner will want to make use of computation servers to plan the LSPs that will be provisioned in their network." (5) "Sequential re-optimization ... will unlikely to produce substantial improvements in overall network optimization except in very sparsely utilized networks." - We will rephrase the statement. (6) Multi-Session Object - We agreed that this will move this feature to the second phase. (7) "Multi-step" rerouting - We agreed that we will add the potential impact by this feature. (8) Objective Function - We are in sync 100%. Thanks for your comments. Best Regard, Young -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, May 11, 2007 9:02 AM To: JP Vasseur Cc: Young Lee; 'LE ROUX Jean-Louis RD-CORE-LAN'; 'Eiji Oki'; 'Daniel King' Subject: Re: Comments on draft-lee-pce-global-concurrent-optimization-03.txt Hi, [PCE list removed] >> Define "real-time". >> >> The applicability to the problem space is clear. A well-known set of >> LSP has been impacted by a network failure. Rather than compute new >> paths on demand from the head-end LSPs with the consequent resource- >> contention blocking problems, there may be considerable benefit in >> computing the paths of the LSPs as a set. (Of course, this assumes >> the availability of certain information, but an NMS might reasonably >> have access to this and make the bulk computation request.) >> >> Thus, if there is any modification to make, I suggest only deleting >> "in real-time". > > I guess that we can agree on the fact that centralized system provide > more qualitative output in term of path quality but are typically fairly > slow and not appropriate for "real time" processing. I think that Dan and I are bound to argue about "fairly slow". But it does depend on the definition of "real time". On the whole, n CSPF computations can be expected to take n times the time of one CSPF computation. Bulk computations can be made to scale far better than linearly with the number of paths. > Now of course, we could argue for ever on: > * More qualitative: by how much ? > * What do we mean by path quality or optimality ? > * What does "slow" mean ? > We could certainly find scenarios where the delta in term of > optimality is fairly negligible and centralized systems > are extremely slow, and vice versa. > So my point was to not "promote" such system for "real-time" processing. OK. Well I'd turn it around and say "do promote such systems for offline processing" and allow them to be used on-line if someone wants to and if they are observed to work. And finally, reoptimization and recovery after FRR do not need the same "insant" action that unprotected recovery needs. So I think it is probaly OK to not push "real time" as I suggested. [SNIP] >> Why would the procedures not be applicable to a head-end LSR >> requesting bulk reoptimization of the set of LSPs for which it acts >> as ingress? (I.e. a subset of all LSPs in the system.) >> >> We already accept that such an LSR should be allowed to issue >> individual LSP reoptimization requests. And we already accept that >> a PCReq may contain multiple computation requests that are 'linked'. >> >> So, if JP's request is that an LSR should not issue an optimization >> request for an LSP for which it is not the head-end, I can see the >> point. Although I might want to rephrase this because the important >> question is what use is made of the computation response - that is, >> if the PCC is unable to make use of the computed path, there is no >> value in performing the computation. >> >> Clearly, NMS is a primary application of this work, but it is not >> the only application. Another key use would be the VNT Manager >> component discussed in the multi-layer PCE drafts. > > This is an important point, on which we may not 100% agree. If now > one want to use this model where each LSR is a PCC so as to globally > optimize the path computation of a set of TE LSPs, that clearly > requires very significant synchronizations between the PCE and each > of those PCCs (which is not the base with synchronized path > computation request such as diverse path computations > originated by a single LSR. In other words, consider the case where > a PCC requires to resize one of its TE LSPs and sends a request to > the PCE, which in turn triggers the reroute of hundreds of TE LSPs > to satisfy that demand. See the number of synchronizations that this > does require between the PCE and all PCCs. And there are many > other scenarios where such model could have limitations that the draft > should point out. > > Are we agreeing ? Completely, but... You must not assume that there is only one point of provisioning control for any LSP. And you must not assume that there is only one PCC for any head-end of an LSP. So, for example, when an LSP is requested, the NMS may or may not act as a PCC to find a path for the LSP. Thus the message sent by the NMS to the head-end LSR may or may not contain a full path. Thus the head-end LSR may not or may act as a PCC and consult a PCE. So, on recovery, there are options: 1. The head-end LSR acts as PCC for a single LSP 2. The head-end LSR acts as PCC for a batch of LSPs 3. The head-end LSR acts as PCC for a single distributed request for global reoptimization, including LSPs for which it is not head-end 4. As 1 or 2, but the PCE is responsible for coordinating all requests from PCCs and treating them as one 5. The NMS is responsible for determining all LSPs that need to be recomputed. I would not speak in favor of options 3 and 4. I would speak in favor of options 1, 2 and 5. Dimitry would, of course, be worried about the fact that we are potentially taking intelligence that was previously distributed into the control plane and putting it back into the "management" plane. For options 1 and 2, I would say this is not true. For option 5, this is clearly true, but it is the cost of full optimization. [SNIP] > So it is a green field for a very short period of time. Such is the nature of *all* green fields. Otherwise, what would be the point? :-) >>>>> 5) >>>>> >>>>> Note that sequential re- >>>>> optimization of such TE LSPs is unlikely to produce >>>>> substantial improvements in overall network optimization >>>>> except in very sparsely utilized networks. >>>>> >>>>> Well, that DEPENDS ! I could show you distributed algorithms where >>>>> sequential reoptimization allows for a significant improvements. I >>>>> would suggest to remove that statement. >> >> Actually, I think that the sequential algorithms that JP refers to >> are actually *global* reoptimization. That is, they sequence through >> the set of LSPs making optimization improvements. The fact that the >> algorithms are distributed is neither here nor there. > > We keep facing that terminology issue with the word "distributed" > where this could apply to the algorithm itself or the fact that path > computations may be performed by different engine (e.g. case > where each LSR is its own PCE). I was referring to the "unlikely to > produce substantial ..." statement. > Techniques exist that produce good results with sequential re- > optimization, thus my suggestion to delete that statement, or > please refine it. Well, certainly the text that stands is a little too definitive. But there is a simple 6-node networks where sequential processing simply will not produce a solution unless there is coordination between the LSP computations, and since the LSPs have separate head-ends, a favorable result can only be achieved using coordinated requests, or a central request. In no way does this say that you must always do this, just that in order to get best results you may want to. >>> Yes, it actually depends on the topology, the traffic matrix, the >>> online algorithm used, etc. We will delete this statement. >> >> So rather than deleting the statement, I suggest qualifying it. >> Of course, the potential for network-wide gains from reoptimization >> of LSPs one-by-one is dependent on the network usage and size of the >> LSPs being reoptimized. But the key point remains: if you only >> compute the reoptimized path of one LSP at a time, and if you give >> no consideration to the other LSPs in the network when you do it, >> you run the risk of significant devaluation of the process. > > See it is always difficult to avoid "significant", ... That really > depends. For example, dynamic preemption schemes based > on LSP size can be designed to get close to the results given > by a global CSPF applied by placing TE LSPs in decreasing > sizes, which itself can be fairly close to some centralized > algorithms. True. But hard to justify such schemes in the same thread where you talk about the importance of minimising traffic loss and jitter. >>> I mentioned >>> a trade-off between optimization versus network impact. Indeed, if >>> you can reoptimize the set of TE LSPs in order to reduce the max >>> link utilization by 5% but this requires to reroute two hundreds >>> TE LSPs with on the average 4 reroutes per TE LSP, this may not be >>> a good idea. >> >> Well, that would depend, wouldn't it? If the network is unable to >> place any more LSPs, one might think that retrieving 5% was >> pretty cool :-) > > Ah I was referring to a reoptimization case (not failure): " if you > can reoptimize the set of TE LSPs in order to reduce the max link > utilization by 5% ..." Yup. I, too, am talking about the reoptimization case. Oh, this *is* fun. Well more fun than my real job ;-) Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri May 11 18:53: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 1Hmdyl-0008IU-KB; Fri, 11 May 2007 18:52:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmdyk-0008IO-OI for pce@ietf.org; Fri, 11 May 2007 18:52:50 -0400 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmdyk-0003iu-Cl for pce@ietf.org; Fri, 11 May 2007 18:52:50 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1149851wri for ; Fri, 11 May 2007 15:52:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a77ZQ/fdT5Abq5boMj5q0kybUWZf+aebWxrJwSt/ytm/gvOmZ3HP5c6zKYTMyPEHtKC+qV10OO0qHKROa+kGQU+FqHzv0PCTMsv3tXvhKdqhIFZAhZVb1Xgbh08uceYAEFWmDAZaBc9eADjVGyBhoGR3+1oMDeYBogHHbOnjjS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nZlAKPHf+CkgEINfvrezdcTJA40kyWUyB+uz6l6Ru0z8JWphZsk0CJIfCy5SZHuPUjOYREhG1CQXITI8o9UcVd3lFBwQ6s+H9MqLSvDcv/DpMCwBk9PTmjPsKZGhy9zIlI0/CjiyO/kTnr196k86/u7rcvzjuyF+CXbbebRWi6U= Received: by 10.114.46.1 with SMTP id t1mr42947wat.1178923969692; Fri, 11 May 2007 15:52:49 -0700 (PDT) Received: by 10.115.15.3 with HTTP; Fri, 11 May 2007 15:52:49 -0700 (PDT) Message-ID: <406e32c00705111552v5f928b7aja6777cc6803c0a57@mail.gmail.com> Date: Fri, 11 May 2007 18:52:49 -0400 From: "Peng He" To: rbradfor@cisco.com Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-path-key-00.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.5 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hello Rich, Regarding your recent draft "Preserving Topology Confidentiality in Inter-Domain Path Computation using a key based mechanism", Section 3 Path-Key Solution, in the middle of the first paragraph, "The entry and boundary LSR of each CPS SHOULD be specified as hops in the returned path immediately preceding the PKS, but where two PKSs are supplied in sequence the entry node to the second MAY be encoded within the first." Does that mean you use the number of hops as the only metric to choose the best inter-AS end-to-end path among the several computed (by the cooperation among PCEs) candidate end-to-end paths? Or the only property of the PKS is the number of hops, no any other TE metrics? Particularly, "specified as hops in the returned path immediately preceding the PKS" What does the "path" here refer to, "sub-path" or "path segment" , or "end-to-end inter-AS path"? Thanks, Peng On 5/2/07, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group of the IETF. > > Title : 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-00.txt > Pages : > Date : 2007-5-2 > > Multiprotocol Label Switching (MPLS) 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 (ASs), 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 ASs 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 LSP 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 (RSVP) explicit route object. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-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-path-key-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-path-key-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. > > > _______________________________________________ > 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 May 12 13:20:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmvGi-0005Eo-F7; Sat, 12 May 2007 13:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmvF1-0004oB-E4; Sat, 12 May 2007 13:18:47 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HmvEZ-00061i-8Q; Sat, 12 May 2007 13:18:21 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4f464654a1; Sun, 13 May 2007 01:29:23 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1b46417044; Wed, 09 May 2007 07:03:45 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 09 May 2007 07:03:45 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYVj-0001D3-AI; Tue, 08 May 2007 18:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYVP-00089r-7b; Tue, 08 May 2007 18:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlYVO-0002Xy-QY; Tue, 08 May 2007 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8916D26EB2; Tue, 8 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlYVO-0002F6-BZ; Tue, 08 May 2007 18:50: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, 08 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) 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-Spam-Score: 2.2 (++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-isis-05.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 : IS-IS protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-isis-05.txt Pages : 19 Date : 2007-5-8 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-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-disco-proto-isis-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-disco-proto-isis-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-5-8151125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-isis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-8151125.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 Mon May 14 15:42: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 1HngRN-0003YO-7w; Mon, 14 May 2007 15:42:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngRM-0003XX-6L for pce@ietf.org; Mon, 14 May 2007 15:42:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HngRL-0001DD-6z for pce@ietf.org; Mon, 14 May 2007 15:42:40 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 May 2007 15:42:39 -0400 X-IronPort-AV: i="4.14,532,1170651600"; d="scan'208,217"; a="60203732:sNHT309801676" 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 l4EJgciq010226; Mon, 14 May 2007 15:42:38 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4EJgc5j019841; Mon, 14 May 2007 19:42:38 GMT Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 15:42:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-path-key-00.txt Date: Mon, 14 May 2007 15:42:37 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D332030FF55C@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <406e32c00705111552v5f928b7aja6777cc6803c0a57@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-path-key-00.txt Thread-Index: AceUHx2sYqGSvQgbSU+RA81CIMHmxwCNytcg From: "Rich Bradford \(rbradfor\)" To: "Peng He" X-OriginalArrivalTime: 14 May 2007 19:42:38.0694 (UTC) FILETIME=[074E3060:01C79660] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=31906; t=1179171758; x=1180035758; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rbradfor@cisco.com; z=From:=20=22Rich=20Bradford=20\(rbradfor\)=22=20 |Subject:=20RE=3A=20[Pce]=20I-D=20ACTION=3Adraft-ietf-pce-path-key-00.txt |Sender:=20 |To:=20=22Peng=20He=22=20; bh=avy4JYBGE+DJafZycfhnsQMrAOTG0kDe5xVrzMtcmHI=; b=UwqnJdcgzDo1h0MlCvajMm+zKd1de4kpSOqhU/nrEP8bRuYHH42gYIoJa6Ln36K3hLb91S7h Yri/lwjp7Q28r4dDo4wTRUwWRSSwss9xQcvpVZ6ZFIVrQTh+iCnD9zeL; Authentication-Results: rtp-dkim-1; header.From=rbradfor@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fedb3c53163e7310de985aa5c1c03936 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="===============0767850907==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0767850907== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79660.070DBBB2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79660.070DBBB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peng, The number of hops is only one metric. Other TE metrics are still valid for EROs containing PKSs. The term "path" in this context generally refers to the path as returned by the PCE, but is most relevant to the ERO portion of that path. A PCE returns a path-list which may contain more than one path. Each path consists of an ERO optionally followed objects like BANDWIDTH and METRICS. The presence of a PKS within a particular ERO is independent of the presence or absence of any metrics associated with the path. Does that answer your question? Best Regards, Rich =20 > -----Original Message----- > From: Peng He [mailto:peng.he.2000@gmail.com] > Sent: Friday, May 11, 2007 6:53 PM > To: Rich Bradford (rbradfor) > Cc: pce@ietf.org > Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-path-key-00.txt >=20 > Hello Rich, >=20 > Regarding your recent draft "Preserving Topology Confidentiality in > Inter-Domain Path Computation using a key based mechanism", Section 3 > Path-Key Solution, in the middle of the first paragraph, >=20 > "The entry and boundary LSR of > each CPS SHOULD be specified as hops in the returned path > immediately preceding the PKS, but where two PKSs are supplied in > sequence the entry node to the second MAY be encoded within the > first." >=20 > Does that mean you use the number of hops as the only metric to choose > the best inter-AS end-to-end path among the several computed (by the > cooperation among PCEs) candidate end-to-end paths? Or the only > property of the PKS is the number of hops, no any other TE metrics? >=20 > Particularly, "specified as hops in the returned path immediately > preceding the PKS" What does the "path" here refer to, "sub-path" or > "path segment" , or "end-to-end inter-AS path"? >=20 > Thanks, > Peng >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 5/2/07, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Path Computation Element Working Group of the > IETF. > > > > Title : 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-00.txt > > Pages : > > Date : 2007-5-2 > > > > Multiprotocol Label Switching (MPLS) 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 (ASs), 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 ASs 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 LSP 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 (RSVP) explicit route object. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-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-path-key-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-path-key-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. > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > ------_=_NextPart_001_01C79660.070DBBB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peng,

   The number of hops is only one metric. Other TE = metrics are still valid for EROs containing PKSs.

   The term “path” in this context = generally refers to the path as returned by the PCE, but is most relevant to the ERO = portion of that path. A PCE returns a path-list which may contain more than one = path. Each path consists of an ERO optionally followed objects like BANDWIDTH and = METRICS. The presence of a PKS within a particular ERO is independent of the = presence or absence of any metrics associated with the = path.

  Does that answer your = question?

  Best Regards,

    Rich

 

> -----Original Message-----

> From: Peng He = [mailto:peng.he.2000@gmail.com]

> Sent: Friday, May 11, 2007 6:53 PM

> To: Rich = Bradford (rbradfor)

> Cc: pce@ietf.org

> Subject: Re: [Pce] I-D = ACTION:draft-ietf-pce-path-key-00.txt

>

> Hello Rich,

>

> Regarding your recent draft "Preserving Topology Confidentiality in

> Inter-Domain Path Computation using a key based = mechanism", Section 3

> Path-Key Solution, in the middle of the first = paragraph,

>

> "The entry and boundary LSR of

>    each CPS SHOULD be specified as hops in = the returned path

>    immediately preceding the PKS, but where = two PKSs are supplied in

>    sequence the entry node to the second MAY = be encoded within the

>    first."

>

> Does that mean you use the number of hops as the only = metric to choose

> the best inter-AS end-to-end path among the several = computed  (by the

> cooperation among PCEs) candidate end-to-end paths? Or the = only

> property of the PKS is the number of hops, no any other TE metrics?

>

> Particularly, "specified as hops in the returned = path  immediately

> preceding the PKS" What does the "path" here = refer to, "sub-path" or

> "path segment" , or "end-to-end inter-AS path"?

>

> Thanks,

> Peng

>

>

>

>

>

>

>

>

> On 5/2/07, Internet-Drafts@ietf.org <Internet-Drafts@ietf.org> wrote:

> > A New Internet-Draft is available from the on-line Internet-Drafts

> > directories.

> > This draft is a work item of the Path Computation = Element Working Group of the

> IETF.

> >

> >         = Title           : 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-00.txt

> >         Pages           = :

> >        =  Date          &nb= sp; : 2007-5-2

> >

> >    Multiprotocol Label Switching (MPLS) 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 (ASs), 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 ASs 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 LSP = 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 (RSVP) explicit = route object.

> >

> >

> > A URL for this Internet-Draft is:

> > http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-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-path-key-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-path-key-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.

> >

> >

> > = _______________________________________________

> > Pce mailing list

> > Pce@lists.ietf.org

> > = https://www1.ietf.org/mailman/listinfo/pce

> >

> >

------_=_NextPart_001_01C79660.070DBBB2-- --===============0767850907== 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 --===============0767850907==-- From pce-bounces@lists.ietf.org Tue May 15 09:26: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 1Hnx3I-0007K7-VF; Tue, 15 May 2007 09:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnx3H-0007K1-0q for pce@ietf.org; Tue, 15 May 2007 09:26:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnx3G-0000sn-FT for pce@ietf.org; Tue, 15 May 2007 09:26:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 May 2007 09:26:54 -0400 X-IronPort-AV: i="4.14,537,1170651600"; d="scan'208"; a="121128879:sNHT64240768" 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 l4FDQsa9001140; Tue, 15 May 2007 09:26:54 -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 l4FDQb5l007775; Tue, 15 May 2007 13:26:46 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); Tue, 15 May 2007 09:26:37 -0400 Received: from [10.86.104.185] ([10.86.104.185]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 09:26:36 -0400 In-Reply-To: <001b01c7940a$9f79c550$520c7c0a@china.huawei.com> References: <001b01c7940a$9f79c550$520c7c0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04BA7BBE-4AC3-4BCF-B613-E8146E5B81AF@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Tue, 15 May 2007 09:24:52 -0400 To: Young Lee X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 15 May 2007 13:26:36.0717 (UTC) FILETIME=[A9BB75D0:01C796F4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12462; t=1179235614; x=1180099614; 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=20Comments=20on=20draft-lee-pce-global-concurrent-optim ization-03.txt |Sender:=20 |To:=20Young=20Lee=20; bh=dzQ9KhbuAg7RjxtxT92S1cG0zHQYYMo+ekUS0gqErvs=; b=YwQB7p5Z7r61PBiigWzmIphsZYm3zx6hXHe+JfL/LrwenA58n2rvyWPwLWLWSumjwgdUeD/g JKkoyc1385ypogGfXQVBGpPSbZPi3PIKkPerYgWdtg5Giv5VsL8gD3Z0; 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: 10dcc25e55b9b5f7d6ded516404bdc4c Cc: pce@ietf.org Subject: [Pce] Re: Comments on draft-lee-pce-global-concurrent-optimization-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, On May 11, 2007, at 4:26 PM, Young Lee wrote: > Hi all, > > Thanks for your comments and rather intense discussions on various > points. > Let me recapitulate all the discussion points here before the next > version > would be updated. > > (i) Applicability section > - The applicability section clearly and thoroughly states the detail > scenarios to which GCO can be applied, highlighting potential problems > associated with GCO application such as scalability, synchronization, > failure impact during re-optimization, etc. > - There shouldn't be, however, any assumptions that preclude GCO > from the > applicability to specific networks or scenarios. > Yes as long as the flags are in place to indicate when such mechanisms could be fairly "dangerous" in some deployment scenarios in term of network stability. > (2) "Real-time" lingo. > - We will delete "real-time" from the original statement at the > minimum. > - Add some statement associated with an NMS based approach when a > large > number of LSPs fails. > Yes. > (3) Is PCC = NMS for GCO application? > - We can add "The PCE GCO application is primarily an NMS based > solution" in > abstract/introduction. > - I don't believe we need to say that the PCC for GCO MUST be an NMS. > In that case, you would need to explain in more details what are the consequences of applying such a model to the case where each LSR is a PCC. In particular, I'm referring to the synchronization issues between all PCCs and the PCE for GCO, including the case where an LSR fails to signal a TE LSP after the GCO has been performed. > (4) "Green-field" issue > - Switch the order in Section 3 such that Re-optimization of an > existing > network appears before "green-field" application. > - Rephrase to add: > (i) "Green-field application is a special case when there is no LSP > setup. Once the LSPs are setup, it is not a green field." > (ii) "The need for green-field application arises when network > planner will want to make use of computation servers to plan the LSPs > that will be provisioned in their network." > > (5) "Sequential re-optimization ... will unlikely to produce > substantial > improvements in overall network optimization except in very sparsely > utilized networks." > - We will rephrase the statement. > Thanks ... How ? > (6) Multi-Session Object > - We agreed that this will move this feature to the second phase. > OK. > (7) "Multi-step" rerouting > - We agreed that we will add the potential impact by this feature. > OK, will wait for your text. > (8) Objective Function > - We are in sync 100%. > Thanks. JP. > Thanks for your comments. > > Best Regard, > > Young > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, May 11, 2007 9:02 AM > To: JP Vasseur > Cc: Young Lee; 'LE ROUX Jean-Louis RD-CORE-LAN'; 'Eiji Oki'; > 'Daniel King' > Subject: Re: Comments on draft-lee-pce-global-concurrent- > optimization-03.txt > > Hi, > > [PCE list removed] > >>> Define "real-time". >>> >>> The applicability to the problem space is clear. A well-known set of >>> LSP has been impacted by a network failure. Rather than compute new >>> paths on demand from the head-end LSPs with the consequent resource- >>> contention blocking problems, there may be considerable benefit in >>> computing the paths of the LSPs as a set. (Of course, this assumes >>> the availability of certain information, but an NMS might reasonably >>> have access to this and make the bulk computation request.) >>> >>> Thus, if there is any modification to make, I suggest only deleting >>> "in real-time". >> >> I guess that we can agree on the fact that centralized system provide >> more qualitative output in term of path quality but are typically >> fairly >> slow and not appropriate for "real time" processing. > > I think that Dan and I are bound to argue about "fairly slow". > > But it does depend on the definition of "real time". > On the whole, n CSPF computations can be expected to take n times > the time > of one CSPF computation. > Bulk computations can be made to scale far better than linearly > with the > number of paths. > >> Now of course, we could argue for ever on: >> * More qualitative: by how much ? >> * What do we mean by path quality or optimality ? >> * What does "slow" mean ? >> We could certainly find scenarios where the delta in term of >> optimality is fairly negligible and centralized systems >> are extremely slow, and vice versa. >> So my point was to not "promote" such system for "real-time" >> processing. > > OK. > Well I'd turn it around and say "do promote such systems for offline > processing" and allow them to be used on-line if someone wants to > and if > they are observed to work. > > And finally, reoptimization and recovery after FRR do not need the > same > "insant" action that unprotected recovery needs. So I think it is > probaly OK > > to not push "real time" as I suggested. > > [SNIP] > >>> Why would the procedures not be applicable to a head-end LSR >>> requesting bulk reoptimization of the set of LSPs for which it acts >>> as ingress? (I.e. a subset of all LSPs in the system.) >>> >>> We already accept that such an LSR should be allowed to issue >>> individual LSP reoptimization requests. And we already accept that >>> a PCReq may contain multiple computation requests that are 'linked'. >>> >>> So, if JP's request is that an LSR should not issue an optimization >>> request for an LSP for which it is not the head-end, I can see the >>> point. Although I might want to rephrase this because the important >>> question is what use is made of the computation response - that is, >>> if the PCC is unable to make use of the computed path, there is no >>> value in performing the computation. >>> >>> Clearly, NMS is a primary application of this work, but it is not >>> the only application. Another key use would be the VNT Manager >>> component discussed in the multi-layer PCE drafts. >> >> This is an important point, on which we may not 100% agree. If now >> one want to use this model where each LSR is a PCC so as to globally >> optimize the path computation of a set of TE LSPs, that clearly >> requires very significant synchronizations between the PCE and each >> of those PCCs (which is not the base with synchronized path >> computation request such as diverse path computations >> originated by a single LSR. In other words, consider the case where >> a PCC requires to resize one of its TE LSPs and sends a request to >> the PCE, which in turn triggers the reroute of hundreds of TE LSPs >> to satisfy that demand. See the number of synchronizations that this >> does require between the PCE and all PCCs. And there are many >> other scenarios where such model could have limitations that the >> draft >> should point out. >> >> Are we agreeing ? > > Completely, but... > > You must not assume that there is only one point of provisioning > control for > > any LSP. And you must not assume that there is only one PCC for any > head-end > > of an LSP. > > So, for example, when an LSP is requested, the NMS may or may not > act as a > PCC to find a path for the LSP. > Thus the message sent by the NMS to the head-end LSR may or may not > contain > a full path. > Thus the head-end LSR may not or may act as a PCC and consult a PCE. > > So, on recovery, there are options: > 1. The head-end LSR acts as PCC for a single LSP > 2. The head-end LSR acts as PCC for a batch of LSPs > 3. The head-end LSR acts as PCC for a single distributed request > for global reoptimization, including LSPs for which it is not > head-end > 4. As 1 or 2, but the PCE is responsible for coordinating all > requests from PCCs and treating them as one > 5. The NMS is responsible for determining all LSPs that need > to be recomputed. > > I would not speak in favor of options 3 and 4. > I would speak in favor of options 1, 2 and 5. > > Dimitry would, of course, be worried about the fact that we are > potentially > taking intelligence that was previously distributed into the > control plane > and putting it back into the "management" plane. For options 1 and > 2, I > would say this is not true. For option 5, this is clearly true, but > it is > the cost of full optimization. > > [SNIP] > >> So it is a green field for a very short period of time. > > Such is the nature of *all* green fields. Otherwise, what would be the > point? :-) > >>>>>> 5) >>>>>> >>>>>> Note that sequential re- >>>>>> optimization of such TE LSPs is unlikely to produce >>>>>> substantial improvements in overall network optimization >>>>>> except in very sparsely utilized networks. >>>>>> >>>>>> Well, that DEPENDS ! I could show you distributed algorithms >>>>>> where >>>>>> sequential reoptimization allows for a significant >>>>>> improvements. I >>>>>> would suggest to remove that statement. >>> >>> Actually, I think that the sequential algorithms that JP refers to >>> are actually *global* reoptimization. That is, they sequence through >>> the set of LSPs making optimization improvements. The fact that the >>> algorithms are distributed is neither here nor there. >> >> We keep facing that terminology issue with the word "distributed" >> where this could apply to the algorithm itself or the fact that path >> computations may be performed by different engine (e.g. case >> where each LSR is its own PCE). I was referring to the "unlikely to >> produce substantial ..." statement. >> Techniques exist that produce good results with sequential re- >> optimization, thus my suggestion to delete that statement, or >> please refine it. > > Well, certainly the text that stands is a little too definitive. > > But there is a simple 6-node networks where sequential processing > simply > will not produce a solution unless there is coordination between > the LSP > computations, and since the LSPs have separate head-ends, a > favorable result > > can only be achieved using coordinated requests, or a central request. > > In no way does this say that you must always do this, just that in > order to > get best results you may want to. > >>>> Yes, it actually depends on the topology, the traffic matrix, the >>>> online algorithm used, etc. We will delete this statement. >>> >>> So rather than deleting the statement, I suggest qualifying it. >>> Of course, the potential for network-wide gains from reoptimization >>> of LSPs one-by-one is dependent on the network usage and size of the >>> LSPs being reoptimized. But the key point remains: if you only >>> compute the reoptimized path of one LSP at a time, and if you give >>> no consideration to the other LSPs in the network when you do it, >>> you run the risk of significant devaluation of the process. >> >> See it is always difficult to avoid "significant", ... That really >> depends. For example, dynamic preemption schemes based >> on LSP size can be designed to get close to the results given >> by a global CSPF applied by placing TE LSPs in decreasing >> sizes, which itself can be fairly close to some centralized >> algorithms. > > True. > But hard to justify such schemes in the same thread where you talk > about the > > importance of minimising traffic loss and jitter. > >>>> I mentioned >>>> a trade-off between optimization versus network impact. Indeed, if >>>> you can reoptimize the set of TE LSPs in order to reduce the max >>>> link utilization by 5% but this requires to reroute two hundreds >>>> TE LSPs with on the average 4 reroutes per TE LSP, this may not be >>>> a good idea. >>> >>> Well, that would depend, wouldn't it? If the network is unable to >>> place any more LSPs, one might think that retrieving 5% was >>> pretty cool :-) >> >> Ah I was referring to a reoptimization case (not failure): " if you >> can reoptimize the set of TE LSPs in order to reduce the max link >> utilization by 5% ..." > > Yup. > I, too, am talking about the reoptimization case. > > Oh, this *is* fun. > Well more fun than my real job ;-) > > Cheers, > Adrian > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 16 10:46: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 1HoKm8-0002gZ-QU; Wed, 16 May 2007 10:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoKm7-0002gQ-6t for pce@ietf.org; Wed, 16 May 2007 10:46:47 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoKm5-0005Eh-Lp for pce@ietf.org; Wed, 16 May 2007 10:46:47 -0400 Received: by nz-out-0506.google.com with SMTP id z6so621651nzd for ; Wed, 16 May 2007 07:46:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XkJ4PHN6euP48KeSmvVRAIrAGC3BtDAAtLmKGhyKy+HX58ntyAi8Ihn+BuooPs6szQnl3kRrdEQUktcB3rnsUIlwObGaFdLtUb3BTRgtgpreQMBvy3UI6WIstSPaxn3P+NDhYNRDaap3VF3MXR6kE7wBUp0M/lVCvB2vkH6NDRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NKjXrlI7an83rZ8NGJIPatcm2KWrfjz6ztoGClqQCF++qhWDAXWXFH0lAAZlVZVKRs1R/6t0u154NGA8J4R2++pYaHHj8f8lkn77ZmklOmd57j3zeTHr2weO+JzLOMI8g/8dZBd30pcRoaeZXfx6tZlBT5VQy98RgvwOKysExOw= Received: by 10.114.171.1 with SMTP id t1mr2194542wae.1179326804355; Wed, 16 May 2007 07:46:44 -0700 (PDT) Received: by 10.115.15.3 with HTTP; Wed, 16 May 2007 07:46:44 -0700 (PDT) Message-ID: <406e32c00705160746k66a5b6c8ma3aebffae88e0e99@mail.gmail.com> Date: Wed, 16 May 2007 10:46:44 -0400 From: "Peng He" To: "Rich Bradford (rbradfor)" Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-path-key-00.txt In-Reply-To: <3C292CE901FC634693F24FB2DDC4D332030FF55C@xmb-rtp-20d.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <406e32c00705111552v5f928b7aja6777cc6803c0a57@mail.gmail.com> <3C292CE901FC634693F24FB2DDC4D332030FF55C@xmb-rtp-20d.amer.cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hello Rich, Please see in line. On 5/14/07, Rich Bradford (rbradfor) wrote: > > > > > Hi Peng, > > The number of hops is only one metric. Other TE metrics are still valid >> for EROs containing PKSs. > I think this is mainly because path key can be considered as kind of "label" or "index" with only local meaning. The purpose of it is only to mask (all of or part of) explicit sequence of nodes within a PCE-computed path. There is no particular property with the path key, like TE metrics, etc. But there are properties WITH the ERO that contains the path key(s), which should be enough. > The term "path" in this context generally refers to the path as returned > by the PCE, but is most relevant to the ERO portion of that path. A PCE > returns a path-list which may contain more than one path. Each path consists > of an ERO optionally followed objects like BANDWIDTH and METRICS. The > presence of a PKS within a particular ERO is independent of the presence or > absence of any metrics associated with the path. > Agreed. But I just guess you might need to define/distinguish the "path" and "end-to-end path" somewhere, especially when taking about inter-AS/multi-AS path computing, which need close cooperation among PCEs and each PCE just computes a "segment" of the overall path actually. > Does that answer your question? Yes. Thanks, Peng > > Best Regards, > > Rich > > > > > > -----Original Message----- > > > From: Peng He [mailto:peng.he.2000@gmail.com] > > > Sent: Friday, May 11, 2007 6:53 PM > > > To: Rich Bradford (rbradfor) > > > Cc: pce@ietf.org > > > Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-path-key-00.txt > > > > > > Hello Rich, > > > > > > Regarding your recent draft "Preserving Topology Confidentiality in > > > Inter-Domain Path Computation using a key based mechanism", Section 3 > > > Path-Key Solution, in the middle of the first paragraph, > > > > > > "The entry and boundary LSR of > > > each CPS SHOULD be specified as hops in the returned path > > > immediately preceding the PKS, but where two PKSs are supplied in > > > sequence the entry node to the second MAY be encoded within the > > > first." > > > > > > Does that mean you use the number of hops as the only metric to choose > > > the best inter-AS end-to-end path among the several computed (by the > > > cooperation among PCEs) candidate end-to-end paths? Or the only > > > property of the PKS is the number of hops, no any other TE metrics? > > > > > > Particularly, "specified as hops in the returned path immediately > > > preceding the PKS" What does the "path" here refer to, "sub-path" or > > > "path segment" , or "end-to-end inter-AS path"? > > > > > > Thanks, > > > Peng > > > > > > > > > > > > > > > > > > > > > > > > > > > On 5/2/07, Internet-Drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > This draft is a work item of the Path Computation Element Working Group > of the > > > IETF. > > > > > > > > Title : 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-00.txt > > > > Pages : > > > > Date : 2007-5-2 > > > > > > > > Multiprotocol Label Switching (MPLS) 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 (ASs), 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 ASs 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 LSP 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 (RSVP) explicit route object. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-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-path-key-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 et/intern-drafts/draft-ietf-pce-path-key-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. > > > > > > > > > > > > _______________________________________________ > > > > 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 May 18 11:15:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4Ad-0007Jx-At; Fri, 18 May 2007 11:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4Ac-0007IX-1C for pce@ietf.org; Fri, 18 May 2007 11:15:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp4AZ-0005F7-Iu for pce@ietf.org; Fri, 18 May 2007 11:15:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 May 2007 11:15:03 -0400 X-IronPort-AV: i="4.14,552,1170651600"; d="scan'208,217"; a="60609231:sNHT78453676" 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 l4IFF3jT023715 for ; Fri, 18 May 2007 11:15:03 -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 l4IFF165008823 for ; Fri, 18 May 2007 15:15:03 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); Fri, 18 May 2007 11:15:03 -0400 Received: from [10.86.104.185] ([10.86.104.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 11:12:33 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <2197FB23-8788-4D22-9699-8760535F2674@cisco.com> References: <34AA8CEA-CB65-4A17-BC4E-F90487343CF4@cisco.com> From: JP Vasseur Subject: Fwd: [Pce] PCEP Codepoints Date: Fri, 18 May 2007 11:12:20 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 18 May 2007 15:12:33.0965 (UTC) FILETIME=[F62FC5D0:01C7995E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4996; t=1179501303; x=1180365303; 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]=20PCEP=20Codepoints |Sender:=20 |To:=20pce@ietf.org; bh=vpYPXVB/VjzYlZkPaxinoqX0w45vRK8d+ITx4HJ4a8Q=; b=QWcDkphZhPq3Ry+Mpic7gQdCVxUjYueMVaZ/CLnWulJqPKmRz0fz5Ac/2pXZ8pfnSOjX2v/4 /swVQn0uRul2N5NOKRb9HgK4E3ofxBPImTBE8+oMkkt5Jf9EAw3Hs+vS; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1460376196==" Errors-To: pce-bounces@lists.ietf.org --===============1460376196== Content-Type: multipart/alternative; boundary=Apple-Mail-69--669522166 --Apple-Mail-69--669522166 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: JP Vasseur > Date: March 2, 2007 5:28:12 PM EST > To: pce@ietf.org > Subject: [Pce] PCEP Codepoints > > Hi, > > As you know, Adrian generously offered to maintain the temporary > PCEP registry of codepoints at http://www.olddog.co.uk/pce.htm > until IANA takes over. > > Since there are several IDs defining new PCEP messages and objects, > if you have such IDs, could you please send me the code-points so > that we could update it accordingly ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-69--669522166 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

= --Apple-Mail-69--669522166-- --===============1460376196== 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 --===============1460376196==-- From pce-bounces@lists.ietf.org Tue May 22 23:09: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 1HqhDk-00037e-WB; Tue, 22 May 2007 23:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqhDj-00037V-Fu for pce@ietf.org; Tue, 22 May 2007 23:09:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqhDh-00065q-EB for pce@ietf.org; Tue, 22 May 2007 23:09:03 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 May 2007 05:08:59 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4N38wmf031583 for ; Wed, 23 May 2007 05:08:58 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4N38wDR020712 for ; Wed, 23 May 2007 03:08:58 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 05:08:58 +0200 Received: from [10.43.1.84] ([10.58.48.2]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 05:08:57 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: References: From: JP Vasseur Date: Wed, 23 May 2007 05:08:45 +0200 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 May 2007 03:08:57.0092 (UTC) FILETIME=[B3C77440:01C79CE7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20720; t=1179889738; x=1180753738; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20I-D=20ACTION=3Adraft-vasseur-pce-monitoring-03.txt=2 0 |Sender:=20; bh=6p9G96yn5H6SguniZVNZdQkyT+7YO2Cg8U2xjv7tOpQ=; b=QfS2njS7ff5GunOSl0vC0K41J28c6RblkW1Mhvplfx3ZmGS4ZEtXoVv7Rgv0c58w2EVvzQpQ lTZ9QINuFaLceAoRTvhAR/PBvU1vUq6nz2FdhEdQjx5k8kHYywY6KHNh; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Cc: Subject: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-monitoring-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1209223905==" Errors-To: pce-bounces@lists.ietf.org --===============1209223905== Content-Type: multipart/alternative; boundary=Apple-Mail-172--280937214 --Apple-Mail-172--280937214 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed New revision accounting for a few editorial comments received on the list and during the last meeting. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: May 11, 2007 9:50:02 PM GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-vasseur-pce-monitoring-03.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A set of monitoring tools for Path Computation Element > based Architecture > Author(s) : J. Vasseur > Filename : draft-vasseur-pce-monitoring-03.txt > Pages : 20 > Date : 2007-5-11 > > 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-vasseur-pce- > monitoring-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-vasseur-pce-monitoring-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-vasseur-pce-monitoring-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-5-11111555.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-172--280937214 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 New revision accounting for a = few editorial comments received on the list and during the last = meeting.

Thanks.

JP.

Begin = forwarded message:

Date: May 11, 2007 9:50:02 PM = GMT+02:00
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-vasseur-pce-monitoring-03.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts=A0
directories.


Title : A set of monitoring tools for = Path Computation Element based Architecture
= Author(s) = : J. Vasseur
= Filename = : draft-vasseur-pce-monitoring-03.txt
Pages : 20
Date : = 2007-5-11

=

A Path = Computation Element (PCE) based architecture has been
=A0=A0 = specified for the computation of Traffic Engineering (TE) = Label
=A0=A0 Switched Paths (LSPs) in = Multiprotocol Label Switching (MPLS) and
=A0=A0 Generalized MPLS (GMPLS) = networks in the context of single or
=A0=A0 multiple domains (where a = domain is referred to as a collection of
=A0=A0 network elements within a = common sphere of address management or path
=A0=A0 computational = responsibility such as IGP areas and Autonomous
=A0=A0 = Systems).=A0 In = PCE-based environments it is thus critical to monitor
=A0=A0 = the state of the path computation chain for troubleshooting = and
=A0=A0 performance monitoring = purposes: liveness of each element (PCE)
=A0=A0 involved in the PCE chain, = detection of potential resource contention
=A0=A0 states, statistics in term = of path computation times are examples of
=A0=A0 such metrics of = interest.=A0 This document = specifies procedures and
=A0=A0 extensions to the Path = Computation Element Protocol (PCEP) in order
=A0=A0 = to gather such information.

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-vasseur-pce-monitoring-03.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-vasseur-pce-monitoring-03.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-172--280937214-- --===============1209223905== 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 --===============1209223905==-- From pce-bounces@lists.ietf.org Wed May 23 00:24:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqiOX-00083O-Mq; Wed, 23 May 2007 00:24:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqiOW-00083J-MS for pce@ietf.org; Wed, 23 May 2007 00:24:16 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqiOV-0006UO-D8 for pce@ietf.org; Wed, 23 May 2007 00:24:16 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 May 2007 06:24:13 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4N4OCSR007708 for ; Wed, 23 May 2007 06:24:12 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4N4O8DR028509 for ; Wed, 23 May 2007 04:24:12 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 06:24:08 +0200 Received: from [10.43.1.84] ([10.58.48.2]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 06:24:07 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain To: pce@ietf.org From: JP Vasseur Date: Wed, 23 May 2007 06:23:57 +0200 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 May 2007 04:24:08.0071 (UTC) FILETIME=[34883970:01C79CF2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2; t=1179894252; x=1180758252; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20draft-ietf-pce-pcecp-interarea-reqs-05=20in=20RFC=20Editor=20 Queue |Sender:=20; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=szEzgH35PY/RnabFtUMs7538CSXvjoSATMxBIkCRbvfG4oobwJtCy7VJtFyiZE3GlsvqnJY1 /ekuoMa3tsCGoNGAtruSnm2I4S63C3uG4fT7CLs2G9TksXrnSu1L+ra0; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Cc: Subject: [Pce] draft-ietf-pce-pcecp-interarea-reqs-05 in RFC Editor Queue X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 23 12:50:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqu2c-0001Ts-Ai; Wed, 23 May 2007 12:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqu2a-0001Tn-NF for pce@ietf.org; Wed, 23 May 2007 12:50:24 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqu2Z-0004Jd-2d for pce@ietf.org; Wed, 23 May 2007 12:50:24 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 May 2007 18:50:20 +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 l4NGoKcT001672 for ; Wed, 23 May 2007 18:50:20 +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 l4NGoKDR007707 for ; Wed, 23 May 2007 16:50:20 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 18:50:20 +0200 Received: from [10.43.1.233] ([10.58.48.17]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 18:50:19 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Wed, 23 May 2007 18:50:07 +0200 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 May 2007 16:50:19.0633 (UTC) FILETIME=[72766E10:01C79D5A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8309; t=1179939020; x=1180803020; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Preliminary=20Agenda=20IETF-69 |Sender:=20; bh=4fa9YXNigJbVIlEPFl86gb7r+20tEkGkBM5Vqxlm7og=; b=bIpgWC6VUJ4g7lX4Js8y77XfB38G0YrjYApheiOPiFvf4MsJnfqRDYYdUiSJcHK01PRUjETC Rn/PQEaMADhZuRfulh0KQdJY1qcd0GJghGwbBHPqMhjzVNKfqLTwH37v; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.4 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Subject: [Pce] Preliminary Agenda IETF-69 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="===============0086993413==" Errors-To: pce-bounces@lists.ietf.org --===============0086993413== Content-Type: multipart/alternative; boundary=Apple-Mail-210--231655579 --Apple-Mail-210--231655579 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed https://datatracker.ietf.org/public/meeting_agenda_html.cgi? meeting_num=69 MONDAY, July 23, 2007 1520-1720 Afternoon Session II Breakout 1 APP sieve Sieve Mail Filtering Language WG Breakout 5 INT intarea Internet Area Open Meeting Breakout 6 RAI avt Audio/Video Transport WG Breakout 4 RTG pce Path Computation Element WG Breakout 2 RTG sidr Secure Inter-Domain Routing WG Breakout 3 SEC nea Network Endpoint Assessment WG --Apple-Mail-210--231655579 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

MONDAY, July 23, = 2007=A0

1520-1720 Afternoon Session = II
Breakout 1
APP
Sieve Mail Filtering Language = WG
Breakout = 5
INT
intarea
Internet Area Open Meeting
Breakout 6
RAI
Audio/Video Transport WG
Breakout 4
RTG
Path Computation Element WG
Breakout 2
RTG
Secure Inter-Domain Routing = WG
Breakout = 3
SEC
Network Endpoint Assessment = WG

= --Apple-Mail-210--231655579-- --===============0086993413== 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 --===============0086993413==-- From pce-bounces@lists.ietf.org Wed May 23 12:56:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqu8g-0005FT-PC; Wed, 23 May 2007 12:56:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqu8d-00055g-FS; Wed, 23 May 2007 12:56:39 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hqu8c-0002Kb-74; Wed, 23 May 2007 12:56:39 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 27C90175D7; Wed, 23 May 2007 16:56:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hqu87-0005iV-Tu; Wed, 23 May 2007 12:56:07 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 23 May 2007 12:56:07 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-disco-proto-ospf (OSPF protocol extensions for Path Computation Element (PCE) Discovery) to Proposed Standard X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'OSPF protocol extensions for Path Computation Element (PCE) Discovery ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-06-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15173&rfc_flag=0 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 23 13:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HquE3-0000EK-Tp; Wed, 23 May 2007 13:02:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HquE0-0000De-R3; Wed, 23 May 2007 13:02:12 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HquDz-0007aD-Km; Wed, 23 May 2007 13:02:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 975C43292C; Wed, 23 May 2007 17:02:11 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HquDz-0005om-Gs; Wed, 23 May 2007 13:02:11 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 23 May 2007 13:02:11 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: pce@ietf.org Subject: [Pce] Last Call: draft-ietf-pce-disco-proto-isis (IS-IS protocol extensions for Path Computation Element (PCE) Discovery) to Proposed Standard X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'IS-IS protocol extensions for Path Computation Element (PCE) Discovery ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-06-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15172&rfc_flag=0 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun May 27 10:53: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 1HsK7D-0007RM-5R; Sun, 27 May 2007 10:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsK7C-0007RH-AD for pce@ietf.org; Sun, 27 May 2007 10:53:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsK7B-0002T9-25 for pce@ietf.org; Sun, 27 May 2007 10:53:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 May 2007 10:53:01 -0400 X-IronPort-AV: i="4.14,585,1170651600"; d="scan'208"; a="61300617:sNHT37970256" 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 l4REr0qH013878 for ; Sun, 27 May 2007 10:53:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4REr0Be005839 for ; Sun, 27 May 2007 14:53:00 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); Sun, 27 May 2007 10:53:00 -0400 Received: from [10.86.104.186] ([10.86.104.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 10:52:58 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Sun, 27 May 2007 10:51:26 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 27 May 2007 14:53:00.0108 (UTC) FILETIME=[B83B28C0:01C7A06E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=112; t=1180277580; x=1181141580; 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:=20Slots=20required=20for=20the=20next=20WG=20Meeting=20? |Sender:=20 |To:=20pce@ietf.org; bh=zffHw1yGkcxm8/vJVL2IwY4plKu5eQT8LnhFK5Z6bw8=; b=rCFTHmIxSm5UJJet7vpPUNVgBWLI6tswxKjrKrmCSWfXaeHLdIDClOmeHTlOVS5UpZVBGkeo 03VkwUm7YEIlMe6u2z1Di/g2Z3vlZIyt7vmH7BGnTR2LX8aiNCD0HjzD; 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: 08e48e05374109708c00c6208b534009 Cc: Subject: [Pce] Slots required for the next WG Meeting ? X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Dear WG, If you need a slot for the next WG meeting in Chicago, thanks to let us know. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed May 30 07:41:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtMY5-0002rj-Md; Wed, 30 May 2007 07:41:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtMY4-0002i7-66 for pce@lists.ietf.org; Wed, 30 May 2007 07:41:04 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtMY2-0002RF-Mr for pce@lists.ietf.org; Wed, 30 May 2007 07:41:04 -0400 Received: (qmail 18906 invoked by uid 0); 30 May 2007 11:41:01 -0000 Received: from 192.35.17.15 by www071.gmx.net with HTTP; Wed, 30 May 2007 13:41:01 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 May 2007 13:41:01 +0200 From: _den@gmx.de Message-ID: <20070530114101.204850@gmx.net> MIME-Version: 1.0 To: pce@lists.ietf.org X-Authenticated: #19887475 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+ySbUW0I6yuZt8UwgAAP/vTTBMNog3AYgYviLOEG +duOfOLAcS5CPmnkHAXwtbbhdU21zNi7zGPw== Content-Transfer-Encoding: 7bit X-GMX-UID: rAsodTFlODB6dBkUXGVMjDs9Ji9SWtLB X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Pce] Comments on Idle and TCPPending states X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org In the description of the Idle state you can find: "Upon receiving a TCP connection on the well-known PCEP TCP port, if the TCP connection establishment succeeds..." Perhaps this is trivial, but I think that it should be mentioned, that if the connection establishment fails, the system remains in the Idle state. In the description of the TCPPending state you can find: "If TCPRetry < TCPMaxRetry the system: o Starts the TCPConnect timer, o Initiates of a TCP connection with the PCEP peer, o Increments the TCPRetry variable, o Stays in the TPCPending state. " If I use an exponentially increased timer, mentioned in description of Idle state, than I understand it so: For example I send SYN-packets in such intervals: 0 sec, 6, 24, 40, 55 Does it make sense to start the TCPConnect timer after each sending of TCP-SYN-packet? I understand the role of TCPConnect timer that it should detect that after sending of 5th SYN-packet it was no answer and should be canceled. Compare connect-function of BSD-sockets: There are will be only 3 SYN-packets sended: 0, 6, 24 seconds and after 75 seconds the function connect returns (=TCPConnect timer expires) -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce