From pce-bounces@lists.ietf.org Mon Apr 02 09:47:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMrh-0000Zt-Da; Mon, 02 Apr 2007 09:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMrg-0000Yw-Kt for pce@ietf.org; Mon, 02 Apr 2007 09:46:32 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee03s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMrf-00086V-5M for pce@ietf.org; Mon, 02 Apr 2007 09:46:32 -0400 Received: from wpwuee03s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee03s.mail.mercury.atosorigin.com (Postfix) with ESMTP id F2737114017; Mon, 2 Apr 2007 15:46:23 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee03s.mail.mercury.atosorigin.com (Postfix) with ESMTP id D306411402F; Mon, 2 Apr 2007 15:46:23 +0200 (CEST) Message-ID: <008401c7752d$357310e0$15600337@AOFR11476> From: "fabien.verhaeghe" To: "Adrian Farrel" , "LE ROUX Jean-Louis RD-CORE-LAN" , "Dan Li" , References: <0cb301c7712e$c1f03e10$ea138182@your029b8cecfe> <002a01c77142$2cda9050$15600337@AOFR11476> <0f4101c77219$08ec6f10$ea138182@your029b8cecfe> Subject: Re: [Pce] Switching type Constraint in PCEP Date: Mon, 2 Apr 2007 15:45:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Adrian, >> However, where we seem to have arrived is that the PCEP I-D contains the >> protocol definition and "core" functional units. Other units that were >> identified in 4657 (such as XRO, objective funcions, ...) are going into >> seperate I-Ds. Following that model, the GMPLS-specific work definitely >> goes into a separate draft. As above, I am comfortable for that to be in >> the multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to >> help keep the number of I-Ds manageable Having a unique "GMPLS and multi-layer requirement" document seems a good idea to me. If we'd have 2 seperate drafts I'm afraid there would be some overlapping just like for the switching type. >> So my view (other will surely correct me :-) is that encoding type is >> only needed where the signal is unpacked for some reason. Typically, this >> only happens at end points, so the PCE function is to ensure that the >> destination interface is capable of decoding the signal and delivering >> the data. In general, it has been considered that the destination >> capabilities are either known to the ingress (guaranteed LSP setup >> success - you wouldn't even bother trying to set up an LSP to someone you >> knew couldn't understand you) or are not known in which case the LSP will >> either succeed or fail (but no amount of re-routing will help). Now, it >> *is* possible that different interfaces on the egress have different >> levels of support for encoding types, but this has generally been >> considered as very advanced and not worth optimising for. >> >> However, recent discussion has suggested that in certain technologies, >> signal regeneration also requires knowledge of the encoding type. This >> would certainly expand the requirement for PCE to know about encoding >> type. I am not sure about the hardware specifics here and perhaps someone >> can enlighten us. Thank you Adrian for the clarification. It helps a lot :-)... Regards Fabien ----- Original Message ----- From: "Adrian Farrel" To: "fabien.verhaeghe" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; "Dan Li" ; Sent: Thursday, March 29, 2007 5:18 PM Subject: Re: [Pce] Switching type Constraint in PCEP > Hi Fabien, > >> Reading the generic and inter layer requirement documents it is not clear >> to me if Switching Type is really specific to inter layer application. >> As far as I understand inter-layer requirement refers to path computation >> which result path may comprise multiple layer technologies. >> Though I understand Switching type is required in this context, it is >> also >> required for mono layer path computation in a multi-layer environment >> (e.g. to computate a Lambda path using a TE Database that contains also >> TDM TE Links). >> So it is more a GMPLS specific requirement to me. > > I think you are correct. That is, the switching type constraint is > required in the multi-layer context, but it may have wider applicability. > > Provided that the multi-layer work progress quite quickly, I would suggest > that it is convenient to group all of the protocol extensions together. > You can then select from the set of optional objects as necessary for your > application. I would hope that you would provide your review input to the > multi-layer work to ensure that the protocol extensions give you what you > need. > > On the other hand, if the multi-layer work seems to get stuck or held up, > then I would understand you pushing to get the "GMPLS-specific" extensions > done separately. > >> Acually it is not clear to me what is the scope of generic and >> "application specific" requirements. Generic Requirement RFC4657 section >> 5.1.16 >> mention Switching and encoding type as "GMPLS specific requirements". >> Does it mean "GMPLS specific" is "considered as generic? > > Hmmm. > This is a line we have not succeeded in drawing very clearly. > > However, where we seem to have arrived is that the PCEP I-D contains the > protocol definition and "core" functional units. Other units that were > identified in 4657 (such as XRO, objective funcions, ...) are going into > seperate I-Ds. Following that model, the GMPLS-specific work definitely > goes into a separate draft. As above, I am comfortable for that to be in > the multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to > help keep the number of I-Ds manageable. > >> Concerning the necessity of "encoding type" in PCEP I have to admit that >> I'm not sure to correctly understand the meaning of this parameter in the >> GMPLS >> architecture :-). > > I think this puts you in the majority! > >> What I understand at least is that it is both an interface and >> an LSP property, so from this it seems to be required in PCEP. >> I would be interested to see discussion about encoding type >> requirement in PCEP cause it may clarify the encoding type meaning to me >> ;-). > > So my view (other will surely correct me :-) is that encoding type is only > needed where the signal is unpacked for some reason. Typically, this only > happens at end points, so the PCE function is to ensure that the > destination interface is capable of decoding the signal and delivering the > data. In general, it has been considered that the destination capabilities > are either known to the ingress (guaranteed LSP setup success - you > wouldn't even bother trying to set up an LSP to someone you knew couldn't > understand you) or are not known in which case the LSP will either succeed > or fail (but no amount of re-routing will help). Now, it *is* possible > that different interfaces on the egress have different levels of support > for encoding types, but this has generally been considered as very > advanced and not worth optimising for. > > However, recent discussion has suggested that in certain technologies, > signal regeneration also requires knowledge of the encoding type. This > would certainly expand the requirement for PCE to know about encoding > type. I am not sure about the hardware specifics here and perhaps someone > can enlighten us. > > Cheers, > Adrian > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Apr 03 07:08:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgs9-0005MD-S8; Tue, 03 Apr 2007 07:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgs9-0005M2-1f for pce@ietf.org; Tue, 03 Apr 2007 07:08:21 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee01s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYgs7-000244-EW for pce@ietf.org; Tue, 03 Apr 2007 07:08:21 -0400 Received: from wpwuee01s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 7FD16F402E; Tue, 3 Apr 2007 13:08:16 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 520A6F4047; Tue, 3 Apr 2007 13:08:16 +0200 (CEST) Message-ID: <006f01c775e0$490559c0$15600337@AOFR11476> From: "fabien.verhaeghe" To: "Tomohiro Otani" , "Adrian Farrel" References: <0cb301c7712e$c1f03e10$ea138182@your029b8cecfe> <002a01c77142$2cda9050$15600337@AOFR11476> <0f4101c77219$08ec6f10$ea138182@your029b8cecfe> <460C4F77.7040309@kddilabs.jp> Subject: Re: [Pce] Switching type Constraint in PCEP Date: Tue, 3 Apr 2007 13:07:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-2022-JP"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Tomo, I read your draft pointed by Dan that indeed contains some valuable information. Especially in section 2.2: "For the simplicity of the analysis in path consideration, the below basic assumptions are made when the LSP is created. (1) Switching capabilities (SC) of outgoing links from the ingress and egress nodes (link1-2 and link4-3 in Figure 1) must be consistent with each other. (2) SC of all transit links including incoming links to the ingress and egress nodes (link2-1 and link3-4) should be consistent with switching type of a LSP to be created. (3) Encoding-types of all transit links should be consistent with encoding type of a LSP to be created." Point 2 and 3 seems to imply that a PCE needs to know both the switching and encoding type of the LSP. To me the information would typically be provided by the PCC (which knows what kind of LSP is being established) using PCEP. Am I misunderstanding something or do you agree? Regards Fabien ----- Original Message ----- From: "Tomohiro Otani" To: "Adrian Farrel" Cc: "fabien.verhaeghe" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; "Dan Li" ; Sent: Friday, March 30, 2007 1:44 AM Subject: Re: [Pce] Switching type Constraint in PCEP > Hi Fabien and Adrian, > > Looking at the discussion, path computation itself and a protocol > staff such as PCEP are a different thing. I believe, touch upon > by Dan, that our cspf draft is a kind of guideline how to consider > GMPLS-specific constrains including encoding type for path computation. > I hope that the cspf draft help Fabien to understand parameters. > > If you need any help for GMPLS specific extensions, please let me know. > > With best regards, > > Tomo > > > > Adrian Farrel wrote: >> Hi Fabien, >> >>> Reading the generic and inter layer requirement documents it is not >>> clear to me if Switching Type is really specific to inter layer >>> application. >>> As far as I understand inter-layer requirement refers to path >>> computation which result path may comprise multiple layer technologies. >>> Though I understand Switching type is required in this context, it is >>> also >>> required for mono layer path computation in a multi-layer environment >>> (e.g. to computate a Lambda path using a TE Database that contains >>> also TDM TE Links). >>> So it is more a GMPLS specific requirement to me. >> >> I think you are correct. That is, the switching type constraint is >> required in the multi-layer context, but it may have wider applicability. >> >> Provided that the multi-layer work progress quite quickly, I would >> suggest that it is convenient to group all of the protocol extensions >> together. You can then select from the set of optional objects as >> necessary for your application. I would hope that you would provide your >> review input to the multi-layer work to ensure that the protocol >> extensions give you what you need. >> >> On the other hand, if the multi-layer work seems to get stuck or held >> up, then I would understand you pushing to get the "GMPLS-specific" >> extensions done separately. >> >>> Acually it is not clear to me what is the scope of generic and >>> "application specific" requirements. Generic Requirement RFC4657 >>> section 5.1.16 >>> mention Switching and encoding type as "GMPLS specific requirements". >>> Does it mean "GMPLS specific" is "considered as generic? >> >> Hmmm. >> This is a line we have not succeeded in drawing very clearly. >> >> However, where we seem to have arrived is that the PCEP I-D contains the >> protocol definition and "core" functional units. Other units that were >> identified in 4657 (such as XRO, objective funcions, ...) are going into >> seperate I-Ds. Following that model, the GMPLS-specific work definitely >> goes into a separate draft. As above, I am comfortable for that to be in >> the multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to >> help keep the number of I-Ds manageable. >> >>> Concerning the necessity of "encoding type" in PCEP I have to admit >>> that I'm not sure to correctly understand the meaning of this >>> parameter in the GMPLS >>> architecture :-). >> >> I think this puts you in the majority! >> >>> What I understand at least is that it is both an interface and >>> an LSP property, so from this it seems to be required in PCEP. >>> I would be interested to see discussion about encoding type >>> requirement in PCEP cause it may clarify the encoding type meaning to >>> me ;-). >> >> So my view (other will surely correct me :-) is that encoding type is >> only needed where the signal is unpacked for some reason. Typically, >> this only happens at end points, so the PCE function is to ensure that >> the destination interface is capable of decoding the signal and >> delivering the data. In general, it has been considered that the >> destination capabilities are either known to the ingress (guaranteed LSP >> setup success - you wouldn't even bother trying to set up an LSP to >> someone you knew couldn't understand you) or are not known in which case >> the LSP will either succeed or fail (but no amount of re-routing will >> help). Now, it *is* possible that different interfaces on the egress >> have different levels of support for encoding types, but this has >> generally been considered as very advanced and not worth optimising for. >> >> However, recent discussion has suggested that in certain technologies, >> signal regeneration also requires knowledge of the encoding type. This >> would certainly expand the requirement for PCE to know about encoding >> type. I am not sure about the hardware specifics here and perhaps >> someone can enlighten us. >> >> Cheers, >> Adrian >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Apr 03 08:31:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYi9z-0002Uq-MN; Tue, 03 Apr 2007 08:30:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYi9y-0002TX-Hl for pce@ietf.org; Tue, 03 Apr 2007 08:30:50 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYi9w-0003Ti-4R for pce@ietf.org; Tue, 03 Apr 2007 08:30:50 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Apr 2007 05:30:48 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l33CUl8d017706; Tue, 3 Apr 2007 05:30:47 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l33CUfEk004402; Tue, 3 Apr 2007 12:30:47 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 08:30:44 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 08:30:44 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) References: <8A700039-B848-4CB0-9AD3-62BD86B61240@cisco.com> Message-Id: From: JP Vasseur Date: Tue, 3 Apr 2007 08:30:49 -0400 To: PAPADIMITRIOU Dimitri X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Apr 2007 12:30:44.0594 (UTC) FILETIME=[E65C9520:01C775EB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4033; t=1175603447; x=1176467447; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20ID=20Monitoring |Sender:=20; bh=ltT11FykbHQy+XKxmBw5fGR/NbuaiJ2ZNG378z86IOw=; b=rsbiTZ0nXnNDpxtRKiNwIVRV26SCo2zVYjrjEw7+KpglJyUZ9LwIwSrimCuShAszYR63sAJM H9Dm1B8iP5qTFxR8BktDc0QVUDWmtBPWk5XEwY7DguOWXc75KDRDiRsu; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pce@ietf.org Subject: [Pce] Fwd: ID Monitoring 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="===============1120221480==" Errors-To: pce-bounces@lists.ietf.org --===============1120221480== Content-Type: multipart/alternative; boundary=Apple-Mail-123--272246349 --Apple-Mail-123--272246349 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Begin forwarded message: > From: JP Vasseur > Date: March 29, 2007 3:32:18 PM EDT > To: PAPADIMITRIOU Dimitri > Cc: pce@ietf.org > Subject: ID Monitoring > > Hi Dimitri, > > In order to move forward here ... > > Could you list the set of items for which you'd like a clarification ? > > Thanks. > > JP. --Apple-Mail-123--272246349 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = March 29, 2007 3:32:18 PM EDT
To: PAPADIMITRIOU Dimitri <Dimitri.Papadimitr= iou@alcatel-lucent.be>
Subject: = ID Monitoring

