From pce-bounces@ietf.org Sat Apr 2 13:14:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10036; Sat, 2 Apr 2005 13:14:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHnGa-00046g-Oy; Sat, 02 Apr 2005 13:22:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHn7t-0000mV-Bp; Sat, 02 Apr 2005 13:13:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHn7r-0000mQ-Mn for pce@megatron.ietf.org; Sat, 02 Apr 2005 13:13:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10004 for ; Sat, 2 Apr 2005 13:13:36 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHnFQ-0003ve-IC for pce@ietf.org; Sat, 02 Apr 2005 13:21:29 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id B9918E00033F for ; Sat, 2 Apr 2005 19:13:28 +0100 (BST) Received: from Puppy ([212.43.203.73] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 2 Apr 2005 19:13:15 +0100 Message-ID: <15f101c537af$e34d0fd0$dccb2bd4@Puppy> From: "Adrian Farrel" To: Date: Sat, 2 Apr 2005 18:30:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 02 Apr 2005 18:13:16.0838 (UTC) FILETIME=[A47CE460:01C537AF] X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Pce] Liaison statement received from ITU-T SG15 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: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Hi, We have received a response liaison from the ITU-T. This will be published on the IETF's web site in due course. In the mean time, the text can be found below. We will craft and send a response in due course. Adrian ==== To: IETF PCE Working group From: Hing-Kam Lam, Rapporteur Q14/15 Malcolm Betts, Rapporteur Q12/15 Jerry Shrimpton, Rapporteur Q6/15 Subject: Liaison Statement to IETF on the creation of a new PCE Working group For: Action Deadline: 9 May 2005 Thank you for your liaison on the creation of the PCE working group. The ASON architecture (G.8080) already fully supports the distribution of functions that you have described. Providing protocols to support such distributions is therefore of interest to SG 15. We look forward to establishing a cooperative working relationship on this topic. Q.6/15 (Characteristics of optical systems for terrestrial transport networks) noted that your charter contains the following item: "- Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models." Could you please clarify the meaning of "path quality" in the above definition? If this includes optical monitoring aspects, please be aware that ITU-T Q.6/15 has developed a Recommendation, G.697, Optical monitoring for DWDM systems which may be of interest to the PCE working group. This Recommendation is currently in force. In addition, we would appreciate a better understanding of whether the PCE working group will study mechanisms by which optical path quality can be calculated or only mechanisms for communicating the results of such calculations. An electronic copy of this liaison can be found at ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Apr 5 16:50:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15700; Tue, 5 Apr 2005 16:50:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIv8Q-0005n8-1b; Tue, 05 Apr 2005 16:58:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIuxP-0006cm-OB; Tue, 05 Apr 2005 16:47:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIuxO-0006cT-50 for pce@megatron.ietf.org; Tue, 05 Apr 2005 16:47:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15030 for ; Tue, 5 Apr 2005 16:47:26 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIv1D-0005JK-3H for pce@ietf.org; Tue, 05 Apr 2005 16:51:27 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id D10A9E0001D4 for ; Tue, 5 Apr 2005 21:42:45 +0100 (BST) Received: from Puppy ([212.43.203.74] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 21:32:39 +0100 Message-ID: <175201c53a1e$dd7f3b20$dccb2bd4@Puppy> From: "Adrian Farrel" To: Date: Tue, 5 Apr 2005 21:20:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 05 Apr 2005 20:32:40.0491 (UTC) FILETIME=[9CDA4FB0:01C53A1E] X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Subject: [Pce] Fw: Enforcement of Updated IPR Boilerplate 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: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Please be aware and update your new draft submissions accordingly. Adrian ----- Original Message ----- From: "IETF Secretariat" To: "IETF Announcement list" Sent: Monday, April 04, 2005 6:05 PM Subject: Enforcement of Updated IPR Boilerplate > As you may be aware, RFC 3667 (BCP 78), "IETF Rights in Contributions," > has been obsoleted by RFC 3978 (BCP 78), which was published in March > 2005, and which bears the same title. The major difference between the > two RFCs is that the IPR-related notices and disclaimers that the IETF > requires in all Internet-Drafts have been updated to correct anomalies. > > The updated versions of the required notices and disclaimers are specified > in Section 5, "Notices Required in IETF Documents," of RFC 3978, and in > Section 3, "IPR-Related Notices Required in Internet-Drafts," of the > recently revised "Guidelines to Authors of Internet-Drafts" > (http://www.ietf.org/ietf/1id-guidelines.html). The "Guidelines" document > also provides additional guidance regarding the placement of these notices. > > Currently, the IETF Secretariat accepts and posts Internet-Drafts that > include *either* the RFC 3667 or the RFC 3978 version of these notices. > However, as of 17:00 ET on Friday May 6, 2005, the Secretariat will > accept *only* those Internet-Drafts that comply with the requirements > of RFC 3978, and with the most recent version of the "Guidelines" > document. > > Please note that the required notices and disclaimers must be reproduced > verbatim since they have been legally reviewed and formally adopted as part > of the IETF process. The Secretariat will not accept deviations from the > specified text, nor will it correct the text. Any documents that do not > comply with the requirements will be returned to the submitter. > > The IETF Secretariat > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Apr 11 16:51:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25643; Mon, 11 Apr 2005 16:51:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL62B-0006pV-Lj; Mon, 11 Apr 2005 17:01:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5CL-0003PX-4M; Mon, 11 Apr 2005 16:07:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5CJ-0003Ja-Fk for pce@megatron.ietf.org; Mon, 11 Apr 2005 16:07:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16623 for ; Mon, 11 Apr 2005 16:07:41 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5Lc-0003kO-5t for pce@ietf.org; Mon, 11 Apr 2005 16:17:29 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Apr 2005 13:07:33 -0700 X-IronPort-AV: i="3.92,94,1112598000"; d="scan'208"; a="627814501:sNHT26904316" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3BK7S7T020795; Mon, 11 Apr 2005 13:07:29 -0700 (PDT) Received: from [192.168.1.100] (che-vpn-cluster-2-44.cisco.com [10.86.242.44]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA03014; Mon, 11 Apr 2005 13:07:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <116da15ae601e11e94f3e4bf283e8763@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Mon, 11 Apr 2005 16:07:46 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Pce] Please comment on 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: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Hi, We just wanted to capture your attention on draft-ash-pce-comm-protocol-gen-reqs-00.txt (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen- reqs-00.txt) which is a product of the Design Team. The DT managed to produce this ID in a short timeframe after extensive discussion (thanks !). Please comment. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Apr 15 17:05:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25566; Fri, 15 Apr 2005 17:05:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYAh-0001BB-Al; Fri, 15 Apr 2005 17:16:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXju-0000cN-NH; Fri, 15 Apr 2005 16:48:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXjr-0000bv-Cn for pce@megatron.ietf.org; Fri, 15 Apr 2005 16:48:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23345 for ; Fri, 15 Apr 2005 16:48:23 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXu1-0008Os-BG for pce@ietf.org; Fri, 15 Apr 2005 16:59:02 -0400 Received: from du-203-88.nat.dialup.claranet.fr ([212.43.203.88] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DMXjd-000D8f-Hq for pce@ietf.org; Fri, 15 Apr 2005 21:48:18 +0100 Message-ID: <03c601c541fc$b727cc90$cdcb2bd4@Puppy> From: "Adrian Farrel" To: Date: Fri, 15 Apr 2005 16:49:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.8 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Pce] Progress with the architecture draft 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: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit All, The editors are shortly to work on revising the architecture draft. We have a bunch of comments received at and since Minneapolis that we need to incorporate. It has also been pointed out that we could usefully work on the definitions to ensure that they are clear within the context of PCE. Lastly, we need to do some work to distinguish architectural models and functional/operational models. Largely speaking, this is a case of showing the component decomposition, and how this decomposition may be used operationally and how it would be perceived by PCCs and PCEs in the system. Before we start on the revision it would be great if you could all send your comments on the current version so that we can include them. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 18 05:03:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNS9h-0004at-N7; Mon, 18 Apr 2005 05:02:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNS9e-0004Zx-Ee for pce@megatron.ietf.org; Mon, 18 Apr 2005 05:02:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28679 for ; Mon, 18 Apr 2005 05:02:44 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNSKI-0005zL-Q8 for pce@ietf.org; Mon, 18 Apr 2005 05:13:55 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 11:02:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Apr 2005 11:02:32 +0200 Message-ID: Thread-Topic: WG feedback required on PCE Capability Discovery Thread-Index: AcVD9VylIGJ5USTBQze+F1NSR1//TA== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 18 Apr 2005 09:02:33.0250 (UTC) FILETIME=[5B958020:01C543F5] X-Spam-Score: 0.6 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: Subject: [Pce] WG feedback required on PCE Capability Discovery 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="===============0463063221==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0463063221== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C543F5.5B8C97FB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C543F5.5B8C97FB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, There has been several discussions within the PCE com Design Team and among PCE discovery requirements co-authors, regarding dynamic discovery of PCE capabilities.=20 Once we agree that there is a need for dynamic PCE capability discovery, then it appears that there are three options: Option 1: A single specific PCE discovery mechanism is used to discover all PCE capabilities (as currently required in the PCE discovery requirements I-D http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.t xt). Option 2: All PCE capabilities are discovered through added functionality in the PCE communication protocol (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-req s-00.txt). Option 3: Discovery of some generic PCE capabilities (computation domain, scope...) is done by the PCE discovery mechanism and discovery of detailed capabilities (e.g. type of constraints supported...) relies on the PCE communication protocol. In 1) since PCC knows all PCE capabilities, it is the reponsibility of the PCC to select the appropriate PCE for a particular path computation. So, no capability-related request parameters are needed in the communication protocol, since the PCC alreay knows what is expected from the PCE. In 3) PCC knows certain basic capabilities, but for the capabilities that it is unaware of, it may request specific parameters in the communication protocol when a path computation request is made to the PCE. If the PCE is not capable of the requested paramters, then appropriate failure is reported. Note that this does not take into account discovery of PCE location, that can be done either statically or dynamically through functionality in the PCE discovery mechanism (here the PCE communication protocol cannot help). =20 Note also that PCE capabilities could of course be configured statically but this is out of the scope of this discussion focused on dynamic capability discovery. WG feedback on this topic would be highly desired.=20 Please give us your comments and preferences regarding these three options. JL ------_=_NextPart_001_01C543F5.5B8C97FB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable WG feedback required on PCE Capability Discovery

Hi all,

There has been several = discussions within the PCE com Design Team and among PCE discovery = requirements co-authors, regarding dynamic discovery of PCE = capabilities.

Once we agree that there is a = need for dynamic PCE capability discovery, then it appears that there = are three options:

Option 1: A single specific PCE = discovery mechanism is used to discover all PCE capabilities (as = currently required in the PCE discovery requirements I-D http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-= 00.txt).

Option 2: All PCE capabilities = are discovered through added functionality in the PCE communication = protocol (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-= reqs-00.txt).

Option 3: Discovery of some = generic PCE capabilities (computation domain, scope...) is done by the = PCE discovery mechanism and discovery of detailed capabilities (e.g. = type of constraints supported...) relies on the PCE communication = protocol.

In 1) since PCC knows all PCE = capabilities, it is the reponsibility of the PCC to select the = appropriate PCE for a particular path computation. So, no = capability-related request parameters are needed in the communication = protocol, since the PCC alreay knows what is expected from the = PCE.

In 3) PCC knows certain basic = capabilities, but for the capabilities that it is unaware of, it may = request specific parameters in the communication protocol when a path = computation request is made to the PCE. If the PCE is not capable of the = requested paramters, then appropriate failure is reported.

Note that this does not take into = account discovery of PCE location, that can be done either statically or = dynamically through functionality in the PCE discovery mechanism (here = the PCE communication protocol cannot help). 

Note also that PCE capabilities = could of course be configured statically but this is out of the scope of = this discussion focused on dynamic capability discovery.

WG feedback on this topic would = be highly desired.
Please give us your comments and = preferences regarding these three options.

JL



------_=_NextPart_001_01C543F5.5B8C97FB-- --===============0463063221== 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 --===============0463063221==-- From pce-bounces@lists.ietf.org Mon Apr 18 06:04:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNT7e-0001VA-H1; Mon, 18 Apr 2005 06:04:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNT6P-0001Mi-9i for pce@megatron.ietf.org; Mon, 18 Apr 2005 06:03:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02433 for ; Mon, 18 Apr 2005 06:03:33 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNTH7-0001bA-Ss for pce@ietf.org; Mon, 18 Apr 2005 06:14:45 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IF400KW6ZRBQ3@szxga02-in.huawei.com> for pce@ietf.org; Mon, 18 Apr 2005 17:59:35 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IF400KQ4ZRBB1@szxga02-in.huawei.com> for pce@ietf.org; Mon, 18 Apr 2005 17:59:35 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IF40079MZVZ7S@szxml01-in.huawei.com>; Mon, 18 Apr 2005 18:02:23 +0800 (CST) Date: Mon, 18 Apr 2005 17:33:47 +0800 From: Zhang Renhai Subject: Re: [Pce] WG feedback required on PCE Capability Discovery To: LE ROUX Jean-Louis RD-CORE-LAN Message-id: <007901c543f9$bba81640$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.8 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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="===============0314475073==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0314475073== Content-type: multipart/alternative; boundary="Boundary_(ID_hdL3LCxPUTv13vrrGg8iXw)" This is a multi-part message in MIME format. --Boundary_(ID_hdL3LCxPUTv13vrrGg8iXw) Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT WG feedback required on PCE Capability DiscoveryHi, I go for option 1. Because there will be least needless protocol peckets sent by PCCs and replied by PCEs when a PCC asks a computation, most efficient one. Zhang ----- Original Message ----- From: LE ROUX Jean-Louis RD-CORE-LAN To: pce@ietf.org Sent: Monday, April 18, 2005 5:02 PM Subject: [Pce] WG feedback required on PCE Capability Discovery Hi all, There has been several discussions within the PCE com Design Team and among PCE discovery requirements co-authors, regarding dynamic discovery of PCE capabilities. Once we agree that there is a need for dynamic PCE capability discovery, then it appears that there are three options: Option 1: A single specific PCE discovery mechanism is used to discover all PCE capabilities (as currently required in the PCE discovery requirements I-D http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt). Option 2: All PCE capabilities are discovered through added functionality in the PCE communication protocol (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-reqs-00.txt). Option 3: Discovery of some generic PCE capabilities (computation domain, scope...) is done by the PCE discovery mechanism and discovery of detailed capabilities (e.g. type of constraints supported...) relies on the PCE communication protocol. In 1) since PCC knows all PCE capabilities, it is the reponsibility of the PCC to select the appropriate PCE for a particular path computation. So, no capability-related request parameters are needed in the communication protocol, since the PCC alreay knows what is expected from the PCE. In 3) PCC knows certain basic capabilities, but for the capabilities that it is unaware of, it may request specific parameters in the communication protocol when a path computation request is made to the PCE. If the PCE is not capable of the requested paramters, then appropriate failure is reported. Note that this does not take into account discovery of PCE location, that can be done either statically or dynamically through functionality in the PCE discovery mechanism (here the PCE communication protocol cannot help). Note also that PCE capabilities could of course be configured statically but this is out of the scope of this discussion focused on dynamic capability discovery. WG feedback on this topic would be highly desired. Please give us your comments and preferences regarding these three options. JL ------------------------------------------------------------------------------ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --Boundary_(ID_hdL3LCxPUTv13vrrGg8iXw) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT WG feedback required on PCE Capability Discovery
Hi,
 I go for option 1.
 Because there will be least needless protocol peckets sent by PCCs and replied by PCEs when a PCC asks a computation, most efficient one.
 
Zhang
----- Original Message -----
Sent: Monday, April 18, 2005 5:02 PM
Subject: [Pce] WG feedback required on PCE Capability Discovery

Hi all,

There has been several discussions within the PCE com Design Team and among PCE discovery requirements co-authors, regarding dynamic discovery of PCE capabilities.

Once we agree that there is a need for dynamic PCE capability discovery, then it appears that there are three options:

Option 1: A single specific PCE discovery mechanism is used to discover all PCE capabilities (as currently required in the PCE discovery requirements I-D http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt).

Option 2: All PCE capabilities are discovered through added functionality in the PCE communication protocol (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-reqs-00.txt).

Option 3: Discovery of some generic PCE capabilities (computation domain, scope...) is done by the PCE discovery mechanism and discovery of detailed capabilities (e.g. type of constraints supported...) relies on the PCE communication protocol.

In 1) since PCC knows all PCE capabilities, it is the reponsibility of the PCC to select the appropriate PCE for a particular path computation. So, no capability-related request parameters are needed in the communication protocol, since the PCC alreay knows what is expected from the PCE.

In 3) PCC knows certain basic capabilities, but for the capabilities that it is unaware of, it may request specific parameters in the communication protocol when a path computation request is made to the PCE. If the PCE is not capable of the requested paramters, then appropriate failure is reported.

Note that this does not take into account discovery of PCE location, that can be done either statically or dynamically through functionality in the PCE discovery mechanism (here the PCE communication protocol cannot help). 

Note also that PCE capabilities could of course be configured statically but this is out of the scope of this discussion focused on dynamic capability discovery.

WG feedback on this topic would be highly desired.
Please give us your comments and preferences regarding these three options.

JL