Hi = Dimitri,

In order to move forward here ...

Could = you list the set of items for which you'd like a clarification = ?

Thanks.

JP.
=

= --Apple-Mail-123--272246349-- --===============1120221480== 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 --===============1120221480==-- From pce-bounces@lists.ietf.org Tue Apr 03 15:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp1B-0003fn-9B; Tue, 03 Apr 2007 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp16-0003c1-Qi; Tue, 03 Apr 2007 15:50:08 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYp16-0003TK-IB; Tue, 03 Apr 2007 15:50:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6CE5B26F37; Tue, 3 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HYp10-0007ng-Ar; Tue, 03 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 03 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-xro-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions Author(s) : E. Oki, A. Farrel Filename : draft-ietf-pce-pcep-xro-00.txt Pages : 12 Date : 2007-4-3 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify as constraints to the path computation abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from routes. Such constraints are termed route exclusions. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-xro-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-pcep-xro-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-pcep-xro-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-3111526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcep-xro-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcep-xro-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-3111526.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Mon Apr 09 15:50:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HazsT-0004PF-IZ; Mon, 09 Apr 2007 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HazsL-0004Mm-7e; Mon, 09 Apr 2007 15:50:05 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HazsK-00089d-Re; Mon, 09 Apr 2007 15:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8D72026EC2; Mon, 9 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HazsI-0005c1-FA; Mon, 09 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-isis-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : IS-IS protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-isis-03.txt Pages : 20 Date : 2007-4-9 There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCE), along with some information that can be used for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to discover PCEs consists of using IGP flooding. For that purpose this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-isis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-9104314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-isis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-9104314.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Thu Apr 12 06:02:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbw8K-00054j-6M; Thu, 12 Apr 2007 06:02:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbw8I-00054e-UF for pce@lists.ietf.org; Thu, 12 Apr 2007 06:02:26 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hbw8H-0003kN-GS for pce@lists.ietf.org; Thu, 12 Apr 2007 06:02:26 -0400 Received: (qmail 3908 invoked by uid 0); 12 Apr 2007 10:02:24 -0000 Received: from 192.35.17.24 by www042.gmx.net with HTTP; Thu, 12 Apr 2007 12:02:24 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Apr 2007 12:02:24 +0200 From: _den@gmx.de Message-ID: <20070412100224.297270@gmx.net> MIME-Version: 1.0 To: pce@lists.ietf.org X-Authenticated: #19887475 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/iDXcgTwPiEXBleSdv/67HVetLoGpb9iqzPSI278 OPCUDUfU5uYPhLEER9lch8+ZQkEC8FX82W+Q== Content-Transfer-Encoding: 7bit X-GMX-UID: hzsody1HYmYBf0VCSnY3ZrdCWkZTQdTU X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Pce] PCEP messages with ASN.1 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, I am currently implementing the pcep protocol. At the moment I think, how should the messages be encoded. Is it possible to use ASN.1c compiler to code pcep messages conform to the current draft? Has anybody used it for this purpose? Thanks -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Apr 12 06:11:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbwH3-00011m-PV; Thu, 12 Apr 2007 06:11:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbwH2-00011f-LT for pce@ietf.org; Thu, 12 Apr 2007 06:11:28 -0400 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbwH2-0005sw-1j for pce@ietf.org; Thu, 12 Apr 2007 06:11:28 -0400 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1HbwH0-0003bl-OZ for pce@ietf.org; Thu, 12 Apr 2007 10:11:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Switching type Constraint in PCEP Date: Thu, 12 Apr 2007 11:11:25 +0100 Message-ID: <3D1918258E6DE14DAAABBD34D53D2934112550@cortex.aria-networks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Switching type Constraint in PCEP Thread-Index: Acd14H1wIBPrLDIGTW+LVF94ExLh3QHAOJeg From: "Daniel King" To: "fabien.verhaeghe" , "Tomohiro Otani" , "Adrian Farrel" X-Originating-Rutherford-IP: [88.96.235.142] X-Spam-Score: 0.1 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hello Fabien,=20 I agree with you, but this knowledge is only needed in a network with multi-switching capability nodes. Running such a network is a Multi Layer Network (MLN) problem. So it would be necessary to know the capabilities of the interfaces of the nodes in the network, their adaptation capabilities between switching types, and the LSP type. Although I would not think that for the path computation it is needed to know that the transit nodes support the same switching capabilities. What you need to know is that you could build a technology tunnel (an FA-LSP) over the nodes that do not support your end to end LSP switching type. This is what MLN is supposed to do for you. The PCE could then make an end to end path that includes other switching capabilities provided that a trigger for the FA-LSP will be set up. You might want to look at Eiji's two PCE MLN drafts. Hopefully, Eiji's PCEP extensions will give everyone what they need. Thanks, Dan -----Original Message----- From: fabien.verhaeghe [mailto:fabien.verhaeghe@atosorigin.com]=20 Sent: 03 April 2007 12:08 To: Tomohiro Otani; Adrian Farrel Cc: pce@ietf.org Subject: Re: [Pce] Switching type Constraint in PCEP Hi Tomo, I read your draft pointed by Dan that indeed contains some valuable=20 information. Especially in section 2.2: "For the simplicity of the analysis in path consideration, the below basic assumptions are made when the LSP is created. (1) Switching capabilities (SC) of outgoing links from the ingress and egress nodes (link1-2 and link4-3 in Figure 1) must be consistent with each other. (2) SC of all transit links including incoming links to the ingress and egress nodes (link2-1 and link3-4) should be consistent with switching type of a LSP to be created. (3) Encoding-types of all transit links should be consistent with encoding type of a LSP to be created." Point 2 and 3 seems to imply that a PCE needs to know both the switching and=20 encoding type of the LSP. To me the information would typically be provided by the PCC (which knows=20 what kind of LSP is being established) using PCEP. Am I misunderstanding something or do you agree? Regards Fabien ----- Original Message -----=20 From: "Tomohiro Otani" To: "Adrian Farrel" Cc: "fabien.verhaeghe" ; "LE ROUX=20 Jean-Louis RD-CORE-LAN" ; "Dan Li"=20 ; Sent: Friday, March 30, 2007 1:44 AM Subject: Re: [Pce] Switching type Constraint in PCEP > Hi Fabien and Adrian, > > Looking at the discussion, path computation itself and a protocol > staff such as PCEP are a different thing. I believe, touch upon > by Dan, that our cspf draft is a kind of guideline how to consider > GMPLS-specific constrains including encoding type for path computation. > I hope that the cspf draft help Fabien to understand parameters. > > If you need any help for GMPLS specific extensions, please let me know. > > With best regards, > > Tomo > > > > Adrian Farrel wrote: >> Hi Fabien, >> >>> Reading the generic and inter layer requirement documents it is not >>> clear to me if Switching Type is really specific to inter layer >>> application. >>> As far as I understand inter-layer requirement refers to path >>> computation which result path may comprise multiple layer technologies. >>> Though I understand Switching type is required in this context, it is >>> also >>> required for mono layer path computation in a multi-layer environment >>> (e.g. to computate a Lambda path using a TE Database that contains >>> also TDM TE Links). >>> So it is more a GMPLS specific requirement to me. >> >> I think you are correct. That is, the switching type constraint is >> required in the multi-layer context, but it may have wider applicability. >> >> Provided that the multi-layer work progress quite quickly, I would >> suggest that it is convenient to group all of the protocol extensions >> together. You can then select from the set of optional objects as >> necessary for your application. I would hope that you would provide your >> review input to the multi-layer work to ensure that the protocol >> extensions give you what you need. >> >> On the other hand, if the multi-layer work seems to get stuck or held >> up, then I would understand you pushing to get the "GMPLS-specific" >> extensions done separately. >> >>> Acually it is not clear to me what is the scope of generic and >>> "application specific" requirements. Generic Requirement RFC4657 >>> section 5.1.16 >>> mention Switching and encoding type as "GMPLS specific requirements". >>> Does it mean "GMPLS specific" is "considered as generic? >> >> Hmmm. >> This is a line we have not succeeded in drawing very clearly. >> >> However, where we seem to have arrived is that the PCEP I-D contains the >> protocol definition and "core" functional units. Other units that were >> identified in 4657 (such as XRO, objective funcions, ...) are going into >> seperate I-Ds. Following that model, the GMPLS-specific work definitely >> goes into a separate draft. As above, I am comfortable for that to be in >> the multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to >> help keep the number of I-Ds manageable. >> >>> Concerning the necessity of "encoding type" in PCEP I have to admit >>> that I'm not sure to correctly understand the meaning of this >>> parameter in the GMPLS >>> architecture :-). >> >> I think this puts you in the majority! >> >>> What I understand at least is that it is both an interface and >>> an LSP property, so from this it seems to be required in PCEP. >>> I would be interested to see discussion about encoding type >>> requirement in PCEP cause it may clarify the encoding type meaning to >>> me ;-). >> >> So my view (other will surely correct me :-) is that encoding type is >> only needed where the signal is unpacked for some reason. Typically, >> this only happens at end points, so the PCE function is to ensure that >> the destination interface is capable of decoding the signal and >> delivering the data. In general, it has been considered that the >> destination capabilities are either known to the ingress (guaranteed LSP >> setup success - you wouldn't even bother trying to set up an LSP to >> someone you knew couldn't understand you) or are not known in which case >> the LSP will either succeed or fail (but no amount of re-routing will >> help). Now, it *is* possible that different interfaces on the egress >> have different levels of support for encoding types, but this has >> generally been considered as very advanced and not worth optimising for. >> >> However, recent discussion has suggested that in certain technologies, >> signal regeneration also requires knowledge of the encoding type. This >> would certainly expand the requirement for PCE to know about encoding >> type. I am not sure about the hardware specifics here and perhaps >> someone can enlighten us. >> >> Cheers, >> Adrian >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Apr 12 15:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc5Jp-0003WB-Pq; Thu, 12 Apr 2007 15:50:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc5JR-0002fb-S8; Thu, 12 Apr 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hc5JQ-00009A-EB; Thu, 12 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5C4BD17637; Thu, 12 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hc5Iw-0002av-4d; Thu, 12 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : OSPF protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-ospf-03.txt Pages : 22 Date : 2007-4-12 There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCE), along with some information that can be used for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to discover PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-ospf-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-12144054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-ospf-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-12144054.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Thu Apr 12 20:03:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc9Ge-0003RN-2p; Thu, 12 Apr 2007 20:03:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc9Gc-0003QD-VB; Thu, 12 Apr 2007 20:03:54 -0400 Received: from mail.turinnetworks.com ([63.197.247.126] helo=milan.turin.turinnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc9Gb-00089n-KY; Thu, 12 Apr 2007 20:03:54 -0400 Received: from tnpetmail1.turin.turinnetworks.com ([10.1.1.58]) by milan.turin.turinnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 17:03:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Apr 2007 17:03:52 -0700 Message-ID: <381DCCFA122A3E41AD664D4AB384362612428A@tnpetmail1.turin.turinnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pce-disco-proto-ospf-03.txt Thread-Index: Acd9XIE6iVG94t9kQueXB3rCLBSWvQ== From: "Greg Mirsky" To: , X-OriginalArrivalTime: 13 Apr 2007 00:03:52.0721 (UTC) FILETIME=[3888E810:01C77D5F] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ospf@ietf.org, pce@ietf.org Subject: [Pce] draft-ietf-pce-disco-proto-ospf-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1260366309==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1260366309== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77D5F.382C5215" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77D5F.382C5215 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Editors, I think that wording of chapter 3.3 Flooding Scope can use some = refinement. Currently it reads: " The flooding scope for PCE information advertised through OSPF can = be=20 limited to one or more OSPF areas the PCE belongs to, or can be=20 extended across the entire OSPF routing domain. =20 =20 Note that some PCEs may belong to multiple areas, in which case the=20 flooding scope may comprise these areas. This could be the case for=20 an ABR for instance advertising its PCE information within the=20 backbone area and/or a subset of its attached IGP area(s). " But the scope of OSPFv2 or OSPFv3 Router Information LSA can be either = an Area or Autonomous System, but it can not be several areas. If PCED = TLV needs to be flooded through some but not all areas, the proper = Router Information LSA must be originated by the PCE into each area. And = here I have a question - would PCED TLV MUST be the same in all areas or = it MAY be different? Regards, Greg ------_=_NextPart_001_01C77D5F.382C5215 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-pce-disco-proto-ospf-03.txt

Dear Editors,
I think that wording of chapter 3.3 Flooding Scope can use some = refinement. Currently it reads:
"   The flooding scope for PCE information advertised = through OSPF can be
   limited to one or more OSPF areas the PCE belongs to, or = can be
   extended across the entire OSPF routing domain. 
   
   Note that some PCEs may belong to multiple areas, in which = case the
   flooding scope may comprise these areas. This could be the = case for
   an ABR for instance advertising its PCE information within = the
   backbone area and/or a subset of its attached IGP area(s). = "

But the scope of OSPFv2 or OSPFv3 Router Information LSA can be either = an Area or Autonomous System, but it can not be several areas. If PCED = TLV needs to be flooded through some but not all areas, the proper = Router Information LSA must be originated by the PCE into each area. And = here I have a question - would PCED TLV MUST be the same in all areas or = it MAY be different?

Regards,
Greg

------_=_NextPart_001_01C77D5F.382C5215-- --===============1260366309== 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 --===============1260366309==-- From pce-bounces@lists.ietf.org Thu Apr 12 20:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc9QD-00027J-PE; Thu, 12 Apr 2007 20:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc9QC-00021U-49; Thu, 12 Apr 2007 20:13:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc9QA-0004PB-QE; Thu, 12 Apr 2007 20:13:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2007 20:13:47 -0400 X-IronPort-AV: i="4.14,405,1170651600"; d="scan'208,217"; a="57514026:sNHT77559096" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3D0DkPm031586; Thu, 12 Apr 2007 20:13:46 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3D0DkGd006785; Fri, 13 Apr 2007 00:13:46 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 20:13:45 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 20:13:38 -0400 In-Reply-To: <381DCCFA122A3E41AD664D4AB384362612428A@tnpetmail1.turin.turinnetworks.com> References: <381DCCFA122A3E41AD664D4AB384362612428A@tnpetmail1.turin.turinnetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <446E8213-13D5-4789-ACC3-4FB0B9E9DA04@cisco.com> From: JP Vasseur Date: Thu, 12 Apr 2007 20:13:23 -0400 To: "Greg Mirsky" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Apr 2007 00:13:40.0974 (UTC) FILETIME=[972930E0:01C77D60] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3449; t=1176423226; x=1177287226; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20draft-ietf-pce-disco-proto-ospf-03.txt |Sender:=20 |To:=20=22Greg=20Mirsky=22=20; bh=TQlxtInDlMBDw+Ik5yO9DdQmdDf+o/Lkur7cHPDM1co=; b=yIKjgFaP7fn8rPOSCGpMj+RBwkjgVmOAvVL8mdtJ2uLCGwkBn/55tk4C2sSuzVGTBWZ3LWte XQk9oowUM8iKahn5iLEPG3aXI0nKH899dQXMkFhzq2enu2/sFzZ4NRxA; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ospf@ietf.org, pce@ietf.org, jpv@cisco.com Subject: [Pce] Re: draft-ietf-pce-disco-proto-ospf-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1845234720==" Errors-To: pce-bounces@lists.ietf.org --===============1845234720== Content-Type: multipart/alternative; boundary=Apple-Mail-21-547508422 --Apple-Mail-21-547508422 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Apr 12, 2007, at 8:03 PM, Greg Mirsky wrote: > Dear Editors, > I think that wording of chapter 3.3 Flooding Scope can use some > refinement. Currently it reads: > " The flooding scope for PCE information advertised through OSPF > can be > limited to one or more OSPF areas the PCE belongs to, or can be > extended across the entire OSPF routing domain. > > Note that some PCEs may belong to multiple areas, in which case the > flooding scope may comprise these areas. This could be the case for > an ABR for instance advertising its PCE information within the > backbone area and/or a subset of its attached IGP area(s). " > > But the scope of OSPFv2 or OSPFv3 Router Information LSA can be > either an Area or Autonomous System, but it can not be several > areas. If PCED TLV needs to be flooded through some but not all > areas, the proper Router Information LSA must be originated by the > PCE into each area. And here I have a question - would PCED TLV > MUST be the same in all areas or it MAY be different? If a PCE acting as an ABR (attached to area 0 and area 1) originates an LSA Type 10 in area 0 and area 1, each LSA could be different indeed. Thanks. JP. > > Regards, > Greg > > > > > > > > > > > > > > > --Apple-Mail-21-547508422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Apr 12, 2007, = at 8:03 PM, Greg Mirsky wrote:

Dear Editors,
I think that wording of chapter 3.3 = Flooding Scope can use some refinement. Currently it reads:
"=A0=A0 = The flooding scope for PCE information advertised through OSPF can = be
=A0=A0 limited to one or more OSPF areas the PCE belongs to, or = can be
=A0=A0 extended across the entire OSPF routing domain.=A0
= =A0=A0=A0
=A0=A0 Note that some PCEs may belong to multiple areas, = in which case the
=A0=A0 flooding scope may comprise these areas. = This could be the case for
=A0=A0 an ABR for instance advertising = its PCE information within the
=A0=A0 backbone area and/or a subset = of its attached IGP area(s). "

But the scope of OSPFv2 or = OSPFv3 Router Information LSA can be either an Area or Autonomous = System, but it can not be several areas. If PCED TLV needs to be flooded = through some but not all areas, the proper Router Information LSA must = be originated by the PCE into each area. And here I have a question - = would PCED TLV MUST be the same in all areas or it MAY be = different?

If a PCE acting as an ABR = (attached to area 0 and area 1) originates an LSA Type 10 in area 0 and = area 1, each LSA could be different indeed.

Thanks.

JP.


Regards,
Greg


=











=

= --Apple-Mail-21-547508422-- --===============1845234720== 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 --===============1845234720==-- From pce-bounces@lists.ietf.org Fri Apr 13 04:42:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHM4-0000L5-VA; Fri, 13 Apr 2007 04:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHM3-0000Kt-O6; Fri, 13 Apr 2007 04:42:03 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcHM2-000139-8q; Fri, 13 Apr 2007 04:42:03 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:41:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Apr 2007 10:41:51 +0200 Message-ID: In-Reply-To: <381DCCFA122A3E41AD664D4AB384362612428A@tnpetmail1.turin.turinnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pce-disco-proto-ospf-03.txt Thread-Index: Acd9XIE6iVG94t9kQueXB3rCLBSWvQASpjCg References: <381DCCFA122A3E41AD664D4AB384362612428A@tnpetmail1.turin.turinnetworks.com> From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Greg Mirsky" , X-OriginalArrivalTime: 13 Apr 2007 08:41:51.0413 (UTC) FILETIME=[94E0F650:01C77DA7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: ospf@ietf.org, pce@ietf.org Subject: [Pce] RE: draft-ietf-pce-disco-proto-ospf-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0345371399==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0345371399== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77DA7.950556FB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77DA7.950556FB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, =20 =20 ________________________________ De : Greg Mirsky [mailto:gmirsky@turinnetworks.com]=20 Envoy=E9 : vendredi 13 avril 2007 02:04 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; jpv@cisco.com Cc : pce@ietf.org; ospf@ietf.org Objet : draft-ietf-pce-disco-proto-ospf-03.txt =09 =09 Dear Editors, I think that wording of chapter 3.3 Flooding Scope can use some = refinement. Currently it reads: " The flooding scope for PCE information advertised through OSPF can = be limited to one or more OSPF areas the PCE belongs to, or can be extended across the entire OSPF routing domain.=20 =20 Note that some PCEs may belong to multiple areas, in which case the flooding scope may comprise these areas. This could be the case for an ABR for instance advertising its PCE information within the backbone area and/or a subset of its attached IGP area(s). " =09 But the scope of OSPFv2 or OSPFv3 Router Information LSA can be either = an Area or Autonomous System, but it can not be several areas. If PCED = TLV needs to be flooded through some but not all areas, the proper = Router Information LSA must be originated by the PCE into each area. =20 Yes, the ABR can generate a type 10 Router Info LSA in each target = area. And here I have a question - would PCED TLV MUST be the same in all = areas or it MAY be different?=20 They may differ. Regards, JL =20 =09 Regards, Greg =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C77DA7.950556FB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-pce-disco-proto-ospf-03.txt
Hi Greg,
 
 