_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--Boundary_(ID_hdL3LCxPUTv13vrrGg8iXw)-- --===============0314475073== 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 --===============0314475073==-- From pce-bounces@lists.ietf.org Mon Apr 18 22:40:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNifF-0003px-EJ; Mon, 18 Apr 2005 22:40:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNifE-0003pi-2u for pce@megatron.ietf.org; Mon, 18 Apr 2005 22:40:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05967 for ; Mon, 18 Apr 2005 22:40:33 -0400 (EDT) Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNiq8-0007Pu-CB for pce@ietf.org; Mon, 18 Apr 2005 22:51:53 -0400 Received: from m2.gw.fujitsu.co.jp ([10.0.50.72]) by fgwmail5.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id j3J2eAEi018083 for ; Tue, 19 Apr 2005 11:40:10 +0900 (envelope-from shimizu.takao@jp.fujitsu.com) Received: from s6.gw.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id j3J2eAgB030376 for ; Tue, 19 Apr 2005 11:40:10 +0900 (envelope-from shimizu.takao@jp.fujitsu.com) Received: from s6.gw.fujitsu.co.jp (s6 [127.0.0.1]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id EA6CC3CE3DB for ; Tue, 19 Apr 2005 11:40:09 +0900 (JST) Received: from fjm504.ms.jp.fujitsu.com (fjm504.ms.jp.fujitsu.com [10.56.99.80]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id A8D7D3CE3E8 for ; Tue, 19 Apr 2005 11:40:09 +0900 (JST) Received: from SHIMIZUPC (fjmscan503.ms.jp.fujitsu.com [10.56.99.143])by fjm504.ms.jp.fujitsu.com with SMTP id j3J2dnWZ028872 for ; Tue, 19 Apr 2005 11:39:49 +0900 Message-ID: <006301c54489$1ed4d480$9b46110a@SHIMIZUPC> From: =?utf-8?B?5riF5rC044CA6ZqG6ZuE?= To: References: <03c601c541fc$b727cc90$cdcb2bd4@Puppy> Subject: Re: [Pce] Progress with the architecture draft Date: Tue, 19 Apr 2005 11:40:16 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA05967 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, All I have 2 comments for the PCE Architecture I-D. 1) Stateful vs Stateless I think PCE should be stateful basically. And 2 options for Stateful; Option-1 is Link State (Trap event: up/down/congestion) Option-2 is Full Link State (Option-1 + Link Usage Rate by FEC) 2) Metrics requirement For inter-domain operetion, metrics model should be consistent through domains. As for FEC, TOS(PRI) 8 Level classification may be better. Best=E3=80=80Regards T.S. =E3=80=80=E3=80=80 > All, > > The editors are shortly to work on revising the architecture draft. We > have a bunch of comments received at and since Minneapolis that we need= to > incorporate. > > It has also been pointed out that we could usefully work on the > definitions to ensure that they are clear within the context of PCE. > > Lastly, we need to do some work to distinguish architectural models and > functional/operational models. Largely speaking, this is a case of show= ing > the component decomposition, and how this decomposition may be used > operationally and how it would be perceived by PCCs and PCEs in the > system. > > Before we start on the revision it would be great if you could all send > your comments on the current version so that we can include them. > > Thanks, > Adrian > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Apr 19 07:58:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNrMu-00036k-LK; Tue, 19 Apr 2005 07:58:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNrMt-00036e-Px for pce@megatron.ietf.org; Tue, 19 Apr 2005 07:58:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02040 for ; Tue, 19 Apr 2005 07:58:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNrXt-0003D4-KN for pce@ietf.org; Tue, 19 Apr 2005 08:09:38 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DNrMq-0009s8-U2; Tue, 19 Apr 2005 11:58:13 +0000 Message-ID: <4264F256.20907@psg.com> Date: Tue, 19 Apr 2005 13:58:14 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org all, some comments on the architecture document: section 5. "an error is returned together with as much information as possible about the reasons for the failure, and potentially advice about which constraints might be relaxed to be more likely to achieve a positive result." -> what "as much" means in the present context - wouldn't be advisable to say enough information such that the appropriate decision can be made by the PCC to know whether it has to relax constraints or query another PCE ? section 6.1.1 "The protocol MUST be capable of returning any explicit path that would be acceptable for use in RSVP-TE for MPLS and GMPLS LSPs when suitably encoded in an Explicit Route Object." -> this is definitelly a possible way to encode such information, but is it within the scope of the present document to enforce this ? section 6.3.3 "The communication protocol SHOULD allow a stateful PCE to resynchronize and recover states (e.g., LSP status, paths, etc.) after a restart." -> this in an interesting statement because it proofs that robustness is achieved from distribution (and not centralized state maintenance) ... anyway there is a strict need to define the notion a path computation state (which is not identical to an LSP status) before starting discussing the needs to allow for such capability hope this helps, - dimitri. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Apr 19 08:31:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNrtH-0008UC-E1; Tue, 19 Apr 2005 08:31:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNrtG-0008U6-7C for pce@megatron.ietf.org; Tue, 19 Apr 2005 08:31:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04698 for ; Tue, 19 Apr 2005 08:31:40 -0400 (EDT) Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNs4D-0004iB-5q for pce@ietf.org; Tue, 19 Apr 2005 08:43:05 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j3JCUNSY022442 for ; Tue, 19 Apr 2005 08:31:28 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (7.2.052) id 4262897200076928; Tue, 19 Apr 2005 08:31:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt Date: Tue, 19 Apr 2005 07:31:25 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C8A8D@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt Thread-Index: AcVE13P/ZLcXyXe8Szyp0/ngz7kUWQAA5IJw From: "Ash, Gerald R \(Jerry\), ALABS" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, Thanks for your comments. > section 5. > > "an error is returned together with as much > information as possible about the reasons for the failure, and > potentially advice about which constraints might be relaxed to be more > likely to achieve a positive result." > > -> what "as much" means in the present context - wouldn't be advisable > to say enough information such that the appropriate decision can be made > by the PCC to know whether it has to relax constraints or query another > PCE? Your rewording is clearer, thanks. > section 6.1.1 > > "The protocol MUST be capable of returning any explicit path that would > be acceptable for use in RSVP-TE for MPLS and GMPLS LSPs when suitably > encoded in an Explicit Route Object." > -> this is definitelly a possible way to encode such information, but is > it within the scope of the present document to enforce this? We think it's in scope. > section 6.3.3 > > "The communication protocol SHOULD allow a stateful PCE to resynchronize > and recover states (e.g., LSP status, paths, etc.) after a restart." > > -> this in an interesting statement because it proofs that robustness is > achieved from distribution (and not centralized state maintenance) ... > anyway there is a strict need to define the notion a path computation=20 > state (which is not identical to an LSP status) before starting=20 > discussing the needs to allow for such capability Agreed. Thanks, Jerry > hope this helps, > - dimitri. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Apr 20 06:50:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOCnC-000234-Gs; Wed, 20 Apr 2005 06:50:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOCn9-00021K-SJ for pce@megatron.ietf.org; Wed, 20 Apr 2005 06:50:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25455 for ; Wed, 20 Apr 2005 06:50:45 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOCyM-0006De-Om for pce@ietf.org; Wed, 20 Apr 2005 07:02:23 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DOCn8-000BIB-EY; Wed, 20 Apr 2005 10:50:46 +0000 Message-ID: <42663408.6010004@psg.com> Date: Wed, 20 Apr 2005 12:50:48 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN Subject: Re: [Pce] WG feedback required on PCE Capability Discovery References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org hi jean-louis, option (3) makes sense but it also requires to sort out these generic base capabilities that are expected from a PCE (i.e. the common baseline to have a working interoperable system) this would constitute a good balance allowing to avoid high rejection rate w/o overloading the discovery exchange and increase requirements in terms of information propagation and processing, i.e., the following constraint is imho important to take into account [variation rate of generic PCE cap. >> convergence time] now, in any case, it will be very difficult to make this exchange lightweight even when using the so-called PCC-PCE communication protocol (as the set of supported type of constraints is expected to be exchanged from i can read from the below); therefore, some abstraction and/or classification may probably help in avoiding being fully explicit concerning all these capabilities, and in particular, the computational constraints. thanks, - dimitri. LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi all, > > There has been several discussions within the PCE com Design Team and > among PCE discovery requirements co-authors, regarding dynamic discovery > of PCE capabilities. > > Once we agree that there is a need for dynamic PCE capability discovery, > then it appears that there are three options: > > Option 1: A single specific PCE discovery mechanism is used to discover > all PCE capabilities (as currently required in the PCE discovery > requirements I-D > http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.t > xt). > > Option 2: All PCE capabilities are discovered through added > functionality in the PCE communication protocol > (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-req > s-00.txt). > > Option 3: Discovery of some generic PCE capabilities (computation > domain, scope...) is done by the PCE discovery mechanism and discovery > of detailed capabilities (e.g. type of constraints supported...) relies > on the PCE communication protocol. > > In 1) since PCC knows all PCE capabilities, it is the reponsibility of > the PCC to select the appropriate PCE for a particular path computation. > So, no capability-related request parameters are needed in the > communication protocol, since the PCC alreay knows what is expected from > the PCE. > > In 3) PCC knows certain basic capabilities, but for the capabilities > that it is unaware of, it may request specific parameters in the > communication protocol when a path computation request is made to the > PCE. If the PCE is not capable of the requested paramters, then > appropriate failure is reported. > > Note that this does not take into account discovery of PCE location, > that can be done either statically or dynamically through functionality > in the PCE discovery mechanism (here the PCE communication protocol > cannot help). > Note also that PCE capabilities could of course be configured statically > but this is out of the scope of this discussion focused on dynamic > capability discovery. > > WG feedback on this topic would be highly desired. > Please give us your comments and preferences regarding these three > options. > > JL > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Wed Apr 20 09:32:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFJr-0000Pf-5F; Wed, 20 Apr 2005 09:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFJo-0000PY-Ud for pce@megatron.ietf.org; Wed, 20 Apr 2005 09:32:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07975 for ; Wed, 20 Apr 2005 09:32:39 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFV1-0002h6-09 for pce@ietf.org; Wed, 20 Apr 2005 09:44:17 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j3KDbsAw009125 for ; Wed, 20 Apr 2005 06:37:54 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j3KDYjsA010827 for ; Wed, 20 Apr 2005 08:34:46 -0500 (CDT) Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Apr 2005 19:02:33 +0530 Message-ID: From: Vivek Dubey-G20041 To: pce@ietf.org Subject: RE: [Pce] WG feedback required on PCE Capability Discovery Date: Wed, 20 Apr 2005 19:02:32 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Option 1 -------- In case of single PCE discovery mechanism, all PCE capabilities (at that instant), are advertised. These are taken into consideration by PCC, while selecting a particular PCE(out of many available) for a particular path computation request. In case of change in PCE capability, incremental updates can happen. Option 3 -------- Assuming base PCE capabilities are advertised during discovery. For path computation request it is required by PCC to request all available PCEs for there "specific required" capabilities, than select one out of them and finally make a request. Further "change" in PCE capability wont be available unless PCC makes a path computation request. So before making any path request, PCC must get the last updated PCE capability. Considering above points "Option 1" is better choice. Thanks Vivek LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi all, > > There has been several discussions within the PCE com Design Team and > among PCE discovery requirements co-authors, regarding dynamic > discovery of PCE capabilities. > > Once we agree that there is a need for dynamic PCE capability > discovery, then it appears that there are three options: > > Option 1: A single specific PCE discovery mechanism is used to > discover all PCE capabilities (as currently required in the PCE > discovery requirements I-D > http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00 > .t > xt). > > Option 2: All PCE capabilities are discovered through added > functionality in the PCE communication protocol > (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-r > eq > s-00.txt). > > Option 3: Discovery of some generic PCE capabilities (computation > domain, scope...) is done by the PCE discovery mechanism and discovery > of detailed capabilities (e.g. type of constraints supported...) > relies on the PCE communication protocol. > > In 1) since PCC knows all PCE capabilities, it is the reponsibility of > the PCC to select the appropriate PCE for a particular path > computation. So, no capability-related request parameters are needed > in the communication protocol, since the PCC alreay knows what is > expected from the PCE. > > In 3) PCC knows certain basic capabilities, but for the capabilities > that it is unaware of, it may request specific parameters in the > communication protocol when a path computation request is made to the > PCE. If the PCE is not capable of the requested paramters, then > appropriate failure is reported. > > Note that this does not take into account discovery of PCE location, > that can be done either statically or dynamically through > functionality in the PCE discovery mechanism (here the PCE > communication protocol cannot help). > Note also that PCE capabilities could of course be configured statically > but this is out of the scope of this discussion focused on dynamic > capability discovery. > > WG feedback on this topic would be highly desired. > Please give us your comments and preferences regarding these three > options. > > JL > > > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 01:12:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPvtR-0005E3-3E; Mon, 25 Apr 2005 01:12:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPvtO-0005Dy-SB for pce@megatron.ietf.org; Mon, 25 Apr 2005 01:12:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20914 for ; Mon, 25 Apr 2005 01:12:19 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPw5X-0003cF-5F for pce@ietf.org; Mon, 25 Apr 2005 01:24:56 -0400 Received: from aatlas-lt.avici.com (b2-pc249.avici.com [10.2.100.249]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j3P5C47l009248 for ; Mon, 25 Apr 2005 01:12:04 -0400 Message-Id: <5.1.0.14.2.20050425004615.01e5f710@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Apr 2005 01:11:27 -0400 To: pce@ietf.org From: Alia Atlas Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org In ref to the request prioritization, I agree that discarding lower priority requests shouldn't generally be necessary. At the same time, I think it is necessary to consider whether request starvation can occur for particular priorities, whether that is acceptable, and how that is handled. For the failure response discussed in 6.3.2, is it possible for the PCC to believe that the PCE is unreachable - but not vice versa? If such a scenario is possible, then it is necessary to have a mechanism to clear out old requests when communication is re-established. A few more words here could be helpful. For instance, is the assumption that the underlying reliable communication mechanism ensures reciprocal knowledge of liveness? I'm not sure that we want to fully consider stateful PCEs, but assuming that we do at least wish to cover it somewhat, how is the success/failure of the computed LSP reported back to the PCE? This seems to be a requirement - unless there's an assumption that all LSP signalling will always succeed in scenarios where there is a stateful PCE. For that matter, the stateful PCE introduces the requirement for a PCE to be able to delete/remove a previously computed LSP. I think that there may be similar requirements related to the recovery & failure scenarios. Thoughts? Alia _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 01:23:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPw3j-0005zq-LK; Mon, 25 Apr 2005 01:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPw3i-0005zH-5v for pce@megatron.ietf.org; Mon, 25 Apr 2005 01:23:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21559 for ; Mon, 25 Apr 2005 01:23:00 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPwFs-00048A-O6 for pce@ietf.org; Mon, 25 Apr 2005 01:35:38 -0400 Received: from aatlas-lt.avici.com (b2-pc249.avici.com [10.2.100.249]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j3P5Mo7l010336 for ; Mon, 25 Apr 2005 01:22:50 -0400 Message-Id: <5.1.0.14.2.20050425011633.01eb37d8@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Apr 2005 01:22:13 -0400 To: pce@ietf.org From: Alia Atlas Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Pce] different version support for PCC-PCE communication? 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org There are naturally requirements for extensibility and policy considerations such that different constraints can be specified - and some such constraints may not be considered at the initial time of protocol design. For incremental deployability of such new constraints, there may want to be a requirement describing the required interactions to handle unknown constraints and capabilities. For instance, does the PCE advertise capabilities that define all the constraints the PCC is allow to use? In such a case, if a PCC doesn't understand a capability, the PCC should be able probably to ignore one capability and consider the others. Thoughts? Alia _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 04:29:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPyyM-0004jd-4G; Mon, 25 Apr 2005 04:29:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPyyJ-0004jA-80 for pce@megatron.ietf.org; Mon, 25 Apr 2005 04:29:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24356 for ; Mon, 25 Apr 2005 04:29:36 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPzAT-0004JW-Lc for pce@ietf.org; Mon, 25 Apr 2005 04:42:16 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IFH00LV9UDLI8@szxga01-in.huawei.com> for pce@ietf.org; Mon, 25 Apr 2005 16:32:09 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IFH00I30UDLYY@szxga01-in.huawei.com> for pce@ietf.org; Mon, 25 Apr 2005 16:32:09 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IFH00JQ0UF3N4@szxml02-in.huawei.com>; Mon, 25 Apr 2005 16:33:03 +0800 (CST) Date: Mon, 25 Apr 2005 16:07:00 +0800 From: Zhang Renhai Subject: Re: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt To: Alia Atlas Message-id: <004c01c5496d$c544a3c0$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5.1.0.14.2.20050425004615.01e5f710@10.2.0.68> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7BIT 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi,Alia Atlas, all ----- Original Message ----- From: "Alia Atlas" To: Sent: Monday, April 25, 2005 1:11 PM Subject: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt > In ref to the request prioritization, I agree that discarding lower > priority requests shouldn't generally be necessary. At the same time, I > think it is necessary to consider whether request starvation can occur for > particular priorities, whether that is acceptable, and how that is handled. > > For the failure response discussed in 6.3.2, is it possible for the PCC to > believe that the PCE is unreachable - but not vice versa? If such a > scenario is possible, then it is necessary to have a mechanism to clear out > old requests when communication is re-established. A few more words here > could be helpful. For instance, is the assumption that the underlying > reliable communication mechanism ensures reciprocal knowledge of liveness? > > I'm not sure that we want to fully consider stateful PCEs, but assuming > that we do at least wish to cover it somewhat, how is the success/failure > of the computed LSP reported back to the PCE? This seems to be a > requirement - unless there's an assumption that all LSP signalling will > always succeed in scenarios where there is a stateful PCE. No matter whether it is the scope of this draft , some interesting thoughts arose: Even with stateful PCEs, we might not hope that all computed LSPs will be successfully established.( might we? ),there should be such possibility,even not a lot. Using crankback, there will be some difference between the computed LSP and the established LSP. To keep PCEs stateful, the difference should be reported to PCEs by ingress after the LSP has been established ,so I think some more communation is needed in this draft.).(between having computed and receiving this communation, the stateful PCE is temporarily stateless! ) Another question: what is the substaintial differece between stateful and stateless when establishing the computed LSPs? Is it the result of establishing the LSP or the possibility of successfully establishing the LSP? Third question:Is there loose node in the computed result? if yes, then: The more there are strict nodes in the computed LSP, the more possibility of unsuccessfully establishing the LSP there is.Using crankback, I suggest that more loose node should be included in the result, some small-scope computation can be distributed to mid-LSRs when establishing LSP. For ingress, the most important thing is if there is a LSP satisfying the restriction. Thanks, Zhang > For that > matter, the stateful PCE introduces the requirement for a PCE to be able to > delete/remove a previously computed LSP. I think that there may be > similar requirements related to the recovery & failure scenarios. > > Thoughts? > > Alia > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 06:58:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ1Ht-0006xN-Fo; Mon, 25 Apr 2005 06:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ1Hq-0006wV-7Y for pce@megatron.ietf.org; Mon, 25 Apr 2005 06:58:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05083 for ; Mon, 25 Apr 2005 06:57:55 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ1U4-0002wu-DN for pce@ietf.org; Mon, 25 Apr 2005 07:10:36 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2005 07:09:44 -0400 X-IronPort-AV: i="3.92,127,1112587200"; d="scan'208"; a="45935785:sNHT51648164" 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 j3PAvZRU002970; Mon, 25 Apr 2005 06:57:43 -0400 (EDT) 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.211); Mon, 25 Apr 2005 06:57:36 -0400 Received: from [192.168.1.100] ([10.86.240.47]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 06:57:36 -0400 In-Reply-To: <004c01c5496d$c544a3c0$69646e0a@huawei.com> References: <5.1.0.14.2.20050425004615.01e5f710@10.2.0.68> <004c01c5496d$c544a3c0$69646e0a@huawei.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <7e13f179dae35933c660ee564a6d8f95@cisco.com> From: JP Vasseur Subject: Re: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt Date: Mon, 25 Apr 2005 06:57:49 -0400 To: Zhang Renhai , Alia Atlas X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 25 Apr 2005 10:57:36.0106 (UTC) FILETIME=[96E5FCA0:01C54985] X-Spam-Score: 0.0 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 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="===============1839233346==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1839233346== Content-Type: multipart/alternative; boundary=Apple-Mail-8-827999461 --Apple-Mail-8-827999461 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, On Apr 25, 2005, at 4:07 AM, Zhang Renhai wrote: > Hi,Alia Atlas, all > > ----- Original Message ----- > From: "Alia Atlas" > To: > Sent: Monday, April 25, 2005 1:11 PM > Subject: [Pce] a few comments on > draft-ash-pce-comm-protocol-gen-reqs-00.txt > > >> In ref to the request prioritization, I agree that discarding lower >> priority requests shouldn't generally be necessary. At the same >> time, I >> think it is necessary to consider whether request starvation can >> occur for >> particular priorities, whether that is acceptable, and how that is >> handled. >> >> For the failure response discussed in 6.3.2, is it possible for the >> PCC to >> believe that the PCE is unreachable - but not vice versa? If such a >> scenario is possible, then it is necessary to have a mechanism to >> clear out >> old requests when communication is re-established. A few more words >> here >> could be helpful. For instance, is the assumption that the underlying >> reliable communication mechanism ensures reciprocal knowledge of >> liveness? >> Agree with you Alia. >> I'm not sure that we want to fully consider stateful PCEs, but >> assuming >> that we do at least wish to cover it somewhat, how is the >> success/failure >> of the computed LSP reported back to the PCE? This seems to be a >> requirement - unless there's an assumption that all LSP signalling >> will >> always succeed in scenarios where there is a stateful PCE. > I do not think that this could be an assumption. In the case of statefull PCE, LSP status should of course be known by the PCE and thus be reported by PCC. Same thing, when/id head-end decides to tear an LSP down. My assumption was that such requirement would be discussed in the context of an application-specific requirement ID whereas this ID is related to generic requirements. Can the DT confirm ? > No matter whether it is the scope of this draft , some interesting > thoughts arose: > Even with stateful PCEs, we might not hope that all computed LSPs will > be > successfully established.( might we? ),there should be such > possibility,even not a lot. > Using crankback, there will be some difference between the computed > LSP and > the established LSP. To keep PCEs stateful, the difference should be > reported > to PCEs by ingress after the LSP has been established ,so I think some > more communation > is needed in this draft.).(between having computed and receiving this > communation, the stateful > PCE is temporarily stateless! ) > I'm not sure that crankback used in combination with statefull PCE is a very likely scenario but in any case, statefull PCE would need to know the LSP state for sure. > Another question: what is the substaintial differece between stateful > and stateless > when establishing the computed LSPs? Is it the result of establishing > the LSP or the > possibility of successfully establishing the LSP? > > Third question:Is there loose node in the computed result? Could be a possibility indeed. > if yes, then: > The more there are strict nodes in the computed LSP, the more > possibility of unsuccessfully establishing the LSP there is. I do not think that this is a correct statement ... > Using crankback, > I suggest that more loose node should be included in the result, some > small-scope computation can be distributed to mid-LSRs when > establishing LSP. > For ingress, the most important thing is if there is a LSP satisfying > the restriction. > It is application specific and there won't be *one* model of statefull PCE. Consider the case of a GMPLS network where a statefull PCE is used to compute optimal paths satisfying multi-constraint criterions for a limited number of LSPs that do not change very often. Then in this case, computing path with strict hops only is certainly the most desirable scenario and loose hops with cranback would certainly lead to less optimal paths and increased signalling overhead/call set up time. Again, I'm afraid that there won't be one model capable of addressing all scenarios. Hence, I think that the model of specifying a generic protocol requirements followed by more specific requirements ID is a good approach. Thanks. JP. > Thanks, > Zhang > >> For that >> matter, the stateful PCE introduces the requirement for a PCE to be >> able to >> delete/remove a previously computed LSP. I think that there may be >> similar requirements related to the recovery & failure scenarios. > >> >> Thoughts? >> >> Alia >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-8-827999461 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, On Apr 25, 2005, at 4:07 AM, Zhang Renhai wrote: Hi,Alia Atlas, all ----- Original Message ----- From: "Alia Atlas" < To: < Sent: Monday, April 25, 2005 1:11 PM Subject: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt In ref to the request prioritization, I agree that discarding lower priority requests shouldn't generally be necessary. At the same time, I think it is necessary to consider whether request starvation can occur for particular priorities, whether that is acceptable, and how that is handled. For the failure response discussed in 6.3.2, is it possible for the PCC to believe that the PCE is unreachable - but not vice versa? If such a scenario is possible, then it is necessary to have a mechanism to clear out old requests when communication is re-established. A few more words here could be helpful. For instance, is the assumption that the underlying reliable communication mechanism ensures reciprocal knowledge of liveness? Agree with you Alia. I'm not sure that we want to fully consider stateful PCEs, but assuming that we do at least wish to cover it somewhat, how is the success/failure of the computed LSP reported back to the PCE? This seems to be a requirement - unless there's an assumption that all LSP signalling will always succeed in scenarios where there is a stateful PCE. I do not think that this could be an assumption. In the case of statefull PCE, LSP status should of course be known by the PCE and thus be reported by PCC. Same thing, when/id head-end decides to tear an LSP down. My assumption was that such requirement would be discussed in the context of an application-specific requirement ID whereas this ID is related to generic requirements. Can the DT confirm ? No matter whether it is the scope of this draft , some interesting thoughts arose: Even with stateful PCEs, we might not hope that all computed LSPs will be successfully established.( might we? ),there should be such possibility,even not a lot. Using crankback, there will be some difference between the computed LSP and the established LSP. To keep PCEs stateful, the difference should be reported to PCEs by ingress after the LSP has been established ,so I think some more communation is needed in this draft.).(between having computed and receiving this communation, the stateful PCE is temporarily stateless! ) I'm not sure that crankback used in combination with statefull PCE is a very likely scenario but in any case, statefull PCE would need to know the LSP state for sure. Another question: what is the substaintial differece between stateful and stateless when establishing the computed LSPs? Is it the result of establishing the LSP or the possibility of successfully establishing the LSP? Third question:Is there loose node in the computed result? Could be a possibility indeed. if yes, then: The more there are strict nodes in the computed LSP, the more possibility of unsuccessfully establishing the LSP there is. I do not think that this is a correct statement ... Using crankback, I suggest that more loose node should be included in the result, some small-scope computation can be distributed to mid-LSRs when establishing LSP. For ingress, the most important thing is if there is a LSP satisfying the restriction. It is application specific and there won't be *one* model of statefull PCE. Consider the case of a GMPLS network where a statefull PCE is used to compute optimal paths satisfying multi-constraint criterions for a limited number of LSPs that do not change very often. Then in this case, computing path with strict hops only is certainly the most desirable scenario and loose hops with cranback would certainly lead to less optimal paths and increased signalling overhead/call set up time. Again, I'm afraid that there won't be one model capable of addressing all scenarios. Hence, I think that the model of specifying a generic protocol requirements followed by more specific requirements ID is a good approach. Thanks. JP. Thanks, Zhang For that matter, the stateful PCE introduces the requirement for a PCE to be able to delete/remove a previously computed LSP. I think that there may be similar requirements related to the recovery & failure scenarios. Thoughts? Alia _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-8-827999461-- --===============1839233346== 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 --===============1839233346==-- From pce-bounces@lists.ietf.org Mon Apr 25 07:01:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ1LG-0007CK-Ax; Mon, 25 Apr 2005 07:01:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ1LE-0007CE-PD for pce@megatron.ietf.org; Mon, 25 Apr 2005 07:01:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05323 for ; Mon, 25 Apr 2005 07:01:25 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ1XR-00031h-2u for pce@ietf.org; Mon, 25 Apr 2005 07:14:07 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 Apr 2005 07:01:18 -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 j3PB0qRY003536; Mon, 25 Apr 2005 07:01:15 -0400 (EDT) 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.211); Mon, 25 Apr 2005 06:59:56 -0400 Received: from [192.168.1.100] ([10.86.240.47]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 06:59:56 -0400 In-Reply-To: <5.1.0.14.2.20050425011633.01eb37d8@10.2.0.68> References: <5.1.0.14.2.20050425011633.01eb37d8@10.2.0.68> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65ddd3b08b5e350da967f6e7c043c94d@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] different version support for PCC-PCE communication? Date: Mon, 25 Apr 2005 07:00:10 -0400 To: Alia Atlas X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 25 Apr 2005 10:59:56.0518 (UTC) FILETIME=[EA972860:01C54985] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Alia, On Apr 25, 2005, at 1:22 AM, Alia Atlas wrote: > There are naturally requirements for extensibility and policy > considerations such that different constraints can be specified - and > some such constraints may not be considered at the initial time of > protocol design. > > For incremental deployability of such new constraints, there may want > to be a requirement describing the required interactions to handle > unknown constraints and capabilities. For instance, does the PCE > advertise capabilities that define all the constraints the PCC is > allow to use? In such a case, if a PCC doesn't understand a > capability or by policy, "does not allow for requesting path computation with such constraint" (e.g. case of inter-domain). > , the PCC should be able probably to ignore one capability and > consider the others. > > Thoughts? > > Alia > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 08:29:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ2hz-0004bx-Gd; Mon, 25 Apr 2005 08:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ2hx-0004bb-Eq for pce@megatron.ietf.org; Mon, 25 Apr 2005 08:29:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11211 for ; Mon, 25 Apr 2005 08:28:59 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ2uC-0007By-Lh for pce@ietf.org; Mon, 25 Apr 2005 08:41:40 -0400 Received: from aatlas-lt.avici.com (b2-pc249.avici.com [10.2.100.249]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j3PCRU7l030917; Mon, 25 Apr 2005 08:27:30 -0400 Message-Id: <5.1.0.14.2.20050425081718.01e638c8@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Apr 2005 08:26:46 -0400 To: JP Vasseur From: Alia Atlas Subject: Re: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt In-Reply-To: <7e13f179dae35933c660ee564a6d8f95@cisco.com> References: <004c01c5496d$c544a3c0$69646e0a@huawei.com> <5.1.0.14.2.20050425004615.01e5f710@10.2.0.68> <004c01c5496d$c544a3c0$69646e0a@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, At 06:57 AM 4/25/2005, JP Vasseur wrote: >>>I'm not sure that we want to fully consider stateful PCEs, but assuming >>>that we do at least wish to cover it somewhat, how is the success/failure >>>of the computed LSP reported back to the PCE? This seems to be a >>>requirement - unless there's an assumption that all LSP signalling will >>>always succeed in scenarios where there is a stateful PCE. > >I do not think that this could be an assumption. In the case of statefull >PCE, LSP status should of course be known by the PCE and thus be reported >by PCC. Same thing, when/id head-end decides to tear an LSP down. > >My assumption was that such requirement would be discussed in the context >of an application-specific requirement ID whereas this ID is related to >generic requirements. Can the DT confirm ? My assumption is that all stateful PCEs would impose some basic requirements on learning the results of an LSP set-up. I agree that there may be additional application-specific requirements, but the basics for maintaining/obtaining state info would be the same. >I'm not sure that crankback used in combination with statefull PCE is a >very likely scenario but in any case, statefull PCE would need to know the >LSP state for sure. I also don't see crankback with a stateful PCE as very likely. >Again, I'm afraid that there won't be one model capable of addressing all >scenarios. > >Hence, I think that the model of specifying a generic protocol >requirements followed by more specific requirements ID is a good approach. Absolutely. I just think there are some generic requirements imposed by statefulness. Alia _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 08:32:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ2l7-0004rJ-8s; Mon, 25 Apr 2005 08:32:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ2l6-0004r4-9z for pce@megatron.ietf.org; Mon, 25 Apr 2005 08:32:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11526 for ; Mon, 25 Apr 2005 08:32:14 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ2xL-0007HT-Jg for pce@ietf.org; Mon, 25 Apr 2005 08:44:55 -0400 Received: from aatlas-lt.avici.com (b2-pc249.avici.com [10.2.100.249]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j3PCW57l031358; Mon, 25 Apr 2005 08:32:05 -0400 Message-Id: <5.1.0.14.2.20050425082739.01f95380@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Apr 2005 08:31:21 -0400 To: JP Vasseur From: Alia Atlas Subject: Re: [Pce] different version support for PCC-PCE communication? In-Reply-To: <65ddd3b08b5e350da967f6e7c043c94d@cisco.com> References: <5.1.0.14.2.20050425011633.01eb37d8@10.2.0.68> <5.1.0.14.2.20050425011633.01eb37d8@10.2.0.68> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP, At 07:00 AM 4/25/2005, JP Vasseur wrote: >>For incremental deployability of such new constraints, there may want to >>be a requirement describing the required interactions to handle unknown >>constraints and capabilities. For instance, does the PCE advertise >>capabilities that define all the constraints the PCC is allow to use? In >>such a case, if a PCC doesn't understand a capability > >or by policy, "does not allow for requesting path computation with such >constraint" (e.g. case of inter-domain). > >>, the PCC should be able probably to ignore one capability and consider >>the others. I agree that the handling of different constraints may depend not only on the PCC and PCE's abilities to understand them but also on the policy configured at the PCC and PCE. The question then becomes what defaults and interactions are appropriate? Perhaps the first step is to think about the different usage scenarios and what would be desirable to do in each one; then we could see what common cases fall out. Alia _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 08:35:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ2o2-00059R-PS; Mon, 25 Apr 2005 08:35:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ2o1-00059L-D1 for pce@megatron.ietf.org; Mon, 25 Apr 2005 08:35:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11711 for ; Mon, 25 Apr 2005 08:35:15 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ30E-0007L0-FB for pce@ietf.org; Mon, 25 Apr 2005 08:47:57 -0400 Received: from ib (vpn14.atlanta.movaz.com [172.18.0.14]) by jera.movaz.com (Postfix) with SMTP id C2E8A1800B; Mon, 25 Apr 2005 08:34:52 -0400 (EDT) Message-ID: <002101c54993$2f3eeb80$6701a8c0@movaz.com> From: "Igor Bryskin" To: , "Alia Atlas" References: <5.1.0.14.2.20050425004615.01e5f710@10.2.0.68> Subject: Re: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt Date: Mon, 25 Apr 2005 08:34:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA11711 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Alia, See my comments in-line. Igor ----- Original Message -----=20 From: "Alia Atlas" To: Sent: Monday, April 25, 2005 1:11 AM Subject: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.= txt =D8 In ref to the request prioritization, I agree that discarding lo= wer > priority requests shouldn't generally be necessary. At the same time, = I > think it is necessary to consider whether request starvation can occur = for > particular priorities, whether that is acceptable, and how that is handled. > =D8 IB>> Agreed =D8 > For the failure response discussed in 6.3.2, is it possible for the PCC= to > believe that the PCE is unreachable - but not vice versa? If such a > scenario is possible, then it is necessary to have a mechanism to clear out > old requests when communication is re-established. A few more words he= re > could be helpful. For instance, is the assumption that the underlying > reliable communication mechanism ensures reciprocal knowledge of livene= ss? > =D8 IB>> Agreed > I'm not sure that we want to fully consider stateful PCEs, but assuming > that we do at least wish to cover it somewhat, how is the success/failu= re > of the computed LSP reported back to the PCE? IB>> PCE does not compute LSPs, rather, paths for LSPs. There could be multiple reasons why a path is not materialized as an LSP taking this pat= h. To name a few: =D8 PCC may do pre-computation - just request a path for an LSP to g= et an idea how it will be routed without actually triggering the setup; =D8 PCC may request paths from several PCEs and choose the most suit= able response; =D8 PCE may not be involved at all - the path for the LSP could be explicitly specified by management; =D8 LSP could be rerouted because of some failure during or after th= e setup =D8 ... Hence, stateful PCE does not need PCCs to report LSPs, rather, there sho= uld be some mechanism to feed PCE with LSPs and their actual paths no matter = how the LSPs end up taking these paths. This is something that very difficult= to achieve in a timely and scalable manner. One approach is to have PCE use SNMP sessions with each and every LSR in the network and query LSPs that they have originated. Igor This seems to be a > requirement - unless there's an assumption that all LSP signalling will > always succeed in scenarios where there is a stateful PCE. For that > matter, the stateful PCE introduces the requirement for a PCE to be abl= e to > delete/remove a previously computed LSP. I think that there may be > similar requirements related to the recovery & failure scenarios. > > Thoughts? > > Alia > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 11:15:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5Iq-0001pw-D7; Mon, 25 Apr 2005 11:15:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5In-0001pq-Vu for pce@megatron.ietf.org; Mon, 25 Apr 2005 11:15:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23586 for ; Mon, 25 Apr 2005 11:15:11 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ5V1-0004cj-Ei for pce@ietf.org; Mon, 25 Apr 2005 11:27:54 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3PFEkb00784; Mon, 25 Apr 2005 11:14:47 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Apr 2005 11:14:46 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4017A3FD6@zrtphxm2> From: "Don Fedyk" To: Alia Atlas , pce@ietf.org Subject: RE: [Pce] different version support for PCC-PCE communication? Date: Mon, 25 Apr 2005 11:14:42 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Alia I agree with the requirements. Perhaps the PCC/PCE should specify constraints as mandatory and optional (or ordered/weighted). Constraints Can be exclusive, inclusive, minimizing or maximizing etc. In the past dealing with multiple minimization/maximization constraints has been more difficult. An ordering or weight option might help. Regards, Don > -----Original Message----- > From: pce-bounces@lists.ietf.org > [mailto:pce-bounces@lists.ietf.org] On Behalf Of Alia Atlas > Sent: Monday, April 25, 2005 1:22 AM > To: pce@ietf.org > Subject: [Pce] different version support for PCC-PCE communication? > > > There are naturally requirements for extensibility and policy > considerations such that different constraints can be > specified - and some > such constraints may not be considered at the initial time of > protocol design. > > For incremental deployability of such new constraints, there > may want to be > a requirement describing the required interactions to handle unknown > constraints and capabilities. For instance, does the PCE advertise > capabilities that define all the constraints the PCC is allow > to use? In > such a case, if a PCC doesn't understand a capability, the > PCC should be > able probably to ignore one capability and consider the others. > > Thoughts? > > Alia > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 11:56:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5wx-00074y-Lw; Mon, 25 Apr 2005 11:56:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5wv-00074l-Vj for pce@megatron.ietf.org; Mon, 25 Apr 2005 11:56:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27206 for ; Mon, 25 Apr 2005 11:56:39 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ69C-0006CC-Qc for pce@ietf.org; Mon, 25 Apr 2005 12:09:23 -0400 Received: from du-069-0484.access.clara.net ([217.158.145.230] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DQ5wq-0005RQ-IE; Mon, 25 Apr 2005 16:56:38 +0100 Message-ID: <01e801c549af$a3e93000$1c849ed9@Puppy> From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" , References: Subject: Re: [Pce] WG feedback required on PCE Capability Discovery Date: Mon, 25 Apr 2005 16:56:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JL, Well, it all depends on how much information, how many PCEs, how many PCCs, and how often the information is re-distributed. If you use an IGP to achieve option 1 then you are requiring that all routers in the network store the PCE capabilities information so that they can flood it. So we must hope that the product {number of PCEs}x{volume of capabilities information} is not too large. If you are talking about a list of bit flags then option 1 is probably cool. If the information is extensive you probably need option 3. If you don't yet know, I suggest you follow option 1 with the knowledge that option 3 can be added. (Option 3 is not such a burden since it is a request/response interaction and that is exactly what the PCE-PCC communications protocol does best.) Note that the PCE-PCC comms draft currently says that items like Policies must be advertised as part of the PCE capabilities. These could be non-trivial and many in number. To pick you up on one point... > Note that this does not take into account discovery of PCE location, > that can be done either statically or dynamically through functionality > in the PCE discovery mechanism (here the PCE communication protocol > cannot help). This is not true. You may wish to distinguish the two functions and keep them in separate protocols, and this may be a really good idea, but it is also possible to point at many client/server protocols where the client discovers the servers as part of the protocol operation. Cheers, Adrian ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" To: Sent: Monday, April 18, 2005 10:02 AM Subject: [Pce] WG feedback required on PCE Capability Discovery Hi all, There has been several discussions within the PCE com Design Team and among PCE discovery requirements co-authors, regarding dynamic discovery of PCE capabilities. Once we agree that there is a need for dynamic PCE capability discovery, then it appears that there are three options: Option 1: A single specific PCE discovery mechanism is used to discover all PCE capabilities (as currently required in the PCE discovery requirements I-D http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.t xt). Option 2: All PCE capabilities are discovered through added functionality in the PCE communication protocol (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-req s-00.txt). Option 3: Discovery of some generic PCE capabilities (computation domain, scope...) is done by the PCE discovery mechanism and discovery of detailed capabilities (e.g. type of constraints supported...) relies on the PCE communication protocol. In 1) since PCC knows all PCE capabilities, it is the reponsibility of the PCC to select the appropriate PCE for a particular path computation. So, no capability-related request parameters are needed in the communication protocol, since the PCC alreay knows what is expected from the PCE. In 3) PCC knows certain basic capabilities, but for the capabilities that it is unaware of, it may request specific parameters in the communication protocol when a path computation request is made to the PCE. If the PCE is not capable of the requested paramters, then appropriate failure is reported. Note that this does not take into account discovery of PCE location, that can be done either statically or dynamically through functionality in the PCE discovery mechanism (here the PCE communication protocol cannot help). Note also that PCE capabilities could of course be configured statically but this is out of the scope of this discussion focused on dynamic capability discovery. WG feedback on this topic would be highly desired. Please give us your comments and preferences regarding these three options. JL -------------------------------------------------------------------------- ------ > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 11:56:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5x0-00075R-69; Mon, 25 Apr 2005 11:56:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5ww-00074q-NG for pce@megatron.ietf.org; Mon, 25 Apr 2005 11:56:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27209 for ; Mon, 25 Apr 2005 11:56:39 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ69C-0006CB-PA for pce@ietf.org; Mon, 25 Apr 2005 12:09:24 -0400 Received: from du-069-0484.access.clara.net ([217.158.145.230] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DQ5wn-0005RQ-IE; Mon, 25 Apr 2005 16:56:34 +0100 Message-ID: <01e601c549af$a1d0d750$1c849ed9@Puppy> From: "Adrian Farrel" To: , , References: <4264F256.20907@psg.com> Date: Mon, 25 Apr 2005 16:41:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Re: comments on draft-ash-pce-comm-protocol-gen-reqs-00.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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, > section 6.1.1 > > "The protocol MUST be capable of returning any explicit path that would > be acceptable for use in RSVP-TE for MPLS and GMPLS LSPs when suitably > encoded in an Explicit Route Object." > > -> this is definitelly a possible way to encode such information, but is > it within the scope of the present document to enforce this ? This is not how I read the text. I assumed they meant that the information supplied by the PCE should have everything that you need to construct an ERO. That is, it could be re-written as... The protocol MUST be capable of returning any explicit path that would be acceptable for use for MPLS and GMPLS LSPs once converted to an Explicit ROute Object for use in RSVP-TE signaling. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 25 23:31:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQGnd-00014O-0d; Mon, 25 Apr 2005 23:31:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQGnZ-00014J-Qm for pce@megatron.ietf.org; Mon, 25 Apr 2005 23:31:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28519 for ; Mon, 25 Apr 2005 23:31:42 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQGzw-0007aP-21 for pce@ietf.org; Mon, 25 Apr 2005 23:44:33 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IFJ00D74B1P9D@szxga03-in.huawei.com> for pce@ietf.org; Tue, 26 Apr 2005 11:29:49 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IFJ00A9OB1PQT@szxga03-in.huawei.com> for pce@ietf.org; Tue, 26 Apr 2005 11:29:49 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IFJ00LAKB5FH3@szxml02-in.huawei.com>; Tue, 26 Apr 2005 11:32:04 +0800 (CST) Date: Tue, 26 Apr 2005 11:06:03 +0800 From: Zhang Renhai Subject: Re: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt To: JP Vasseur Message-id: <008001c54a0c$e1bdc320$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Priority: 3 X-MSMail-priority: Normal References: <5.1.0.14.2.20050425004615.01e5f710@10.2.0.68> <004c01c5496d$c544a3c0$69646e0a@huawei.com> <7e13f179dae35933c660ee564a6d8f95@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 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="===============1353979883==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1353979883== Content-type: multipart/alternative; boundary="Boundary_(ID_mFyjkE5F7M0NCZ0meXHz3g)" This is a multi-part message in MIME format. --Boundary_(ID_mFyjkE5F7M0NCZ0meXHz3g) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi,JP Thank you for your replay. See in line. ----- Original Message ----- From: JP Vasseur To: Zhang Renhai ; Alia Atlas Cc: pce@ietf.org Sent: Monday, April 25, 2005 6:57 PM Subject: Re: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt Hi, On Apr 25, 2005, at 4:07 AM, Zhang Renhai wrote: Hi,Alia Atlas, all ----- Original Message ----- From: "Alia Atlas" To: Sent: Monday, April 25, 2005 1:11 PM Subject: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt In ref to the request prioritization, I agree that discarding lower priority requests shouldn't generally be necessary. At the same time, I think it is necessary to consider whether request starvation can occur for particular priorities, whether that is acceptable, and how that is handled. For the failure response discussed in 6.3.2, is it possible for the PCC to believe that the PCE is unreachable - but not vice versa? If such a scenario is possible, then it is necessary to have a mechanism to clear out old requests when communication is re-established. A few more words here could be helpful. For instance, is the assumption that the underlying reliable communication mechanism ensures reciprocal knowledge of liveness? Agree with you Alia. I'm not sure that we want to fully consider stateful PCEs, but assuming that we do at least wish to cover it somewhat, how is the success/failure of the computed LSP reported back to the PCE? This seems to be a requirement - unless there's an assumption that all LSP signalling will always succeed in scenarios where there is a stateful PCE. I do not think that this could be an assumption. In the case of statefull PCE, LSP status should of course be known by the PCE and thus be reported by PCC. Same thing, when/id head-end decides to tear an LSP down. My assumption was that such requirement would be discussed in the context of an application-specific requirement ID whereas this ID is related to generic requirements. Can the DT confirm ? No matter whether it is the scope of this draft , some interesting thoughts arose: Even with stateful PCEs, we might not hope that all computed LSPs will be successfully established.( might we? ),there should be such possibility,even not a lot. Using crankback, there will be some difference between the computed LSP and the established LSP. To keep PCEs stateful, the difference should be reported to PCEs by ingress after the LSP has been established ,so I think some more communation is needed in this draft.).(between having computed and receiving this communation, the stateful PCE is temporarily stateless! ) I'm not sure that crankback used in combination with statefull PCE is a very likely scenario but in any case, statefull PCE would need to know the LSP state for sure. [zrh] Why not ?Think of crankback's funtion. In spite of which kind of PCE the LSP is established through(stateful or stateless), not all nodes or links on the LSP can be local repaired for some reason, crankback will be a good substitute. Otherwise, the failure of these nodes or links may lead to the LSP's end-to-end restoration. Another question: what is the substaintial differece between stateful and stateless when establishing the computed LSPs? Is it the result of establishing the LSP or the possibility of successfully establishing the LSP? Third question:Is there loose node in the computed result? Could be a possibility indeed. if yes, then: The more there are strict nodes in the computed LSP, the more possibility of unsuccessfully establishing the LSP there is. I do not think that this is a correct statement ... [zrh]By saying this, I mean that, for example, in a ospf TE area, node A can get to C through B or D, if two stateful PCEs serve this area, and two computation request are *simultaneously and respectively* done by these two PCEs, resouces competiton may occur when establishing LSPs, the two computed LSP may all go through B or through D, perhaps the B's or D's resource can only serve one LSP,but another is enough. one of the two LSPs will fail. With loose node information,this may be avoided,because the A can compute in-order. I think that there will be much issue on stateful PCE for the duration between computing and establishing LSP. Using crankback, I suggest that more loose node should be included in the result, some small-scope computation can be distributed to mid-LSRs when establishing LSP. For ingress, the most important thing is if there is a LSP satisfying the restriction. It is application specific and there won't be *one* model of statefull PCE. Consider the case of a GMPLS network where a statefull PCE is used to compute optimal paths satisfying multi-constraint criterions for a limited number of LSPs that do not change very often. Then in this case, computing path with strict hops only is certainly the most desirable scenario and loose hops with cranback would certainly lead to less optimal paths and increased signalling overhead/call set up time. Again, I'm afraid that there won't be one model capable of addressing all scenarios. [zrh] agree Hence, I think that the model of specifying a generic protocol requirements followed by more specific requirements ID is a good approach. [zrh] Agree . Thanks Zhang Thanks. JP. Thanks, Zhang For that matter, the stateful PCE introduces the requirement for a PCE to be able to delete/remove a previously computed LSP. I think that there may be similar requirements related to the recovery & failure scenarios. Thoughts? Alia _______________________________________________ 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 --Boundary_(ID_mFyjkE5F7M0NCZ0meXHz3g) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,JP
 
Thank you for your replay.
See in line.
 
----- Original Message -----
From: JP Vasseur
Sent: Monday, April 25, 2005 6:57 PM
Subject: Re: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt

Hi,

On Apr 25, 2005, at 4:07 AM, Zhang Renhai wrote:

Hi,Alia Atlas, all

----- Original Message -----
From: "Alia Atlas" <aatlas@avici.com>
To: <pce@ietf.org>
Sent: Monday, April 25, 2005 1:11 PM
Subject: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt


In ref to the request prioritization, I agree that discarding lower
priority requests shouldn't generally be necessary. At the same time, I
think it is necessary to consider whether request starvation can occur for
particular priorities, whether that is acceptable, and how that is handled.

For the failure response discussed in 6.3.2, is it possible for the PCC to
believe that the PCE is unreachable - but not vice versa? If such a
scenario is possible, then it is necessary to have a mechanism to clear out
old requests when communication is re-established. A few more words here
could be helpful. For instance, is the assumption that the underlying
reliable communication mechanism ensures reciprocal knowledge of liveness?


Agree with you Alia.

I'm not sure that we want to fully consider stateful PCEs, but assuming
that we do at least wish to cover it somewhat, how is the success/failure
of the computed LSP reported back to the PCE? This seems to be a
requirement - unless there's an assumption that all LSP signalling will
always succeed in scenarios where there is a stateful PCE.