De : Greg Mirsky=20 [mailto:gmirsky@turinnetworks.com]
Envoy=E9 : vendredi = 13 avril=20 2007 02:04
=C0 : LE ROUX Jean-Louis RD-CORE-LAN;=20 jpv@cisco.com
Cc : pce@ietf.org;=20 ospf@ietf.org
Objet :=20 draft-ietf-pce-disco-proto-ospf-03.txt

Dear Editors,
I think that wording of chapter 3.3 = Flooding=20 Scope can use some refinement. Currently it reads:
"   = The=20 flooding scope for PCE information advertised through OSPF can=20 be
   limited to one or more OSPF areas the PCE belongs = to, or=20 can be
   extended across the entire OSPF routing=20 domain. 
   
   Note that some = PCEs may=20 belong to multiple areas, in which case the
   flooding = scope may=20 comprise these areas. This could be the case for
   an = ABR for=20 instance advertising its PCE information within the
   = backbone=20 area and/or a subset of its attached IGP area(s). "

But the = scope of=20 OSPFv2 or OSPFv3 Router Information LSA can be either an Area or = Autonomous=20 System, but it can not be several areas. If PCED TLV needs to be = flooded=20 through some but not all areas, the proper Router Information LSA must = be=20 originated by the PCE into each area.  

Yes, the=20 ABR can generate a type 10 Router Info LSA in each target=20 area.

 And = here I have a=20 question - would PCED TLV MUST be the same in all areas or it MAY be=20 different? 

 They = may=20 differ.

Regards,

JL

 

Regards,
Greg

<= BR>











------_=_NextPart_001_01C77DA7.950556FB-- --===============0345371399== 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 --===============0345371399==-- From pce-bounces@lists.ietf.org Fri Apr 20 14:29:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hexr0-0006dl-35; Fri, 20 Apr 2007 14:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hexqy-0006Xp-PN for pce@lists.ietf.org; Fri, 20 Apr 2007 14:29:04 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hexqx-0002Lp-8c for pce@lists.ietf.org; Fri, 20 Apr 2007 14:29:04 -0400 Received: (qmail invoked by alias); 20 Apr 2007 18:29:02 -0000 Received: from host176.natpool.mwn.de (EHLO r049048.osh.swh.mhn.de) [138.246.7.176] by mail.gmx.net (mp034) with SMTP; 20 Apr 2007 20:29:02 +0200 X-Authenticated: #19887475 X-Provags-ID: V01U2FsdGVkX190phhopXt0hh2Zv0lLBlMke7Aahc2EtcbhuADBl5 5KlGq6fWnlLxnY From: Dennis Aristow <_den@gmx.de> To: pce@lists.ietf.org User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Disposition: inline Date: Fri, 20 Apr 2007 20:29:00 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200704202029.01041._den@gmx.de> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Pce] CLOSE object X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hello, all I'm currently implementing the pcep-protocol based on draft07. I have got 2 questions to the CLOSE object. 1) In draft where the CLOSE object is described, it is said that there are 4 bits for each field "Reason" and "Flags", but if you see the figure 22, there are 8 bits for each of these fields. 2) There are no description how to pad "Flags" field. Thanks for your answers _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Apr 20 15:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeytO-0003hD-4H; Fri, 20 Apr 2007 15:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeytL-0003h8-Uc for pce@ietf.org; Fri, 20 Apr 2007 15:35:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeytK-0004gR-B8 for pce@ietf.org; Fri, 20 Apr 2007 15:35:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2007 15:35:34 -0400 X-IronPort-AV: i="4.14,433,1170651600"; d="scan'208"; a="119089196:sNHT39766586" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3KJZY9I030723 for ; Fri, 20 Apr 2007 15:35:34 -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 l3KJZKGp022987 for ; Fri, 20 Apr 2007 19:35:33 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 15:35:26 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 15:35:26 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Fri, 20 Apr 2007 15:35:17 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Apr 2007 19:35:26.0449 (UTC) FILETIME=[0BC0D610:01C78383] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=179; t=1177097734; x=1177961734; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Draft=20PCE=20WG=20IETF-68=20minutes |Sender:=20 |To:=20pce@ietf.org; bh=0yxhoecpoAymKIlgdYTDFhJWxRnpdcQV1J61y4nv1UI=; b=k8igyYF8fJScY2vwL5k0jIUgG1U+AtEPrPrVQYd4+ghXi9le4fIvVFRhahtBQImKRWemp6Or /KcVm2R+LJt1FlLvs7ZPonRy9/N70DfAGVA0ZEJ9zvtl+O/cHzpKf6H4; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Pce] Draft PCE WG IETF-68 minutes X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Dear WG, The WG meeting minutes are available: http://www3.ietf.org/ proceedings/07mar/minutes/pce.txt Let us know by April 27 is you have any comment. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Apr 22 10:22:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfcxh-00044T-Gs; Sun, 22 Apr 2007 10:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfcxg-00044H-AI for pce@ietf.org; Sun, 22 Apr 2007 10:22:44 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfcxe-0005A6-Ns for pce@ietf.org; Sun, 22 Apr 2007 10:22:44 -0400 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1Hfcxd-0004hq-Pg for pce@ietf.org; Sun, 22 Apr 2007 14:22:41 +0000 Received: from your029b8cecfe ([217.158.132.135] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Apr 2007 15:22:39 +0100 Message-ID: <095b01c784e9$a832dae0$6f849ed9@your029b8cecfe> From: "Adrian Farrel" To: References: <04d301c744d2$7c9eeec0$76849ed9@your029b8cecfe> Date: Sun, 22 Apr 2007 15:10:04 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 22 Apr 2007 14:22:40.0526 (UTC) FILETIME=[AF37BAE0:01C784E9] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Pce] Path Key draft to WG status X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, After extreme caution, a poll on the list in Jan/Feb, and testing the waters in Prague, this I-D will become a working group draft. Note that both WG chairs are authors of this work, although Rich Bradford is the Editor. If you have any problems with this decision, please raise it on the list and copy the ADs. Rich, please resubmit the I-D as draft-ietf-pce-path-key-00.txt with only the following changes: - File name changes to draft-ietf-pce-path-key-00.txt in all places in the document - Title moves to above filename on document header - Date changes - Anything necessary to pass idnits (http://tools.ietf.org/tools/idnits/) Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Apr 25 03:53:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcJz-0007MF-2g; Wed, 25 Apr 2007 03:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcJx-0007MA-5A for pce@ietf.org; Wed, 25 Apr 2007 03:53:49 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee01s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgcJu-0004DF-Os for pce@ietf.org; Wed, 25 Apr 2007 03:53:49 -0400 Received: from wpwuee01s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id AC8B7F4127 for ; Wed, 25 Apr 2007 09:53:45 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 98F36F411A for ; Wed, 25 Apr 2007 09:53:45 +0200 (CEST) Message-ID: <003d01c7870e$c262df60$15600337@AOFR11476> From: "fabien.verhaeghe" To: Date: Wed, 25 Apr 2007 09:53:05 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Subject: [Pce] PCEP Object Common header P flag 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="===============0269412564==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0269412564== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C7871F.85748390" This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C7871F.85748390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, Quick question about PCEP section 7.1 Common object header: "If the PCE does not understand an object with the P flag set or understands the object but decides to ignore the object, the entire PCEP message MUST be rejected and the PCE MUST send a PCErr message with Error-Type=3D"Unknown Object" or "Not supported Object"." Why rejecting the entire PCReq message? Why not just rejecting the = request that contains the=20 unknown/not supported object and send a PCErr with the rejected Request = Id? Regards Fabien ------=_NextPart_000_003A_01C7871F.85748390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,
 