I do not think that this could be an assumption. In the case of statefull PCE, LSP status should of course be known by the PCE and thus be reported by PCC. Same thing, when/id head-end decides to tear an LSP down.

My assumption was that such requirement would be discussed in the context of an application-specific requirement ID whereas this ID is related to generic requirements. Can the DT confirm ?

 
No matter whether it is the scope of this draft , some interesting thoughts arose:
Even with stateful PCEs, we might not hope that all computed LSPs will be
successfully established.( might we? ),there should be such possibility,even not a lot.
Using crankback, there will be some difference between the computed LSP and
the established LSP. To keep PCEs stateful, the difference should be reported
to PCEs by ingress after the LSP has been established ,so I think some more communation
is needed in this draft.).(between having computed and receiving this communation, the stateful
PCE is temporarily stateless! )


I'm not sure that crankback used in combination with statefull PCE is a very likely scenario but in any case, statefull PCE would need to know the LSP state for sure.
[zrh] Why not ?Think of crankback's funtion.
       In spite of which kind of PCE the LSP is established through(stateful or stateless),
       not all nodes or links on the LSP can be local repaired for some reason,
       crankback will be a good substitute. Otherwise, the failure of these nodes or links
       may lead to the LSP's end-to-end restoration.
 
Another question: what is the substaintial differece between stateful and stateless
when establishing the computed LSPs? Is it the result of establishing the LSP or the
possibility of successfully establishing the LSP?

Third question:Is there loose node in the computed result?

Could be a possibility indeed.

if yes, then:
The more there are strict nodes in the computed LSP, the more
possibility of unsuccessfully establishing the LSP there is.

I do not think that this is a correct statement ...
[zrh]By saying this, I mean that, for example, in a ospf TE area, node A can get to C through B or D,
       if two stateful PCEs serve this area, and two computation request are *simultaneously and respectively*
       done by these two PCEs, resouces competiton may occur when establishing LSPs, the two
       computed LSP may all go through B or through D, perhaps the B's or D's resource can only serve one LSP,but another is enough.
       one of the two LSPs will fail. With loose node information,this may be avoided,because the A can compute in-order.
 
       I think that there will be much issue on stateful PCE for the duration between computing and establishing LSP.      
   
Using crankback,
I suggest that more loose node should be included in the result, some
small-scope computation can be distributed to mid-LSRs when establishing LSP.
For ingress, the most important thing is if there is a LSP satisfying the restriction.