Quick question about PCEP section 7.1 = Common object=20 header:

   "If the PCE does not = understand an=20 object with the P flag set or
   understands the object but = decides=20 to ignore the object, the entire
   PCEP message MUST be = rejected=20 and the PCE MUST send a PCErr message
   with = Error-Type=3D"Unknown=20 Object" or "Not supported Object"."
 
Why rejecting the entire PCReq message? = Why not=20 just rejecting the request that contains the
unknown/not supported object and send a = PCErr with=20 the rejected Request Id?
 
Regards
Fabien
 
------=_NextPart_000_003A_01C7871F.85748390-- --===============0269412564== 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 --===============0269412564==-- From pce-bounces@lists.ietf.org Wed Apr 25 08:32:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HggfT-00046R-7u; Wed, 25 Apr 2007 08:32:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HggfS-00046M-Qy for pce@ietf.org; Wed, 25 Apr 2007 08:32:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HggfS-0001ET-Gn for pce@ietf.org; Wed, 25 Apr 2007 08:32:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2007 08:32:19 -0400 X-IronPort-AV: i="4.14,450,1170651600"; d="scan'208,217"; a="58568940:sNHT74681828" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3PCWI2m020367; Wed, 25 Apr 2007 08:32:18 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3PCWHGf012665; Wed, 25 Apr 2007 12:32:18 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 08:32:17 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 08:32:17 -0400 In-Reply-To: <003d01c7870e$c262df60$15600337@AOFR11476> References: <003d01c7870e$c262df60$15600337@AOFR11476> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <228B679F-9CBC-47F3-8B8B-EFCC25C9E7C5@cisco.com> From: JP Vasseur Subject: Re: [Pce] PCEP Object Common header P flag Date: Wed, 25 Apr 2007 08:32:11 -0400 To: "fabien.verhaeghe" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Apr 2007 12:32:17.0463 (UTC) FILETIME=[C2CDC470:01C78735] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3608; t=1177504338; x=1178368338; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20PCEP=20Object=20Common=20header=20P=20flag |Sender:=20 |To:=20=22fabien.verhaeghe=22=20; bh=5MIMCeArFr4JrombuqJ/homKfim8o3ZSpz0l91h60pQ=; b=QH92/lLg9fenbixfpfSQo5s9Fjfap6aPtH1xzx01/zsRPLLU2aDFhOrvazLTCBGKJ5neA5SL 1u+Hv2OVx31hzFimYW7lDeHXOFiAP3PJp15E2TF86465rc4Xsp8TfXYG; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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="===============1926202418==" Errors-To: pce-bounces@lists.ietf.org --===============1926202418== Content-Type: multipart/alternative; boundary=Apple-Mail-8--518847277 --Apple-Mail-8--518847277 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Apr 25, 2007, at 3:53 AM, fabien.verhaeghe wrote: > Hello All, > > Quick question about PCEP section 7.1 Common object header: > > "If the PCE does not understand an object with the P flag set or > understands the object but decides to ignore the object, the entire > PCEP message MUST be rejected and the PCE MUST send a PCErr message > with Error-Type="Unknown Object" or "Not supported Object"." > > Why rejecting the entire PCReq message? Why not just rejecting the > request that contains the > unknown/not supported object and send a PCErr with the rejected > Request Id? > You mean in case the message would contain more than one requests ? Thanks. JP. > > Regards > Fabien > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-8--518847277 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

On Apr 25, = 2007, at 3:53 AM, fabien.verhaeghe wrote:

=
Hello All,
=A0
Quick question about PCEP section 7.1 Common object = header:

=A0=A0 "If = the PCE does not understand an object with the P flag set or
=A0=A0 = understands the object but decides to ignore the object, the = entire
=A0=A0 PCEP message MUST be rejected and the PCE MUST send a = PCErr message
=A0=A0 with Error-Type=3D"Unknown Object" or "Not = supported Object"."
=A0
Why = rejecting the entire PCReq message? Why not just rejecting the request = that contains the
unknown/not supported object and send a PCErr with the = rejected Request Id?


You mean in case the = message would contain more than one requests ?

Thanks.

JP.

=A0
Regards
Fabien
=A0
Pce mailing list
=

= --Apple-Mail-8--518847277-- --===============1926202418== 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 --===============1926202418==-- From pce-bounces@lists.ietf.org Wed Apr 25 18:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgqQa-0004rI-3Z; Wed, 25 Apr 2007 18:57:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgqQY-0004rC-Kn for pce@ietf.org; Wed, 25 Apr 2007 18:57:34 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgqQW-00071R-Q5 for pce@ietf.org; Wed, 25 Apr 2007 18:57:34 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH2003VOT3TRM@usaga01-in.huawei.com> for pce@ietf.org; Wed, 25 Apr 2007 15:57:29 -0700 (PDT) Received: from Lee736821 ([10.124.12.82]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JH200021T3PSC@usaga01-in.huawei.com> for pce@ietf.org; Wed, 25 Apr 2007 15:57:29 -0700 (PDT) Date: Wed, 25 Apr 2007 17:57:25 -0500 From: Young Lee To: pce@ietf.org Message-id: <000001c7878d$17b5aff0$520c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AceHjRdhNdxfXbhvSpKgbRXcSQAaSQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: Subject: [Pce] I-D ACTION:draft-lee-pce-global-concurrent-optimization-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0306710783==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0306710783== Content-type: multipart/alternative; boundary="Boundary_(ID_YHse1qIQZqAY7SdHGZt6bQ)" This is a multi-part message in MIME format. --Boundary_(ID_YHse1qIQZqAY7SdHGZt6bQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, A new version (03) of PCE Global Concurrent Optimization (GCO) draft has been published as below. Manageability Section has been updated with the revision. Any comments and suggestions are appreciated. Thanks. Young ---------------------------------------------------------------------------- --------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-lee-pce-global-concurrent-optimization-03.txt Pages : 32 Date : 2007-4-25 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A Global Concurrent Optimization is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all LSPs. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent path computation application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimiza tion-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lee-pce-global-concurrent-optimization-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_YHse1qIQZqAY7SdHGZt6bQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

A new version (03) of PCE Global Concurrent Optimization (GCO) draft has been published as below.  

 

Manageability Section has been updated with the revision. Any comments and suggestions are appreciated. Thanks.

 

Young

 

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

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 
 
               Title                        : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization
               Author(s)                : Y. Lee, et al.
               Filename                : draft-lee-pce-global-concurrent-optimization-03.txt
               Pages                    : 32
               Date                       : 2007-4-25
               
The Path Computation Element (PCE) is a network component,
   application, or node that is capable of performing path computations
   at the request of Path Computation Clients (PCCs).  The PCE is
   applied in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
   determine the routes of Label Switched Paths (LSPs) through the
   network.  The Path Computation Element Communication Protocol (PCEP)
   is specified for communications between PCCs and PCEs, and between
   cooperating PCEs.
 
   When computing or re-optimizing the routes of a set of LSPs through a
   network it may be advantageous to perform bulk path computations in
   order to avoid blocking problems and to achieve more optimal network-
   wide solutions.  Such bulk optimization is termed Global Concurrent
   Optimization (GCO).  A Global Concurrent Optimization is able to
   simultaneously consider the entire topology of the network and the
   complete set of existing LSPs, and their respective constraints, and
   look to optimize or re-optimize the entire network to satisfy all
   constraints for all LSPs.
 
   This document provides application-specific requirements and the PCEP
   extensions in support of a global concurrent path computation
   application.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-03.txt
 
To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.
 
Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-lee-pce-global-concurrent-optimization-03.txt".
 
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 
Internet-Drafts can also be obtained by e-mail.
 
Send a message to:
               mailserv at ietf.org.
In the body type:
               "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-03.txt".
               
NOTE:    The mail server at ietf.org can return the document in
               MIME-encoded form by using the "mpack" utility.  To use this
               feature, insert the command "ENCODING mime" before the "FILE"
               command.  To decode the response(s), you will need "munpack" or
               a MIME-compliant mail reader.  Different MIME-compliant mail readers
               exhibit different behavior, especially when dealing with
               "multipart" MIME messages (i.e. documents which have been split
               up into multiple messages), so check your local documentation on
               how to manipulate these messages.
 
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-03.txt> 

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

 

--Boundary_(ID_YHse1qIQZqAY7SdHGZt6bQ)-- --===============0306710783== 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 --===============0306710783==-- From pce-bounces@lists.ietf.org Thu Apr 26 02:26:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgxRJ-0007Er-IY; Thu, 26 Apr 2007 02:26:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgxRH-0007Ej-K3 for pce@ietf.org; Thu, 26 Apr 2007 02:26:47 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee03s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgxRF-0000RK-VK for pce@ietf.org; Thu, 26 Apr 2007 02:26:47 -0400 Received: from wpwuee03s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee03s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 07109114012; Thu, 26 Apr 2007 08:26:45 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee03s.mail.mercury.atosorigin.com (Postfix) with ESMTP id E405A114006; Thu, 26 Apr 2007 08:26:44 +0200 (CEST) Message-ID: <006601c787cb$c4c8e700$15600337@AOFR11476> From: "fabien.verhaeghe" To: "JP Vasseur" References: <8A700039-B848-4CB0-9AD3-62BD86B61240@cisco.com> Subject: Re: [Pce] PCEP Object Common header P flag Date: Thu, 26 Apr 2007 08:26:04 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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="===============1804358653==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1804358653== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C787DC.87CC3350" This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C787DC.87CC3350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Hi,=20 > > >On Apr 25, 2007, at 3:53 AM, fabien.verhaeghe wrote: > > >>Hello All, >> >>Quick question about PCEP section 7.1 Common object header: >> >> "If the PCE does not understand an object with the P flag set or >> understands the object but decides to ignore the object, the entire >> PCEP message MUST be rejected and the PCE MUST send a PCErr message >> with Error-Type=3D"Unknown Object" or "Not supported Object"." >> >>Why rejecting the entire PCReq message? Why not just rejecting the = request that contains the=20 >>unknown/not supported object and send a PCErr with the rejected = Request Id? >> >> > > >You mean in case the message would contain more than one requests ? > Yes exactly. I understand it makes sense for synchronized requests listed in an SVEC = object. But for independent requests I'm not sure why we should reject all = requests because one of them has an "unknown/not supported" object. > >Thanks. > > >JP. >> >> >> >>Regards >>Fabien=20 ------=_NextPart_000_0063_01C787DC.87CC3350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>Hi,
>
>
>On Apr = 25, 2007, at=20 3:53 AM, fabien.verhaeghe wrote:
>
>
>>Hello=20 All,
>>
>>Quick question about PCEP section 7.1 Common = object=20 header:
>>
>>   "If the PCE does not = understand an=20 object with the P flag set or
>>   understands the = object but=20 decides to ignore the object, the entire
>>   PCEP = message=20 MUST be rejected and the PCE MUST send a PCErr = message
>>  =20 with Error-Type=3D"Unknown Object" or "Not supported=20 Object"."
>>
>>Why rejecting the entire PCReq message? = Why not=20 just rejecting the request that contains the
>>unknown/not = supported=20 object and send a PCErr with the rejected Request=20 Id?
>>
>>
 
>
>
>You mean in case = the message=20 would contain more than one requests ?
>
 
Yes exactly.
I understand it makes = sense for=20 synchronized requests listed in an SVEC object.
But for independent = requests=20 I'm not sure why we should reject all requests because one
of them = has an=20 "unknown/not supported" object.
 

>
>Thanks.
>
>
>JP.
>>>>
>>
>>Regards
>>Fabien=20
 
------=_NextPart_000_0063_01C787DC.87CC3350-- --===============1804358653== 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 --===============1804358653==--