It is application specific and there won't be *one* model of statefull PCE. Consider the case of a GMPLS network where a statefull PCE is used to compute optimal paths satisfying multi-constraint criterions for a limited number of LSPs that do not change very often. Then in this case, computing path with strict hops only is certainly the most desirable scenario and loose hops with cranback would certainly lead to less optimal paths and increased signalling overhead/call set up time.

Again, I'm afraid that there won't be one model capable of addressing all scenarios.
[zrh] agree
 
Hence, I think that the model of specifying a generic protocol requirements followed by more specific requirements ID is a good approach.
[zrh] Agree .
 
Thanks
Zhang
 

Thanks.

JP.

Thanks,
Zhang

For that
matter, the stateful PCE introduces the requirement for a PCE to be able to
delete/remove a previously computed LSP. I think that there may be
similar requirements related to the recovery & failure scenarios.


Thoughts?

Alia


_______________________________________________
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

--Boundary_(ID_mFyjkE5F7M0NCZ0meXHz3g)-- --===============1353979883== 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 --===============1353979883==-- From pce-bounces@lists.ietf.org Thu Apr 28 10:49:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRAKi-00053w-Ud; Thu, 28 Apr 2005 10:49:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRAKh-00053r-Qt for pce@megatron.ietf.org; Thu, 28 Apr 2005 10:49:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22967 for ; Thu, 28 Apr 2005 10:49:37 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRAXM-0005m2-Ue for pce@ietf.org; Thu, 28 Apr 2005 11:02:46 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 16:49:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] WG feedback required on PCE Capability Discovery Date: Thu, 28 Apr 2005 16:49:21 +0200 Message-ID: Thread-Topic: [Pce] WG feedback required on PCE Capability Discovery Thread-Index: AcVJr12nHBss1rSZTAuwnOCkEMdbzgCP7SwQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 28 Apr 2005 14:49:22.0020 (UTC) FILETIME=[76B55240:01C54C01] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Adrian Thanks for this useful feedback Please see inline for some comments >-----Message d'origine----- >De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 >Envoy=E9 : lundi 25 avril 2005 17:56 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org >Objet : Re: [Pce] WG feedback required on PCE Capability Discovery > > >Hi JL, > >Well, it all depends on how much information, how many PCEs,=20 >how many PCCs, and how often the information is re-distributed. > >If you use an IGP to achieve option 1 then you are requiring=20 >that all routers in the network store the PCE capabilities=20 >information so that they can flood it. So we must hope that=20 >the product {number of PCEs}x{volume of capabilities=20 >information} is not too large. Fully agree > >If you are talking about a list of bit flags then option 1 is=20 >probably cool.=20 Yes actually most of PCE capabilities could be encoded in a simple list of bit flags >If the information is extensive you probably=20 >need option 3. If you don't yet know, I suggest you follow=20 >option 1 with the knowledge that option 3 can be added.=20 This sounds a good approach >(Option 3 is not such a burden since it is a request/response=20 >interaction and that is exactly what the PCE-PCC=20 >communications protocol does best.) Yes, but this may lead to multiple PCC-PCE crankbacks (ie a PCC may have = to try various PCEs before to find the appropriate one) > >Note that the PCE-PCC comms draft currently says that items=20 >like Policies must be advertised as part of the PCE=20 >capabilities. These could be non-trivial and many in number. Most of the policies (constraints, criterias...) can IMHO be encoded = using flags... > >To pick you up on one point... > >> Note that this does not take into account discovery of PCE location,=20 >> that can be done either statically or dynamically through=20 >> functionality in the PCE discovery mechanism (here the PCE=20 >> communication protocol cannot help). > >This is not true. You may wish to distinguish the two=20 >functions and keep them in separate protocols, and this may be=20 >a really good idea, but it is also possible to point at many=20 >client/server protocols where the client discovers the servers=20 >as part of the protocol operation. Agree, there are protocols that include both location discovery and = communication, but strictly speaking if you start dissecting these protocols you often = find two sub-protocols: A discovery sub-protocol and a communication = sub-protocol with completely distinct functionalities... Cheers, JL =20 > >Cheers, >Adrian > >----- Original Message -----=20 >From: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > >To: >Sent: Monday, April 18, 2005 10:02 AM >Subject: [Pce] WG feedback required on PCE Capability Discovery > > >Hi all, > >There has been several discussions within the PCE com Design=20 >Team and among PCE discovery requirements co-authors,=20 >regarding dynamic discovery of PCE capabilities. > >Once we agree that there is a need for dynamic PCE capability=20 >discovery, then it appears that there are three options: > >Option 1: A single specific PCE discovery mechanism is used to=20 >discover all PCE capabilities (as currently required in the=20 >PCE discovery requirements I-D=20 >http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery- >reqs-00.t >xt). > >Option 2: All PCE capabilities are discovered through added=20 >functionality in the PCE communication protocol=20 >(http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protoco >l-gen-req >s-00.txt). > >Option 3: Discovery of some generic PCE capabilities=20 >(computation domain, scope...) is done by the PCE discovery=20 >mechanism and discovery of detailed capabilities (e.g. type of=20 >constraints supported...) relies on the PCE communication protocol. > >In 1) since PCC knows all PCE capabilities, it is the=20 >reponsibility of the PCC to select the appropriate PCE for a=20 >particular path computation. So, no capability-related request=20 >parameters are needed in the communication protocol, since the=20 >PCC alreay knows what is expected from the PCE. > >In 3) PCC knows certain basic capabilities, but for the=20 >capabilities that it is unaware of, it may request specific=20 >parameters in the communication protocol when a path=20 >computation request is made to the PCE. If the PCE is not=20 >capable of the requested paramters, then appropriate failure=20 >is reported. > >Note that this does not take into account discovery of PCE=20 >location, that can be done either statically or dynamically=20 >through functionality in the PCE discovery mechanism (here the=20 >PCE communication protocol cannot help). Note also that PCE=20 >capabilities could of course be configured statically but this=20 >is out of the scope of this discussion focused on dynamic=20 >capability discovery. > >WG feedback on this topic would be highly desired. >Please give us your comments and preferences regarding these=20 >three options. > >JL > > > > > > >--------------------------------------------------------------- >----------- >------ > > >> _______________________________________________ >> 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 Thu Apr 28 12:08:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRBYm-0006z2-Ta; Thu, 28 Apr 2005 12:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRBYk-0006yl-4l for pce@megatron.ietf.org; Thu, 28 Apr 2005 12:08:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00106 for ; Thu, 28 Apr 2005 12:08:11 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRBlZ-0000wX-Pk for pce@ietf.org; Thu, 28 Apr 2005 12:21:33 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2005 12:08:02 -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 j3SG7qRW024077; Thu, 28 Apr 2005 12:07:59 -0400 (EDT) Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 12:07:58 -0400 Received: from [10.0.0.94] ([10.86.240.100]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 12:07:57 -0400 In-Reply-To: <008001c54a0c$e1bdc320$69646e0a@huawei.com> References: <5.1.0.14.2.20050425004615.01e5f710@10.2.0.68> <004c01c5496d$c544a3c0$69646e0a@huawei.com> <7e13f179dae35933c660ee564a6d8f95@cisco.com> <008001c54a0c$e1bdc320$69646e0a@huawei.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <99ee78392daf2f34d528a7710ba4d0fb@cisco.com> From: JP Vasseur Subject: Re: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt Date: Thu, 28 Apr 2005 12:08:12 -0400 To: Zhang Renhai X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 28 Apr 2005 16:07:57.0797 (UTC) FILETIME=[7187C950:01C54C0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a0f005dcc96c32c6d659bdf82d519da 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="===============1330870596==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1330870596== Content-Type: multipart/alternative; boundary=Apple-Mail-1--1041661274 --Apple-Mail-1--1041661274 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On Apr 25, 2005, at 11:06 PM, Zhang Renhai wrote: > Hi,JP > =A0 > Thank you for your replay. > See in line. > =A0 >> ----- Original Message ----- >> From: JP Vasseur >> To: Zhang Renhai ; Alia Atlas >> Cc: pce@ietf.org >> Sent: Monday, April 25, 2005 6:57 PM >> Subject: Re: [Pce] a few comments on=20 >> draft-ash-pce-comm-protocol-gen-reqs-00.txt >> >> Hi, >> >> On Apr 25, 2005, at 4:07 AM, Zhang Renhai wrote: >> >>> Hi,Alia Atlas, all >>> >>> ----- Original Message ----- >>> From: "Alia Atlas" >>> To: >>> Sent: Monday, April 25, 2005 1:11 PM >>> Subject: [Pce] a few comments on=20 >>> draft-ash-pce-comm-protocol-gen-reqs-00.txt >>> >>> >>>> In ref to the request prioritization, I agree that discarding lower >>>> priority requests shouldn't generally be necessary. At the same=20 >>>> time, I >>>> think it is necessary to consider whether request starvation can=20 >>>> occur for >>>> particular priorities, whether that is acceptable, and how that is=20= >>>> handled. >>>> >>>> For the failure response discussed in 6.3.2, is it possible for the=20= >>>> PCC to >>>> believe that the PCE is unreachable - but not vice versa? If such a >>>> scenario is possible, then it is necessary to have a mechanism to=20= >>>> clear out >>>> old requests when communication is re-established. A few more words=20= >>>> here >>>> could be helpful. For instance, is the assumption that the=20 >>>> underlying >>>> reliable communication mechanism ensures reciprocal knowledge of=20 >>>> liveness? >>>> >> >> Agree with you Alia. >> >>>> I'm not sure that we want to fully consider stateful PCEs, but=20 >>>> assuming >>>> that we do at least wish to cover it somewhat, how is the=20 >>>> success/failure >>>> of the computed LSP reported back to the PCE? This seems to be a >>>> requirement - unless there's an assumption that all LSP signalling=20= >>>> will >>>> always succeed in scenarios where there is a stateful PCE. >> >> I do not think that this could be an assumption. In the case of=20 >> statefull PCE, LSP status should of course be known by the PCE and=20 >> thus be reported by PCC. Same thing, when/id head-end decides to tear=20= >> an LSP down. >> >> My assumption was that such requirement would be discussed in the=20 >> context of an application-specific requirement ID whereas this ID is=20= >> related to generic requirements. Can the DT confirm ? >> >> =A0 >>> No matter whether it is the scope of this draft , some interesting=20= >>> thoughts arose: >>> Even with stateful PCEs, we might not hope that all computed LSPs=20 >>> will be >>> successfully established.( might we? ),there should be such=20 >>> possibility,even not a lot. >>> Using crankback, there will be some difference between the computed=20= >>> LSP and >>> the established LSP. To keep PCEs stateful, the difference should be=20= >>> reported >>> to PCEs by ingress after the LSP has been established ,so I think=20 >>> some more communation >>> is needed in this draft.).(between having computed and receiving=20 >>> this communation, the stateful >>> PCE is temporarily stateless! ) >>> >> >> I'm not sure that crankback used in combination with statefull PCE is=20= >> a very likely scenario but in any case, statefull PCE would need to=20= >> know the LSP state for sure. >> [zrh] Why not ?Think of crankback's funtion. >> =A0=A0=A0=A0=A0=A0 In spite of which kind of PCE the LSP is = established=20 >> through(stateful or stateless), >> =A0=A0=A0=A0=A0=A0 not all nodes or links on the LSP can be local = repaired=A0for=20 >> some reason, >> =A0=A0=A0=A0=A0=A0=A0crankback will be a good substitute. Otherwise, = the failure of=20 >> these nodes or links >> =A0=A0=A0=A0=A0=A0 may lead to the LSP's end-to-end restoration. >> =A0 But this is a different scenario than relying on a statefull PCE to=20 return loose hops ... You "may" use crankback for partial repair and in=20= this case, you need to keep the statefull PCE updated of course. Note=20 that another alternative (probably more efficient) is to rely on local=20= protection, followed by end to end reoptimization. >>> Another question: what is the substaintial differece between=20 >>> stateful and stateless >>> when establishing the computed LSPs? Is it the result of=20 >>> establishing the LSP or the >>> possibility of successfully establishing the LSP? >>> >>> Third question:Is there loose node in the computed result? >> >> Could be a possibility indeed. >> >>> if yes, then: >>> The more there are strict nodes in the computed LSP, the more >>> possibility of unsuccessfully establishing the LSP there is. >> >> I do not think that this is a correct statement ... >> [zrh]By saying this, I mean that, for example, in a ospf=A0TE area,=20= >> node A can get to C through B or D, >> =A0=A0=A0=A0=A0=A0 if two stateful PCEs serve this area, and two = computation=20 >> request are *simultaneously and respectively* >> =A0=A0=A0=A0=A0=A0 done=A0by these two PCEs, resouces competiton may = occur when=20 >> establishing LSPs, the two >> =A0=A0=A0=A0=A0=A0=A0computed LSP may all=A0go through B or through = D, perhaps the=20 >> B's or D's resource can only serve one LSP,but another is enough. >> =A0=A0=A0=A0=A0=A0=A0one of the two LSPs will fail. Well if you refer to the case of using N non synchronized statefull=20 PCEs then the race condition issue is not the more challenging ;-)=20 (furthermore note that distributed CSPF path computation leads to race=20= condition also (and there are solutions to help there) and I do not=20 think that the use of loose hops is the way to address the problem. >> With loose node information,this=A0may be avoided,because the A can=20= >> compute in-order. >> =A0 >> =A0=A0=A0=A0=A0=A0 I think that there will be much issue on stateful = PCE for the=20 >> duration between computing and establishing LSP.=A0=A0=A0=A0=A0=A0 >> =A0=A0=A0 >> >> >>> Using crankback, >>> I suggest that more loose node should be included in the result, = some >>> small-scope computation can be distributed to mid-LSRs when=20 >>> establishing LSP. >>> For ingress, the most important thing is if there is a LSP=20 >>> satisfying the restriction. >>> >> >> It is application specific and there won't be *one* model of=20 >> statefull PCE. Consider the case of a GMPLS network where a statefull=20= >> PCE is used to compute optimal paths satisfying multi-constraint=20 >> criterions for a limited number of LSPs that do not change very=20 >> often. Then in this case, computing path with strict hops only is=20 >> certainly the most desirable scenario and loose hops with cranback=20 >> would certainly lead to less optimal paths and increased signalling=20= >> overhead/call set up time. >> >> Again, I'm afraid that there won't be one model capable of addressing=20= >> all scenarios. >> [zrh] agree >> =A0 >> Hence, I think that the model of specifying a generic protocol=20 >> requirements followed by more specific requirements ID is a good=20 >> approach. >> [zrh] Agree . >> JP. >> =A0 >> Thanks >> >> Zhang >> >> =A0 >> >> Thanks. >> >> JP. >> >>> Thanks, >>> Zhang >>> >>>> For that >>>> matter, the stateful PCE introduces the requirement for a PCE to be=20= >>>> able to >>>> delete/remove a previously computed LSP. I think that there may be >>>> similar requirements related to the recovery & failure scenarios. >>> >>>> >>>> Thoughts? >>>> >>>> Alia >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> =20 =20= --Apple-Mail-1--1041661274 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On Apr 25, 2005, at 11:06 PM, Zhang Renhai wrote: Hi,JP =A0 Thank you for your replay. See in line. =A0 Helvetica----- Original Message ----- = HelveticaFrom:Helvetica=20 0000,0000,EEECJP Vasseur = = HelveticaTo:<= /smaller>Helvetica= 0000,0000,EEECZhang Renhai ; 0000,0000,EEECAlia Atlas = = HelveticaCc:<= /smaller>Helvetica= 0000,0000,EEECpce@ietf.org = = HelveticaSent:Helvetica Monday, April 25, 2005 6:57 PM = HelveticaSubject:Helvetica Re: [Pce] a few comments on = draft-ash-pce-comm-protocol-gen-reqs-00.txt Hi, On Apr 25, 2005, at 4:07 AM, Zhang Renhai wrote: Hi,Alia Atlas, all ----- Original Message ----- From: "Alia Atlas" <<0000,0000,EEECaatlas@avici.com> To: <<0000,0000,EEECpce@ietf.org> Sent: Monday, April 25, 2005 1:11 PM Subject: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt In ref to the request prioritization, I agree that discarding lower priority requests shouldn't generally be necessary. At the same time, I think it is necessary to consider whether request starvation can occur for particular priorities, whether that is acceptable, and how that is handled. For the failure response discussed in 6.3.2, is it possible for the PCC to believe that the PCE is unreachable - but not vice versa? If such a scenario is possible, then it is necessary to have a mechanism to clear out old requests when communication is re-established. A few more words here could be helpful. For instance, is the assumption that the underlying reliable communication mechanism ensures reciprocal knowledge of liveness? Agree with you Alia. I'm not sure that we want to fully consider stateful PCEs, but assuming that we do at least wish to cover it somewhat, how is the success/failure of the computed LSP reported back to the PCE? This seems to be a requirement - unless there's an assumption that all LSP signalling will always succeed in scenarios where there is a stateful PCE. I do not think that this could be an assumption. In the case of statefull PCE, LSP status should of course be known by the PCE and thus be reported by PCC. Same thing, when/id head-end decides to tear an LSP down. My assumption was that such requirement would be discussed in the context of an application-specific requirement ID whereas this ID is related to generic requirements. Can the DT confirm ? =A0 No matter whether it is the scope of this draft , some interesting thoughts arose: Even with stateful PCEs, we might not hope that all computed LSPs will be successfully established.( might we? ),there should be such possibility,even not a lot. Using crankback, there will be some difference between the computed LSP and the established LSP. To keep PCEs stateful, the difference should be reported to PCEs by ingress after the LSP has been established ,so I think some more communation is needed in this draft.).(between having computed and receiving this communation, the stateful PCE is temporarily stateless! ) I'm not sure that crankback used in combination with statefull PCE is a very likely scenario but in any case, statefull PCE would need to know the LSP state for sure. [zrh] Why not ?Think of crankback's funtion. =A0=A0=A0=A0=A0=A0 In spite of which kind of PCE the LSP is established through(stateful or stateless), =A0=A0=A0=A0=A0=A0 not all nodes or links on the LSP can be local = repaired=A0for some reason, =A0=A0=A0=A0=A0=A0=A0crankback will be a good substitute. Otherwise, the = failure of these nodes or links =A0=A0=A0=A0=A0=A0 may lead to the LSP's end-to-end restoration. =A0 But this is a different scenario than relying on a statefull PCE to return loose hops ... You "may" use crankback for partial repair and in this case, you need to keep the statefull PCE updated of course. Note that another alternative (probably more efficient) is to rely on local protection, followed by end to end reoptimization. Another question: what is the substaintial differece between stateful and stateless when establishing the computed LSPs? Is it the result of establishing the LSP or the possibility of successfully establishing the LSP? Third question:Is there loose node in the computed result? Could be a possibility indeed. if yes, then: The more there are strict nodes in the computed LSP, the more possibility of unsuccessfully establishing the LSP there is. I do not think that this is a correct statement ... [zrh]By saying this, I mean that, for example, in a ospf=A0TE area, node A can get to C through B or D, =A0=A0=A0=A0=A0=A0 if two stateful PCEs serve this area, and two = computation request are *simultaneously and respectively* =A0=A0=A0=A0=A0=A0 done=A0by these two PCEs, resouces competiton may = occur when establishing LSPs, the two =A0=A0=A0=A0=A0=A0=A0computed LSP may all=A0go through B or through D, = perhaps the B's or D's resource can only serve one LSP,but another is enough. =A0=A0=A0=A0=A0=A0=A0one of the two LSPs will fail.=20 Well if you refer to the case of using N non synchronized statefull PCEs then the race condition issue is not the more challenging ;-) (furthermore note that distributed CSPF path computation leads to race condition also (and there are solutions to help there) and I do not think that the use of loose hops is the way to address the problem. With loose node information,this=A0may be avoided,because the A can compute in-order. =A0 =A0=A0=A0=A0=A0=A0 I think that there will be much issue on stateful PCE = for the duration between computing and establishing LSP.=A0=A0=A0=A0=A0=A0 Helvetica=A0=A0=A0 = Using crankback, I suggest that more loose node should be included in the result, some small-scope computation can be distributed to mid-LSRs when establishing LSP. For ingress, the most important thing is if there is a LSP satisfying the restriction. It is application specific and there won't be *one* model of statefull PCE. Consider the case of a GMPLS network where a statefull PCE is used to compute optimal paths satisfying multi-constraint criterions for a limited number of LSPs that do not change very often. Then in this case, computing path with strict hops only is certainly the most desirable scenario and loose hops with cranback would certainly lead to less optimal paths and increased signalling overhead/call set up time. Again, I'm afraid that there won't be one model capable of addressing all scenarios. [zrh] agree =A0 Hence, I think that the model of specifying a generic protocol requirements followed by more specific requirements ID is a good approach. [zrh] Agree . JP. =A0 Courier = NewThanks Courier = NewZhang =A0 Thanks. JP. Thanks, Zhang For that matter, the stateful PCE introduces the requirement for a PCE to be able to delete/remove a previously computed LSP. I think that there may be similar requirements related to the recovery & failure scenarios. Thoughts? Alia _______________________________________________ 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 =20= --Apple-Mail-1--1041661274-- --===============1330870596== 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 --===============1330870596==-- From pce-bounces@lists.ietf.org Fri Apr 29 07:37:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRTof-0005dZ-TU; Fri, 29 Apr 2005 07:37:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRToe-0005dS-70 for pce@megatron.ietf.org; Fri, 29 Apr 2005 07:37:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15527 for ; Fri, 29 Apr 2005 07:37:50 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRU1g-000716-J5 for pce@ietf.org; Fri, 29 Apr 2005 07:51:21 -0400 Received: from du-069-0084.access.clara.net ([217.158.132.84] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DRToZ-0005WE-JC; Fri, 29 Apr 2005 12:37:48 +0100 Message-ID: <063001c54cb0$25b76c20$1c849ed9@Puppy> From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" , References: Subject: Re: [Pce] WG feedback required on PCE Capability Discovery Date: Fri, 29 Apr 2005 12:37:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JL, Basic agreement. Two small points. > >(Option 3 is not such a burden since it is a request/response > >interaction and that is exactly what the PCE-PCC > >communications protocol does best.) > >Yes, but this may lead to multiple PCC-PCE crankbacks (ie > a PCC may have to try various PCEs before to find the > appropriate one) Yes and no. Yes, the first time. No subsequent times. That is, we may assume that a PCC will retain the PCE capabilities information regardless of how it is propagated. Certainly you wouldn't suggest that a PCC that receieves this information through an IGP would have a problem deciding whihc PCE to contact because it hasn't received an update for 10 minutes! >>Note that the PCE-PCC comms draft currently says that items >>like Policies must be advertised as part of the PCE >>capabilities. These could be non-trivial and many in number. > >Most of the policies (constraints, criterias...) can IMHO be encoded >using flags... Well, OK. But let's be really careful about the word Policy. It has established meaning in other protocols and it sounds like this is intended to be a different meaning. An example of a Policy by my lights would be "PCCs from this domain are not allowed to ask for paths of this type that cross that domain for this priority traffic except on a Wednesday or when there is an R in the month." A _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Apr 29 12:16:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRYAd-0003Ly-I0; Fri, 29 Apr 2005 12:16:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRYAb-0003Kz-Bc for pce@megatron.ietf.org; Fri, 29 Apr 2005 12:16:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11101 for ; Fri, 29 Apr 2005 12:16:46 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRYNh-0003AC-CF for pce@ietf.org; Fri, 29 Apr 2005 12:30:21 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 29 Apr 2005 12:29:21 -0400 X-IronPort-AV: i="3.92,139,1112587200"; d="scan'208"; a="46660328:sNHT45389396" 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 j3TGG7eN010698; Fri, 29 Apr 2005 12:16:38 -0400 (EDT) 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.211); Fri, 29 Apr 2005 12:16:37 -0400 Received: from [192.168.1.100] ([10.86.240.47]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 12:16:36 -0400 In-Reply-To: <063001c54cb0$25b76c20$1c849ed9@Puppy> References: <063001c54cb0$25b76c20$1c849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <4c743bded1dbe6e22355973ce9b9c67f@cisco.com> From: JP Vasseur Subject: Re: [Pce] WG feedback required on PCE Capability Discovery Date: Fri, 29 Apr 2005 12:16:51 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 29 Apr 2005 16:16:36.0613 (UTC) FILETIME=[D12E9350:01C54CD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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="===============1660818198==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1660818198== Content-Type: multipart/alternative; boundary=Apple-Mail-1--954741509 --Apple-Mail-1--954741509 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, On Apr 29, 2005, at 7:37 AM, Adrian Farrel wrote: > Hi JL, > > Basic agreement. > > Two small points. > >>> (Option 3 is not such a burden since it is a request/response >>> interaction and that is exactly what the PCE-PCC >>> communications protocol does best.) >> >> Yes, but this may lead to multiple PCC-PCE crankbacks (ie >> a PCC may have to try various PCEs before to find the >> appropriate one) > > Yes and no. > Yes, the first time. > But ... the first time may lead to the impossibility to compute a path unless we extend signaling to support crankback. Furthermore, the cap may change ... and this may also lead to increase response time should the capability of the backup PCE be discovered upon reroute. > No subsequent times. > That is, we may assume that a PCC will retain the PCE capabilities > information regardless of how it is propagated. Certainly you wouldn't > suggest that a PCC that receieves this information through an IGP would > have a problem deciding whihc PCE to contact because it hasn't > received an > update for 10 minutes! > >>> Note that the PCE-PCC comms draft currently says that items >>> like Policies must be advertised as part of the PCE >>> capabilities. These could be non-trivial and many in number. >> >> Most of the policies (constraints, criterias...) can IMHO be encoded >> using flags... > > Well, OK. > But let's be really careful about the word Policy. > It has established meaning in other protocols and it sounds like this > is > intended to be a different meaning. > An example of a Policy by my lights would be "PCCs from this domain are > not allowed to ask for paths of this type that cross that domain for > this > priority traffic except on a Wednesday or when there is an R in the > month." Right. In my opinion, unless the PCC cannot support dynamic discovery and/or the capability does require to exchange a large amount of information, it looks reasonable to rely on a single discovery mechanism. Cheers, JP. > > A > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-1--954741509 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, On Apr 29, 2005, at 7:37 AM, Adrian Farrel wrote: Hi JL, Basic agreement. Two small points. (Option 3 is not such a burden since it is a request/response interaction and that is exactly what the PCE-PCC communications protocol does best.) Yes, but this may lead to multiple PCC-PCE crankbacks (ie a PCC may have to try various PCEs before to find the appropriate one) Yes and no. Yes, the first time. But ... the first time may lead to the impossibility to compute a path unless we extend signaling to support crankback. Furthermore, the cap may change ... and this may also lead to increase response time should the capability of the backup PCE be discovered upon reroute. No subsequent times. That is, we may assume that a PCC will retain the PCE capabilities information regardless of how it is propagated. Certainly you wouldn't suggest that a PCC that receieves this information through an IGP would have a problem deciding whihc PCE to contact because it hasn't received an update for 10 minutes! Note that the PCE-PCC comms draft currently says that items like Policies must be advertised as part of the PCE capabilities. These could be non-trivial and many in number. Most of the policies (constraints, criterias...) can IMHO be encoded using flags... Well, OK. But let's be really careful about the word Policy. It has established meaning in other protocols and it sounds like this is intended to be a different meaning. An example of a Policy by my lights would be "PCCs from this domain are not allowed to ask for paths of this type that cross that domain for this priority traffic except on a Wednesday or when there is an R in the month." Right. In my opinion, unless the PCC cannot support dynamic discovery and/or the capability does require to exchange a large amount of information, it looks reasonable to rely on a single discovery mechanism. Cheers, JP. A _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-1--954741509-- --===============1660818198== 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 --===============1660818198==-- From pce-bounces@lists.ietf.org Fri Apr 29 13:50:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRZdK-0003mq-25; Fri, 29 Apr 2005 13:50:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRZdI-0003ml-HI for pce@megatron.ietf.org; Fri, 29 Apr 2005 13:50:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23192 for ; Fri, 29 Apr 2005 13:50:31 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRZqP-0008UY-94 for pce@ietf.org; Fri, 29 Apr 2005 14:04:05 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j3THoM931555; Fri, 29 Apr 2005 10:50:22 -0700 (PDT) (envelope-from ina@juniper.net) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j3THoHe42881; Fri, 29 Apr 2005 10:50:17 -0700 (PDT) (envelope-from ina@juniper.net) Date: Fri, 29 Apr 2005 10:50:17 -0700 (PDT) From: Ina Minei To: JP Vasseur Subject: Re: [Pce] WG feedback required on PCE Capability Discovery In-Reply-To: <4c743bded1dbe6e22355973ce9b9c67f@cisco.com> Message-ID: <20050429104213.Y31338@garnet.juniper.net> References: <063001c54cb0$25b76c20$1c849ed9@Puppy> <4c743bded1dbe6e22355973ce9b9c67f@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JP, Adrian and all, It seems to me that the discussion on how the policies are communicated is tightly coupled to what these policies are. From reading section 6.2.3, the concept of policies was not clear to me. Following the discussion on the list, I get the sense that different people have different ideas what the policies should convey. I did notice that the draft states that "actual policies are out of scope", but to be able to encode them, one must have a sense of what they are. Can the authors expand on section 6.2.3 to shed some light on the policies? In particular: - what kind of functionality do the policies provide - how dynamic they are (how often do they change) - how fast must a policy change be propagated to the PCC - what is the relationship between a policy and a capability - should policies be advertised in the same way as capabilities are Thanks, Ina On Fri, 29 Apr 2005, JP Vasseur wrote: > Hi, > > On Apr 29, 2005, at 7:37 AM, Adrian Farrel wrote: > > > Hi JL, > > > > Basic agreement. > > > > Two small points. > > > >>> (Option 3 is not such a burden since it is a request/response > >>> interaction and that is exactly what the PCE-PCC > >>> communications protocol does best.) > >> > >> Yes, but this may lead to multiple PCC-PCE crankbacks (ie > >> a PCC may have to try various PCEs before to find the > >> appropriate one) > > > > Yes and no. > > Yes, the first time. > > > > But ... the first time may lead to the impossibility to compute a path > unless we extend signaling to support crankback. Furthermore, the cap > may change ... and this may also lead to increase response time should > the capability of the backup PCE be discovered upon reroute. > > > No subsequent times. > > That is, we may assume that a PCC will retain the PCE capabilities > > information regardless of how it is propagated. Certainly you wouldn't > > suggest that a PCC that receieves this information through an IGP would > > have a problem deciding whihc PCE to contact because it hasn't > > received an > > update for 10 minutes! > > > >>> Note that the PCE-PCC comms draft currently says that items > >>> like Policies must be advertised as part of the PCE > >>> capabilities. These could be non-trivial and many in number. > >> > >> Most of the policies (constraints, criterias...) can IMHO be encoded > >> using flags... > > > > Well, OK. > > But let's be really careful about the word Policy. > > It has established meaning in other protocols and it sounds like this > > is > > intended to be a different meaning. > > An example of a Policy by my lights would be "PCCs from this domain are > > not allowed to ask for paths of this type that cross that domain for > > this > > priority traffic except on a Wednesday or when there is an R in the > > month." > > Right. > > In my opinion, unless the PCC cannot support dynamic discovery and/or > the capability does require to exchange a large amount of information, > it looks reasonable to rely on a single discovery mechanism. > > Cheers, > > JP. > > > > > A > > > > > > _______________________________________________ > > 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 Apr 30 04:18:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRnAr-0004LQ-0h; Sat, 30 Apr 2005 04:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRnAo-0004LL-RP for pce@megatron.ietf.org; Sat, 30 Apr 2005 04:18:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20160 for ; Sat, 30 Apr 2005 04:17:59 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRnO0-0008OB-Q2 for pce@ietf.org; Sat, 30 Apr 2005 04:31:42 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IFR001A132Q4Y@szxga03-in.huawei.com> for pce@ietf.org; Sat, 30 Apr 2005 16:18:27 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IFR004N632QRL@szxga03-in.huawei.com> for pce@ietf.org; Sat, 30 Apr 2005 16:18:26 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IFR00IKT36IRT@szxml02-in.huawei.com> for pce@ietf.org; Sat, 30 Apr 2005 16:20:42 +0800 (CST) Date: Sat, 30 Apr 2005 15:54:25 +0800 From: Zhang Renhai To: pce@ietf.org Message-id: <005f01c54d59$d7b4b6e0$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [Pce] a question on draft-ash-pce-comm-protocol-gen-reqs-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: , Content-Type: multipart/mixed; boundary="===============0788686631==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0788686631== Content-type: multipart/alternative; boundary="Boundary_(ID_UELDWCrqWFGmSwu+Hk3hHA)" This is a multi-part message in MIME format. --Boundary_(ID_UELDWCrqWFGmSwu+Hk3hHA) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi, all Section 6.1.2 about PCC-PCE and PCE-PCE communication "A single protocol MUST be defined for PCC-PCE and PCE-PCE communication. A PCE requesting a path from another PCE can be considered as a PCC." Here I am not very clear about if the content of PCE-PCE communicating and PCC-PCE communicating strictly is the same. Could some more words be added here such as: "PCE-PCE communication can transfer more info with the protocol, for example their computing capability, status, etc." Thanks. Zhang --Boundary_(ID_UELDWCrqWFGmSwu+Hk3hHA) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Hi, all
Section 6.1.2 about PCC-PCE and PCE-PCE communication
"A single protocol MUST be defined for PCC-PCE and PCE-PCE communication.
A PCE requesting a path from another PCE can be considered as a PCC."
Here I am not very clear about  if the content of PCE-PCE communicating
and PCC-PCE communicating strictly is the same.
Could some more words be added here such as:
"PCE-PCE communication can transfer more info with the protocol, for example
their computing capability, status, etc."
Thanks.
Zhang
--Boundary_(ID_UELDWCrqWFGmSwu+Hk3hHA)-- --===============0788686631== 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 --===============0788686631==-- From pce-bounces@lists.ietf.org Sat Apr 30 04:58:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRnnj-0004Ur-6X; Sat, 30 Apr 2005 04:58:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRnng-0004TK-Jv for pce@megatron.ietf.org; Sat, 30 Apr 2005 04:58:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21902 for ; Sat, 30 Apr 2005 04:58:10 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRo0u-00017c-Uc for pce@ietf.org; Sat, 30 Apr 2005 05:11:53 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IFR00E4O4TLTX@szxga03-in.huawei.com> for pce@ietf.org; Sat, 30 Apr 2005 16:56:09 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IFR000E74TLXM@szxga03-in.huawei.com> for pce@ietf.org; Sat, 30 Apr 2005 16:56:09 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IFR00HEU5272Q@szxml01-in.huawei.com>; Sat, 30 Apr 2005 17:01:20 +0800 (CST) Date: Sat, 30 Apr 2005 16:32:13 +0800 From: Zhang Renhai Subject: Re: [Pce] WG feedback required on PCE Capability Discovery To: LE ROUX Jean-Louis RD-CORE-LAN Message-id: <008101c54d5f$1c4a7240$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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="===============0273545321==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0273545321== Content-type: multipart/alternative; boundary="Boundary_(ID_lbhYfShMEvZt1spjS3vUmQ)" This is a multi-part message in MIME format. --Boundary_(ID_lbhYfShMEvZt1spjS3vUmQ) Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT WG feedback required on PCE Capability DiscoveryHi, JL If every PCE know well of the capabilities of other's PCE, before PCE reject a request because of its computation capabilities , it can get the appropriate one and return it to PCC. if so ,at any time ,the PCC need not to know the detailed capabilities,knowing only generic PCE capabilities is enough for PCC. Could this be another choise? Thanks. Zhang ----- Original Message ----- From: LE ROUX Jean-Louis RD-CORE-LAN To: pce@ietf.org Sent: Monday, April 18, 2005 5:02 PM Subject: [Pce] WG feedback required on PCE Capability Discovery Hi all, There has been several discussions within the PCE com Design Team and among PCE discovery requirements co-authors, regarding dynamic discovery of PCE capabilities. Once we agree that there is a need for dynamic PCE capability discovery, then it appears that there are three options: Option 1: A single specific PCE discovery mechanism is used to discover all PCE capabilities (as currently required in the PCE discovery requirements I-D http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt). Option 2: All PCE capabilities are discovered through added functionality in the PCE communication protocol (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-reqs-00.txt). Option 3: Discovery of some generic PCE capabilities (computation domain, scope...) is done by the PCE discovery mechanism and discovery of detailed capabilities (e.g. type of constraints supported...) relies on the PCE communication protocol. In 1) since PCC knows all PCE capabilities, it is the reponsibility of the PCC to select the appropriate PCE for a particular path computation. So, no capability-related request parameters are needed in the communication protocol, since the PCC alreay knows what is expected from the PCE. In 3) PCC knows certain basic capabilities, but for the capabilities that it is unaware of, it may request specific parameters in the communication protocol when a path computation request is made to the PCE. If the PCE is not capable of the requested paramters, then appropriate failure is reported. Note that this does not take into account discovery of PCE location, that can be done either statically or dynamically through functionality in the PCE discovery mechanism (here the PCE communication protocol cannot help). Note also that PCE capabilities could of course be configured statically but this is out of the scope of this discussion focused on dynamic capability discovery. WG feedback on this topic would be highly desired. Please give us your comments and preferences regarding these three options. JL -------------------------------------------------------------------------------- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --Boundary_(ID_lbhYfShMEvZt1spjS3vUmQ) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT WG feedback required on PCE Capability Discovery
Hi, JL
 
If every PCE know well of the capabilities of other's PCE, before PCE reject
a request because of its computation capabilities , it can get the appropriate one and
return it to PCC. if so ,at any time ,the PCC need not to know the detailed
capabilities,knowing only generic PCE capabilities is enough for PCC.
Could this be  another choise?
 
Thanks.
Zhang
 

----- Original Message -----
From: LE ROUX Jean-Louis RD-CORE-LAN
To: pce@ietf.org
Sent: Monday, April 18, 2005 5:02 PM
Subject: [Pce] WG feedback required on PCE Capability Discovery
 

Hi all,
 
There has been several discussions within the PCE com Design Team and among PCE discovery requirements co-authors, regarding dynamic discovery of PCE capabilities.
 
Once we agree that there is a need for dynamic PCE capability discovery, then it appears that there are three options:
 
Option 1: A single specific PCE discovery mechanism is used to discover all PCE capabilities (as currently required in the PCE discovery requirements I-D http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt).
 
Option 2: All PCE capabilities are discovered through added functionality in the PCE communication protocol (http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-reqs-00.txt).
 
Option 3: Discovery of some generic PCE capabilities (computation domain, scope...) is done by the PCE discovery mechanism and discovery of detailed capabilities (e.g. type of constraints supported...) relies on the PCE communication protocol.
 
In 1) since PCC knows all PCE capabilities, it is the reponsibility of the PCC to select the appropriate PCE for a particular path computation. So, no capability-related request parameters are needed in the communication protocol, since the PCC alreay knows what is expected from the PCE.
 
In 3) PCC knows certain basic capabilities, but for the capabilities that it is unaware of, it may request specific parameters in the communication protocol when a path computation request is made to the PCE. If the PCE is not capable of the requested paramters, then appropriate failure is reported.
 
Note that this does not take into account discovery of PCE location, that can be done either statically or dynamically through functionality in the PCE discovery mechanism (here the PCE communication protocol cannot help). 
 
Note also that PCE capabilities could of course be configured statically but this is out of the scope of this discussion focused on dynamic capability discovery.
 
WG feedback on this topic would be highly desired.
Please give us your comments and preferences regarding these three options.
 
JL
 
 
 
 
 

--------------------------------------------------------------------------------
 

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--Boundary_(ID_lbhYfShMEvZt1spjS3vUmQ)-- --===============0273545321== 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 --===============0273545321==-- From pce-bounces@lists.ietf.org Sat Apr 30 15:11:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRxN6-0001V6-Fb; Sat, 30 Apr 2005 15:11:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRxN5-0001Ux-4q for pce@megatron.ietf.org; Sat, 30 Apr 2005 15:11:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25508 for ; Sat, 30 Apr 2005 15:11:20 -0400 (EDT) Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRxaM-0004H8-QT for pce@ietf.org; Sat, 30 Apr 2005 15:25:09 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j3UJAB33014826 for ; Sat, 30 Apr 2005 14:11:10 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.2.052) id 42628972003B4DD2; Sat, 30 Apr 2005 15:11:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] WG feedback required on PCE Capability Discovery Date: Sat, 30 Apr 2005 14:11:09 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE58C@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] WG feedback required on PCE Capability Discovery Thread-Index: AcVM5D4oXJLH8o/ETcCvL4jqzyVcpgA0rIHQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Ina Minei" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Ina, > It seems to me that the discussion on how the policies are > communicated is tightly coupled to what these policies are. From reading > section 6.2.3, the concept of policies was not clear to me. Following the > discussion on the list, I get the sense that different people have > different ideas what the policies should convey. > > I did notice that the draft states that "actual policies are out > of scope", but to be able to encode them, one must have a sense of what > they are. > > Can the authors expand on section 6.2.3 to shed some light on the > policies? In particular: > - what kind of functionality do the policies provide > - how dynamic they are (how often do they change) > - how fast must a policy change be propagated to the PCC > - what is the relationship between a policy and a capability > - should policies be advertised in the same way as capabilities are The authors of http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-gen-reqs -00.txt have had much recent discussion about the requirements in Section 6.2.3. We agree that much of the second part of the discussion RE 'encoding policies, etc.' should be removed. The revised text is as follows: "6.2.3 Policy Support The communication protocol MUST allow for policies to accept/reject requests, and include the ability for a PCE to reject requests with sufficient detail to allow the PCC to determine the reason for rejection or failure. For example, filtering could be required for intra-AS PCE path computation such that all requests are rejected that come from another AS. However, specific policy details are left to application-specific communication protocol requirements. Furthermore, the communication protocol MUST allow for the notification of a policy violation. Actual policies, configuration of policies, and applicability of policies are out of scope." The -01 revision of the draft will be issued shortly. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce