From pce-bounces@lists.ietf.org Thu Feb 01 00:49:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCUoq-0001Iw-7j; Thu, 01 Feb 2007 00:49:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCUoo-0001Im-6v for pce@ietf.org; Thu, 01 Feb 2007 00:49:10 -0500 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCUoh-0005g0-Kc for pce@ietf.org; Thu, 01 Feb 2007 00:49:10 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 749F836006A; Thu, 1 Feb 2007 11:18:58 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid 3676D36005B; Thu, 1 Feb 2007 11:18:58 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 11:18:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Date: Thu, 1 Feb 2007 11:18:46 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt thread-index: AcdFcNOSI1iZzixqSEW2yVgq/AMZHQATsvjg From: "Vijayanand C - TLS, Chennai." To: "JP Vasseur" X-OriginalArrivalTime: 01 Feb 2007 05:48:58.0059 (UTC) FILETIME=[AA8C81B0:01C745C4] X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-27.0053 TC:1F TRN:95 TV:3.6.1039(14970.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: bafbea1cda3c7af8b3569c0286e44c21 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="===============0859642449==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0859642449== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C745C4.A6CBCEDA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C745C4.A6CBCEDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are you suggesting that BGP should propagate all possible next-hops/As paths and regular path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ? =20 The inter-AS TE link information can be made aware only to the ASes on either side of the inter-AS link by the IGP. It may not be possible to propagate it beyond that ( or can it ?). So some of the possible AS paths found by BGP( if we propagate all next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of violation of some TE constraint.=20 =20 In our proposal we can pick the paths which are really feasible, since we have the inter-AS graph, and then invoke methods like BRPC=20 =20 Regards Vijay=20 =20 =20 =20 =20 -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Thursday, February 01, 2007 1:19 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 Hi, =20 On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: =20 Hello all, We have submitted the following I-D, please send in your comments/suggestions =20 * speaking as a technical contributor * =20 In [BRPC], a method to optimally compute a inter-domain TE=20 path for MPLS and GMPS LSPs using the PCE architecture detailed in=20 [PCE_ARCH] is described. However the method described requires the=20 list of Autonomous systems or domains to be determined apriori.=20 Determining the list of ASes/domains to be traversed to reach a=20 destination, satisfying the TE constraints is non-trivial. It=20 requires knowledge of the inter-AS connectivity and the TE=20 characteristics of the inter-AS links along with the knowledge of=20 the available paths within each of the ASes/domains. BGP contains=20 information on the list of ASes to be traversed to reach a=20 destination, however BGP route selection and decision process=20 truncates most of the feasible paths, and it also does not carry=20 the TE characteristics of the inter-AS links and path availability=20 within a domain. =20 =20 What does prevent you from relying on BGP to provide you all possible paths toward=20 a specific destination skipping the regular path selection process for specific routes (see proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE link could easily be obtained via the IGP with minor additions. =20 This is in my opinion a fundamental question that must first be addressed before=20 moving forward. =20 Thanks. =20 JP. =20 Regards Vijay =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, January 23, 2007 2:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =20 =20 Title : A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-bgp-interas-te-path-01.txt Pages : 26 Date : 2007-1-22 =20 The ability to compute an optimal path for setting up Traffic=20 engineering Label Switched Paths spanning multiple autonomous=20 systems managed by different operators has been a key requirement in=20 MPLS and GMPLS networks. This document specifies a method of=20 computing inter-AS paths consisting of a list of ASes to be=20 traversed and a list of TE-Tunnels to be traversed in each AS. The=20 method described here uses BGP speakers in the PCEs of each AS to=20 distribute the inter-AS connectivity information and the TE-Tunnels=20 in each AS to its neighbors to facilitate the construction of an=20 inter-AS topology graph which can be used for computing inter-AS paths. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-interas-te -path-01.txt =20 =20 =20 DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- =20 The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. =20 ------------------------------------------------------------------------ ----------------------------------------------- =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 ------_=_NextPart_001_01C745C4.A6CBCEDA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are you suggesting that  BGP = should propagate all possible next-hops/As paths and regular path selection = process avoided for all prefixes which can be destinations of inter-AS TE = tunnels ?

 

The inter-AS TE link information = can be made aware only to the ASes on either side of the inter-AS link by the = IGP. It may not be possible to propagate it beyond that ( or can it = ?).

So some of the possible AS paths = found by BGP( if we propagate all next-hops/aspaths in bgp) may not be worth trying = for path setup (by BRPC) because of violation of some TE constraint. =

 

In our proposal we can pick the = paths which are really feasible, since we have the inter-AS graph, and then = invoke methods like BRPC

 

Regards

Vijay

 

 

 

 

-----Original = Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Thursday, February = 01, 2007 1:19 AM
To: Vijayanand C - TLS, = Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: = I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =

 

Hi,

 

On Jan 25, 2007, at 9:32 AM, Vijayanand C - = TLS, Chennai. wrote:



 

Hello all,

We have submitted the following I-D, please = send in your

comments/suggestions

 

* speaking as a technical contributor = *

 

  =  In [BRPC], a method to optimally compute a inter-domain = TE 

   path for MPLS and GMPS LSPs using the PCE architecture detailed = in 

   [PCE_ARCH] is described. However the method described requires = the 

   list of Autonomous systems or domains to be determined = apriori. 

   Determining the list of ASes/domains to be traversed to reach = a 

   destination, satisfying the TE constraints is non-trivial. = It 

   requires knowledge of the inter-AS connectivity and the = TE 

   characteristics of the inter-AS links along with the knowledge = of 

   the available paths within each of the ASes/domains. BGP = contains 

   information on the list of ASes to be traversed to reach = a 

   destination, however BGP route selection and decision = process 

   truncates most of the feasible paths, and it also does not = carry 

   the TE characteristics of the inter-AS links and path = availability 

   within a domain.  

 

What does prevent you from relying on BGP to = provide you all possible paths toward 

a specific destination skipping the regular = path selection process for specific routes (see

proposals made in the past) and then use BRPC = as currently specified? The Inter-AS TE

link could easily be obtained via the IGP = with minor additions.

 

This is in my opinion a fundamental question = that must first be addressed before 

moving forward.

 

Thanks.

 

JP.



 

Regards

Vijay

 

-----Original Message-----

From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org<= /a>] 

Sent: Tuesday, January 23, 2007 2:20 = AM

Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt 

 

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

directories.

 

 

       &nbs= p;    Title        &n= bsp;         : A BGP based method to compute inter-AS Traffic

engineering Label Switched Paths with = PCE

       &nbs= p;    Author(s)        &n= bsp; : C. Vijayanand, S. Bhattacharya

       &nbs= p;    Filename        &n= bsp;  :

draft-vijay-somen-pce-bgp-interas-te-path-01.t= xt

       &nbs= p;    Pages        &n= bsp;      : 26

       &nbs= p;    Date        &n= bsp;        : 2007-1-22

       &nbs= p;   

The ability to compute an optimal path for = setting up Traffic 

   engineering Label Switched Paths spanning multiple autonomous 

   systems managed by different operators has been a key requirement in 

   MPLS and GMPLS networks. This document specifies a method of 

   computing inter-AS paths consisting of a list of ASes to be 

   traversed and a list of TE-Tunnels to be traversed in each AS. The 

   method described here uses BGP speakers in the PCEs of each AS to 

   distribute the inter-AS connectivity information and the TE-Tunnels 

   in each AS to its neighbors to facilitate the construction of an 

   inter-AS topology graph which can be used for computing inter-AS

    paths.

 

A URL for this Internet-Draft = is:

-path-01.txt

 

 

 

DISCLAIMER:

----------------------------------------------= -------------------------------------------------------------------------=

 

The contents of this e-mail and any = attachment(s) are confidential and intended for the named recipient(s) = only.

It shall not attach any liability on the = originator or HCL or its affiliates. Any views or opinions presented in 

this email are solely those of the author and = may not necessarily reflect the opinions of HCL or its = affiliates.

Any form of reproduction, dissemination, = copying, disclosure, modification, distribution and / or publication of 

this message without the prior written = consent of the author of this e-mail is strictly prohibited. If you have 

received this email in error please delete it = and notify the sender immediately. Before opening any mail and 

attachments please check them for viruses and = defect.

 

----------------------------------------------= -------------------------------------------------------------------------=

 

______________________________________________= _

Pce mailing list

 

------_=_NextPart_001_01C745C4.A6CBCEDA-- --===============0859642449== 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 --===============0859642449==-- From pce-bounces@lists.ietf.org Thu Feb 01 14:58:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCi4k-0006yo-B4; Thu, 01 Feb 2007 14:58:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCi4i-0006yc-PR for pce@ietf.org; Thu, 01 Feb 2007 14:58:28 -0500 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 1HCi4e-0002Om-CF for pce@ietf.org; Thu, 01 Feb 2007 14:58:28 -0500 Received: from clavin.turin.turinnetworks.com ([10.1.1.33]) by milan.turin.turinnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 11:58:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Date: Thu, 1 Feb 2007 11:58:52 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Thread-Index: AcdE6ZYKEszcspqZRmWtx7gJ2monJABTn7lg From: "Greg Mirsky" To: "Zhang Renhai" , , X-OriginalArrivalTime: 01 Feb 2007 19:58:53.0069 (UTC) FILETIME=[65F183D0:01C7463B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Dear Zhang, I have couple questions related to Link ID of inter-AS link. According = to the document it is the Router ID of Remote ASBR. My question: - as I understand the mechanism of how TE information for links R6-R9 = and R8-R10 is populated into R5's TE DB is outside the scope of this = document. I this mechanism is not IGP but EGP (BGP), then what is the = benefit to introduce new LSA in IGP (OSPF) and not use exisitng = mechanisms. Regards, Greg PS. I think that OSPF WG needs to be informed as well. -----Original Message----- From: Zhang Renhai [mailto:zhangrenhai@huawei.com] Sent: Tuesday, January 30, 2007 7:38 PM To: ccamp@ops.ietf.org; pce@ietf.org Subject: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Hi, allWe have just submitted the following draft in which we describe = some problemsin inter-AS TE scenarios and the corresponding OSPF = extension is introduced.PCE environment is also considerd in this I-d so = I'd also like pce working groupto pay attention to it.we'd highly = appreciate your comments.Thanks a lot,Zhang Renhai & Mach A New = Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : OSPF Extensions in Support of Inter-AS (G)MPLS TE=20 Author(s) : M. Chen, R. Zhang Filename : draft-chen-ccamp-ospf-interas-te-extension-00.txt Pages : 9 Date : 2007-1-30 =09 This document describes extensions to the OSPF to support inter-AS=20 Traffic engineering (TE). It defines OSPF extensions for the flooding = of inter-AS links information which can be used to perform inter-AS=20 path computation.=20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-exte= nsion-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body = of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-chen-ccamp-ospf-interas-te-extension-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-chen-ccamp-ospf-interas-te-extension-00.txt". =09 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. =20 _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ 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 Feb 01 20:15:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCn12-00029c-0x; Thu, 01 Feb 2007 20:15:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCn0z-000283-QR; Thu, 01 Feb 2007 20:14:57 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCn0y-0003fb-0U; Thu, 01 Feb 2007 20:14:57 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCT00B10A3HDW@szxga02-in.huawei.com>; Fri, 02 Feb 2007 09:14:06 +0800 (CST) Received: from M55527 ([10.111.12.91]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JCT000B2A3GPT@szxga02-in.huawei.com>; Fri, 02 Feb 2007 09:14:05 +0800 (CST) Date: Fri, 02 Feb 2007 09:14:51 +0800 From: Mach Chen To: ccamp , pce Message-id: <004001c74667$8a560ee0$5b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/mixed; boundary="Boundary_(ID_V0EbhgiDZt+cdQsFQkJXtg)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Pce] Fw: I-D ACTION:draft-chen-ccamp-ospf-interas-te-extension-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --Boundary_(ID_V0EbhgiDZt+cdQsFQkJXtg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, We have just submitted the second revision of our I-D,draft-chen-ccamp-ospf-interas-te-extensions. The problem we are trying to solve is how a PCE or entry-point ASBR can select the exit-point ASBR for a TE LSP when it knows (from the ERO) the downstream AS or the downstream ASBR. We believe that IGP needs to flood the inter-AS TE links together with additional information about the neighboring AS and ASBR. The problem arises for both the pd-path and brpc computation methods. We would welcome your input on our problem statement and our proposed solution. Best regards, Mach & Renhai ----- Original Message ----- From: To: Sent: Friday, February 02, 2007 4:50 AM Subject: I-D ACTION:draft-chen-ccamp-ospf-interas-te-extension-01.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : OSPF Extensions in Support of Inter-AS (G)MPLS TE > Author(s) : M. Chen, R. Zhang > Filename : draft-chen-ccamp-ospf-interas-te-extension-01.txt > Pages : 11 > Date : 2007-2-1 > > This document describes extensions to the OSPF protocol to support > Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It > defines OSPF extensions for the flooding of inter-AS links which can > be used to perform inter-AS path computation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-chen-ccamp-ospf-interas-te-extension-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > --Boundary_(ID_V0EbhgiDZt+cdQsFQkJXtg) Content-type: application/octet-stream; name=ATT00043.dat Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ATT00043.dat Content-Type: text/plain Content-ID: <2007-2-1120010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-01.txt --Boundary_(ID_V0EbhgiDZt+cdQsFQkJXtg) Content-type: text/plain; name=draft-chen-ccamp-ospf-interas-te-extension-01.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-chen-ccamp-ospf-interas-te-extension-01.txt Content-Type: text/plain Content-ID: <2007-2-1120010.I-D@ietf.org> --Boundary_(ID_V0EbhgiDZt+cdQsFQkJXtg) 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 --Boundary_(ID_V0EbhgiDZt+cdQsFQkJXtg)-- From pce-bounces@lists.ietf.org Thu Feb 01 21:37:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCoIo-0001n8-OZ; Thu, 01 Feb 2007 21:37:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCoIn-0001mw-Id for pce@ietf.org; Thu, 01 Feb 2007 21:37:25 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCoIl-0005zA-7K for pce@ietf.org; Thu, 01 Feb 2007 21:37:25 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCT00CE8DVLAH@szxga04-in.huawei.com> for pce@ietf.org; Fri, 02 Feb 2007 10:35:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCT001PZDVKHS@szxga04-in.huawei.com> for pce@ietf.org; Fri, 02 Feb 2007 10:35:45 +0800 (CST) Received: from Z18605a ([10.111.12.121]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCT008EADVFOE@szxml04-in.huawei.com> for pce@ietf.org; Fri, 02 Feb 2007 10:35:44 +0800 (CST) Date: Fri, 02 Feb 2007 10:35:39 +0800 From: Zhang Renhai Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links To: Greg Mirsky , ccamp@ops.ietf.org, pce@ietf.org Message-id: <025401c74672$d67ada20$790c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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, Greg Thanks a lot for your question. See inline please. Dear Zhang, I have couple questions related to Link ID of inter-AS link. According to the document it is the Router ID of Remote ASBR. [ZRH]Yes, and this can be easily got by manual configuration in the local ASBR. My question: - as I understand the mechanism of how TE information for links R6-R9 and R8-R10 is populated into R5's TE DB is outside the scope of this document. I this mechanism is not IGP but EGP (BGP), then what is the benefit to introduce new LSA in IGP (OSPF) and not use exisitng mechanisms. [ZRH]I think BGP could also be another alternative especially for PCE scenario, but it's not very applicable to per-domian method because the inter-AS TE information may be needed throughout the local AS in case that the path computation function is distributed among LSRs in the local AS, and BGP can hardly advertise the TE information among those LSRs if BGP sessions are not established between the ASBR and those LSRs. So IGP extension is considered in this draft. We have submitted the revised version of this draft, hoping make the problem statement more clear, and relax the use of type 11 opaque lsa, also allow Type 10 lsa (by which the advertising scope is an area of OSPF). http://www.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-01.txt Cheers, Zhang Renhai Regards, Greg PS. I think that OSPF WG needs to be informed as well. -----Original Message----- From: Zhang Renhai [mailto:zhangrenhai@huawei.com] Sent: Tuesday, January 30, 2007 7:38 PM To: ccamp@ops.ietf.org; pce@ietf.org Subject: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Hi, allWe have just submitted the following draft in which we describe some problemsin inter-AS TE scenarios and the corresponding OSPF extension is introduced.PCE environment is also considerd in this I-d so I'd also like pce working groupto pay attention to it.we'd highly appreciate your comments.Thanks a lot,Zhang Renhai & Mach A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF Extensions in Support of Inter-AS (G)MPLS TE Author(s) : M. Chen, R. Zhang Filename : draft-chen-ccamp-ospf-interas-te-extension-00.txt Pages : 9 Date : 2007-1-30 This document describes extensions to the OSPF to support inter-AS Traffic engineering (TE). It defines OSPF extensions for the flooding of inter-AS links information which can be used to perform inter-AS path computation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-00.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-chen-ccamp-ospf-interas-te-extension-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-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. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Feb 02 14:50:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD4Q6-000100-Nh; Fri, 02 Feb 2007 14:50:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD4Q5-0000zv-OY for pce@ietf.org; Fri, 02 Feb 2007 14:50:01 -0500 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD4Q2-0001u3-9H for pce@ietf.org; Fri, 02 Feb 2007 14:50:01 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1HD4Pb-0006vz-00 for pce@ietf.org; Fri, 02 Feb 2007 19:49:31 +0000 Received: from your029b8cecfe ([217.158.132.181] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 19:49:34 +0000 Message-ID: <0a6e01c74703$3b3f0bd0$76849ed9@your029b8cecfe> From: "Adrian Farrel" To: "Zhang Renhai" , "Greg Mirsky" , , References: <025401c74672$d67ada20$790c6f0a@china.huawei.com> Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Date: Fri, 2 Feb 2007 19:41:19 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="GB2312"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 02 Feb 2007 19:49:34.0659 (UTC) FILETIME=[4384A930:01C74703] X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi all, >> I have couple questions related to Link ID >> of inter-AS link. According to the document >> it is the Router ID of Remote ASBR. To be precise, the I-D says "TE Router ID". I think the difference is very important. > [ZRH]Yes, and this can be easily got by manual > configuration in the local ASBR. > >> My question: >> - as I understand the mechanism of how TE >> information for links R6-R9 and R8-R10 is >> populated into R5's TE DB is outside the >> scope of this document. I this mechanism >> is not IGP but EGP (BGP), then what is the >> benefit to introduce new LSA in IGP (OSPF) >> and not use exisitng mechanisms. I think you mean R8-R9 (at least in the latest revision of the I-D). When you say an "existing mechanism" I don't think there is any mechanism for advertising TE information in BGP although there are proposed extensions. But there would be two issues: 1. How to stop the information propagating further than AS2 (AS1 does not want/need to know about the inter-AS links between AS2 and AS3). I guess we could use the new AS_PATHLIMIT stuff. 2. How to get the information into the TED of every LSR in AS2 without them all having to be BGP speakers. I think this is why the IGP is more appealing. The question arrises (as indicated by Renhai, below) as to whether this information only needs to reach PCEs, PCEs and ASBR, or all LSRs. > [ZRH]I think BGP could also be another alternative > especially for PCE scenario, but it's not very > applicable to per-domian method because the inter-AS > TE information may be needed throughout the local AS > in case that the path computation function is > distributed among LSRs in the local AS, and BGP can > hardly advertise the TE information among those LSRs > if BGP sessions are not established between the ASBR > and those LSRs. So IGP extension is considered in this > draft. [SNIP] >> PS. I think that OSPF WG needs to be informed as well. Yes. If CCAMP and/or PCE think that this is something they want to pursue, then we will definitely need to discuss this with the OSPF working group. But I don't want to waste their time or energy before we have discussed this a bit more. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Feb 02 15:07:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD4gS-0006W5-Rt; Fri, 02 Feb 2007 15:06:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD4gR-0006Vw-UF for pce@ietf.org; Fri, 02 Feb 2007 15:06:55 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD4gR-0004Ny-DU for pce@ietf.org; Fri, 02 Feb 2007 15:06:55 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 21:06:51 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Fwd: [Pce] Compliance with the PCECP Requirement Document Date: Fri, 2 Feb 2007 21:06:34 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: [Pce] Compliance with the PCECP Requirement Document Thread-Index: AcdB5DcfM7704+ChQRq57b6WIMw35gFIF+sg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 02 Feb 2007 20:06:51.0521 (UTC) FILETIME=[AD893F10:01C74705] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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 Dimitri, Yes your reading is correct, and you actually pointed out a mistake in = the draft. The exact processing is the one actually defined in section 10: "If a malformed PCEP message is received or the TCP connection fails, the systems sends a PCEP CLOSE message, the system releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle State." So upon TCP connection failure, the PCE releases pending requests. Thus = a PCC never receives responses for requests sent during a previous = session. We are going to align section 5.2.5 with section 10. Regards, JL > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel-lucent.be=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Envoy=E9 : samedi 27 janvier 2007 08:24 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : JP Vasseur; pce@ietf.org > Objet : RE: Fwd: [Pce] Compliance with the PCECP Requirement Document >=20 > hi jean-louis >=20 > is my reading correct: >=20 > " In case of TCP connection failure, the PCEP session SHOULD be > maintained for a period of time equal to the DeadTimer." >=20 > DeadTimer =3D recommended 4 x KeepAlive (min 1s and recommended 30 s)=20 >=20 > during that interval (recommended =3D 120s) which is not=20 > negligible how pending requests are processed ? or did i miss=20 > something ? >=20 > thanks, > - d. >=20 >=20 >=20 >=20 > "LE ROUX Jean-Louis RD-CORE-LAN" > 27/01/2007 00:45 > =20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP=20 > Vasseur"=20 > > cc: > Subject: RE: Fwd: [Pce] Compliance with the PCECP=20 > Requirement Document >=20 >=20 > Hi Dimitri, >=20 > As stated in the spec, if the TCP connection fails the PCE=20 > releases all ressources for the session, including pending=20 > requests. Hence a PCC will never receive a reply for a=20 > request sent during a previous session. >=20 > Regards, >=20 > JL >=20 > > -----Message d'origine----- > > De : Dimitri.Papadimitriou@alcatel-lucent.be > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] > > Envoy=E9 : samedi 27 janvier 2007 00:13 > > =C0 : JP Vasseur > > Cc : pce@ietf.org > > Objet : Re: Fwd: [Pce] Compliance with the PCECP=20 > Requirement Document > >=20 > > Attention, votre correspondant continue de vous =E9crire =E0 votre=20 > > ancienne adresse en @orange-ft.com, qui va =EAtre d=E9sactiv=E9e = d=E9but=20 > > avril. Veuillez lui demander de mettre =E0 jour son carnet = d'adresses=20 > > avec votre nouvelle adresse en @orange-ftgroup.com. > >=20 > > Caution : your correspondent is still writing to your orange-ft.com=20 > > address, which will be disabled beginning of April. Please=20 > ask him/her=20 > > to update his/her address book to orange-ftgroup.com=20 > > .................................................. > >=20 > > hi j-p > >=20 > > one point on the last issue, assuming wg goes as planned: > >=20 > > there is a need to distinguish re-sync and de-sync (or=20 > out-of-sync),=20 > > you > >=20 > > may certainly want to prevent complex re-sync, but de-sync=20 > must lead=20 > > to > >=20 > > the possibility to drop replies from previous requests,=20 > assume that a=20 > > PCC > >=20 > > initiates a req. to a PCE, the TCP connection breaks, PCC=20 > re-initiates=20 > > the > >=20 > > same request, and receives an answer does it come from the=20 > former or=20 > > the > >=20 > > latter req. (this may lead to false positive or true negative) ? > >=20 > > thanks, > > - d. > >=20 > >=20 > >=20 > >=20 > > JP Vasseur > > 26/01/2007 17:09 > >=20 > >=20 > > To: pce@ietf.org > > cc: > >=20 > > Subject: Fwd: [Pce] Compliance with the PCECP=20 > > Requirement > >=20 > > Document > >=20 > >=20 > > Dear WG, > >=20 > > In absence of negative reply we'll go ahead with the proposed plan=20 > > below. > >=20 > > Let us know within 1-2 weeks max if you have comments. > >=20 > > Thanks, > >=20 > > JP. > >=20 > > Begin forwarded message: > >=20 > > From: JP Vasseur > > Date: January 24, 2007 11:38:04 AM EST > > To: pce@ietf.org > > Subject: [Pce] Compliance with the PCECP Requirement Document > >=20 > > Dear WG, > >=20 > > As discussed in San Diego, there are still a few=20 > requirements stated=20 > > in > >=20 > > RFC 4657 that PCEP does not satisfy (see Appendix A of the PCEP ID)=20 > > for > >=20 > > which we'd like your feed-back: > >=20 > >=20 > > Appendix A > >=20 > > The aim of this section is to list the set of requirements set=20 > > forth > > in [RFC4657] that are not satisfied by the current=20 > revision of this > > document. This only concerns the requirements listed as MUST > > according to [RFC2119]. > >=20 > > Here is the list of currently unsatisfied requirements: > >=20 > > o Allow to select/prefer from advertised list of standard=20 > > objective > > functions/options > >=20 > > o Allow to customize objective function/options > >=20 > > o Support "unsynchronized" & "synchronized" objective functions > >=20 > > Comment> The Proposal is to work on this item in the context of a=20 > > Comment> separate > >=20 > > ID that will cover the set of requirements, IGP PCED extensions and=20 > > PCEP > >=20 > > extensions since these functions are not required for the base=20 > > protocol > >=20 > > specification. > >=20 > > o Protocol recovery support resynchronization of information & > > requests between sender & receiver. > >=20 > > Comment> We can see two potential avenues here: > > 1) Upon loosing the PCEP session, pending requests are=20 > considered as=20 > > lost, > >=20 > > and the PCC has the initiative to resend the set of pending=20 > requests.=20 > > The > >=20 > > main benefit of such approach is to be extremely simple and IMO well > >=20 > > suited to most of the cases since path computation requests are not=20 > > likely > >=20 > > to be pending for a long period of time. > > 2) Specify a set of re-synchronization procedures. We came up with=20 > > similar > >=20 > > solutions for many other protocols (in very different=20 > contexts and set=20 > > of > >=20 > > requirements) and our experience clearly tells us that this will=20 > > likely to > >=20 > > be a fairly complex issue. We could see some benefit in statefull=20 > > contexts > >=20 > > though; thus if such functions is required for particular=20 > context, we > >=20 > > would propose not to include in the base protocol specification and=20 > > leave > >=20 > > it for further should the WG think that such function will be=20 > > required. > >=20 > > Thanks for your feed-back. > >=20 > > JP, Jean-Louis et al. > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > >=20 > >=20 > >=20 > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > >=20 > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Feb 02 17:37:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD71c-0006z9-PD; Fri, 02 Feb 2007 17:36:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD6zj-0004qz-OH for pce@ietf.org; Fri, 02 Feb 2007 17:34:59 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD6zh-0003Dy-HN for pce@ietf.org; Fri, 02 Feb 2007 17:34:59 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2007 14:34:57 -0800 X-IronPort-AV: i="4.13,274,1167638400"; d="scan'208,217"; a="52177375:sNHT185753044" 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 l12MYvpr002938; Fri, 2 Feb 2007 17:34:57 -0500 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 l12MYuVT000750; Fri, 2 Feb 2007 17:34:56 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 17:34:57 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 17:34:53 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Date: Fri, 2 Feb 2007 17:34:54 -0500 To: "Vijayanand C - TLS, Chennai." X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 02 Feb 2007 22:34:53.0911 (UTC) FILETIME=[5BDA6670:01C7471A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=60991; t=1170455697; x=1171319697; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20RE=3A=20I-D=20=20ACTION=3Adraft-vijay-somen-p ce-bgp-interas-te-path-01.txt=20 |Sender:=20 |To:=20=22Vijayanand=20C=20-=20TLS,=20Chennai.=22=20; bh=HIPDuMUFiylbyVyTP1gwTwcG449ISuoEqNybUSnYw/Q=; b=vYEMlQTFlVCADQWZNRdVioPmGrsC4UK0CiDuwTEdFlzb8A7hNoad6DUpCi1L40gUSA0S1F5C h/Y7JroDT9X8dZOXqPv0kXFbv7v3u3uYFy6YbmZgaePdAetzWc9cHqcv; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0d9864700e184b480e0033515ee6a795 X-Mailman-Approved-At: Fri, 02 Feb 2007 17:36:55 -0500 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="===============1774436901==" Errors-To: pce-bounces@lists.ietf.org --===============1774436901== Content-Type: multipart/alternative; boundary=Apple-Mail-168-1022450449 --Apple-Mail-168-1022450449 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Let me first try to make sure of something here. When you write "The PCE shall learn the TE attributes of the inter-AS TE links and the TE tunnels that exist between the ASBRs in the domain." Are you suggesting to flood via BGP the intra-domain TE LSPs ? In other words, suppose the following scenario: AS1---AS2---AS3 You have a mesh of intra-domain TE LSPs between all ASBRs within AS2. Are you suggesting to flood in AS1 these TE LSPs (and this for all other ASes that might be between AS1 and the destination domain) ? Thanks. JP. On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. wrote: > Are you suggesting that BGP should propagate all possible next- > hops/As paths and regular path selection process avoided for all > prefixes which can be destinations of inter-AS TE tunnels ? > > > The inter-AS TE link information can be made aware only to the ASes > on either side of the inter-AS link by the IGP. It may not be > possible to propagate it beyond that ( or can it ?). > > So some of the possible AS paths found by BGP( if we propagate all > next-hops/aspaths in bgp) may not be worth trying for path setup > (by BRPC) because of violation of some TE constraint. > > > In our proposal we can pick the paths which are really feasible, > since we have the inter-AS graph, and then invoke methods like BRPC > > > Regards > > Vijay > > > > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, February 01, 2007 1:19 AM > To: Vijayanand C - TLS, Chennai. > Cc: pce@ietf.org > Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas- > te-path-01.txt > > > Hi, > > > On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: > > > > > > Hello all, > > We have submitted the following I-D, please send in your > > comments/suggestions > > > * speaking as a technical contributor * > > > In [BRPC], a method to optimally compute a inter-domain TE > > path for MPLS and GMPS LSPs using the PCE architecture detailed in > > [PCE_ARCH] is described. However the method described requires the > > list of Autonomous systems or domains to be determined apriori. > > Determining the list of ASes/domains to be traversed to reach a > > destination, satisfying the TE constraints is non-trivial. It > > requires knowledge of the inter-AS connectivity and the TE > > characteristics of the inter-AS links along with the knowledge of > > the available paths within each of the ASes/domains. BGP contains > > information on the list of ASes to be traversed to reach a > > destination, however BGP route selection and decision process > > truncates most of the feasible paths, and it also does not carry > > the TE characteristics of the inter-AS links and path availability > > within a domain. > > > What does prevent you from relying on BGP to provide you all > possible paths toward > > a specific destination skipping the regular path selection process > for specific routes (see > > proposals made in the past) and then use BRPC as currently > specified? The Inter-AS TE > > link could easily be obtained via the IGP with minor additions. > > > This is in my opinion a fundamental question that must first be > addressed before > > moving forward. > > > Thanks. > > > JP. > > > > > > Regards > > Vijay > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, January 23, 2007 2:20 AM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : A BGP based method to compute > inter-AS Traffic > > engineering Label Switched Paths with PCE > > Author(s) : C. Vijayanand, S. Bhattacharya > > Filename : > > draft-vijay-somen-pce-bgp-interas-te-path-01.txt > > Pages : 26 > > Date : 2007-1-22 > > > The ability to compute an optimal path for setting up Traffic > > engineering Label Switched Paths spanning multiple autonomous > > systems managed by different operators has been a key > requirement in > > MPLS and GMPLS networks. This document specifies a method of > > computing inter-AS paths consisting of a list of ASes to be > > traversed and a list of TE-Tunnels to be traversed in each AS. The > > method described here uses BGP speakers in the PCEs of each AS to > > distribute the inter-AS connectivity information and the TE-Tunnels > > in each AS to its neighbors to facilitate the construction of an > > inter-AS topology graph which can be used for computing inter-AS > > paths. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp- > interas-te > > -path-01.txt > > > > > DISCLAIMER: > > ---------------------------------------------------------------------- > ------------------------------------------------- > > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > > this message without the prior written consent of the author of > this e-mail is strictly prohibited. If you have > > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > > attachments please check them for viruses and defect. > > > ---------------------------------------------------------------------- > ------------------------------------------------- > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > --Apple-Mail-168-1022450449 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

Let me first try to make = sure of something here. When you write "The PCE shall learn the TE=A0
=A0=A0 = attributes of the = inter-AS TE links and the TE tunnels that exist=A0
=A0=A0 = between the ASBRs = in the domain."

Are you suggesting = to flood via BGP the intra-domain TE LSPs ? In other words, suppose the = following scenario:

AS1---AS2---AS3
You= have a mesh of intra-domain TE LSPs between all ASBRs within = AS2.

Are you = suggesting to flood in AS1 these TE LSPs (and this for all other ASes = that might be between AS1 and the destination domain) ?

Thanks.

JP.

On Feb 1, 2007, at 12:48 = AM, Vijayanand C - TLS, Chennai. wrote:

Are you suggesting = that =A0BGP should propagate all possible next-hops/As paths and regular = path selection process avoided for all prefixes which can be = destinations of inter-AS TE tunnels ?

The inter-AS TE link information can be made aware only to = the ASes on either side of the inter-AS link by the IGP. It may not be = possible to propagate it beyond that ( or can it = ?).

So some of the = possible AS paths found by BGP( if we propagate all next-hops/aspaths in = bgp) may not be worth trying for path setup (by BRPC) because of = violation of some TE constraint.

In our proposal we can pick the paths which are really = feasible, since we have the inter-AS graph, and then invoke methods like = BRPC

Regards

-----Original Message-----
JP Vasseur [mailto:jvasseur@cisco.com] =
Thursday, = February 01, 2007 1:19 AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org
Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

=A0

On Jan 25, 2007, at 9:32 AM, = Vijayanand C - TLS, Chennai. wrote:



=A0

Hello = all,

We have submitted the following = I-D, please send in your

=A0

* speaking as a technical = contributor *

=A0

=A0 =A0In [BRPC], a method to = optimally compute a inter-domain = TE=A0

=A0=A0 path for MPLS and GMPS LSPs = using the PCE architecture detailed = in=A0

=A0=A0 [PCE_ARCH] is described. = However the method described requires = the=A0

=A0=A0 list of Autonomous systems or = domains to be determined = apriori.=A0

=A0=A0 Determining the list of = ASes/domains to be traversed to reach = a=A0

=A0=A0 destination, satisfying the = TE constraints is non-trivial. = It=A0

=A0=A0 requires knowledge of the = inter-AS connectivity and the = TE=A0

=A0=A0 characteristics of the = inter-AS links along with the knowledge = of=A0

=A0=A0 the available paths within = each of the ASes/domains. BGP = contains=A0

=A0=A0 information on the list of = ASes to be traversed to reach = a=A0

=A0=A0 destination, however BGP = route selection and decision = process=A0

=A0=A0 truncates most of the = feasible paths, and it also does not = carry=A0

=A0=A0 the TE characteristics of the = inter-AS links and path = availability=A0

=A0=A0 within a domain. = =A0

=A0

What does prevent you from = relying on BGP to provide you all possible paths = toward=A0

a specific destination skipping = the regular path selection process for specific routes = (see

proposals made in the past) and = then use BRPC as currently specified? The Inter-AS = TE

link could easily be obtained = via the IGP with minor = additions.

=A0

This is in my opinion a = fundamental question that must first be addressed = before=A0

moving = forward.

=A0

=A0



=A0

-----Original = Message-----

=A0

The contents of this e-mail and = any attachment(s) are confidential and intended for the named = recipient(s) only.

It = shall not attach any liability on the originator or HCL or its = affiliates. Any views or opinions presented inthis email are solely those of = the author and may not necessarily reflect the opinions of HCL or its = affiliates.

Any form of reproduction, = dissemination, copying, disclosure, modification, distribution and / or = publication ofthis message without the prior = written consent of the author of this e-mail is strictly prohibited. If = you havereceived this email in error = please delete it and notify the sender immediately. Before opening any = mail andattachments please check them = for viruses and defect.

=A0

=A0

Pce mailing list



= --Apple-Mail-168-1022450449-- --===============1774436901== 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 --===============1774436901==-- From pce-bounces@lists.ietf.org Fri Feb 02 17:43:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD77n-0007Lk-OR; Fri, 02 Feb 2007 17:43:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD77m-0007LZ-Lw for pce@ietf.org; Fri, 02 Feb 2007 17:43:18 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD77k-0004gM-5r for pce@ietf.org; Fri, 02 Feb 2007 17:43:18 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2007 14:43:16 -0800 X-IronPort-AV: i="4.13,274,1167638400"; d="scan'208"; a="52177857:sNHT41810516" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l12MhF3I005408 for ; Fri, 2 Feb 2007 17:43:15 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l12MhFOA003595 for ; Fri, 2 Feb 2007 17:43:15 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 17:43:16 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 17:43:15 -0500 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, 2 Feb 2007 17:43:16 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 02 Feb 2007 22:43:15.0827 (UTC) FILETIME=[8704B430:01C7471B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=143; t=1170456196; x=1171320196; 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:=20Slot=20Request=20for=20the=20next=20IETF |Sender:=20 |To:=20pce@ietf.org; bh=6pckLnhmw+vpRty9W+1LW3w/0u5JOJhVwyJarp5ogBo=; b=cUqfSUVmqTYK/S4/j+4Y6SO4AuvMF9F7emvA+29AoV2iOaKIg04FWPgjsmvMy/nfQZ9cg9z8 QFwZx6ja5yWPLMGGx8zBeIU1konL2MY+lO/IYeS2Ll+O46vnFHghJTOI; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Pce] Slot Request for the next IETF 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, Since it looks like our meeting will likely be heavily booked, please let us know if you have slot requests. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Feb 03 10:24:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDMjq-0004K8-Gv; Sat, 03 Feb 2007 10:23:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDMjp-0004Hw-O4 for pce@ietf.org; Sat, 03 Feb 2007 10:23:37 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDMjl-0002H9-8l for pce@ietf.org; Sat, 03 Feb 2007 10:23:37 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1HDMjx-0001ED-00 for pce@ietf.org; Sat, 03 Feb 2007 15:23:45 +0000 Received: from your029b8cecfe ([217.158.132.137] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Feb 2007 15:23:29 +0000 Message-ID: <0bc001c747a7$3cd067b0$76849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Sat, 3 Feb 2007 15:23:03 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 03 Feb 2007 15:23:29.0848 (UTC) FILETIME=[42299380:01C747A7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Pce] Fw: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic 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 Heads up. ----- Original Message ----- From: To: Sent: Friday, February 02, 2007 5:00 AM Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic > There are two (2) Internet-Draft cutoff dates for the 68th > IETF Meeting in Prague, Czech Republic: > > February 26th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > February 26th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > February 19th at 9:00 AM ET. > > March 5th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, March 5th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, March 19th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 68th IETF Meeting can be found at > http://www.ietf.org/meetings/cutoff_dates_68.html. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 05 05:48:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1No-00055C-7q; Mon, 05 Feb 2007 05:47:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDwZA-0005fx-As for pce@ietf.org; Mon, 05 Feb 2007 00:39:00 -0500 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDwZ5-0004JN-HV for pce@ietf.org; Mon, 05 Feb 2007 00:39:00 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id D9E40360010; Mon, 5 Feb 2007 11:08:48 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid CE7C9360022; Mon, 5 Feb 2007 11:08:48 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 11:08:48 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Date: Mon, 5 Feb 2007 11:08:08 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Thread-Index: AcdHGmIK+WmdESo5RRqVCKhKwCokxgBzArqg From: "Vijayanand C - TLS, Chennai." To: "JP Vasseur" X-OriginalArrivalTime: 05 Feb 2007 05:38:48.0007 (UTC) FILETIME=[E894F570:01C748E7] X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-25.9600 TC:1F TRN:96 TV:3.6.1039(14974.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: f32befa15ef81303d41972a1284d3814 X-Mailman-Approved-At: Mon, 05 Feb 2007 05:47:33 -0500 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="===============1581161213==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1581161213== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C748E7.D3FF557B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C748E7.D3FF557B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 We mean that those inter-ASBR TE LSPs which are permitted by policy/scaling configuration to be propagated outside can be flooded by BGP. This may be a sub-set of TE LSPs specifically provisioned for carrying inter-AS TE traffic and may be a full mesh. If all the ASes support such a mechanism then the itner-AS TE path can be calculated using the inter-AS graph of such LSPs and inter-AS links. =20 But, this may not be always possible though because of policy and scaling constraints.In such situations we can only find the possible AS paths after eliminating the paths through inter-AS links which are not feasible and then use methods like BRPC to complete the path setup. =20 Regards Vijay -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Saturday, February 03, 2007 4:05 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 From pce-bounces@lists.ietf.org Mon Feb 05 05:48:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1No-00055C-7q; Mon, 05 Feb 2007 05:47:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDwZA-0005fx-As for pce@ietf.org; Mon, 05 Feb 2007 00:39:00 -0500 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDwZ5-0004JN-HV for pce@ietf.org; Mon, 05 Feb 2007 00:39:00 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id D9E40360010; Mon, 5 Feb 2007 11:08:48 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid CE7C9360022; Mon, 5 Feb 2007 11:08:48 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 11:08:48 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Date: Mon, 5 Feb 2007 11:08:08 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Thread-Index: AcdHGmIK+WmdESo5RRqVCKhKwCokxgBzArqg From: "Vijayanand C - TLS, Chennai." To: "JP Vasseur" X-OriginalArrivalTime: 05 Feb 2007 05:38:48.0007 (UTC) FILETIME=[E894F570:01C748E7] X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-25.9600 TC:1F TRN:96 TV:3.6.1039(14974.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: f32befa15ef81303d41972a1284d3814 X-Mailman-Approved-At: Mon, 05 Feb 2007 05:47:33 -0500 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="===============1581161213==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1581161213== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C748E7.D3FF557B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C748E7.D3FF557B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 We mean that those inter-ASBR TE LSPs which are permitted by policy/scaling configuration to be propagated outside can be flooded by BGP. This may be a sub-set of TE LSPs specifically provisioned for carrying inter-AS TE traffic and may be a full mesh. If all the ASes support such a mechanism then the itner-AS TE path can be calculated using the inter-AS graph of such LSPs and inter-AS links. =20 But, this may not be always possible though because of policy and scaling constraints.In such situations we can only find the possible AS paths after eliminating the paths through inter-AS links which are not feasible and then use methods like BRPC to complete the path setup. =20 Regards Vijay -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Saturday, February 03, 2007 4:05 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 Hi, =20 Let me first try to make sure of something here. When you write "The PCE shall learn the TE=20 attributes of the inter-AS TE links and the TE tunnels that exist=20 between the ASBRs in the domain." =20 Are you suggesting to flood via BGP the intra-domain TE LSPs ? In other words, suppose the following scenario: =20 AS1---AS2---AS3 You have a mesh of intra-domain TE LSPs between all ASBRs within AS2. =20 Are you suggesting to flood in AS1 these TE LSPs (and this for all other ASes that might be between AS1 and the destination domain) ? =20 Thanks. =20 JP. =20 On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. wrote: Are you suggesting that BGP should propagate all possible next-hops/As paths and regular path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ? =20 The inter-AS TE link information can be made aware only to the ASes on either side of the inter-AS link by the IGP. It may not be possible to propagate it beyond that ( or can it ?). So some of the possible AS paths found by BGP( if we propagate all next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of violation of some TE constraint. =20 In our proposal we can pick the paths which are really feasible, since we have the inter-AS graph, and then invoke methods like BRPC =20 Regards Vijay =20 =20 =20 =20 -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Thursday, February 01, 2007 1:19 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =20 Hi, =20 On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: =20 =20 Hello all, We have submitted the following I-D, please send in your comments/suggestions =20 * speaking as a technical contributor * =20 In [BRPC], a method to optimally compute a inter-domain TE=20 path for MPLS and GMPS LSPs using the PCE architecture detailed in=20 [PCE_ARCH] is described. However the method described requires the=20 list of Autonomous systems or domains to be determined apriori.=20 Determining the list of ASes/domains to be traversed to reach a=20 destination, satisfying the TE constraints is non-trivial. It=20 requires knowledge of the inter-AS connectivity and the TE=20 characteristics of the inter-AS links along with the knowledge of=20 the available paths within each of the ASes/domains. BGP contains=20 information on the list of ASes to be traversed to reach a=20 destination, however BGP route selection and decision process=20 truncates most of the feasible paths, and it also does not carry=20 the TE characteristics of the inter-AS links and path availability=20 within a domain. =20 =20 What does prevent you from relying on BGP to provide you all possible paths toward=20 a specific destination skipping the regular path selection process for specific routes (see proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE link could easily be obtained via the IGP with minor additions. =20 This is in my opinion a fundamental question that must first be addressed before=20 moving forward. =20 Thanks. =20 JP. =20 =20 Regards Vijay =20 -----Original Message----- From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, January 23, 2007 2:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =20 =20 Title : A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-bgp-interas-te-path-01.txt Pages : 26 Date : 20Hi, =20 Let me first try to make sure of something here. When you write "The PCE shall learn the TE=20 attributes of the inter-AS TE links and the TE tunnels that exist=20 between the ASBRs in the domain." =20 Are you suggesting to flood via BGP the intra-domain TE LSPs ? In other words, suppose the following scenario: =20 AS1---AS2---AS3 You have a mesh of intra-domain TE LSPs between all ASBRs within AS2. =20 Are you suggesting to flood in AS1 these TE LSPs (and this for all other ASes that might be between AS1 and the destination domain) ? =20 Thanks. =20 JP. =20 On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. wrote: Are you suggesting that BGP should propagate all possible next-hops/As paths and regular path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ? =20 The inter-AS TE link information can be made aware only to the ASes on either side of the inter-AS link by the IGP. It may not be possible to propagate it beyond that ( or can it ?). So some of the possible AS paths found by BGP( if we propagate all next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of violation of some TE constraint. =20 In our proposal we can pick the paths which are really feasible, since we have the inter-AS graph, and then invoke methods like BRPC =20 Regards Vijay =20 =20 =20 =20 -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Thursday, February 01, 2007 1:19 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =20 Hi, =20 On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: =20 =20 Hello all, We have submitted the following I-D, please send in your comments/suggestions =20 * speaking as a technical contributor * =20 In [BRPC], a method to optimally compute a inter-domain TE=20 path for MPLS and GMPS LSPs using the PCE architecture detailed in=20 [PCE_ARCH] is described. However the method described requires the=20 list of Autonomous systems or domains to be determined apriori.=20 Determining the list of ASes/domains to be traversed to reach a=20 destination, satisfying the TE constraints is non-trivial. It=20 requires knowledge of the inter-AS connectivity and the TE=20 characteristics of the inter-AS links along with the knowledge of=20 the available paths within each of the ASes/domains. BGP contains=20 information on the list of ASes to be traversed to reach a=20 destination, however BGP route selection and decision process=20 truncates most of the feasible paths, and it also does not carry=20 the TE characteristics of the inter-AS links and path availability=20 within a domain. =20 =20 What does prevent you from relying on BGP to provide you all possible paths toward=20 a specific destination skipping the regular path selection process for specific routes (see proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE link could easily be obtained via the IGP with minor additions. =20 This is in my opinion a fundamental question that must first be addressed before=20 moving forward. =20 Thanks. =20 JP. =20 =20 Regards Vijay =20 -----Original Message----- From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, January 23, 2007 2:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =20 =20 Title : A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-bgp-interas-te-path-01.txt Pages : 26 Date : 2007-1-22 =20 The ability to compute an optimal path for setting up Traffic=20 engineering Label Switched Paths spanning multiple autonomous=20 systems managed by different operators has been a key requirement in=20 MPLS and GMPLS networks. This document specifies a method of=20 computing inter-AS paths consisting of a list of ASes to be=20 traversed and a list of TE-Tunnels to be traversed in each AS. The=20 method described here uses BGP speakers in the PCEs of each AS to=20 distribute the inter-AS connectivity information and the TE-Tunnels=20 in each AS to its neighbors to facilitate the construction of an=20 inter-AS topology graph which can be used for computing inter-AS paths. =20 A URL for this Internet-Draft is: =20 http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-interas-te -path-01.txt =20 =20 =20 DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- =20 The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. =20 ------------------------------------------------------------------------ ----------------------------------------------- =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 =20 ------_=_NextPart_001_01C748E7.D3FF557B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


= --Apple-Mail-175--909902535-- --===============1531711168== 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 --===============1531711168==-- From pce-bounces@lists.ietf.org Mon Feb 05 06:40:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE2Cu-0007Vr-OY; Mon, 05 Feb 2007 06:40:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1g3-0006dS-E3 for pce@ietf.org; Mon, 05 Feb 2007 06:06:27 -0500 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE1g0-0002vT-FK for pce@ietf.org; Mon, 05 Feb 2007 06:06:27 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 4B66936008D; Mon, 5 Feb 2007 16:36:22 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid 0F648360022; Mon, 5 Feb 2007 16:36:22 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 16:36:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Date: Mon, 5 Feb 2007 16:35:53 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Thread-Index: AcdJD0TW5ygApM26R9qKCYqAuYCvOwAA/B0A From: "Vijayanand C - TLS, Chennai." To: "JP Vasseur" X-OriginalArrivalTime: 05 Feb 2007 11:06:21.0682 (UTC) FILETIME=[AB15C520:01C74915] X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-18.0820 TC:1F TRN:94 TV:3.6.1039(14978.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: a823e5c4d849e1d26acd3270cf7db916 X-Mailman-Approved-At: Mon, 05 Feb 2007 06:40:23 -0500 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="===============0919584742==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0919584742== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74915.9D6D5F1E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74915.9D6D5F1E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JP, =20 We mean that those inter-ASBR TE LSPs which are permitted by policy/scaling configuration to be propagated outside can be propogated to PCEs in neighbouring ASes by BGP.This information is not flooded to all BGP speakers of neighbouring ASes but only to speakers which are on PCEs or which propogate them to PCEs ( which support the new AFI/SAFI). =20 These LSPs may be a sub-set of TE LSPs specifically provisioned for carrying inter-AS TE traffic and may be a full mesh. If all the ASes support such a mechanism then the itner-AS TE path can be calculated using the inter-AS graph of such LSPs and inter-AS links. =20 =20 Then I've got a much major concern then. Back to when the inter-domain TE discussion started (a few years back), several potential candidates have been investigated including the TE aggregation technique that you propose and that has been excluded for a number of reasons (see also RFC4105 and RFC4216). Thus we proposed two techniques: per-domain and the PCE (where no aggregated TE data is leaked between domains !). You may want to refer to the lists archives for details but TE aggregation has been rejected, this is precisely why we developed PCE-based computation for inter-domain TE.=20 =20 I certainly do not want to re-open the debate for the Nth time, but just consider that in your proposal you would not have to flood just one TE LSP per pair of ASBR but one TE LSP per attribute per pair of ASBRs (combining affinity, CTs, metric, ... ) and for all domains + this would of course be dynamic (based on the TE LSP when they get rerouted because of failures, reoptimization, ...). [[Vijay ]] I ll go through the arguments in the mailing list archive, thanks for the pointer. We are not suggesting this as a solution always, but use it wherever possible since it is a step towards optimality. The aggregation and distribution is limited to the PCEs, and this information is not flooded to the rest of the network.=20 =20 But, this kind of itner-ASBR LSP propogation may not be always possible because of policy and scaling constraints. In such situations we have only the ASes and their inter-AS links in the form of an inter-AS graph and we can only find the 'possible' AS paths after eliminating the paths through inter-AS links which are not feasible and then use methods like BRPC to complete the path setup. =20 But in this case, it is probably not worth the work: you do not have the 'possible' AS since you do not have any information about the resource available within each AS. =20 [[Vijay ]] But is it not better than trying all possible ASpaths towards a destination. In this method we can certainly eliminate many of the AS paths where the inter-AS link cannot support the path. This may also be useful for finding backup paths since the inter-AS graph is known.=20 Hope this helps. =20 Thanks. =20 JP. =20 Regards Vijay =20 =20 -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Saturday, February 03, 2007 4:05 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =20 Hi, =20 Let me first try to make sure of something here. When you write "The PCE shall learn the TE=20 attributes of the inter-AS TE links and the TE tunnels that exist=20 between the ASBRs in the domain." =20 Are you suggesting to flood via BGP the intra-domain TE LSPs ? In other words, suppose the following scenario: =20 AS1---AS2---AS3 You have a mesh of intra-domain TE LSPs between all ASBRs within AS2. =20 Are you suggesting to flood in AS1 these TE LSPs (and this for all other ASes that might be between AS1 and the destination domain) ? =20 Thanks. =20 JP. =20 On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. wrote: =20 Are you suggesting that BGP should propagate all possible next-hops/As paths and regular path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ? =20 The inter-AS TE link information can be made aware only to the ASes on either side of the inter-AS link by the IGP. It may not be possible to propagate it beyond that ( or can it ?). So some of the possible AS paths found by BGP( if we propagate all next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of violation of some TE constraint. =20 In our proposal we can pick the paths which are really feasible, since we have the inter-AS graph, and then invoke methods like BRPC =20 Regards Vijay =20 =20 =20 =20 -----Original Message----- From: JP Vasseur [ mailto:jvasseur@cisco.com]=20 Sent: Thursday, February 01, 2007 1:19 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =20 Hi, =20 On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: =20 =20 Hello all, We have submitted the following I-D, please send in your comments/suggestions =20 * speaking as a technical contributor * =20 In [BRPC], a method to optimally compute a inter-domain TE=20 path for MPLS and GMPS LSPs using the PCE architecture detailed in=20 [PCE_ARCH] is described. However the method described requires the=20 list of Autonomous systems or domains to be determined apriori.=20 Determining the list of ASes/domains to be traversed to reach a=20 destination, satisfying the TE constraints is non-trivial. It=20 requires knowledge of the inter-AS connectivity and the TE=20 characteristics of the inter-AS links along with the knowledge of=20 the available paths within each of the ASes/domains. BGP contains=20 information on the list of ASes to be traversed to reach a=20 destination, however BGP route selection and decision process=20 truncates most of the feasible paths, and it also does not carry=20 the TE characteristics of the inter-AS links and path availability=20 within a domain. =20 =20 What does prevent you from relying on BGP to provide you all possible paths toward=20 a specific destination skipping the regular path selection process for specific routes (see proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE link could easily be obtained via the IGP with minor additions. =20 This is in my opinion a fundamental question that must first be addressed before=20 moving forward. =20 Thanks. =20 JP. =20 =20 Regards Vijay =20 -----Original Message----- From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, January 23, 2007 2:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =20 =20 Title : A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-bgp-interas-te-path-01.txt Pages : 26 Date : 2007-1-22 =20 The ability to compute an optimal path for setting up Traffic=20 engineering Label Switched Paths spanning multiple autonomous=20 systems managed by different operators has been a key requirement in=20 MPLS and GMPLS networks. This document specifies a method of=20 computing inter-AS paths consisting of a list of ASes to be=20 traversed and a list of TE-Tunnels to be traversed in each AS. The=20 method described here uses BGP speakers in the PCEs of each AS to=20 distribute the inter-AS connectivity information and the TE-Tunnels=20 in each AS to its neighbors to facilitate the construction of an=20 inter-AS topology graph which can be used for computing inter-AS paths. =20 A URL for this Internet-Draft is: =20 http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-interas-te -path-01.txt =20 =20 =20 DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- =20 The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. =20 ------------------------------------------------------------------------ ----------------------------------------------- =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 =20 =20 =20 ------_=_NextPart_001_01C74915.9D6D5F1E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks!

JP.
= --Apple-Mail-22--204719750-- --===============1005348882== 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 --===============1005348882==-- From pce-bounces@lists.ietf.org Tue Feb 13 18:50:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7Pv-0000wI-Uu; Tue, 13 Feb 2007 18:50:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7Ps-0000uh-UJ; Tue, 13 Feb 2007 18:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HH7Ps-0004qm-GR; Tue, 13 Feb 2007 18:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6CEEB17608; Tue, 13 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HH7PO-0007pJ-6e; Tue, 13 Feb 2007 18:50:02 -0500 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, 13 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-isis-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : IS-IS protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-isis-02.txt Pages : 20 Date : 2007-2-13 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 of 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-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-isis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-13152516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-isis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-13152516.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue Feb 13 18:50:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7PR-0000nO-Kl; Tue, 13 Feb 2007 18:50:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7PO-0000mm-Nb; Tue, 13 Feb 2007 18:50:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH7PO-0003vr-FL; Tue, 13 Feb 2007 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 512BB26EF0; Tue, 13 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HH7PO-0007pG-62; Tue, 13 Feb 2007 18:50:02 -0500 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, 13 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : OSPF protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-ospf-02.txt Pages : 22 Date : 2007-2-13 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 of 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-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-ospf-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-13151959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-ospf-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-13151959.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue Feb 13 18:50:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7Pv-0000wI-Uu; Tue, 13 Feb 2007 18:50:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7Ps-0000uh-UJ; Tue, 13 Feb 2007 18:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HH7Ps-0004qm-GR; Tue, 13 Feb 2007 18:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6CEEB17608; Tue, 13 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HH7PO-0007pJ-6e; Tue, 13 Feb 2007 18:50:02 -0500 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, 13 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-isis-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : IS-IS protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-isis-02.txt Pages : 20 Date : 2007-2-13 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 of 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-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-isis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-13152516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-isis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-13152516.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed Feb 14 07:00:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHInG-0000LK-II; Wed, 14 Feb 2007 06:59:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHInF-0000L7-UW for pce@ietf.org; Wed, 14 Feb 2007 06:59:25 -0500 Received: from serv108.segi.ulg.ac.be ([139.165.32.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHInE-0001mw-Hp for pce@ietf.org; Wed, 14 Feb 2007 06:59:25 -0500 Received: (qmail 13226 invoked by uid 510); 14 Feb 2007 12:59:23 +0100 Received: from 139.165.223.2 by serv108.segi.ulg.ac.be (envelope-from , uid 501) with qmail-scanner-1.25 (clamdscan: 0.88.6/2562. Clear:RC:1(139.165.223.2):. Processed in 0.023393 secs); 14 Feb 2007 11:59:23 -0000 Received: from unknown (HELO bru.run.montefiore.ulg.ac.be) ([139.165.223.2]) (envelope-sender ) by serv108.segi.ulg.ac.be (qmail-ldap-1.03) with SMTP for ; 14 Feb 2007 12:59:23 +0100 Received: from [139.165.223.27] (phoenix.run.montefiore.ulg.ac.be [139.165.223.27]) by bru.run.montefiore.ulg.ac.be (Postfix) with ESMTP id EE896197D9 for ; Wed, 14 Feb 2007 12:48:48 +0100 (CET) Message-ID: <45D2F99A.6000200@run.montefiore.ulg.ac.be> Date: Wed, 14 Feb 2007 12:59:22 +0100 From: =?ISO-8859-1?Q?Ga=EBl_Monfort?= User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Pce] PCE/PCC implementation X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi all, I am implementing a PCE and would welcome the opportunity to do interoperability testing with a PCC implementation. If you implemented PCC, please contact me privately. Regards, Gael ____________________________________________________________________________ Gaël Monfort Tel : +32 4 366 26 10 Université de Liège Secr : +32 4 366 26 91 Réseaux Informatiques Fax : +32 4 366 29 89 Research Unit in Networking (RUN) monfort@run.montefiore.ulg.ac.be Département d'électricité, électronique et informatique (Institut Montéfiore) BAT. B28 Réseaux informatiques Grande Traverse 10, B-4000 LIEGE 1, BELGIUM TOTEM Toolbox: http://totem.run.montefiore.ulg.ac.be/ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 14 15:27:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQiy-0002Rq-D4; Wed, 14 Feb 2007 15:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQix-0002Rh-VE for pce@ietf.org; Wed, 14 Feb 2007 15:27:31 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHQiu-000753-Hk for pce@ietf.org; Wed, 14 Feb 2007 15:27:31 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1HHQij-0001wS-OF for pce@ietf.org; Wed, 14 Feb 2007 20:27:17 +0000 Received: from your029b8cecfe ([217.158.132.46] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 20:27:10 +0000 Message-ID: <03ec01c75075$d7e31e10$0d01a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 14 Feb 2007 17:35:01 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 14 Feb 2007 20:27:12.0774 (UTC) FILETIME=[826AAA60:01C75076] X-Originating-Heisenberg-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Pce] Working Group Last Call on Discovery Protocols X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-02.txt http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-02.txt The authors have updated these drafts to accommodate my review comments, and I am happy that they are now ready for working group last call. We need to give the OSPF and ISIS working groups the chance to comment, so I am going to make this a three week last call, but please send your comments to the mailing list as soon as you can. The last call will end at 12 noon GMT on Thursday 8th March. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 14 15:50:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5K-0006Qz-4n; Wed, 14 Feb 2007 15:50:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5F-0006PN-Da; Wed, 14 Feb 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHR5F-0008NQ-2b; Wed, 14 Feb 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A59BB17604; Wed, 14 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HHR4j-0004JO-Sb; Wed, 14 Feb 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Feb 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-06.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element (PCE) communication Protocol (PCEP) Author(s) : J. Le Roux, J. Vasseur Filename : draft-ietf-pce-pcep-06.txt Pages : 67 Date : 2007-2-14 This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. The PCEP protocol is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-pcep-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-pcep-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-14122356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcep-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcep-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-14122356.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Fri Feb 16 14:14:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8X0-0005gy-16; Fri, 16 Feb 2007 14:14:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI8Wz-0005bX-1D for pce@ietf.org; Fri, 16 Feb 2007 14:14:05 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI8Wx-0005Cp-Ne for pce@ietf.org; Fri, 16 Feb 2007 14:14:05 -0500 Received: from pc6 (1Cust53.tnt106.lnd4.gbr.da.uu.net [213.116.60.53]) by astro.systems.pipex.net (Postfix) with SMTP id 8BB1EE000397; Fri, 16 Feb 2007 19:14:01 +0000 (GMT) Message-ID: <02aa01c751f6$008b91e0$0601a8c0@pc6> From: "tom.petch" To: "Adrian Farrel" , "JP Vasseur" , References: <05e201c739ad$c43854e0$0601a8c0@pc6> <090f01c73b0d$ea029580$0a23fea9@your029b8cecfe> Subject: Re: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt Date: Fri, 16 Feb 2007 14:23:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Dan \(\(Dan\)\) Romascanu" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org A propos of this initiative, I just saw the I-D below which is operating in the same space albeit from a different direction. It uses the FCAPS model of management. Tom Petch A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for Considering Operations and Management of New Protocols Author(s) : D. Harrington Filename : draft-harrington-operations-and-management-00.txt Pages : 31 Date : 2007-2-15 New protocols or protocol extensions are best designed with due consideration of operations and management issues related to the protocol. Retrofitting operations and management recommendations to protocols is sub-optimal. The purpose of this document is to provide guidance to authors of protocol documents about aspects to consider related to the operations and management that should be considered for inclusion in documents defining requirements or functionality of new protocols or protocol extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-harrington-operations-and-management-0 0.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Feb 16 16:28:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAd8-0002AQ-3Z; Fri, 16 Feb 2007 16:28:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAd7-0002A9-Cz for pce@ietf.org; Fri, 16 Feb 2007 16:28:33 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIAd5-00032X-3b for pce@ietf.org; Fri, 16 Feb 2007 16:28:33 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2007 13:28:29 -0800 X-IronPort-AV: i="4.14,182,1170662400"; d="scan'208,217"; a="763222886:sNHT5198491744" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1GLSSkn011824; Fri, 16 Feb 2007 13:28:28 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1GLSMnJ005605; Fri, 16 Feb 2007 13:28:28 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:28:18 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:28:18 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <5CAD087E-1719-4D9A-9719-7707FDA1647B@cisco.com> From: JP Vasseur Date: Fri, 16 Feb 2007 16:28:16 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 16 Feb 2007 21:28:18.0310 (UTC) FILETIME=[60129260:01C75211] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13847; t=1171661308; x=1172525308; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Changes=20in=20PCEP=20v6 |Sender:=20; bh=wRPas2YhThZFVj1LqPR8gZ7jWbXyIm9mKg51vYrvD0Q=; b=zw+OLkkkJd5YZUa/1CZ2d1RkbB3hlIDxZ9WQqR84qN9y/ROEodmZNoR49b4TXNFYC3B1MEzt ovFyj2dg9qJGEPDJnUTikQug8eYxvrTvG9rPI3wX2OOWT5UuZ6h3X785; Authentication-Results: sj-dkim-8; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: Subject: [Pce] Changes in PCEP v6 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="===============2102815962==" Errors-To: pce-bounces@lists.ietf.org --===============2102815962== Content-Type: multipart/alternative; boundary=Apple-Mail-104-80568347 --Apple-Mail-104-80568347 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, Here an update wrt to PCEP Rev-06: 1) Various edits 2) New header format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Flags | Message-Type | Message-Lenght | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver 3) New Section (6.7: Error message) 4) A few inconsistencies with regards to session establishment (only triggered by PCC) have been fixed. 5) Clarification added: "In case of TCP connection failure, the PCEP session SHOULD be maintained for a period of time equal to the DeadTimer." has been replaced by "In case of TCP connection failure, the PCEP session is immediatly terminated." in section 5.2.5 6) Reserved field and unassigned Clarification added: - Reserved: This field MUST be set to zero on transmission and MUST be ignored on receipt. - Unassigned bits are considered as reserved and MUST be set to zero on transmission. 7) The I flag has no meaning in a PCRep message when the P flag had been set in the corresponding PCRep message. 8) In the PCEP message header, the version field was 4 bits and in the Open Object it was 3 bits. The version field of OPEN has been aligned to 4 bits (Flags field reduced from 5 bits to 4bits). 9) The BNF of the PCReq/PCRep message has been fixed to support multiple METRIC objects. BNF also modified to remove SVEC object in PCRep message. 10) Clarification added on the use of the METRIC object during reoptimization + text modified: B bit used to report a constraint When B=0, metric-value in PCReq may be used to report the cost of a reoptimized TE LSP or =0 When B=0, metric-value in PCRep is used to report the cost of the computed path if C=1 11) One Object-Type for the LSPA object (with affinity) rather than two. 12) Clarified that the reception of a malformed message, the system sends a CLOSE message, releases the PCEP resources and closes the TCP connection. Reason field (CLOSE object=4): Reception of a malformed PCEP message 11) We had defined the following PCEP Error: Error-Type Meaning 1 PCEP session establishment failure Error-value=1: reception of a malformed Open message In the FSM: If an error is detected (e.g. malformed Open message, presence of two Open objects, ...), PCEP generates an error notification, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=1. The system releases the PCEP resources for the PCEP peer, closes the TCP connection and moves to the Idle state. A malformed Open message is no different than any other type of malformed PCEP message => CLOSE object with reason=4. 12) Appendix A Appendix A. Compliance with the PCECP Requirement Document The aim of this section is to list the set of requirements set forth in [RFC4657] that are not satisfied by the current revision of this document. This only concerns the requirements listed as MUST according to [RFC2119]. Here is the list of currently unsatisfied requirements: o Allow to select/prefer from advertised list of standard objective functions/options o Allow to customize objective function/options o Support "unsynchronized" & "synchronized" objective functions => The related work will be covered in a separate ID that will discuss those requirements + IGP PCED extensions and PCEP extensions since these functions are not required for the base protocol specification. o Protocol recovery support resynchronization of information & requests between sender & receiver. => The document has been updated to address this requirement. The resynchronization of information between the PCC and the PCE will be handled by retransmission. "If the PCEP session is torn down, the system releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle State. If the TCP connection fails, the system releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle State" Why ? Full state recover may be a requirement in *some* context, at the price of drastically increase the FSM complexity; there are also many contexts (stateless PCE) where retransmitting is not only significantly more simple but may even be much faster. No decision was taken by the WG as to whether work is needed on this particular item but it would be covered in a separate ID. Thanks. JP. --Apple-Mail-104-80568347 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear WG,

Here an update wrt to PCEP = Rev-06:

1) = Various edits

2) New header = format:

0=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0= 2=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 3
0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
| Ver |=A0 Flags=A0 |=A0 Message-Type |=A0 =A0 =A0=A0 = Message-Lenght=A0 =A0 =A0 =A0 =A0 |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=A0
=

Ver

3) New Section (6.7: Error = message)

4) A = few inconsistencies with regards to=A0session=A0establishment (only = triggered by PCC) have been fixed.

5)=A0Clarification = added:
"In case of TCP connection failure, the PCEP session = SHOULD be=A0maintained for a period of time equal to the DeadTimer." has = been replaced by "In case of TCP connection failure, the PCEP session is = immediatly terminated." in section 5.2.5

6) Reserved field and = unassigned
Clarification added:
-=A0Reserved: This = field MUST be set to zero on transmission and MUST be ignored on = receipt.
- Unassigned bits are considered as reserved and MUST = be set to zero on transmission.

7)=A0The I flag has no = meaning in a PCRep message when the P flag had been set in = the=A0corresponding=A0PCRep message.

8)=A0In the PCEP message = header, the version field was 4 bits and in the Open Object it was 3 = bits.
The version field of OPEN has been aligned to 4 bits = (Flags field reduced from 5 bits to 4bits).=A0

9) The BNF of the = PCReq/PCRep message has been fixed to support multiple METRIC objects. = BNF also modified to remove SVEC object in PCRep message.

10) Clarification added on = the use of the METRIC object during reoptimization + text = modified:
B bit used to report a constraint
When B=3D0,= metric-value in PCReq may be used to report the cost of a reoptimized = TE LSP or =3D0
When B=3D0, metric-value in PCRep = is used to report the cost of the computed path if C=3D1

11) One Object-Type for the = LSPA object (with affinity) rather than two.

12) Clarified that the = reception of a malformed message, the system sends a CLOSE message, = releases the PCEP resources and closes the TCP connection.

Reason field (CLOSE = object=3D4): Reception of a malformed PCEP message

11) We had defined the = following PCEP Error:

Error-Type=A0 =A0 = Meaning
=A0=A0 1=A0 =A0 =A0 =A0 =A0 PCEP session = establishment failure
=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = Error-value=3D1: reception of a malformed Open message

In the FSM:=A0

If an error is detected = (e.g. malformed Open message, presence of two Open objects, ...), PCEP = generates an error notification, the PCEP peer sends a PCErr message = with Error-Type=3D1 and Error-value=3D1. The system releases the PCEP = resources for the PCEP peer, closes the TCP connection and moves to the = Idle state.

A malformed Open message is = no different than any other type of malformed PCEP message =3D> CLOSE = object with reason=3D4.

12) Appendix = A
Appendix A.=A0 Compliance with the PCECP Requirement = Document

=A0=A0 The aim of = this section is to list the set of requirements set = forth
=A0=A0 in [RFC4657] that are not satisfied by the = current revision of this
=A0=A0 document.=A0 This only = concerns the requirements listed as MUST
=A0=A0 = according to [RFC2119].

=A0=A0 Here is the = list of currently unsatisfied requirements:

=A0=A0 o=A0 Allow to = select/prefer from advertised list of standard = objective
=A0 =A0 =A0 = functions/options

=A0=A0 o=A0 Allow to = customize objective function/options

=A0=A0 o=A0 Support = "unsynchronized" & "synchronized" objective functions

=3D> The = related work will be covered in a separate ID that will discuss those = requirements + IGP=A0PCED extensions and PCEP extensions since these = functions are=A0not required for the base protocol = specification.

=A0=A0 o=A0 Protocol = recovery support resynchronization of information = &
=A0 =A0 =A0 requests between sender & = receiver.

=3D> The = document has been updated to address this requirement. The = resynchronization of information
between the PCC = and the PCE will be handled by retransmission.=A0

"If the PCEP session = is torn down, the system releases the PCEP resources for that PCEP peer, = closes the TCP connection and moves to the Idle = State.
If the TCP connection fails, the system releases = the PCEP resources for that PCEP peer, closes the TCP connection and = moves to the Idle State"

Why = ?
Full state recover may be a requirement in = *some* context, at the price of drastically increase the FSM complexity; = there are also many contexts (stateless PCE) where retransmitting is not = only significantly more simple but may even be much faster.

No decision was taken by the WG as to whether work = is needed on this particular item but it would be covered in a separate = ID.


To: pce@lists.ietf.org Date: Tue, 20 Feb 2007 20:41:13 +0100 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702202041.13937._den@gmx.de> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Pce] TCPPending state X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org In the draft for PCEP I need TCPPending state to prevent "collision" - the situation where 2 TCP-connections are established. The TCP-connection is established after such called "3-way-handshake" But to implement it, one peer must be signalled after 2 steps in such handshake. Is it possible to be informed programmatically in some way about this event under Linux? Thanks _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 20 14:54:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJb47-0008W6-Q1; Tue, 20 Feb 2007 14:54:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJb46-0008W1-TI for Pce@lists.ietf.org; Tue, 20 Feb 2007 14:54:18 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJb45-0007Nh-LQ for Pce@lists.ietf.org; Tue, 20 Feb 2007 14:54:18 -0500 Received: (qmail invoked by alias); 20 Feb 2007 19:54:16 -0000 X-Provags-ID: V01U2FsdGVkX1+DmWss53CDGbyGADBkq40TtnUC4K7wOv1uUsfkAM uJXA== From: Dennis Aristow <_den@gmx.de> To: Pce@lists.ietf.org Date: Tue, 20 Feb 2007 20:54:16 +0100 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702202054.16200._den@gmx.de> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Pce] TCPPending state X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org In the draft for PCEP I need TCPPending state to prevent "collision" - the situation where 2 TCP-connections are established. The TCP-connection is established after such called "3-way-handshake" But to implement it, one peer must be signalled after 2 steps in such handshake. Is it possible to be informed programmatically in some way about this event under Linux? Thanks _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 21 06:14:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJpQj-0005Hg-IJ; Wed, 21 Feb 2007 06:14:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJpQi-0005HM-3D for pce@ietf.org; Wed, 21 Feb 2007 06:14:36 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJpQa-000112-DN for pce@ietf.org; Wed, 21 Feb 2007 06:14:36 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1HJpQG-0006Ko-IJ for pce@ietf.org; Wed, 21 Feb 2007 11:14:09 +0000 Received: from your029b8cecfe ([217.158.132.133] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 11:14:06 +0000 Message-ID: <082b01c755a9$5dc27ed0$0d01a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 21 Feb 2007 10:52:45 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 21 Feb 2007 11:14:07.0108 (UTC) FILETIME=[671C2440:01C755A9] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: Subject: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG 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 ----- Original Message ----- From: "Les Ginsberg (ginsberg)" To: "Adrian Farrel" ; Cc: "Jean Philippe Vasseur (jvasseur)" Sent: Monday, February 19, 2007 6:56 PM Subject: RE: [Isis-wg] PCE working group last call ondraft-ietf-pce-disco-proto-isis-02.txt Section 1 ABR: IGP Area Border Router (L1L2 router). LES: Use "L2 capable router" instead - or eliminate the definition since as Mike points out it is not used in the document. Examples of domains include IGP areas and Autonomous Systems. LES: area and domain are not the same - though a domain may have only one area. I would omit this sentence. Section 3.1.1 inter-area, inter-AS, inter-layer\205 LES: Remove Formatting character \205 Section 3.2 The flooding scope for PCE information advertised through IS-IS can be limited to one or more IS-IS areas the PCE belongs to, or can be LES: Flooding can only be area or domain scoped flooding. There is no defined method to restrict flooding to some subset of the areas in a domain. extended across the entire IS-IS 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 a L1L2 router for instance advertising its PCE information within the L2 area and/or a subset of its attached L1 area(s). LES: There is no such thing as an L2 area. There is the L2 sub-domain, which consists of all L2 routers in a domain. Section 4.1. The IS-IS PCED TLV LES: This is a sub-TLV. As Mike has pointed out, it is important to use that terminology consistently throughout the document. The format of the IS-IS PCED TLV and its sub-TLVs is the identical to LES: s/the identical/identical At the end of Section 4.1 it might be helpful to add: "The following sub-sections describe the sub-TLVs which may be carried within the PCED sub-TLV." Section 4.1.3 Two DOMAIN sub-TLVs are defined Sub-TLV type Length Name 1 Variable Area ID sub-TLV 2 4 AS number sub-TLV LES: These codepoints are not mentioned in the IANA section. Section 4.1.3.1 VALUE: This comprises a variable length IS-IS area ID. This is the combination of an Initial Domain Part (IDP) and High Order part of the Domain Specific part (HO-DSP) LES: Rather than invent a term (HO-DSP) which ISO 10589 does not use, say "this is the area address as defined in [ISO]". Which causes me to mention that you have no reference to ISO 10589 in the references section, a most serious breach of etiquette indeed!! Section 4.1.4 LES: The domain/area sub-TLVs (nested level 3) which are defined in 4.1.3 appear to be "reused" here. This should be explicitly stated as the scope of the sub-TLV codepoint for domain/area sub-TLVs is the parent sub-TLV (PCE-domain or PCE-NEIG-DOMAIN) and therefore the codepoints cannot be assumed to be the same - it MUST be explicitly stated. Section 5 defined in [IS-IS-CAP]. A such, elements of procedures are inherited LES: s/A such/As such domain, itMUST be carried within an IS-IS CAPABILITY TLV having the S LES: s/itMUST/it MUST A PCE MUST originate a new IS-IS LSP whenever the content LES: There is a generic issue here. As a PCE is not a router running the IS-IS protocol, it cannot generate any LSPs. :-) Therefore you cannot say (as you do in multiple places) "a PCE originates a new IS-IS LSP". Similarly, you say: A PCC MUST be able to detect that the PCED TLV has been removed from an IS-IS LSP. As a PCC is also not equivalent to a router running the IS-IS protocol, perhaps you want to say "A PCC MUST be informed..." - although I tend to think that all of the communication between the applications (PCE and PCC) and the IS-IS protocol instance is out of scope for this document. The PCE address, i.e. the address indicated within the PCE ADDRESS sub-TLV, MUST be distributed as part of IS-IS routing; LES: I am not sure what you mean here. Do you mean that there MUST be a host route advertisement for the PCE address(es)? Or do you simply mean that the PCE address(es) must be reachable via some prefix(es) advertised by IS-IS? If the latter, then please change the wording. As written it suggests there is a special advertisement required. Section 8 IS-IS provides no mechanism for protecting the privacy of LSAs, and LES: I don't know what you are trying to say here. Do you mean TLVs? Certainly not LSAs! in particular the privacy PCE discovery information. LES: s/privacy/privacy of Les > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, February 14, 2007 9:36 AM > To: isis-wg@ietf.org > Cc: Jean Philippe Vasseur (jvasseur) > Subject: [Isis-wg] PCE working group last call ondraft-ietf-pce-disco- > proto-isis-02.txt > > Hi, > > The PCE working group is holding a last call on > http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-02.t xt > > Since this I-D proposes protocol extensions to ISIS we would like the ISIS > working group to participate in this last call, and we have accordingly > made > the last call period three weeks in order to give you plenty of time to > respond. > > The last call will end at 12 noon GMT on Thursday 8th March. > > Please send your comments to the PCE mailing list if you are subscribed. > Otherwise, please channel your comments through the PCE working group > chairs > (adrian@olddog.co.uk and jvasseur@cisco.com) > > Background reading is: > RFC4655 - The PCE Architecture > RFC4674 - Requirements for Path Computation Element (PCE) Discovery > (These are the requirements that this I-D is addressing) > > > Thanks, > Adrian > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 21 17:24:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJzs9-0002Op-2m; Wed, 21 Feb 2007 17:23:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJzs7-0002Ok-15 for pce@ietf.org; Wed, 21 Feb 2007 17:23:35 -0500 Received: from centrmmtao06.cox.net ([70.168.83.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJzs5-00056K-8K for pce@ietf.org; Wed, 21 Feb 2007 17:23:34 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao06.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070221222332.JREY17320.centrmmtao06.cox.net@eastrmimpo01.cox.net>; Wed, 21 Feb 2007 17:23:32 -0500 Received: from Yong73674 ([68.0.102.87]) by eastrmimpo01.cox.net with bizsmtp id SNPU1W00U1t8SFY0000000; Wed, 21 Feb 2007 17:23:32 -0500 From: "Lucy Yong" To: "'Young Lee'" , Subject: RE: [Pce] PCE Global Concurrent Optimization Date: Wed, 21 Feb 2007 16:23:40 -0600 Message-ID: <019e01c75606$f06b8800$6400a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <001401c743f3$98583520$560c7c0a@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcdD85dum6IPvGbvTNaBdduDcsjDkgSEqw9w X-Spam-Score: 0.0 (/) X-Scan-Signature: 08868c2bcdb53bddcb7cc7e7cf96b038 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1094184029==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1094184029== Content-Type: multipart/alternative; boundary="----=_NextPart_000_019F_01C755D4.A5D11800" This is a multi-part message in MIME format. ------=_NextPart_000_019F_01C755D4.A5D11800 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Young, I just read your draft. It is well written and clear. You describs PCEReq quite bit and mention response order. Will The PCEResp contain all the routes information and listed one by one? I think this work could enable subnetwork connection requiests, mp2mp. Regards, Lucy _____ From: Young Lee [mailto:ylee@huawei.com] Sent: Monday, January 29, 2007 4:20 PM To: pce@ietf.org Subject: [Pce] PCE Global Concurrent Optimization Hello all, We have submitted the following I-D. As we have made significant progress on this I-D from the previous version, we'd appreciate your comments and suggestions. Regards, Young, Jean-Louis, Dan and Eiji ------Original Message-------- 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-01.txt Pages : 31 Date : 2007-1-29 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. 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-01.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-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_019F_01C755D4.A5D11800 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Young,
 
I just read your draft. It is well written and=20 clear.
You describs PCEReq quite bit and mention = response order.=20 Will The PCEResp contain all the routes information and listed one by = one? I=20 think this work could enable subnetwork connection requiests,=20 mp2mp.
 
Regards,
Lucy 

From: Young Lee = [mailto:ylee@huawei.com]=20
Sent: Monday, January 29, 2007 4:20 PM
To:=20 pce@ietf.org
Subject: [Pce] PCE Global Concurrent=20 Optimization

Hello all,=20

 

We have = submitted the=20 following I-D.  As we have made significant progress on this I-D = from the=20 previous version, we’d appreciate your comments and suggestions.=20  

 

Regards,

 

Young, = Jean-Louis,=20 Dan and Eiji

 

------Original=20 Message--------

A New Internet-Draft is available from the on-line =
Internet-Drafts 
directories.
 
 
           &n=
bsp;   =
Title           &n=
bsp;            : =
Path Computation Element Communication 
           &n=
bsp;           &nb=
sp;  Protocol (PCECP) Requirements and Protocol =

           &n=
bsp;           &nb=
sp;  Extensions In Support of Global Concurrent =
Optimization
           &n=
bsp;   Author(s) : Y. Lee, et =
al.
           &n=
bsp;   Filename : =
draft-lee-pce-global-concurrent-optimization-01.txt
           &n= bsp;   = Pages           &n= bsp;         : = 31
           &n=
bsp;   =
Date           &nb=
sp;           : =
2007-1-29
           &n=
bsp;   
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.
 
   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-01.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-01.txt".
= 
 
A list of Internet-Drafts directories can be found =
in
http://www.ietf.org/shadow.html<=
/A> 
or ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt
 
Internet-Drafts can also be obtained by =
e-mail.
 
Send a message =
to:
           &n=
bsp;   mailserv at ietf.org.
In the body =
type:
           &n=
bsp;   "FILE =
/internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt".
           &n=
bsp;   
NOTE:     The mail server at =
ietf.org can return the document in
           &n=
bsp;   MIME-encoded form by using the "mpack" utility.  =
To use this
           &n=
bsp;   feature, insert the command "ENCODING mime" before the =
"FILE"
           &n=
bsp;   command.  To decode the response(s), you will need =
"munpack" or
           &n=
bsp;   a MIME-compliant mail reader.  Different =
MIME-compliant mail readers
           &n=
bsp;   exhibit different behavior, especially when dealing =
with
           &n=
bsp;   "multipart" MIME messages (i.e. documents which have =
been split
           &n=
bsp;   up into multiple messages), so check your local =
documentation on
           &n=
bsp;   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-p= ce-global-concurrent-optimization-01.txt>=20 

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

 

------=_NextPart_000_019F_01C755D4.A5D11800-- --===============1094184029== 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 --===============1094184029==-- From pce-bounces@lists.ietf.org Thu Feb 22 13:54:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKJ4p-0007Rh-DA; Thu, 22 Feb 2007 13:53:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKJ4o-0007RY-9R for pce@lists.ietf.org; Thu, 22 Feb 2007 13:53:58 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKJ4l-0001ru-R2 for pce@lists.ietf.org; Thu, 22 Feb 2007 13:53:58 -0500 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 <0JDV00JOAOHSDY@usaga01-in.huawei.com> for pce@lists.ietf.org; Thu, 22 Feb 2007 10:53:53 -0800 (PST) Received: from Lee736821 ([10.124.12.86]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDV001ZGOHOSW@usaga01-in.huawei.com> for pce@lists.ietf.org; Thu, 22 Feb 2007 10:53:52 -0800 (PST) Date: Thu, 22 Feb 2007 12:53:48 -0600 From: Young Lee In-reply-to: To: pce@lists.ietf.org Message-id: <000301c756b2$c989b0c0$560c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdWouM1L0NdwHWBQXWybU3hVziKlAAD5ARQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Subject: [Pce] RE: Pce Digest, Vol 30, Issue 19 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 Lucy, Hi Lucy, Regarding your question, the corresponding PC Reply message will have a RP object for each path request (request ID number) in which the order information is contained relative to other paths. There will be a multiple number of RP objects in the PC Reply message. Regards, Young -----Original Message----- From: pce-request@lists.ietf.org [mailto:pce-request@lists.ietf.org] Sent: Thursday, February 22, 2007 11:00 AM To: pce@lists.ietf.org Subject: Pce Digest, Vol 30, Issue 19 Send Pce mailing list submissions to pce@lists.ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/pce or, via email, send a message with subject or body 'help' to pce-request@lists.ietf.org You can reach the person managing the list at pce-owner@lists.ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Pce digest..." Today's Topics: 1. RE: PCE Global Concurrent Optimization (Lucy Yong) ---------------------------------------------------------------------- Message: 1 Date: Wed, 21 Feb 2007 16:23:40 -0600 From: "Lucy Yong" Subject: RE: [Pce] PCE Global Concurrent Optimization To: "'Young Lee'" , Message-ID: <019e01c75606$f06b8800$6400a8c0@china.huawei.com> Content-Type: text/plain; charset="us-ascii" Young, I just read your draft. It is well written and clear. You describs PCEReq quite bit and mention response order. Will The PCEResp contain all the routes information and listed one by one? I think this work could enable subnetwork connection requiests, mp2mp. Regards, Lucy _____ From: Young Lee [mailto:ylee@huawei.com] Sent: Monday, January 29, 2007 4:20 PM To: pce@ietf.org Subject: [Pce] PCE Global Concurrent Optimization Hello all, We have submitted the following I-D. As we have made significant progress on this I-D from the previous version, we'd appreciate your comments and suggestions. Regards, Young, Jean-Louis, Dan and Eiji ------Original Message-------- 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-01.txt Pages : 31 Date : 2007-1-29 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. 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-01.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-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/pce/attachments/20070221/5e3e6144/attachment- 0001.html ------------------------------ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce End of Pce Digest, Vol 30, Issue 19 *********************************** _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Feb 23 10:26:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKcIp-00010v-EE; Fri, 23 Feb 2007 10:25:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKcIn-0000yZ-GW for pce@ietf.org; Fri, 23 Feb 2007 10:25:41 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKcHg-0006OV-Kh for pce@ietf.org; Fri, 23 Feb 2007 10:24:33 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2007 10:24:34 -0500 X-IronPort-AV: i="4.14,212,1170651600"; d="scan'208,217"; a="53521958:sNHT72785864" 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 l1NFOWgh031644 for ; Fri, 23 Feb 2007 10:24:32 -0500 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 l1NFOWVT005106 for ; Fri, 23 Feb 2007 10:24:32 -0500 (EST) 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, 23 Feb 2007 10:24:32 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 10:24:31 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <3E90063F-225F-4EEB-A4F8-D76175CE5053@cisco.com> References: From: JP Vasseur Date: Fri, 23 Feb 2007 10:24:30 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Feb 2007 15:24:31.0757 (UTC) FILETIME=[B75323D0:01C7575E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3759; t=1172244272; x=1173108272; 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:=20PCE=20WG=20Draft=20Agenda=20-=20Fwd=3A=20Slot=20Request=20for =20the=20next=20IETF |Sender:=20 |To:=20pce@ietf.org; bh=qH3zQsjuPQS5b3P9QgunWpVK/sQxI1VAU3jDZlRKjkI=; b=ReUNZmnIrNniPa5g7OknEVFFxhSmNa3G3yQDdv+BaLC0dlexKamWNdvQrDtHPnMwU4EgaAOn ee73v4aQ8+F/XRnr4pywMSu6GepmQWxjKvxeehaWiTaGDkdTaLbazj9F; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [Pce] PCE WG Draft Agenda - Fwd: Slot Request for the next IETF 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="===============1224368453==" Errors-To: pce-bounces@lists.ietf.org --===============1224368453== Content-Type: multipart/alternative; boundary=Apple-Mail-194-663542581 --Apple-Mail-194-663542581 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, We'll post the draft agenda March 2. If you need a slot, please let us know by Feb 28. Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: February 2, 2007 5:43:16 PM EST > To: pce@ietf.org > Subject: Slot Request for the next IETF > > Dear WG, > > Since it looks like our meeting will likely be heavily booked, > please let us know if you have slot requests. > > Thanks. > > JP. --Apple-Mail-194-663542581 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII Dear WG,

We'll post the draft agenda = March 2. If you need a slot, please let us know by Feb 28.

Thanks.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = February 2, 2007 5:43:16 PM EST
Subject: = Slot Request for the next IETF

Dear = WG,

Since it looks like our meeting will likely be = heavily booked, please let us know if you have slot requests.


JP.
=

= --Apple-Mail-194-663542581-- --===============1224368453== 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 --===============1224368453==-- From pce-bounces@lists.ietf.org Mon Feb 26 18:58:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLpio-0006pV-Kn; Mon, 26 Feb 2007 18:57:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLphh-0005Tt-MM for pce@ietf.org; Mon, 26 Feb 2007 18:56:25 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLphX-0000Fw-EY for pce@ietf.org; Mon, 26 Feb 2007 18:56:25 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1HLphP-0000p4-QQ for pce@ietf.org; Mon, 26 Feb 2007 23:56:07 +0000 Received: from your029b8cecfe ([217.158.132.153] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 23:56:06 +0000 Message-ID: <032a01c75a01$a84cefb0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: Date: Mon, 26 Feb 2007 23:53:28 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 26 Feb 2007 23:56:07.0205 (UTC) FILETIME=[AE7A0D50:01C75A01] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Pce] New I-D revision:draft-yasukawa-pce-p2mp-req-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, We have updated this I-D to polish the requirements and the text. We would welcome any review and input before we start work on a draft of the necessary PCEP extensions. Thanks, Adrian ----- Original Message ----- From: To: Sent: Monday, February 26, 2007 8:50 PM Subject: I-D ACTION:draft-yasukawa-pce-p2mp-req-02.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : PCC-PCE Communication Requirements for Point to Multipoint > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > Author(s) : S. Yasukawa, A. Farrel > Filename : draft-yasukawa-pce-p2mp-req-02.txt > Pages : 9 > Date : 2007-2-26 > > The Path Computation Element (PCE) provides path computation > functions in support of traffic engineering in Multi-Protocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > Extensions to the MPLS and GMPLS signaling and routing protocols have > been made in support of point-to-multipoint (P2MP) Traffic Engineered > (TE) Label Switched Paths (LSPs). Since P2MP TE LSP routes are > sometimes complex to compute, and given the use of PCE in MPLS > networks it is likely that PCE will be used in P2MP MPLS-TE networks. > > Generic requirements for a communication protocol between Path > Computation Clients (PCCs) and PCEs are presented in "Path > Computation Element (PCE) Communication Protocol Generic > Requirements". This document complements the generic requirements and > presents a detailed set of PCC-PCE communication protocol > requirements for point-to-multipoint MPLS traffic engineering. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yasukawa-pce-p2mp-req-02.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 27 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1wq-0007qp-Kn; Tue, 27 Feb 2007 08:00:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1wp-0007qZ-FP for pce@ietf.org; Tue, 27 Feb 2007 08:00:51 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1wo-00036a-0G for pce@ietf.org; Tue, 27 Feb 2007 08:00:51 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1HM1wn-00054f-G3 for pce@ietf.org; Tue, 27 Feb 2007 13:00:49 +0000 Received: from your029b8cecfe ([217.158.132.200] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:00:44 +0000 Message-ID: <048b01c75a6f$1d00cd50$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "tom.petch" , "JP Vasseur" References: <05e201c739ad$c43854e0$0601a8c0@pc6> <090f01c73b0d$ea029580$0a23fea9@your029b8cecfe> <02aa01c751f6$008b91e0$0601a8c0@pc6> Date: Tue, 27 Feb 2007 12:55:35 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 27 Feb 2007 13:00:45.0772 (UTC) FILETIME=[4B7D48C0:01C75A6F] X-Originating-Rutherford-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: pce@ietf.org Subject: [Pce] Response to Tom Petch (1) comments on draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Tom, Yes, thanks for flagging this to the working group. I have been working with Dave Harrington on the construction of his I-D since there is obvious input that our draft can provide. If/when his work catches up with or overtakes our I-D we will consider cutting over to it. I expect to see some convergence as we 'borrow' ideas from each other's work. At the moment, the tone of Dave's I-D is gentle and it offers 'guidance'. We are currently trying to be a little firmer with our recommendations in the PCE working group. Hopefully this will all be grist to the mill and the community will discover the benefits (or otherwise) of the different approaches and we will learn some lessons that we can continue to refine. I have just submitted an update to the PCE working group document, and I continue to look for feedback from within the working group or without. Thanks, Adrian ----- Original Message ----- From: "tom.petch" To: "Adrian Farrel" ; "JP Vasseur" ; Cc: "Dan ((Dan)) Romascanu" Sent: Friday, February 16, 2007 1:23 PM Subject: Re: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt >A propos of this initiative, I just saw the I-D below which is operating in >the > same space albeit from a different direction. It uses the FCAPS model of > management. > > Tom Petch > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Guidelines forFrom pce-bounces@lists.ietf.org Tue Feb 27 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1wq-0007qp-Kn; Tue, 27 Feb 2007 08:00:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1wp-0007qZ-FP for pce@ietf.org; Tue, 27 Feb 2007 08:00:51 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1wo-00036a-0G for pce@ietf.org; Tue, 27 Feb 2007 08:00:51 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1HM1wn-00054f-G3 for pce@ietf.org; Tue, 27 Feb 2007 13:00:49 +0000 Received: from your029b8cecfe ([217.158.132.200] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:00:44 +0000 Message-ID: <048b01c75a6f$1d00cd50$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "tom.petch" , "JP Vasseur" References: <05e201c739ad$c43854e0$0601a8c0@pc6> <090f01c73b0d$ea029580$0a23fea9@your029b8cecfe> <02aa01c751f6$008b91e0$0601a8c0@pc6> Date: Tue, 27 Feb 2007 12:55:35 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 27 Feb 2007 13:00:45.0772 (UTC) FILETIME=[4B7D48C0:01C75A6F] X-Originating-Rutherford-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: pce@ietf.org Subject: [Pce] Response to Tom Petch (1) comments on draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Tom, Yes, thanks for flagging this to the working group. I have been working with Dave Harrington on the construction of his I-D since there is obvious input that our draft can provide. If/when his work catches up with or overtakes our I-D we will consider cutting over to it. I expect to see some convergence as we 'borrow' ideas from each other's work. At the moment, the tone of Dave's I-D is gentle and it offers 'guidance'. We are currently trying to be a little firmer with our recommendations in the PCE working group. Hopefully this will all be grist to the mill and the community will discover the benefits (or otherwise) of the different approaches and we will learn some lessons that we can continue to refine. I have just submitted an update to the PCE working group document, and I continue to look for feedback from within the working group or without. Thanks, Adrian ----- Original Message ----- From: "tom.petch" To: "Adrian Farrel" ; "JP Vasseur" ; Cc: "Dan ((Dan)) Romascanu" Sent: Friday, February 16, 2007 1:23 PM Subject: Re: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt >A propos of this initiative, I just saw the I-D below which is operating in >the > same space albeit from a different direction. It uses the FCAPS model of > management. > > Tom Petch > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Guidelines for Considering Operations and Management of New > Protocols > Author(s) : D. Harrington > Filename : draft-harrington-operations-and-management-00.txt > Pages : 31 > Date : 2007-2-15 > > New protocols or protocol extensions are best designed with due > consideration of operations and management issues related to the > protocol. Retrofitting operations and management recommendations to > protocols is sub-optimal. The purpose of this document is to provide > guidance to authors of protocol documents about aspects to consider > related to the operations and management that should be considered > for inclusion in documents defining requirements or functionality of > new protocols or protocol extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-harrington-operations-and-management-0 > 0.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 27 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x4-00083L-3M; Tue, 27 Feb 2007 08:01:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x1-00082z-Ry for pce@ietf.org; Tue, 27 Feb 2007 08:01:03 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1x0-000382-Cj for pce@ietf.org; Tue, 27 Feb 2007 08:01:03 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1HM1wz-0005H6-Pa for pce@ietf.org; Tue, 27 Feb 2007 13:01:02 +0000 Received: from your029b8cecfe ([217.158.132.200] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:01:00 +0000 Message-ID: <048d01c75a6f$1f122120$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "JP Vasseur" , References: Date: Tue, 27 Feb 2007 12:55:48 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 27 Feb 2007 13:01:00.0959 (UTC) FILETIME=[548AA2F0:01C75A6F] X-Originating-Rutherford-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: pce@ietf.org Subject: [Pce] Response to Dimitri Papadimitriou comments on draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, In producing the new revision of the WG doc I have made some changes to address your points as follows... > a couple of comments though > > -- concerns on section 3.3 - it will for each document open the pandora > box of the protocol dependencies - these should remain at most > illustrative otherwise > > o) becoming restrictive with respect to the protocol applicability - > > o) potentially impacting and/or assuming other protocol(s) behaviour Quite right. In fact, the intention is to uncover any issues that might prevent future applicability and to unearth any issues that might cause disruptive impacts on other protocoFrom pce-bounces@lists.ietf.org Tue Feb 27 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1wq-0007qp-Kn; Tue, 27 Feb 2007 08:00:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1wp-0007qZ-FP for pce@ietf.org; Tue, 27 Feb 2007 08:00:51 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1wo-00036a-0G for pce@ietf.org; Tue, 27 Feb 2007 08:00:51 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1HM1wn-00054f-G3 for pce@ietf.org; Tue, 27 Feb 2007 13:00:49 +0000 Received: from your029b8cecfe ([217.158.132.200] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:00:44 +0000 Message-ID: <048b01c75a6f$1d00cd50$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "tom.petch" , "JP Vasseur" References: <05e201c739ad$c43854e0$0601a8c0@pc6> <090f01c73b0d$ea029580$0a23fea9@your029b8cecfe> <02aa01c751f6$008b91e0$0601a8c0@pc6> Date: Tue, 27 Feb 2007 12:55:35 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 27 Feb 2007 13:00:45.0772 (UTC) FILETIME=[4B7D48C0:01C75A6F] X-Originating-Rutherford-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: pce@ietf.org Subject: [Pce] Response to Tom Petch (1) comments on draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Tom, Yes, thanks for flagging this to the working group. I have been working with Dave Harrington on the construction of his I-D since there is obvious input that our draft can provide. If/when his work catches up with or overtakes our I-D we will consider cutting over to it. I expect to see some convergence as we 'borrow' ideas from each other's work. At the moment, the tone of Dave's I-D is gentle and it offers 'guidance'. We are currently trying to be a little firmer with our recommendations in the PCE working group. Hopefully this will all be grist to the mill and the community will discover the benefits (or otherwise) of the different approaches and we will learn some lessons that we can continue to refine. I have just submitted an update to the PCE working group document, and I continue to look for feedback from within the working group or without. Thanks, Adrian ----- Original Message ----- From: "tom.petch" To: "Adrian Farrel" ; "JP Vasseur" ; Cc: "Dan ((Dan)) Romascanu" Sent: Friday, February 16, 2007 1:23 PM Subject: Re: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt >A propos of this initiative, I just saw the I-D below which is operating in >the > same space albeit from a different direction. It uses the FCAPS model of > management. > > Tom Petch > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Guidelines forls. In section 3.3 (Liveness Detection and Monitoring) I have added some words to help guide what should be discussed. In section 3.5 (Requirements on Other Protocols and Functional Components) which is also relevant here, I have added a caveat to say that the author is not expected to describe the interaction with every protocol, but should describe the interactions that are assumed in order to achieve correct functioning of the new protocol. Lastly, in section 3.6 (Impact on Network Operation) I have clarified the need for examination of backward compatibility from the perspective of network management. > -- generally speaking, the document should state that manageability > description shall ideally remain device/implementation independent (of > course there will be always exceptions) This is a good point that David Harrington has captured in his I-D. I have added some text to the introduction sections. > -- the document says "3.1 Control of Function and Policy > > This sub-section describes the configurable items that exist for the > control of function or policy" > > the control of functions - via the protocol elements described in the > document is important - but the term policy is to vague at which level of > the policy specification does that section applies Hmmm. I think that I actually meant "Control of Function through Configuration and Policy" That is, I meant that the document should identify which protocol features are controllable through policy. I did not mean that the authors should have to describe in this section how the policy is controlled (since there are frameworks and architectures to discuss that in general terms). I have updated this section accordingly. > -- the document on network operations is important as it forces the writer > to document the dimensions impacting the protocol deployment nevertheless > assuming this is the case (taking the example of the doc. the implementer > is aware of the scaling threat) which mechanism are in place to prevent > protocol deployment ? i guess this boils down somehow to the RFC 1264 > discussion and ultimately to the usefulness of the doc. not in terms of > description but actual practice Thanks for reminding me about RFC 1264 and the discussion that led to it being obsoleted. Yes, in time, this I-D may also be found to be overly oppressive, inflexible, or out of date. Experience will show. At the moment, however, the trend has been to ignore manageability and we are trying this experiment to see if we can get things back on track. By the way, I think section 3.6 (Impact on Network Operation) would benefit from some additional work and I would appreciate textual suggestions. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 27 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x5-00083Y-MU; Tue, 27 Feb 2007 08:01:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x2-000834-Dj for pce@ietf.org; Tue, 27 Feb 2007 08:01:04 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1x1-00037U-44 for pce@ietf.org; Tue, 27 Feb 2007 08:01:04 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1HM1wu-0001WC-08 for pce@ietf.org; Tue, 27 Feb 2007 13:00:57 +0000 Received: from your029b8cecfe ([217.158.132.200] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:00:53 +0000 Message-ID: <048c01c75a6f$1e3de130$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: , "JP Vasseur" References: <54E8FBBA-2663-4745-AF18-539D10613C0B@cisco.com> Protocols > Author(s) : D. Harrington > Filename : draft-harrington-operations-and-management-00.txt > Pages : 31 > Date : 2007-2-15 > > New protocols or protocol extensions are best designed with due > consideration of operations and management issues related to the > protocol. Retrofitting operations and management recommendations to > protocols is sub-optimal. The purpose of this document is to provide > guidance to authors of protocol documents about aspects to consider > related to the operations and management that should be considered > for inclusion in documents defining requirements or functionality of > new protocols or protocol extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-harrington-operations-and-management-0 > 0.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 27 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x4-00083L-3M; Tue, 27 Feb 2007 08:01:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x1-00082z-Ry for pce@ietf.org; Tue, 27 Feb 2007 08:01:03 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1x0-000382-Cj for pce@ietf.org; Tue, 27 Feb 2007 08:01:03 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1HM1wz-0005H6-Pa for pce@ietf.org; Tue, 27 Feb 2007 13:01:02 +0000 Received: from your029b8cecfe ([217.158.132.200] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:01:00 +0000 Message-ID: <048d01c75a6f$1f122120$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "JP Vasseur" , References: Date: Tue, 27 Feb 2007 12:55:48 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 27 Feb 2007 13:01:00.0959 (UTC) FILETIME=[548AA2F0:01C75A6F] X-Originating-Rutherford-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: pce@ietf.org Subject: [Pce] Response to Dimitri Papadimitriou comments on draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, In producing the new revision of the WG doc I have made some changes to address your points as follows... > a couple of comments though > > -- concerns on section 3.3 - it will for each document open the pandora > box of the protocol dependencies - these should remain at most > illustrative otherwise > > o) becoming restrictive with respect to the protocol applicability - > > o) potentially impacting and/or assuming other protocol(s) behaviour Quite right. In fact, the intention is to uncover any issues that might prevent future applicability and to unearth any issues that might cause disruptive impacts on other protoco7a5@mail.gmail.com> Date: Tue, 27 Feb 2007 12:55:40 -0000 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: 27 Feb 2007 13:00:54.0662 (UTC) FILETIME=[50C9CA60:01C75A6F] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: pce@ietf.org Subject: [Pce] Response to Matthew Meyer comments on draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Matthew, Just been updating the working group document... > I wonder if in the 3.x section it might be useful to optionally break out > a > legacy protocol interworking & native backward compatibility implications > subsection to briefly call attention to their management problem spaces. > > I see the topic could fall under '3.5 Requirements on Other Protocols' > however I perceive from the text of that section that the focus is really > upon protocols that are impacted or required by the proposed protocol, > not necessarily older cousins that perform a similar function and might > pose a manageability problem worth reflecting upon. Yes, this is a good catch. I think this forms part of "3.6 Impact on Network Operation" since (we presume!) the backward compatibility issues are only relevant if the older version of the protocol has actually been deployed. I have added some words to that section. Regards, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce Considering Operations and Management of New > Protocols > Author(s) : D. Harrington > Filename : draft-harrington-operations-and-management-00.txt > Pages : 31 > Date : 2007-2-15 > > New protocols or protocol extensions are best designed with due > consideration of operations and management issues related to the > protocol. Retrofitting operations and management recommendations to > protocols is sub-optimal. The purpose of this document is to provide > guidance to authors of protocol documents about aspects to consider > related to the operations and management that should be considered > for inclusion in documents defining requirements or functionality of > new protocols or protocol extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-harrington-operations-and-management-0 > 0.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 27 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x4-00083L-3M; Tue, 27 Feb 2007 08:01:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x1-00082z-Ry for pce@ietf.org; Tue, 27 Feb 2007 08:01:03 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1x0-000382-Cj for pce@ietf.org; Tue, 27 Feb 2007 08:01:03 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1HM1wz-0005H6-Pa for pce@ietf.org; Tue, 27 Feb 2007 13:01:02 +0000 Received: from your029b8cecfe ([217.158.132.200] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:01:00 +0000 Message-ID: <048d01c75a6f$1f122120$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "JP Vasseur" , References: Date: Tue, 27 Feb 2007 12:55:48 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 27 Feb 2007 13:01:00.0959 (UTC) FILETIME=[548AA2F0:01C75A6F] X-Originating-Rutherford-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: pce@ietf.org Subject: [Pce] Response to Dimitri Papadimitriou comments on draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, In producing the new revision of the WG doc I have made some changes to address your points as follows... > a couple of comments though > > -- concerns on section 3.3 - it will for each document open the pandora > box of the protocol dependencies - these should remain at most > illustrative otherwise > > o) becoming restrictive with respect to the protocol applicability - > > o) potentially impacting and/or assuming other protocol(s) behaviour Quite right. In fact, the intention is to uncover any issues that might prevent future applicability and to unearth any issues that might cause disruptive impacts on other protocols. In section 3.3 (Liveness Detection and Monitoring) I have added some words to help guide what should be discussed. In section 3.5 (Requirements on Other Protocols and Functional Components) which is also relevant here, I have added a caveat to say that the author is not expected to describe the interaction with every protocol, but should describe the interactions that are assumed in order to achieve correct functioning of the new protocol. Lastly, in section 3.6 (Impact on Network Operation) I have clarified the need for examination of backward compatibility from the perspective of network management. > -- generally speaking, the document should state that manageability > description shall ideally remain device/implementation independent (of > course there will be always exceptions) This is a good point that David Harrington has captured in his I-D. I have added some text to the introduction sections. > -- the document says "3.1 Control of Function and Policy > > This sub-section describes the configurable items that exist for the > control of function or policy" > > the control of functions - via the protocol elements described in the > document is important - but the term policy is to vague at which level of > the policy specification does that section applies Hmmm. I think that I actually meant "Control of Function through Configuration and Policy" That is, I meant that the document should identify which protocol features are controllable through policy. I did not mean that the authors should have to describe in this section how the policy is controlled (since there are frameworks and architectures to discuss that in general terms). I have updated this section accordingly. > -- the document on network operations is important as it forces the writer > to document the dimensions impacting the protocol deployment nevertheless > assuming this is the case (taking the example of the doc. the implementer > is aware of the scaling threat) which mechanism are in place to prevent > protocol deployment ? i guess this boils down somehow to the RFC 1264 > discussion and ultimately to the usefulness of the doc. not in terms of > description but actual practice Thanks for reminding me about RFC 1264 and the discussion that led to it being obsoleted. Yes, in time, this I-D may also be found to be overly oppressive, inflexible, or out of date. Experience will show. At the moment, however, the trend has been to ignore manageability and we are trying this experiment to see if we can get things back on track. By the way, I think section 3.6 (Impact on Network Operation) would benefit from some additional work and I would appreciate textual suggestions. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 27 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x5-00083Y-MU; Tue, 27 Feb 2007 08:01:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x2-000834-Dj for pce@ietf.org; Tue, 27 Feb 2007 08:01:04 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1x1-00037U-44 for pce@ietf.org; Tue, 27 Feb 2007 08:01:04 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1HM1wu-0001WC-08 for pce@ietf.org; Tue, 27 Feb 2007 13:00:57 +0000 Received: from your029b8cecfe ([217.158.132.200] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:00:53 +0000 Message-ID: <048c01c75a6f$1e3de130$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: , "JP Vasseur" References: <54E8FBBA-2663-4745-AF18-539D10613C0B@cisco.com> Date: Tue, 27 Feb 2007 12:55:40 -0000 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: 27 Feb 2007 13:00:54.0662 (UTC) FILETIME=[50C9CA60:01C75A6F] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: pce@ietf.org Subject: [Pce] Response to Matthew Meyer comments on draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Matthew, Just been updating the working group document... > I wonder if in the 3.x section it might be useful to optionally break out > a > legacy protocol interworking & native backward compatibility implications > subsection to briefly call attention to their management problem spaces. > > I see the topic could fall under '3.5 Requirements on Other Protocols' > however I perceive from the text of that section that the focus is really > upon protocols that are impacted or required by the proposed protocol, > not necessarily older cousins that perform a similar function and might > pose a manageability problem worth reflecting upon. Yes, this is a good catch. I think this forms part of "3.6 Impact on Network Operation" since (we presume!) the backward compatibility issues are only relevant if the older version of the protocol has actually been deployed. I have added some words to that section. Regards, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ls. In section 3.3 (Liveness Detection and Monitoring) I have added some words to help guide what should be discussed. In section 3.5 (Requirements on Other Protocols and Functional Components) which is also relevant here, I have added a caveat to say that the author is not expected to describe the interaction with every protocol, but should describe the interactions that are assumed in order to achieve correct functioning of the new protocol. Lastly, in section 3.6 (Impact on Network Operation) I have clarified the need for examination of backward compatibility from the perspective of network management. > -- generally speaking, the document should state that manageability > description shall ideally remain device/implementation independent (of > course there will be always exceptions) This is a good point that David Harrington has captured in his I-D. I have added some text to the introduction sections. > -- the document says "3.1 Control of Function and Policy > > This sub-section describes the configurable items that exist for the > control of function or policy" > > the control of functions - via the protocol elements described in the > document is important - but the term policy is to vague at which level of > the policy specification does that section applies Hmmm. I think that I actually meant "Control of Function through Configuration and Policy" That is, I meant that the document should identify which protocol features are controllable through policy. I did not mean that the authors should have to describe in this section how the policy is controlled (since there are frameworks and architectures to discuss that in general terms). I have updated this section accordingly. > -- the document on network operations is important as it forces the writer > to document the dimensions impacting the protocol deployment nevertheless > assuming this is the case (taking the example of the doc. the implementer > is aware of the scaling threat) which mechanism are in place to prevent > protocol deployment ? i guess this boils down somehow to the RFC 1264 > discussion and ultimately to the usefulness of the doc. not in terms of > description but actual practice Thanks for reminding me about RFC 1264 and the discussion that led to it being obsoleted. Yes, in time, this I-D may also be found to be overly oppressive, inflexible, or out of date. Experience will show. At the moment, however, the trend has been to ignore manageability and we are trying this experiment to see if we can get things back on track. By the way, I think section 3.6 (Impact on Network Operation) would benefit from some additional work and I would appreciate textual suggestions. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 27 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x5-00083Y-MU; Tue, 27 Feb 2007 08:01:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1x2-000834-Dj for pce@ietf.org; Tue, 27 Feb 2007 08:01:04 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1x1-00037U-44 for pce@ietf.org; Tue, 27 Feb 2007 08:01:04 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1HM1wu-0001WC-08 for pce@ietf.org; Tue, 27 Feb 2007 13:00:57 +0000 Received: from your029b8cecfe ([217.158.132.200] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:00:53 +0000 Message-ID: <048c01c75a6f$1e3de130$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: , "JP Vasseur" References: <54E8FBBA-2663-4745-AF18-539D10613C0B@cisco.com> Date: Tue, 27 Feb 2007 12:55:40 -0000 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: 27 Feb 2007 13:00:54.0662 (UTC) FILETIME=[50C9CA60:01C75A6F] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: pce@ietf.org Subject: [Pce] Response to Matthew Meyer comments on draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Matthew, Just been updating the working group document... > I wonder if in the 3.x section it might be useful to optionally break out > a > legacy protocol interworking & native backward compatibility implications > subsection to briefly call attention to their management problem spaces. > > I see the topic could fall under '3.5 Requirements on Other Protocols' > however I perceive from the text of that section that the focus is really > upon protocols that are impacted or required by the proposed protocol, > not necessarily older cousins that perform a similar function and might > pose a manageability problem worth reflecting upon. Yes, this is a good catch. I think this forms part of "3.6 Impact on Network Operation" since (we presume!) the backward compatibility issues are only relevant if the older version of the protocol has actually been deployed. I have added some words to that section. Regards, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 27 08:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1xB-00085U-TT; Tue, 27 Feb 2007 08:01:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM1xA-00085G-A3 for pce@ietf.org; Tue, 27 Feb 2007 08:01:12 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM1x7-00039d-Vs for pce@ietf.org; Tue, 27 Feb 2007 08:01:12 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1HM1x6-000231-Uk for pce@ietf.org; Tue, 27 Feb 2007 13:01:09 +0000 Received: from your029b8cecfe ([217.158.132.200] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 13:01:05 +0000 Message-ID: <048e01c75a6f$2bdde2e0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "tom.petch" , "JP Vasseur" References: <05e201c739ad$c43854e0$0601a8c0@pc6> <090f01c73b0d$ea029580$0a23fea9@your029b8cecfe> Date: Tue, 27 Feb 2007 12:56:01 -0000 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: 27 Feb 2007 13:01:06.0162 (UTC) FILETIME=[57A48D20:01C75A6F] X-Originating-Heisenberg-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: pce@ietf.org Subject: [Pce] Response to Tom Petch (2) comments on draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Tom, In updating the working group draft I have added some general text describing manageability, FCAPS and the management plane. Also a reference to draft-harrington-operations-and-management. I have tried not to make this a book on the topic, but if you have any specific suggestions for text to include, I'd be willing to fold them in. Thanks, Adrian >>I think that this draft should start from a broader perspective of what >> management is before getting into what I see as the details, especially >> if the intent is to roll it out across other WG. I think that that is >> particularly important in PCE because of the specialised usage of the >> term management that may crop up (as in the individual ccamp I-D that was >> entitled 'GMPLS Signaling Extensions for the Transfer of >> Ownership of Label Switched Paths Between the Management and >> Control Planes' which is not a use of the word management that I expect >> many in the IETF - but not other SDOs - outside these working groups >> would recognise). >> >> I might use a model of management as made up of:- >> Security, Accounting, Configuration, Fault, Performance; >> of which, Security is already accounted for, Accounting is out of >> scope and the remaining detail items are structured under one of >> the other three. >> >> I am concerned that, without a paragraph or two of overview along these >> lines, the wood will be lost amongst the trees. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 27 20:33:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMDgJ-0002ch-Oo; Tue, 27 Feb 2007 20:32:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMDYr-0000gV-6o for pce@ietf.org; Tue, 27 Feb 2007 20:24:53 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMDWG-0001nF-OD for pce@ietf.org; Tue, 27 Feb 2007 20:22:14 -0500 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1HMDWB-0002v3-Tc for pce@ietf.org; Wed, 28 Feb 2007 01:22:08 +0000 Received: from your029b8cecfe ([217.158.132.175] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 01:22:06 +0000 Message-ID: <059901c75ad6$d84c03b0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 28 Feb 2007 01:20:00 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 28 Feb 2007 01:22:06.0679 (UTC) FILETIME=[DC2D0E70:01C75AD6] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Pce] New I-D:draft-yasukawa-pce-p2mp-app-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, We have written an I-D to discuss how PCE might be applicable to P2MP MPLS-TE. This I-D is not necessarily going all the way to RFC (although it could). It is mainly designed to stimulate debate about how and if PCE should be used to address path computation for P2MP LSPs. Comments solicited. Thanks, Adrian ----- Original Message ----- From: To: Sent: Tuesday, February 27, 2007 8:50 PM Subject: I-D ACTION:draft-yasukawa-pce-p2mp-app-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Applicability of the Path Computation Element (PCE) to > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) Traffic Engineering (TE) > Author(s) : S. Yasukawa, A. Farrel > Filename : draft-yasukawa-pce-p2mp-app-00.txt > Pages : > Date : 2007-2-27 > > The Path Computation Element (PCE) provides path computation > functions in support of traffic engineering in Multi-Protocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > Extensions to the MPLS and GMPLS signaling and routing protocols have > been made in support of point-to-multipoint (P2MP) Traffic Engineered > (TE) Label Switched Paths (LSPs). > > This document examines the applicability of PCE to path computation > P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation > for using a PCE to compute these paths, and examines which of the > PCE architectural models are appropriate. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yasukawa-pce-p2mp-app-00.txt > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 28 11:40:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMRqH-0005zb-TQ; Wed, 28 Feb 2007 11:39:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMRqG-0005vZ-IB for pce@ietf.org; Wed, 28 Feb 2007 11:39:48 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMRqE-0003Kj-4U for pce@ietf.org; Wed, 28 Feb 2007 11:39:48 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 17:39:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Feb 2007 17:39:24 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-leroux-pce-of-00.txt Thread-Index: AcdbVwERm/G70y43SzGrppgaWl9PcQ== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 28 Feb 2007 16:39:38.0556 (UTC) FILETIME=[09A6D7C0:01C75B57] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Subject: [Pce] draft-leroux-pce-of-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1739241126==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1739241126== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75B57.09569CC2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75B57.09569CC2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This new draft defines PCED and PCEP extensions for the encoding of objective functions. We are waiting for WG feedback/comments. http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00.txt Regards, JL ------_=_NextPart_001_01C75B57.09569CC2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-leroux-pce-of-00.txt

Hi all,

This new draft defines PCED and PCEP = extensions for the encoding of objective functions.
We are waiting for WG = feedback/comments.

<= U>http://www.ietf.org/internet-drafts/draft-leroux-pce-of-00= .txt

Regards,

JL


------_=_NextPart_001_01C75B57.09569CC2-- --===============1739241126== 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 --===============1739241126==-- From pce-bounces@lists.ietf.org Wed Feb 28 19:17:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYyL-0002EV-T7; Wed, 28 Feb 2007 19:16:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYyK-0002E1-Kn for pce@ietf.org; Wed, 28 Feb 2007 19:16:36 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMYy7-0006p3-0q for pce@ietf.org; Wed, 28 Feb 2007 19:16:36 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1172707773!11800689!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 12120 invoked from network); 1 Mar 2007 00:09:33 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-120.messagelabs.com with SMTP; 1 Mar 2007 00:09:33 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2109TBG018469; Wed, 28 Feb 2007 19:09:29 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2109MAw018435; Wed, 28 Feb 2007 19:09:22 -0500 (EST) 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] New I-D:draft-yasukawa-pce-p2mp-app-00.txt Date: Wed, 28 Feb 2007 18:09:22 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8258@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <059901c75ad6$d84c03b0$0a23fea9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New I-D:draft-yasukawa-pce-p2mp-app-00.txt Thread-Index: Acda2Kq5+dWptKZPTpS8VQlEMKTAXgArj1mA From: "ASH, GERALD R, ATTLABS" To: "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Brief comments: 1. It certainly seems worthwhile to include path computation for P2MP LSPs within PCE capability; is this within the PCE charter scope, or does it require an extension? 2. Real-time P2MP path computation seems like an especially good application of PCE (offload large computational tasks needed in real time). 3. Need to be careful to confine the complexity of P2MP path computation. E.g., it isn't obvious that fragmenting the computation of the P2MP tree, as described in Section 3, does not significantly increase the complexity of P2MP path computation. 4. Editorial: Section 3 (Manageability Considerations) follows Section 7 (Disjoint Paths). Overall support/encourage to progress the work. Thanks, Jerry -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, February 27, 2007 8:20 PM To: pce@ietf.org Subject: [Pce] New I-D:draft-yasukawa-pce-p2mp-app-00.txt=20 Hi, We have written an I-D to discuss how PCE might be applicable to P2MP=20 MPLS-TE. This I-D is not necessarily going all the way to RFC (although it could). It=20 is mainly designed to stimulate debate about how and if PCE should be used=20 to address path computation for P2MP LSPs. Comments solicited. Thanks, Adrian ----- Original Message -----=20 From: To: Sent: Tuesday, February 27, 2007 8:50 PM Subject: I-D ACTION:draft-yasukawa-pce-p2mp-app-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Applicability of the Path Computation Element (PCE) to=20 > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) and=20 > Generalized MPLS (GMPLS) Traffic Engineering (TE) > Author(s) : S. Yasukawa, A. Farrel > Filename : draft-yasukawa-pce-p2mp-app-00.txt > Pages : > Date : 2007-2-27 > > The Path Computation Element (PCE) provides path computation > functions in support of traffic engineering in Multi-Protocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) networks. > > Extensions to the MPLS and GMPLS signaling and routing protocols have > been made in support of point-to-multipoint (P2MP) Traffic Engineered > (TE) Label Switched Paths (LSPs). > > This document examines the applicability of PCE to path computation > P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation > for using a PCE to compute these paths, and examines which of the > PCE architectural models are appropriate. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yasukawa-pce-p2mp-app-00.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce

JP,

 

We mean that those inter-ASBR TE LSPs which are permitted by policy/scaling configuration to be propagated outside can be propogated to PCEs in neighbouring ASes by BGP.This information is not flooded to all BGP = speakers of neighbouring ASes but only to speakers which are on PCEs or which = propogate them to PCEs ( which support the new AFI/SAFI).

 

 These LSPs may be a sub-set of TE LSPs specifically provisioned for carrying = inter-AS TE traffic and may be a full mesh. If all the ASes support such a = mechanism then the itner-AS TE path can be calculated using the inter-AS graph of = such LSPs and inter-AS links.

 

 

Then I've got a much major concern then. Back to when the inter-domain TE discussion started (a few = years back), several potential candidates have been investigated including the = TE aggregation technique that you propose and that has been excluded for = a number of reasons (see also = RFC4105 and RFC4216). Thus we proposed two techniques: per-domain and the PCE = (where no aggregated TE data is leaked between domains !). You may want to refer = to the lists archives for details but TE aggregation has been rejected, this is precisely why we developed PCE-based computation for = inter-domain TE. 

 

I certainly do not want to re-open the debate for the Nth time, = but just consider that in your proposal you would not have to flood just one = TE LSP per pair of ASBR but one TE LSP per attribute per pair of ASBRs = (combining affinity, CTs, metric, ... ) and for all domains + this would of course = be dynamic (based on the TE LSP when they get rerouted because of failures, reoptimization, ...).



[[Vijay ]] I ll go through the arguments in the = mailing list archive, thanks for the pointer.  We are not suggesting this as a = solution always, but use it wherever possible since it is a step towards = optimality. The aggregation and distribution is limited to the PCEs, and this = information is not flooded to the rest of the network.

 

But, this kind of itner-ASBR LSP propogation may not be always possible = because of policy and scaling constraints. In such situations we have only the ASes = and their inter-AS links in the form of an inter-AS graph and we can only = find the ‘possible’ AS paths after eliminating the paths through = inter-AS links which are not feasible and then use methods like BRPC to complete = the path setup.

 

But in this case, it is probably not worth the work: you do not = have the 'possible' AS since you do not have any information about the = resource available within each AS.

 

[[Vijay ]] But is it not better than trying all = possible ASpaths towards a destination. In this method we can certainly eliminate many of = the AS paths where the inter-AS link cannot support the path. This may also be = useful for finding backup paths since the inter-AS graph is known. =

Hope this helps.

 

Thanks.

 

JP.



 

Regards

Vijay

 

 

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com] =
Sent: Saturday, February 03, 2007 4:05 AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

 

Hi,

 

Let me first try to make sure of something here. When you write = "The PCE shall learn the TE 

   attributes of the inter-AS TE links and the TE tunnels that = exist 

   between the ASBRs in the domain."

 

Are you suggesting to flood via BGP the intra-domain TE LSPs ? In other words, = suppose the following scenario:

 

AS1---AS2---AS3

You have a mesh of intra-domain TE LSPs between all ASBRs within = AS2.

 

Are you suggesting to flood in AS1 these TE LSPs (and this for all other ASes that might be between AS1 and the destination domain) ?

 

Thanks.

 

JP.

 

On = Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. = wrote:

 

Are you = suggesting that  BGP should propagate all possible next-hops/As paths and regular = path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ?

 

The inter-AS TE link information can be made aware only to the ASes on = either side of the inter-AS link by the IGP. It may not be possible to propagate it = beyond that ( or can it ?).

So some of the possible AS paths found by BGP( if we propagate all = next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of = violation of some TE constraint.

 

In our proposal we can pick the paths which are really feasible, since we have = the inter-AS graph, and then invoke methods like = BRPC

 

Regards

Vijay

 

 

 

 

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Thursday, February 01, 2007 1:19 AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

 

Hi,

 

On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. = wrote:

 

 

Hello all,

We have submitted the following I-D, please send in = your

comments/suggestions

 

* speaking as a technical contributor = *

 

   In [BRPC], a method to optimally compute a inter-domain TE 

   path for MPLS and GMPS LSPs using the PCE architecture detailed in 

   [PCE_ARCH] is described. However the method = described requires the 

   list of Autonomous systems or domains to be determined apriori. 

   Determining the list of ASes/domains to be = traversed to reach a 

   destination, satisfying the TE constraints is non-trivial. It 

   requires knowledge of the inter-AS = connectivity and the TE 

   characteristics of the inter-AS links along = with the knowledge of 

   the available paths within each of the = ASes/domains. BGP contains 

   information on the list of ASes to be = traversed to reach a 

   destination, however BGP route selection and = decision process 

   truncates most of the feasible paths, and it = also does not carry 

   the TE characteristics of the inter-AS links = and path availability 

   within a domain. =  

 

What does prevent you from relying on BGP to provide you = all possible paths toward 

a specific destination skipping the regular path selection = process for specific routes (see

proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE

link could easily be obtained via the IGP with minor = additions.

 

This is in my opinion a fundamental question that must = first be addressed before 

moving forward.

 

Thanks.

 

JP.

 

 

Regards

Vijay

 

X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Thread-Index: AcdJD0TW5ygApM26R9qKCYqAuYCvOwAA/B0A From: "Vijayanand C - TLS, Chennai." To: "JP Vasseur" X-OriginalArrivalTime: 05 Feb 2007 11:06:21.0682 (UTC) FILETIME=[AB15C520:01C74915] X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-18.0820 TC:1F TRN:94 TV:3.6.1039(14978.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: a823e5c4d849e1d26acd3270cf7db916 X-Mailman-Approved-At: Mon, 05 Feb 2007 06:40:23 -0500 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="===============0919584742==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0919584742== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74915.9D6D5F1E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74915.9D6D5F1E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JP, =20 We mean that those inter-ASBR TE LSPs which are permitted by policy/scaling configuration to be propagated outside can be propogated to PCEs in neighbouring ASes by BGP.This information is not flooded to all BGP speakers of neighbouring ASes but only to speakers which are on PCEs or which propogate them to PCEs ( which support the new AFI/SAFI). =20 These LSPs may be a sub-set of TE LSPs specifically provisioned for carrying inter-AS TE traffic and may be a full mesh. If all the ASes support such a mechanism then the itner-AS TE path can be calculated using the inter-AS graph of such LSPs and inter-AS links. =20 =20 Then I've got a much major concern then. Back to when the inter-domain TE discussion started (a few years back), several potential candidates have been investigated including the TE aggregation technique that you propose and that has been excluded for a number of reasons (see also RFC4105 and RFC4216). Thus we proposed two 2.0pt; color:black'>-----Original Message-----

Sent: Tuesday, January 23, 2007 2:20 = AM

Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt 

 

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

directories.

 

 

          =   Title           &n= bsp;      : A BGP based method to compute inter-AS = Traffic

engineering Label Switched Paths with = PCE

mailto:jvasseur@cisco.com]=20 Sent: Thursday, February 01, 2007 1:19 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =20 Hi, =20 On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: =20 =20 Hello all, We have submitted the following I-D, please send in your comments/:.5in'>          =   Author(s)          : C. Vijayanand, S. Bhattacharya

          =   Filename           = :

draft-vijay-somen-pce-bgp-interas-te-path-01.txt

          =   Pages           &n= bsp;   : 26

          =   Date           &nb= sp;     : 2007-1-22

     &nbs= p;     

The ability to compute an optimal path for setting up Traffic 

   engineering Label Switched Paths spanning = multiple autonomous 

   systems managed by different operators has = been a key requirement in 

   MPLS and GMPLS networks. This document = specifies a method of 

   computing inter-AS paths consisting of a list = of ASes to be 

   traversed and a list of TE-Tunnels to be = traversed in each AS. The 

Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, January 23, 2007 2:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =20 =20 Title : A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-bgp-interas-te-path-01.txt Pages : 26 Date : 2007-1-22 =20 The ability to compute an optimal path for setting up Traffic=20 engineering Label Switched Paths spanning multiple autonomous=20 systems managed by different operators has been a key requirement in=20 MPLS and GMPLS networks. This document specifies a method of=20 computing inter-AS paths consisting of a list of ASes to be=20 traversed and a list of TE-Tunnels to be traversed in each AS. The=20 method described here uses BGP speakers in the PCEs of each AS to=20 distribute the inter-AS connectivity information and the TE-Tunnels=20 in each AS to its neighbors to facilitate the construction of an=20 inter-AS topology graph which can be used for computing inter-AS paths. =20 A URL for this Internet-Draft is: =20 http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-interas-te -path-01.txt =20 =20 =20 DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- =20 The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 =3D'font-size:12.0pt; color:black'>   method described here uses BGP speakers in the = PCEs of each AS to 

   distribute the inter-AS connectivity = information and the TE-Tunnels 

   in each AS to its neighbors to facilitate the construction of an 

   inter-AS topology graph which can be used for computing inter-AS

    paths.

 

A URL for this Internet-Draft is:

-path-01.txt

 

 

 

DISCLAIMER:

------------------------------------------------------------= -----------------------------------------------------------=

Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 =20 =20 =20 ------_=_NextPart_001_01C74915.9D6D5F1E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JP,

 

We mean that those inter-ASBR TE LSPs which are permitted by policy/scaling configuration to be propagated outside can be propogated to PCEs in neighbouring ASes by BGP.This information is not flooded to all BGP = speakers of neighbouring ASes but only to speakers which are on PCEs or which = propogate them to PCEs ( which support the new AFI/SAFI).

 

 These LSPs may be a sub-set of TE LSPs specifically provisioned for carrying = inter-AS TE traffic and may be a full mesh. If all the ASes support such a = mechanism then the itner-AS TE path can be calculated using the inter-AS graph of = such LSPs and inter-AS links.

 

 

Then I've got a much major concern then. Back to when the inter-domain TE discussion started (a few = years back), several potential candidates have been investigated including the = TE aggregation technique that you propose and that has been excluded for = a number of reasons (see also = RFC4105 and RFC4216). Thus we proposed two techniques: per-domain and the PCE = (where no aggregated TE data iheight: 14px'>

 

The contents of this e-mail and any attachment(s) are = confidential and intended for the named recipient(s) only.

It shall not attach any liability on the originator or HCL = or its affiliates. Any views or opinions presented = in 

this email are solely those of the author and may not = necessarily reflect the opinions of HCL or its affiliates.

Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication = of 

this message without the prior written consent of the = author of this e-mail is strictly prohibited. If you = have 

received this email in error please delete it and notify = the sender immediately. Before opening any mail = and 

attachments please check them for viruses and = defect.

 

------------------------------------------------------------= -----------------------------------------------------------=

 

_______________________________________________

Pce mailing list

 

I certainly do not want to re-open the debate for the Nth time, = but just consider that in your proposal you would not have to flood just one = TE LSP per pair of ASBR but one TE LSP per attribute per pair of ASBRs = (combining affinity, CTs, metric, ... ) and for all domains + this would of course = be dynamic (based on the TE LSP when they get rerouted because of failures, reoptimization, ...).



[[Vijay ]] I ll go through the arguments in the = mailing list archive, thanks for the pointer.  We are not suggesting this as a = solution always, but use it wherever possible since it is a step towards = optimality. The aggregation and distribution is limited to the PCEs, and this = information is not flooded to the rest of the network.

 

But, this kind of itner-ASBR LSP propogation may not be always possible = because of policy and scaling constraints. In such situations we have only the ASes = and their inter-AS links in the form of an inter-AS graph and we can only = find the ‘possible’ AS paths after eliminating the paths through = inter-AS links which are not feasible and then use methods like BRPC to complete = the path setup.

 

But in this case, it is probably not worth the work: you do not = have the 'possible' AS since you do not have any information about the = resource available within each AS.

 

[[Vijay ]] But is it not better than trying all = possible ASpaths towards a destination. In this method we can certainly eliminate many of = the AS paths where the inter-AS link cannot support the path. This may also be = useful for finding backup paths since the inter-AS graph is known. =

Hope this helps.

 

Thanks.

<.5in'>Pce@lists.ietf.org

 

 

 



 

------_=_NextPart_001_01C74915.9D6D5F1E-- --===============0919584742== 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 --===============0919584742==-- From pce-bounces@lists.ietf.org Mon Feb 05 06:40:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE2Cv-0007W5-0j; Mon, 05 Feb 2007 06:40:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1xU-0000Wi-V5 for pce@ietf.org; Mon, 05 Feb 2007 06:24:28 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE1xH-0007VT-Hc for pce@ietf.org; Mon, 05 Feb 2007 06:24:28 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2007 06:24:16 -0500 X-IronPort-AV: i="4.13,282,1167627600"; d="scan'208,217"; a="113143199:sNHT272687964" 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 l15BOFZu026345; Mon, 5 Feb 2007 06:24:15 -0500 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 l15BOEVT004987; Mon, 5 Feb 2007 06:24:14 -0500 (EST) 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); Mon, 5 Feb 2007 06:24:14 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 06:24:10 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Date:/div>

 

JP.



 

Regards

Vijay

 

 

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com] =
Sent: Saturday, February 03, 2007 4:05 AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

 

Hi,

 

Let me first try to make sure of something here. When you write = "The PCE shall learn the TE 

   attributes of the inter-AS TE links and the TE tunnels that = exist 

X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 05 Feb 2007 11:24:10.0902 (UTC) FILETIME=[2863CB60:01C74918] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=98961; t=1170674655; x=1171538655; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20RE=3A=20I-D=20=20=20=20ACTION=3Adraft-vijay-s omen-pce-bgp-interas-te-path-01.txt=20 |Sender:=20 |To:=20=22Vijayanand=20C=20-=20TLS,=20Chennai.=22=20; bh=6LmutWYIwWazGsYpmyeb76lZIdtEKS5/ptsOsxl6jSE=; b=KaoRBE5u9Uw8k49CcWSO/kPz3IOe4uFyMCSJFMxdXbffS0wraWxxtIAdiQwPppnKJokredbZ c9cqIu4CA/A02miivH0OBOWEWHgIZyOvoKCc6ObtqmoSWGSKGhu5o3DX; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d4a64066b1774fc2641038d4c8545f6 X-Mailman-Approved-At: Mon, 05 Feb 2007 06:40:23 -0500 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="===============2006108600==" Errors-To: pce-bounces@lists.ietf.org --===============2006108600== Content-Type: multipart/alternative; boundary=Apple-Mail-177--906076241 --Apple-Mail-177--906076241 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Vijay, On Feb 5, 2007, at 6:05 AM, Vijayanand C - TLS, Chennai. wrote: > JP, > > > We mean that those inter-ASBR TE LSPs which are permitted by policy/=20= > scaling configuration to be propagated outside can be propogated to =20= > PCEs in neighbouring ASes by BGP.This information is not flooded to =20= > all BGP speakers of neighbouring ASes but only to speakers which =20 > are on PCEs or which propogate them to PCEs ( which support the new =20= > AFI/SAFI). > > > These LSPs may be a sub-set of TE LSPs specifically provisioned =20 > for carrying inter-AS TE traffic and may be a full mesh. If all the =20= > ASes support such a mechanism then the itner-AS TE path can be =20 > calculated using the inter-AS graph of such LSPs and inter-AS links. > > > > Then I've got a much major concern then. Back to when the inter-=20 > domain TE discussion started (a few years back), several potential =20 > candidates have been investigated including the TE aggregation =20 > technique that you propose and that has been excluded for a number =20 > of reasons (see also RFC4105 and RFC4216). Thus we proposed two =20 > techniques: per-domain and the PCE (where no aggregated TE data is =20 > leaked between domains !). You may want to refer to the lists =20 > archives for details but TE aggregation has been rejected, this is =20 > precisely why we developed PCE-based computation for inter-domain TE. > > > I certainly do not want to re-open the debate for the Nth time, but =20= > just consider that in your proposal you would not have to flood =20 > just one TE LSP per pair of ASBR but one TE LSP per attribute per =20 > pair of ASBRs (combining affinity, CTs, metric, ... ) and for all =20 > domains + this would of course be dynamic (based on the TE LSP when =20= > they get rerouted because of failures, reoptimization, ...). > > > > > [[Vijay ]] I ll go through the arguments in the mailing list =20 > archive, thanks for the pointer. We are not suggesting this as a =20 > solution always, but use it wherever possible since it is a step =20 > towards optimality. The aggv>

   between the ASBRs in the domain."

 

Are you suggesting to flood via BGP the intra-domain TE LSPs ? In other words, = suppose the following scenario:

 

AS1---AS2---AS3

You have a mesh of intra-domain TE LSPs between all ASBRs within = AS2.

 

Are you suggesting to flood in AS1 these TE LSPs (and this for all other ASes that might be between AS1 and the destination domain) ?

 

Thanks.

 

JP.

 

On = Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. = wrote:

 

Are you = suggesting that  BGP should propagate all possible next-hops/As paths and regular = path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ?

the PCEs, and this information is not flooded to the rest of the =20 > network. I understand, but still, the solution requires to set up N meshes of =20 TE LSPs between all ASBRs (there are many deployment where the TE =20 LSPs are not deployed between the ASBRs but a set of P routers) where =20= N may be large depending on the set of attributes in use. Note that =20 the attributes of these TE LSPs are dynamic (bandwidth, metric =20 (dependency with the path), ... Furthermore this is not compliant with RFC4216 and RFC4105. All the arguments that have been discussed on the mailing list still =20 applies here: also think of the mechanisms that is required to ensure =20= a quick feed-back mechanism between the Inter-ASBR TE LSP states =20 announced through BGP to the various domains and the path computation =20= process during a burst of requests. > > But, this kind of itner-ASBR LSP propogation may not be always =20 > possible because of policy and scaling constraints. In such =20 > situations we have only the ASes and their inter-AS links in the =20 > form of an inter-AS graph and we can only find the =91possible=92 AS =20= > paths after eliminating the paths through inter-AS links which are =20 > not feasible and then use methods like BRPC to complete the path =20 > setup. > > > But in this case, it is probably not worth the work: you do not =20 > have the 'possible' AS since you do not have any information about =20 > the resource available within each AS. > > > [[Vijay ]] But is it not better than trying all possible ASpaths =20 > towards a destination. In this method we can certainly eliminate many Why "many" ? That depends on many factors .. that may be a low as 0 =20 if the inter-AS TE links are all acceptable for a set of constraints. > of the AS paths where the inter-AS link cannot support the path. =20 > This may also be useful for finding backup paths since the inter-AS =20= > graph is known. Thanks. JP. > Hope this helps. > > > Thanks. > > > JP. > > > > > > Regards > > Vijay > > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Saturday, February 03, 2007 4:05 AM > To: Vijayanand C - TLS, Chennai. > Cc: pce@ietf.org > Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-=20= > te-path-01.txt > > > Hi, > > > Let me first try to make sure of something here. When you write =20 > "The PCE shall learn the TE > > attributes of the inter-AS TE links and the TE tunnels that exist > > between the ASBRs in the domain." > > > Are you suggesting to flood via BGP the intra-domain TE LSPs ? In =20 > other words, suppose the following scenario: > > > AS1---AS2---AS3 > > You have a mesh of intra-domain TE LSPs between all ASBRs within AS2. > > > Are you suggesting to flood in AS1 these TE LSPs (and this for all =20 > other ASes that might be between AS1 and the destination domain) ? > > > Thanks. > > > JP. > > > On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. wrote: > > > Are you suggesting that BGP should propagate all possible next-=20 > hops/As paths and regular path selection process avoided for all =20 > prefixes which can be destinations of inter-AS TE tunnels ? > > > The inter-AS TE link information can be made aware only to the ASes =20= > on either side of the inter-AS link by the IGP. It may not be =20 > possible to propagate it beyond that ( or can it ?). > > So some of the possible AS paths found by BGP( if we propagate all =20 > next-hops/aspaths in bgp) may not be worth trying for path setup =20 > (by BRPC) because of violation of some TE constraint. > > > In our proposal we can pick the paths which are really feasible, =20 > since we have the inter-AS graph, and then invoke methods like BRPC > > > Regards > > Vijay > > > > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, February 01, 2007 1:19 AM > To: Vijayanand C - TLS, Chennai. > Cc: pce@ietf.org > Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-=20= > te-path-01.txt > > >

 

The inter-AS TE link information can be made aware only to the ASes on = either side of the inter-AS link by the IGP. It may not be possible to propagate it = beyond that ( or can it ?).

So some of the possible AS paths found by BGP( if we propagate all = next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of = violation of some TE constraint.

 

In our proposal we can pick the paths which are really feasible, since we have = the inter-AS graph, and then invoke methods like = BRPC

 

Regards

Vijay

 

 

 

 

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Thursday, February 01, 2007 1:19 AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org<> Hi, > > > On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: > > > > Hello all, > > We have submitted the following I-D, please send in your > > comments/suggestions > > > * speaking as a technical contributor * > > > In [BRPC], a method to optimally compute a inter-domain TE > > path for MPLS and GMPS LSPs using the PCE architecture detailed in > > [PCE_ARCH] is described. However the method described requires the > > list of Autonomous systems or domains to be determined apriori. > > Determining the list of ASes/domains to be traversed to reach a > > destination, satisfying the TE constraints is non-trivial. It > > requires knowledge of the inter-AS connectivity and the TE > > characteristics of the inter-AS links along with the knowledge of > > the available paths within each of the ASes/domains. BGP contains > > information on the list of ASes to be traversed to reach a > > destination, however BGP route selection and decision process > > truncates most of the feasible paths, and it also does not carry > > the TE characteristics of the inter-AS links and path availability > > within a domain. > > > What does prevent you from relying on BGP to provide you all =20 > possible paths toward > > a specific destination skipping the regular path selection process =20 > for specific routes (see > > proposals made in the past) and then use BRPC as currently =20 > specified? The Inter-AS TE > > link could easily be obtained via the IGP with minor additions. > > > This is in my opinion a fundamental question that must first be =20 > addressed before > > moving forward. > > > Thanks. > > > JP. > > > > Regards > > Vijay > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, January 23, 2007 2:20 AM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : A BGP based method to compute =20 > inter-AS Traffic > > engineering Label Switched Paths with PCE > > Author(s) : C. Vijayanand, S. Bhattacharya > > Filename : > > draft-vijay-somen-pce-bgp-interas-te-path-01.txt > > Pages : 26 > > Date : 2007-1-22 > > > The ability to compute an optimal path for setting up Traffic > > engineering Label Switched Paths spanning multiple autonomous > > systems managed by different operators has been a key =20 > requirement in > > MPLS and GMPLS networks. This document specifies a method of > > computing inter-AS paths consisting of a list of ASes to be > > traversed and a list of TE-Tunnels to be traversed in each AS. The > > method described here uses BGP speakers in the PCEs of each AS to > > distribute the inter-AS connectivity information and the TE-Tunnels > > in each AS to its neighbors to facilitate the construction of an > > inter-AS topology graph which can be used for computing inter-AS > > paths. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-=20 > interas-te > > -path-01.txt > > > > > DISCLAIMER: > > ----------------------------------------------------------------------=20= > ------------------------------------------------- > > > The contents of this e-mail and any attachment(s) are confidential =20 > and intended for the named recipient(s) only. > > It shall not attach any liability on the originator or HCL or its =20 > affiliates. Any views or opinions presented in > > this email are solely those of the author and may not necessarily =20 > reflect the opinions of HCL or its affiliates. > > Any form of reproduction, dissemination, copying, disclosure, =20 > modification, distribution and / or publication of > > this message without the prior written consent of the author of =20 > this e-mail is strictly prohibited. If you have > > received this email br> Subject: Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

 

Hi,

 

On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. = wrote:

 

 

Hello all,

We have submitted the following I-D, please send in = your

comments/suggestions

 

* speaking as a technical contributor = *

 

   In [BRPC], a method to optimally compute a inter-domain TE 

   path for MPLS and GMPS LSPs using the PCE architecture detailed in 

 in error please delete it and notify the sender =20= > immediately. Before opening any mail and > > attachments please check them for viruses and defect. > > > ----------------------------------------------------------------------=20= > ------------------------------------------------- > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > --Apple-Mail-177--906076241 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Vijay,


On = Feb 5, 2007, at 6:05 AM, Vijayanand C - TLS, Chennai. wrote:

We mean that those inter-ASBR TE LSPs which are permitted = by policy/scaling configuration to be propagated outside can be = propogated to PCEs in neighbouring ASes by BGP.This information is not = flooded to all BGP speakers of neighbouring ASes but only to speakers = which are on PCEs or which propogate them to PCEs ( which support the = new AFI/SAFI).

=A0

=A0These LSPs may be a sub-set of TE LSPs specifically = provisioned for carrying inter-AS TE traffic and may be a full mesh. If = all the ASes support such a mechanism then the itner-AS TE path can be = calculated using the inter-AS graph of such LSPs and inter-AS = links.

=A0
;  [PCE_ARCH] is described. However the method = described requires the 

   list of Autonomous systems or domains to be determined apriori. 

   Determining the list of ASes/domains to be = traversed to reach a 

   destination, satisfying the TE constraints is non-trivial. It 

   requires knowledge of the inter-AS = connectivity and the TE 

   characteristics of the inter-AS links along = with the knowledge of 

   the available paths within each of the = ASes/domains. BGP contains 

   information on the list of ASes to be = traversed to reach a 

   destination, however BGP route selection and = decision process 

   truncates most of the feasible paths, and it = also does not carry 

   the TE characteristics of the inter-AS links = and path availability 

   within a domain. =  

 

What does prevent you from relying on BGP to provide you = all possible paths toward 

=A0

Then = I've got a=A0much=A0of reasons (see also RFC4105 = and RFC4216). Thus we proposed two techniques: per-domain and the PCE = (where no aggregated TE data is leaked between domains !). You may want = to refer to the lists archives for details but TE aggregation has been = rejected, this is precisely why we=A0developed=A0PCE-based computation = for inter-domain TE.=A0

=A0

I = certainly do not want to re-open the debate for the Nth time, but just = consider that in your proposal you would not have to flood just one TE = LSP per pair of ASBR but one TE LSP per attribute per pair of ASBRs = (combining affinity, CTs, metric, ... ) and for all domains + this would = of course be dynamic (based on the TE LSP when they get rerouted because = of failures, reoptimization, ...).



a specific destination skipping the regular path selection = process for specific routes (see

proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE

link could easily be obtained via the IGP with minor = additions.

 

This is in my opinion a fundamental question that must = first be addressed before 

moving forward.

 

Thanks.

 

JP.

 

 

Regards

Vijay

 

Furthermore this is not = compliant with RFC4216 and RFC4105.
All the arguments that = have been discussed on the mailing list still applies here: also think = of the mechanisms that is required to ensure a quick feed-back mechanism = between the Inter-ASBR TE LSP states announced=A0through BGP to the = various domains and the path computation process during a burst of = requests.

=A0

But, this kind of itner-ASBR LSP propogation may not be = always possible because of policy and scaling constraints. In such = situations we have only the ASes and their inter-AS links in the form of = an inter-AS graph and we can only find the =91possible=92 AS paths after = eliminating the paths through inter-AS links which are not feasible and = then use methods like BRPC to complete the path = setup.

=A0

But = in this case, it is probably not worth the work: you do not have the = 'possible' AS since you do not have any information about the resource = available within each AS.

-----Original Message-----

Sent: Tuesday, January 23, 2007 2:20 = AM

Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt 

 

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

directories.

 

 

          =   Title           &n= bsp;      : A BGP based method to compute inter-AS = Traffic

engineering Label Switched Paths with = PCE

of = the AS paths where the inter-AS link cannot support the path. This may = also be useful for finding backup paths since the inter-AS graph is = known.

Thanks.

JP.

Hope = this helps.

=A0

=A0



          =   Author(s)          : C. Vijayanand, S. Bhattacharya

          =   Filename           = :

draft-vijay-somen-pce-bgp-interas-te-path-01.txt

          =   Pages           &n= bsp;   : 26

          =   Date           &nb= sp;     : 2007-1-22

     &nbs= p;     

The ability to compute an optimal path for setting up Traffic 

   engineering Label Switched Paths spanning = multiple autonomous 

   systems managed by different operators has = been a key requirement in 

   MPLS and GMPLS networks. This document = specifies a method of 

   computing inter-AS paths consisting of a list = of ASes to be 

   traversed and a list of TE-Tunnels to be = traversed in each AS. The 

=A0

Regards

Vijay

=A0
=A0

   distribute the inter-AS connectivity = information and the TE-Tunnels 

   in each AS to its neighbors to facilitate the construction of an 

   inter-AS topology graph which can be used for computing inter-AS

    paths.

 

A URL for this Internet-Draft is:

-path-01.txt

 

 

 

DISCLAIMER:

------------------------------------------------------------= -----------------------------------------------------------=

Saturday, February 03, 2007 4:05 AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org
Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

=A0

=A0

Let me first try to make sure of something here. When you write = "The PCE shall learn the = TE=A0

=A0=A0 attributes of the inter-AS TE = links and the TE tunnels that = exist=A0

 

The contents of this e-mail and any attachment(s) are = confidential and intended for the named recipient(s) only.

It shall not attach any liability on the originator or HCL = or its affiliates. Any views or opinions presented = in 

this email are solely those of the author and may not = necessarily reflect the opinions of HCL or its affiliates.

Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication = of 

this message without the prior written consent of the = author of this e-mail is strictly prohibited. If you = have 

received this email in error please delete it and notify = the sender immediately. Before opening any mail = and 

attachments please check them for viruses and = defect.

 

------------------------------------------------------------= -----------------------------------------------------------=

 

_______________________________________________

Pce mailing list

=A0=A0 between the ASBRs in the = domain."

=A0

Are you suggesting to flood via BGP the intra-domain TE LSPs ? = In other words, suppose the following = scenario:

=A0

AS1---AS2---AS3

You have a mesh of intra-domain TE LSPs between all ASBRs = within AS2.

=A0

Are you suggesting to flood in AS1 these TE LSPs (and this for = all other ASes that might be between AS1 and the destination domain) = ?

=A0

Thanks.

=A0

 

 

 



 

------_=_NextPart_001_01C74915.9D6D5F1E-- --===============0919584742== 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 --===============0919584742==-- From pce-bounces@lists.ietf.org Mon Feb 05 06:40:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE2Cv-0007W5-0j; Mon, 05 Feb 2007 06:40:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1xU-0000Wi-V5 for pce@ietf.org; Mon, 05 Feb 2007 06:24:28 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE1xH-0007VT-Hc for pce@ietf.org; Mon, 05 Feb 2007 06:24:28 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2007 06:24:16 -0500 X-IronPort-AV: i="4.13,282,1167627600"; d="scan'208,217"; a="113143199:sNHT272687964" 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 l15BOFZu026345; Mon, 5 Feb 2007 06:24:15 -0500 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 l15BOEVT004987; Mon, 5 Feb 2007 06:24:14 -0500 (EST) 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); Mon, 5 Feb 2007 06:24:14 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 06:24:10 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Date:olor=3D"black" face=3D"Times New Roman">JP.

=A0

On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. = wrote:

=A0

Are you suggesting that =A0BGP should propagate all = possible next-hops/As paths and regular path selection process avoided = for all prefixes which can be destinations of inter-AS TE tunnels = ?

=A0

The inter-AS TE link information can be made aware only to = the ASes on either side of the inter-AS link by the IGP. It may not be = possible to propagate it beyond that ( or can it = ?).

So some of the possible AS paths found by BGP( if we = propagate all next-hops/aspaths in bgp) may not be worth trying for path = setup (by BRPC) because of violation of some TE = constraint.

=A0

X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 05 Feb 2007 11:24:10.0902 (UTC) FILETIME=[2863CB60:01C74918] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=98961; t=1170674655; x=1171538655; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20RE=3A=20I-D=20=20=20=20ACTION=3Adraft-vijay-s omen-pce-bgp-interas-te-path-01.txt=20 |Sender:=20 |To:=20=22Vijayanand=20C=20-=20TLS,=20Chennai.=22=20; bh=6LmutWYIwWazGsYpmyeb76lZIdtEKS5/ptsOsxl6jSE=; b=KaoRBE5u9Uw8k49CcWSO/kPz3IOe4uFyMCSJFMxdXbffS0wraWxxtIAdiQwPppnKJokredbZ c9cqIu4CA/A02miivH0OBOWEWHgIZyOvoKCc6ObtqmoSWGSKGhu5o3DX; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d4a64066b1774fc2641038d4c8545f6 X-Mailman-Approved-At: Mon, 05 Feb 2007 06:40:23 -0500 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="===============2006108600==" Errors-To: pce-bounces@lists.ietf.org --===============2006108600== Content-Type: multipart/alternative; boundary=Apple-Mail-177--906076241 --Apple-Mail-177--906076241 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Vijay, On Feb 5, 2007, at 6:05 AM, Vijayanand C - TLS, Chennai. wrote: > JP, > > > We mean that those inter-ASBR TE LSPs which are permitted by policy/=20= > scaling configuration to be propagated outside can be propogated to =20= > PCEs in neighbouring ASes by BGP.This information is not flooded to =20= > all BGP speakers of neighbouring ASes but only to speakers which =20 > are on PCEs or which propogate them to PCEs ( which support the new =20= > AFI/SAFI). > > > These LSPs may be a sub-set of TE LSPs specifically provisioned =20 > for carrying inter-AS TE traffic and may be a full mesh. If all the =20= > ASes support such a mechanism then the itner-AS TE path can be =20 > calculated using the inter-AS graph of such LSPs and inter-AS links. > > > > Then I've got a much major concern then. Back to when the inter-=20 > domain TE discussion started (a few years back), several potential =20 > candidates have been investigated including the TE aggregation =20 > technique that you propose and that has been excluded for a number =20 > of reasons (see also RFC4105 and RFC4216). Thus we proposed two =20 > techniques: per-domain and the PCE (where no aggregated TE data is =20 > leaked between domains !). You may want to refer to the lists =20 > archives for details but TE aggregation has been rejected, this is =20 > precisely why we developed PCE-based computation for inter-domain TE. > > > I certainly do not want to re-open the debate for the Nth time, but =20= > just consider that in your proposal you would not have to flood =20 > just one TE LSP per pair of ASBR but one TE LSP per attribute per =20 > pair of ASBRs (combining affinity, CTs, metric, ... ) and for all =20 > domains + this would of course be dynamic (based on the TE LSP when =20= > they get rerouted because of failures, reoptimization, ...). > > > > > [[Vijay ]] I ll go through the arguments in the mailing list =20 > archive, thanks for the pointer. We are not suggesting this as a =20 > solution always, but use it wherever possible since it is a step =20 > towards optimality. The aggspan">In our proposal we can pick the paths which are really = feasible, since we have the inter-AS graph, and then invoke methods like = BRPC

=A0

Regards

Vijay

=A0
=A0
=A0
=A0

-----Original = Message-----
the PCEs, and this information is not flooded to the rest of the =20 > network. I understand, but still, the solution requires to set up N meshes of =20 TE LSPs between all ASBRs (there are many deployment where the TE =20 LSPs are not deployed between the ASBRs but a set of P routers) where =20= N may be large depending on the set of attributes in use. Note that =20 the attributes of these TE LSPs are dynamic (bandwidth, metric =20 (dependency with the path), ... Furthermore this is not compliant with RFC4216 and RFC4105. All the arguments that have been discussed on the mailing list still =20 applies here: also think of the mechanisms that is required to ensure =20= a quick feed-back mechanism between the Inter-ASBR TE LSP states =20 announced through BGP to the various domains and the path computation =20= process during a burst of requests. > > But, this kind of itner-ASBR LSP propogation may not be always =20 > possible because of policy and scaling constraints. In such =20 > situations we have only the ASes and their inter-AS links in the =20 > form of an inter-AS graph and we can only find the =91possible=92 AS =20= > paths after eliminating the paths through inter-AS links which are =20 > not feasible and then use methods like BRPC to complete the path =20 > setup. > > > But in this case, it is probably not worth the work: you do not =20 > have the 'possible' AS since you do not have any information about =20 > the resource available within each AS. > > > [[Vijay ]] But is it not better than trying all possible ASpaths =20 > towards a destination. In this method we can certainly eliminate many Why "many" ? That depends on many factors .. that may be a low as 0 =20 if the inter-AS TE links are all acceptable for a set of constraints. > of the AS paths where the inter-AS link cannot support the path. =20 > This may also be useful for finding backup paths since the inter-AS =20= > graph is known. Thanks. JP. > Hope this helps. > > > Thanks. > > > JP. > > > > > > Regards > > Vijay > > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Saturday, February 03, 2007 4:05 AM > To: Vijayanand C - TLS, Chennai. > Cc: pce@ietf.org > Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-=20= > te-path-01.txt > > > Hi, > > > Let me first try to make sure of something here. When you write =20 > "The PCE shall learn the TE > > attributes of the inter-AS TE links and the TE tunnels that exist > > between the ASBRs in the domain." > > > Are you suggesting to flood via BGP the intra-domain TE LSPs ? In =20 > other words, suppose the following scenario: > > > AS1---AS2---AS3 > > You have a mesh of intra-domain TE LSPs between all ASBRs within AS2. > > > Are you suggesting to flood in AS1 these TE LSPs (and this for all =20 > other ASes that might be between AS1 and the destination domain) ? > > > Thanks. > > > JP. > > > On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. wrote: > > > Are you suggesting that BGP should propagate all possible next-=20 > hops/As paths and regular path selection process avoided for all =20 > prefixes which can be destinations of inter-AS TE tunnels ? > > > The inter-AS TE link information can be made aware only to the ASes =20= > on either side of the inter-AS link by the IGP. It may not be =20 > possible to propagate it beyond that ( or can it ?). > > So some of the possible AS paths found by BGP( if we propagate all =20 > next-hops/aspaths in bgp) may not be worth trying for path setup =20 > (by BRPC) because of violation of some TE constraint. > > > In our proposal we can pick the paths which are really feasible, =20 > since we have the inter-AS graph, and then invoke methods like BRPC > > > Regards > > Vijay > > > > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, February 01, 2007 1:19 AM > To: Vijayanand C - TLS, Chennai. > Cc: pce@ietf.org > Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-=20= > te-path-01.txt > > tyle=3D"font-family: = Tahoma; font-size: 13.3333px; font-weight: bold; = ">From: JP Vasseur = [mailto:jvasseur@cisco.com]
Thursday, = February 01, 2007 1:19 AM
Vijayanand C - = TLS, Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

=A0

Hi,

Hi, > > > On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: > > > > Hello all, > > We have submitted the following I-D, please send in your > > comments/suggestions > > > * speaking as a technical contributor * > > > In [BRPC], a method to optimally compute a inter-domain TE > > path for MPLS and GMPS LSPs using the PCE architecture detailed in > > [PCE_ARCH] is described. However the method described requires the > > list of Autonomous systems or domains to be determined apriori. > > Determining the list of ASes/domains to be traversed to reach a > > destination, satisfying the TE constraints is non-trivial. It > > requires knowledge of the inter-AS connectivity and the TE > > characteristics of the inter-AS links along with the knowledge of > > the available paths within each of the ASes/domains. BGP contains > > information on the list of ASes to be traversed to reach a > > destination, however BGP route selection and decision process > > truncates most of the feasible paths, and it also does not carry > > the TE characteristics of the inter-AS links and path availability > > within a domain. > > > What does prevent you from relying on BGP to provide you all =20 > possible paths toward > > a specific destination skipping the regular path selection process =20 > for specific routes (see > > proposals made in the past) and then use BRPC as currently =20 > specified? The Inter-AS TE > > link could easily be obtained via the IGP with minor additions. > > > This is in my opinion a fundamental question that must first be =20 > addressed before > > moving forward. > > > Thanks. > > > JP. > > > > Regards > > Vijay > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, January 23, 2007 2:20 AM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : A BGP based method to compute =20 > inter-AS Traffic > > engineering Label Switched Paths with PCE > > Author(s) : C. Vijayanand, S. Bhattacharya > > Filename : > > draft-vijay-somen-pce-bgp-interas-te-path-01.txt > > Pages : 26 > > Date : 2007-1-22 > > > The ability to compute an optimal path for setting up Traffic > > engineering Label Switched Paths spanning multiple autonomous > > systems managed by different operators has been a key =20 > requirement in > > MPLS and GMPLS networks. This document specifies a method of > > computing inter-AS paths consisting of a list of ASes to be > > traversed and a list of TE-Tunnels to be traversed in each AS. The > > method described here uses BGP speakers in the PCEs of each AS to > > distribute the inter-AS connectivity information and the TE-Tunnels > > in each AS to its neighbors to facilitate the construction of an > > inter-AS topology graph which can be used for computing inter-AS > > paths. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-=20 > interas-te > > -path-01.txt > > > > > DISCLAIMER: > > ----------------------------------------------------------------------=20= > ------------------------------------------------- > > > The contents of this e-mail and any attachment(s) are confidential =20 > and intended for the named recipient(s) only. > > It shall not attach any liability on the originator or HCL or its =20 > affiliates. Any views or opinions presented in > > this email are solely those of the author and may not necessarily =20 > reflect the opinions of HCL or its affiliates. > > Any form of reproduction, dissemination, copying, disclosure, =20 > modification, distribution and / or publication of > > this message without the prior written consent of the author of =20 > this e-mail is strictly prohibited. If you have > > received this email 0pt;color:black; font-family: = Times New Roman; ">=A0

On Jan 25, 2007, at 9:32 AM, = Vijayanand C - TLS, Chennai. = wrote:

=A0
=A0

Hello = all,

We have submitted the following I-D, please send in = your

=A0

* speaking as a technical = contributor *

=A0

immediately. Before opening any mail and > > attachments please check them for viruses and defect. > > > ----------------------------------------------------------------------=20= > ------------------------------------------------- > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > --Apple-Mail-177--906076241 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Vijay,


On = Feb 5, 2007, at 6:05 AM, Vijayanand C - TLS, Chennai. wrote:

We mean that those inter-ASBR TE LSPs which are permitted = by policy/scaling configuration to be propagated outside can be = propogated to PCEs in neighbouring ASes by BGP.This information is not = flooded to all BGP speakers of neighbouring ASes but only to speakers = which are on PCEs or which propogate them to PCEs ( which support the = new AFI/SAFI).

=A0

=A0These LSPs may be a sub-set of TE LSPs specifically = provisioned for carrying inter-AS TE traffic and may be a full mesh. If = all the ASes support such a mechanism then the itner-AS TE path can be = calculated using the inter-AS graph of such LSPs and inter-AS = links.

=A0
">=A0 =A0In [BRPC], a method to optimally compute a = inter-domain TE=A0

=A0=A0 path for MPLS and GMPS LSPs using the PCE = architecture detailed in=A0

=A0=A0 [PCE_ARCH] is described. However the method = described requires the=A0

=A0=A0 list of Autonomous systems or domains to be = determined apriori.=A0

=A0=A0 Determining the list of ASes/domains to be = traversed to reach a=A0

=A0=A0 destination, satisfying the TE constraints is = non-trivial. It=A0

=A0=A0 requires knowledge of the inter-AS = connectivity and the TE=A0

=A0=A0 characteristics of the inter-AS links along = with the knowledge of=A0

=A0=A0

Then = I've got a=A0much=A0of reasons (see also RFC4105 = and RFC4216). Thus we proposed two techniques: per-domain and the PCE = (where no aggregated TE data is leaked between domains !). You may want = to refer to the lists archives for details but TE aggregation has been = rejected, this is precisely why we=A0developed=A0PCE-based computation = for inter-domain TE.=A0

=A0

I = certainly do not want to re-open the debate for the Nth time, but just = consider that in your proposal you would not have to flood just one TE = LSP per pair of ASBR but one TE LSP per attribute per pair of ASBRs = (combining affinity, CTs, metric, ... ) and for all domains + this would = of course be dynamic (based on the TE LSP when they get rerouted because = of failures, reoptimization, ...).



=A0=A0 information on the list of ASes to be = traversed to reach a=A0

=A0=A0 destination, however BGP route selection and = decision process=A0

=A0=A0 truncates most of the feasible paths, and it = also does not carry=A0

=A0=A0 the TE characteristics of the inter-AS links = and path availability=A0

=A0=A0 within a domain. = =A0

=A0

What does prevent you from = relying on BGP to provide you all possible paths = toward=A0

a specific destination skipping the regular path = selection process for specific routes = (see

Furthermore this is not = compliant with RFC4216 and RFC4105.
All the arguments that = have been discussed on the mailing list still applies here: also think = of the mechanisms that is required to ensure a quick feed-back mechanism = between the Inter-ASBR TE LSP states announced=A0through BGP to the = various domains and the path computation process during a burst of = requests.

=A0

But, this kind of itner-ASBR LSP propogation may not be = always possible because of policy and scaling constraints. In such = situations we have only the ASes and their inter-AS links in the form of = an inter-AS graph and we can only find the =91possible=92 AS paths after = eliminating the paths through inter-AS links which are not feasible and = then use methods like BRPC to complete the path = setup.

=A0

But = in this case, it is probably not worth the work: you do not have the = 'possible' AS since you do not have any information about the resource = available within each AS.

proposals made in the past) and then use BRPC as = currently specified? The Inter-AS = TE

link could easily be obtained via the IGP with minor = additions.

=A0

This is in my opinion a = fundamental question that must first be addressed = before=A0

moving = forward.

=A0

=A0

=A0

of = the AS paths where the inter-AS link cannot support the path. This may = also be useful for finding backup paths since the inter-AS graph is = known.

Thanks.

JP.

Hope = this helps.

=A0

=A0



=A0

Vijay

=A0

-----Original = Message-----

Let me first try to make sure of something here. When you write = "The PCE shall learn the = TE=A0

=A0=A0 attributes of the inter-AS TE = links and the TE tunnels that = exist=A0

engineering Label Switched Paths with = PCE

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0= =A0=A0=A0=A0=A0 : C. Vijayanand, S. = Bhattacharya

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Filename=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = :

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 : 26

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : = 2007-1-22

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0<= /SPAN>

The ability to compute an = optimal path for setting up = Traffic=A0

=A0=A0 engineering Label = Switched Paths spanning multiple = autonomous=A0

=A0=A0 syor=3D"black" face=3D"Times New Roman">=A0=A0 between the ASBRs in the = domain."

=A0

Are you suggesting to flood via BGP the intra-domain TE LSPs ? = In other words, suppose the following = scenario:

=A0

AS1---AS2---AS3

You have a mesh of intra-domain TE LSPs between all ASBRs = within AS2.

=A0

Are you suggesting to flood in AS1 these TE LSPs (and this for = all other ASes that might be between AS1 and the destination domain) = ?

=A0

Thanks.

=A0

=A0=A0 MPLS and GMPLS networks. This document = specifies a method of=A0

=A0=A0 computing inter-AS paths = consisting of a list of ASes to = be=A0

=A0=A0 traversed and a list of TE-Tunnels to be = traversed in each AS. The=A0

=A0=A0 method described here = uses BGP speakers in the PCEs of each AS = to=A0

=A0=A0 distribute the inter-AS connectivity = information and the = TE-Tunnels=A0

=A0=A0 in each AS to its = neighbors to facilitate the construction of = an=A0

=A0=A0 inter-AS topology graph which can be used for = computing inter-AS

=A0 =A0 = paths.

=A0
JP.

=A0

On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. = wrote:

=A0

Are you suggesting that =A0BGP should propagate all = possible next-hops/As paths and regular path selection process avoided = for all prefixes which can be destinations of inter-AS TE tunnels = ?

=A0

The inter-AS TE link information can be made aware only to = the ASes on either side of the inter-AS link by the IGP. It may not be = possible to propagate it beyond that ( or can it = ?).

So some of the possible AS paths found by BGP( if we = propagate all next-hops/aspaths in bgp) may not be worth trying for path = setup (by BRPC) because of violation of some TE = constraint.

=A0

A URL for this Internet-Draft = is:

=A0
=A0
=A0

In our proposal we can pick the paths which are really = feasible, since we have the inter-AS graph, and then invoke methods like = BRPC

=A0

Regards

Vijay

=A0
=A0
=A0
=A0

-----Original = Message-----
=A0

The contents of this e-mail and = any attachment(s) are confidential and intended for the named = recipient(s) only.

It shall not attach any = liability on the originator or HCL or its affiliates. Any views or = opinions presented in=A0

this email are solely those of = the author and may not necessarily reflect the opinions of HCL or its = affiliates.

Any form of reproduction, = dissemination, copying, disclosure, modification, distribution and / or = publication of=A0

this message without the prior = written consent of the author of this e-mail is strictly prohibited. If = you have=A0

received this email in error = please delete it and notify the sender immediately. Before opening any = mail and=A0

attachments please check them = for viruses and defect.

=A0

JP Vasseur = [mailto:jvasseur@cisco.com]
Thursday, = February 01, 2007 1:19 AM
Vijayanand C - = TLS, Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

=A0

Hi,

=A0

Pce mailing list





= --Apple-Mail-177--906076241-- --===============2006108600== 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 --===============2006108600==-- ">=A0 =A0In [BRPC], a method to optimally compute a = inter-domain TE=A0





= --Apple-Mail-177--906076241-- --===============2006108600== 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 --===============2006108600==-- From pce-bounces@lists.ietf.org Mon Feb 05 16:25:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBKP-0008Q9-DB; Mon, 05 Feb 2007 16:24:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBKO-0008Pg-0A for pce@ietf.org; Mon, 05 Feb 2007 16:24:44 -0500 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 1HEBJs-0004a9-P2 for pce@ietf.org; Mon, 05 Feb 2007 16:24:13 -0500 Received: from clavin.turin.turinnetworks.com ([10.1.1.33]) by milan.turin.turinnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 13:24:45 -0800 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] A New Internet-Draft on Advertising of inter-AS TE links Date: Mon, 5 Feb 2007 13:24:43 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Thread-Index: AcdGcvTAFH6NOcS2TZKejRgEgiygegC9NZTw From: "Greg Mirsky" To: "Zhang Renhai" , , X-OriginalArrivalTime: 05 Feb 2007 21:24:45.0806 (UTC) FILETIME=[0EDDC8E0:01C7496C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 Dear Zhang, thank you for your response. I've read the newer version of the draft as you suggested and below are my questions: - would you agree that usually ASBRs are eBGP speakers and are fully mesh connected. In that case eBGP can be viable solution for the inter-AS TE links computation by ASBR. - I'm concerned with scaling aspect of flooding inter-AS TE information throughout both AS and an area and I see that you're concerned as well (SHOULD for Type 10 and MAY for Type 11). I think that it would be helpful if use of both Type 10 and Type 11 for inter-AS TE Link advertisement be illustrated by scenarios. I think that use of area scope makes these OSPF extensions less applicable to inter-AS path computation by the head-end LSR/LER. - Could you please illustrate which links are excluded by the following: " Routers or PCEs that are capable of processing advertisements of=20 inter-AS TE links SHOULD NOT use such links to compute paths that=20 exit an AS to a remote ASBR and then immediately re-enter the AS.=20 Such paths would constitute extremely rare occurrences and MUST only=20 be allowed as the result of specific policy configuration at the=20 router or PCE computing the path." Are there two links that interconnect a pair of ASBRs that belong to two different neighboring ASes? Regards, Greg -----Original Message----- From: Zhang Renhai [mailto:zhangrenhai@huawei.com]=20 Sent: Thursday, February 01, 2007 6:36 PM To: Greg Mirsky; ccamp@ops.ietf.org; pce@ietf.org Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Hi, Greg Thanks a lot for your question. See inline please. Dear Zhang, I have couple questions related to Link ID of inter-AS link. According to the document it is the Router ID of Remote ASBR.=20 [ZRH]Yes, and this can be easily got by manual configuration in the local ASBR. My question: - as I understand the mechanism of how TE information for links R6-R9 and R8-R10 is populated into R5's TE DB is outside the scope of this document. I this mechanism is not IGP but EGP (BGP), then what is the benefit to introduce new LSA in IGP (OSPF) and not use exisitng mechanisms. [ZRH]I think BGP could also be another alternative especially for PCE scenario, but it's not very applicable to per-domian method because the inter-AS TE information may be needed throughout the local AS in case that the path computation function is distributed among LSRs in the local AS, and BGP can hardly advertise the TE information among those LSRs if BGP sessions are not established between the ASBR and those LSRs. So IGP extension is considered in this draft. We have submitted the revised version of this draft, hoping make the problem statement more clear, and relax the use of type 11 opaque lsa, also allow Type 10 lsa (by which the advertising scope is an area of OSPF). http://www.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-ext ension-01.txt Cheers, Zhang Renhai Regards, Greg PS. I think that OSPF WG needs to be informed as well. -----Original Message----- From: Zhang Renhai [mailto:zhangrenhai@huawei.com] Sent: Tuesday, January 30, 2007 7:38 PM To: ccamp@ops.ietf.org; pce@ietf.org Subject: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Hi, allWe have just submitted the following draft in which we describe some problemsin inter-AS TE scenarios and the corresponding OSPF extension is introduced.PCE environment is also considerd in this I-d so I'd also like pce working groupto pay attention to it.we'd highly appreciate your comments.Thanks a lot,Zhang Renhai & Mach A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : OSPF Extensions in Support of Inter-AS (G)MPLS TE=20 Author(s) : M. Chen, R. Zhang Filename : draft-chen-ccamp-ospf-interas-te-extension-00.txt Pages : 9 Date : 2007-1-30 This document describes extensions to the OSPF to support inter-AS=20 Traffic engineering (TE). It defines OSPF extensions for the flooding of inter-AS links information which can be used to perform inter-AS=20 path computation.=20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-ext ension-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-chen-ccamp-ospf-interas-te-extension-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-chen-ccamp-ospf-interas-te-extension-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. =20 _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 05 19:13:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEDwo-0003kR-HG; Mon, 05 Feb 2007 19:12:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEDwn-0003kM-91 for pce@ietf.org; Mon, 05 Feb 2007 19:12:33 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEDwj-00068q-PJ for pce@ietf.org; Mon, 05 Feb 2007 19:12:33 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1HEDwl-00089A-00 for pce@ietf.org; Tue, 06 Feb 2007 00:12:31 +0000 Received: from your029b8cecfe ([217.158.132.83] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 00:12:05 +0000 Message-ID: <0e3e01c74983$6aab40a0$76849ed9@your029b8cecfe> From: "Adrian Farrel" To: "Greg Mirsky" References: Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Date: Tue, 6 Feb 2007 00:11:49 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 06 Feb 2007 00:12:05.0638 (UTC) FILETIME=[6F129260:01C74983] X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ccamp@ops.ietf.org, pce@ietf.org 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 Greg, > - would you agree that usually ASBRs are eBGP speakers > and are fully mesh connected. In that case eBGP can be > viable solution for the inter-AS TE links computation by > ASBR. So the question has to be: Do other nodes apart from ASBRs need this information? What about an ingress LSR trying to compute a path out of the AS? If we require that the ingress LSR always consults an external PCE that is a BGP speaker, then I guess this is fine, but most LSRs today are capable of path computation and could handle this case (for example, for the pd-path scenario) without needing to consult an external PCE. > - I'm concerned with scaling aspect of flooding inter-AS TE > information throughout both AS and an area I have this concern, too, but I wonder how many TE links we are talking about, and how this compares with the number of TE links within an area. > and I see that you're concerned as well (SHOULD for Type > 10 and MAY for Type 11). I think that it would be > helpful if use of both Type 10 and Type 11 for inter-AS > TE Link advertisement be illustrated by scenarios. I think > that use of area scope makes these OSPF extensions less > applicable to inter-AS path computation by the head-end > LSR/LER. Yes, that would be the case. I agree that we need to look more closely at the scenarios. I don't think we have given enough thought to the nested domains case (i.e. areas in ASes) given that both pd-path and brpc (largely) treat the nested case as simply a flat sequence. > - Could you please illustrate which links are excluded by the > following: >" Routers or PCEs that are capable of processing advertisements of > inter-AS TE links SHOULD NOT use such links to compute paths that > exit an AS to a remote ASBR and then immediately re-enter the AS. > Such paths would constitute extremely rare occurrences and MUST only > be allowed as the result of specific policy configuration at the > router or PCE computing the path." > Are there two links that interconnect a pair of ASBRs that belong to two > different neighboring ASes? Renhai can comment, but I assumed that this meant that two ASes are linked by more than two TE links. The LSP should not under normal circumstances leave AS1 to AS2 through TE link 1 and return to AS1 from AS2 through TE link 2. The example you give (ASBR1 in AS1 connects to ASBR2 in AS2 with two links, the LSP goes out on one and back on the other) would be detected as a loop in RSVP-TE, and would not offer any benefit anyway. Regards, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Feb 05 20:45:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEFOU-0003eM-N6; Mon, 05 Feb 2007 20:45:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEFOT-0003dV-0I for pce@ietf.org; Mon, 05 Feb 2007 20:45:13 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEFOR-0004dd-KW for pce@ietf.org; Mon, 05 Feb 2007 20:45:12 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2007 20:45:12 -0500 X-IronPort-AV: i="4.13,285,1167627600"; d="scan'208"; a="113205887:sNHT52272016" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l161jB5V002726; Mon, 5 Feb 2007 20:45:11 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l161j8OA011666; Mon, 5 Feb 2007 20:45:08 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 20:45:08 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 20:45:06 -0500 In-Reply-To: <0e3e01c74983$6aab40a0$76849ed9@your029b8cecfe> References: <0e3e01c74983$6aab40a0$76849ed9@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <56480CEA-78F0-4E10-BAF4-F471703444E3@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Date: Mon, 5 Feb 2007 20:45:10 -0500 To: Adrian Farrel , Greg Mirsky X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Feb 2007 01:45:06.0895 (UTC) FILETIME=[6DC2CDF0:01C74990] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3155; t=1170726311; x=1171590311; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20A=20New=20Internet-Draft=20on=20Advertising=2 0of=20inter-AS=20TE=20links |Sender:=20 |To:=20Adrian=20Farrel=20, =0A=20=20=20=20=20=20=20=2 0Greg=20Mirsky=20; bh=MlU5LanKFWK5BtUbje3cnPRKgLkJcRJb0fOpul1LmMM=; b=JSzPSN/cVSyLdvSWsCdiqs38QkXwTC4Kctwl+IlCzefrxc+OzcG7m1NN8K/DdoSclnHWBwnL eumeEiN4NMhdNoqB/9zx4MX0xBBbZ5OGmkMFVrkEqYbwTLuPOV4anFZe; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ccamp@ops.ietf.org, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Adrian, On Feb 5, 2007, at 7:11 PM, Adrian Farrel wrote: > Hi Greg, > >> - would you agree that usually ASBRs are eBGP speakers >> and are fully mesh connected. In that case eBGP can be >> viable solution for the inter-AS TE links computation by >> ASBR. > > So the question has to be: > Do other nodes apart from ASBRs need this information? > > What about an ingress LSR trying to compute a path out of the AS? > > If we require that the ingress LSR always consults an external PCE > that is a BGP speaker, then I guess this is fine, but most LSRs > today are capable of path computation and could handle this case > (for example, for the pd-path scenario) without needing to consult > an external PCE. > >> - I'm concerned with scaling aspect of flooding inter-AS TE >> information throughout both AS and an area > > I have this concern, too, but I wonder how many TE links we are > talking about, and how this compares with the number of TE links > within an area. > It is probably negligible ... Note that by contrast with the approach proposing to flooding Inter-ASBR TE LSP, we're only looking at flooding the TE information of the inter-ASBR *links*. >> and I see that you're concerned as well (SHOULD for Type >> 10 and MAY for Type 11). I think that it would be >> helpful if use of both Type 10 and Type 11 for inter-AS >> TE Link advertisement be illustrated by scenarios. I think >> that use of area scope makes these OSPF extensions less >> applicable to inter-AS path computation by the head-end >> LSR/LER. > > Yes, that would be the case. > I agree that we need to look more closely at the scenarios. I don't > think we have given enough thought to the nested domains case (i.e. > areas in ASes) given that both pd-path and brpc (largely) treat the > nested case as simply a flat sequence. Looking at the nested case, what would be the point of domain-scope since all TE-related info for the intra-area links have an area scope ? > >> - Could you please illustrate which links are excluded by the >> following: >> " Routers or PCEs that are capable of processing advertisements of >> inter-AS TE links SHOULD NOT use such links to compute paths that >> exit an AS to a remote ASBR and then immediately re-enter the AS. >> Such paths would constitute extremely rare occurrences and MUST >> only >> be allowed as the result of specific policy configuration at the >> router or PCE computing the path." >> Are there two links that interconnect a pair of ASBRs that belong >> to two >> different neighboring ASes? > > Renhai can comment, but I assumed that this meant that two ASes are > linked by more than two TE links. The LSP should not under normal > circumstances leave AS1 to AS2 through TE link 1 and return to AS1 > from AS2 through TE link 2. > > The example you give (ASBR1 in AS1 connects to ASBR2 in AS2 with > two links, the LSP goes out on one and back on the other) would be > detected as a loop in RSVP-TE, and would not offer any benefit anyway. Thanks. JP. > > Regards, > Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 06 01:13:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJZB-0006vl-A2; Tue, 06 Feb 2007 01:12:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJZ9-0006ve-F2 for pce@ietf.org; Tue, 06 Feb 2007 01:12:31 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJZ4-00082R-81 for pce@ietf.org; Tue, 06 Feb 2007 01:12:31 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD100GTJ2JAHU@szxga01-in.huawei.com> for pce@ietf.org; Tue, 06 Feb 2007 14:11:34 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD100DDW2J9TE@szxga01-in.huawei.com> for pce@ietf.org; Tue, 06 Feb 2007 14:11:34 +0800 (CST) Received: from Z18605a ([10.111.12.125]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD100JJJ2J8GU@szxml03-in.huawei.com> for pce@ietf.org; Tue, 06 Feb 2007 14:11:33 +0800 (CST) Date: Tue, 06 Feb 2007 14:11:32 +0800 From: Zhang Renhai Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links To: Greg Mirsky , Adrian Farrel Message-id: <00dc01c749b5$a619ded0$7d0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0e3e01c74983$6aab40a0$76849ed9@your029b8cecfe> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ccamp@ops.ietf.org, 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, See in-line please. > Hi Greg, > >> - would you agree that usually ASBRs are eBGP speakers >> and are fully mesh connected. In that case eBGP can be >> viable solution for the inter-AS TE links computation by >> ASBR. [ZRH]What do you mean by "eBGP", should it be "iBGP"? > > So the question has to be: > Do other nodes apart from ASBRs need this information? > > What about an ingress LSR trying to compute a path out of the AS? > > If we require that the ingress LSR always consults an external PCE that is a > BGP speaker, then I guess this is fine, but most LSRs today are capable of > path computation and could handle this case (for example, for the pd-path > scenario) without needing to consult an external PCE. > >> - I'm concerned with scaling aspect of flooding inter-AS TE >> information throughout both AS and an area > > I have this concern, too, but I wonder how many TE links we are talking > about, and how this compares with the number of TE links within an area. [ZRH]Indeed, so I don't think the additional advertisement in this draft will bring out a new scalability issue. > >> and I see that you're concerned as well (SHOULD for Type >> 10 and MAY for Type 11). I think that it would be >> helpful if use of both Type 10 and Type 11 for inter-AS >> TE Link advertisement be illustrated by scenarios. [ZRH]Indeed, as Adrian said below, we still havn't consider very clear some inter-AS TE applications, consequently, the way for choosing type 11 or type 10 is not given in the draft so far. I just want to relax it for the future discussion and revise this accordingly. I think >> that use of area scope makes these OSPF extensions less >> applicable to inter-AS path computation by the head-end >> LSR/LER. [ZRH]Currently, I also think the type 11 may be the batter choice. but I don't think now we have enough proof to abandon the use of type 10. > > Yes, that would be the case. > I agree that we need to look more closely at the scenarios. I don't think we > have given enough thought to the nested domains case (i.e. areas in ASes) > given that both pd-path and brpc (largely) treat the nested case as simply a > flat sequence. > >> - Could you please illustrate which links are excluded by the >> following: >>" Routers or PCEs that are capable of processing advertisements of >> inter-AS TE links SHOULD NOT use such links to compute paths that >> exit an AS to a remote ASBR and then immediately re-enter the AS. >> Such paths would constitute extremely rare occurrences and MUST only >> be allowed as the result of specific policy configuration at the >> router or PCE computing the path." >> Are there two links that interconnect a pair of ASBRs that belong to two >> different neighboring ASes? > > Renhai can comment, but I assumed that this meant that two ASes are linked > by more than two TE links. The LSP should not under normal circumstances > leave AS1 to AS2 through TE link 1 and return to AS1 from AS2 through TE > link 2. [ZRH]Yes, here I meant that we should have some method to prevent computation loop. Think that there are two pairs of ABSR (R1, R2 belong to AS1 and R3, R4 belong to AS2) and two links interconnect them(R1 connected with R3, R2 connected with R4 ) and a intra-AS link interconnects R3 and R4. There would be a possibility of computation loop. Regards, Zhng Renhai > > The example you give (ASBR1 in AS1 connects to ASBR2 in AS2 with two links, > the LSP goes out on one and back on the other) would be detected as a loop > in RSVP-TE, and would not offer any benefit anyway. > > Regards, > Adrian > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 06 01:29:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJpO-0007HE-Kx; Tue, 06 Feb 2007 01:29:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJpM-0007Cf-Gs for pce@ietf.org; Tue, 06 Feb 2007 01:29:16 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJpK-0005QV-M2 for pce@ietf.org; Tue, 06 Feb 2007 01:29:16 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD100I7Y38437@szxga02-in.huawei.com> for pce@ietf.org; Tue, 06 Feb 2007 14:26:28 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JD1003V53837B@szxga02-in.huawei.com> for pce@ietf.org; Tue, 06 Feb 2007 14:26:28 +0800 (CST) Received: from Z18605a ([10.111.12.125]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD100KMD382A7@szxml04-in.huawei.com> for pce@ietf.org; Tue, 06 Feb 2007 14:26:27 +0800 (CST) Date: Tue, 06 Feb 2007 14:26:26 +0800 From: Zhang Renhai Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links To: JP Vasseur , Adrian Farrel , Greg Mirsky Message-id: <00ec01c749b7$bb2a1a90$7d0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0e3e01c74983$6aab40a0$76849ed9@your029b8cecfe> <56480CEA-78F0-4E10-BAF4-F471703444E3@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ccamp@ops.ietf.org, 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, JP See in-line please. > Hi Adrian, > > On Feb 5, 2007, at 7:11 PM, Adrian Farrel wrote: > >> Hi Greg, >> >>> - would you agree that usually ASBRs are eBGP speakers >>> and are fully mesh connected. In that case eBGP can be >>> viable solution for the inter-AS TE links computation by >>> ASBR. >> >> So the question has to be: >> Do other nodes apart from ASBRs need this information? >> >> What about an ingress LSR trying to compute a path out of the AS? >> >> If we require that the ingress LSR always consults an external PCE >> that is a BGP speaker, then I guess this is fine, but most LSRs >> today are capable of path computation and could handle this case >> (for example, for the pd-path scenario) without needing to consult >> an external PCE. >> >>> - I'm concerned with scaling aspect of flooding inter-AS TE >>> information throughout both AS and an area >> >> I have this concern, too, but I wonder how many TE links we are >> talking about, and how this compares with the number of TE links >> within an area. >> > > It is probably negligible ... Note that by contrast with the approach > proposing to flooding Inter-ASBR TE LSP, we're only looking at > flooding the TE information of the inter-ASBR *links*. > >>> and I see that you're concerned as well (SHOULD for Type >>> 10 and MAY for Type 11). I think that it would be >>> helpful if use of both Type 10 and Type 11 for inter-AS >>> TE Link advertisement be illustrated by scenarios. I think >>> that use of area scope makes these OSPF extensions less >>> applicable to inter-AS path computation by the head-end >>> LSR/LER. >> >> Yes, that would be the case. > >> I agree that we need to look more closely at the scenarios. I don't >> think we have given enough thought to the nested domains case (i.e. >> areas in ASes) given that both pd-path and brpc (largely) treat the >> nested case as simply a flat sequence. > > Looking at the nested case, what would be the point of domain-scope > since all TE-related info for the intra-area links have an area scope ? [ZRH]I try to give an answer. With a new sub-tlv(remote AS number)and a new link type (inter-AS link type) are specified, in a multi-areas AS, the entry ASBR when receving a path mesg can get the exit ASBR(in another area) with this AS-scope advertisement and the path mesg(downstream AS number is given in ERO). then, the inter-area computation can be performed. Regards, Zhang Renhai > >> >>> - Could you please illustrate which links are excluded by the >>> following: >>> " Routers or PCEs that are capable of processing advertisements of >>> inter-AS TE links SHOULD NOT use such links to compute paths that >>> exit an AS to a remote ASBR and then immediately re-enter the AS. >>> Such paths would constitute extremely rare occurrences and MUST >>> only >>> be allowed as the result of specific policy configuration at the >>> router or PCE computing the path." >>> Are there two links that interconnect a pair of ASBRs that belong >>> to two >>> different neighboring ASes? >> >> Renhai can comment, but I assumed that this meant that two ASes are >> linked by more than two TE links. The LSP should not under normal >> circumstances leave AS1 to AS2 through TE link 1 and return to AS1 >> from AS2 through TE link 2. >> >> The example you give (ASBR1 in AS1 connects to ASBR2 in AS2 with >> two links, the LSP goes out on one and back on the other) would be >> detected as a loop in RSVP-TE, and would not offer any benefit anyway. > > Thanks. > > JP. > >> >> Regards, >> Adrian > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 06 21:37:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEcfB-0007Ub-Mv; Tue, 06 Feb 2007 21:36:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEcfA-0007UV-Ib for pce@ietf.org; Tue, 06 Feb 2007 21:36:00 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEcf9-0003Pj-0B for pce@ietf.org; Tue, 06 Feb 2007 21:36:00 -0500 Received: by ug-out-1314.google.com with SMTP id 72so58834ugd for ; Tue, 06 Feb 2007 18:35:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uhJIhQmT0eciBAq3vtmYQDs6QzqbRwge6rorKZoOmtK63fKtPKrUULm0olGntvSZB6uv11+Davq5veN3IzliW7LE5Zm7JMl7W+7rJMZpwaukcOQ5W1VxUljJFfiM14zZEQLAVYNj9tlGIYRclDIl9alAGn+2gaBX3DOYMpaR43o= Received: by 10.82.120.15 with SMTP id s15mr267914buc.1170815757006; Tue, 06 Feb 2007 18:35:57 -0800 (PST) Received: by 10.82.135.20 with HTTP; Tue, 6 Feb 2007 18:35:56 -0800 (PST) Message-ID: <406e32c00702061835s75d7911awd82c26b41d01c3e8@mail.gmail.com> Date: Tue, 6 Feb 2007 21:35:56 -0500 From: "Peng He" To: "Zhang Renhai" Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links In-Reply-To: <00ec01c749b7$bb2a1a90$7d0c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0e3e01c74983$6aab40a0$76849ed9@your029b8cecfe> <56480CEA-78F0-4E10-BAF4-F471703444E3@cisco.com> <00ec01c749b7$bb2a1a90$7d0c6f0a@china.huawei.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ccamp@ops.ietf.org, 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 I agreed with the following: "... we need to look more closely at the scenarios. I don't >> think we have given enough thought to the nested domains case (i.e. >> areas in ASes) given that both pd-path and brpc (largely) treat the >> nested case as simply a flat sequence. > > Looking at the nested case, what would be the point of domain-scope > since all TE-related info for the intra-area links have an area scope ?" I guess following the thinking line of this draft, we might need another extension so as to advertising "inter-area" TE links into non-backbone areas, or, just treat one area as a "domain"? And in Renhai's "[ZRH]I try to give an answer.", last line, how to perform this inter-area computation? per-area? or Backward Recursive Path Computation in a multi-area AS? Regards, Peng On 2/6/07, Zhang Renhai wrote: > Hi, JP > > See in-line please. > > > Hi Adrian, > > > > On Feb 5, 2007, at 7:11 PM, Adrian Farrel wrote: > > > >> Hi Greg, > >> > >>> - would you agree that usually ASBRs are eBGP speakers > >>> and are fully mesh connected. In that case eBGP can be > >>> viable solution for the inter-AS TE links computation by > >>> ASBR. > >> > >> So the question has to be: > >> Do other nodes apart from ASBRs need this information? > >> > >> What about an ingress LSR trying to compute a path out of the AS? > >> > >> If we require that the ingress LSR always consults an external PCE > >> that is a BGP speaker, then I guess this is fine, but most LSRs > >> today are capable of path computation and could handle this case > >> (for example, for the pd-path scenario) without needing to consult > >> an external PCE. > >> > >>> - I'm concerned with scaling aspect of flooding inter-AS TE > >>> information throughout both AS and an area > >> > >> I have this concern, too, but I wonder how many TE links we are > >> talking about, and how this compares with the number of TE links > >> within an area. > >> > > > > It is probably negligible ... Note that by contrast with the approach > > proposing to flooding Inter-ASBR TE LSP, we're only looking at > > flooding the TE information of the inter-ASBR *links*. > > > >>> and I see that you're concerned as well (SHOULD for Type > >>> 10 and MAY for Type 11). I think that it would be > >>> helpful if use of both Type 10 and Type 11 for inter-AS > >>> TE Link advertisement be illustrated by scenarios. I think > >>> that use of area scope makes these OSPF extensions less > >>> applicable to inter-AS path computation by the head-end > >>> LSR/LER. > >> > >> Yes, that would be the case. > > > >> I agree that we need to look more closely at the scenarios. I don't > >> think we have given enough thought to the nested domains case (i.e. > >> areas in ASes) given that both pd-path and brpc (largely) treat the > >> nested case as simply a flat sequence. > > > > Looking at the nested case, what would be the point of domain-scope > > since all TE-related info for the intra-area links have an area scope ? > [ZRH]I try to give an answer. > With a new sub-tlv(remote AS number)and a new link type > (inter-AS link type) are specified, in a multi-areas AS, the entry ASBR > when receving a path mesg can get the exit ASBR(in another area) with > this AS-scope advertisement and the path mesg(downstream AS number > is given in ERO). then, the inter-area computation can be performed. > > Regards, > Zhang Renhai > > > > >> > >>> - Could you please illustrate which links are excluded by the > >>> following: > >>> " Routers or PCEs that are capable of processing advertisements of > >>> inter-AS TE links SHOULD NOT use such links to compute paths that > >>> exit an AS to a remote ASBR and then immediately re-enter the AS. > >>> Such paths would constitute extremely rare occurrences and MUST > >>> only > >>> be allowed as the result of specific policy configuration at the > >>> router or PCE computing the path." > >>> Are there two links that interconnect a pair of ASBRs that belong > >>> to two > >>> different neighboring ASes? > >> > >> Renhai can comment, but I assumed that this meant that two ASes are > >> linked by more than two TE links. The LSP should not under normal > >> circumstances leave AS1 to AS2 through TE link 1 and return to AS1 > >> from AS2 through TE link 2. > >> > >> The example you give (ASBR1 in AS1 connects to ASBR2 in AS2 with > >> two links, the LSP goes out on one and back on the other) would be > >> detected as a loop in RSVP-TE, and would not offer any benefit anyway. > > > > Thanks. > > > > JP. > > > >> > >> Regards, > >> Adrian > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 07 01:53:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEgfk-0004Bs-Ah; Wed, 07 Feb 2007 01:52:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEgfj-0004Bn-51 for pce@ietf.org; Wed, 07 Feb 2007 01:52:51 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEgfi-0004gn-5r for pce@ietf.org; Wed, 07 Feb 2007 01:52:51 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD200BIVZ2THJ@szxga01-in.huawei.com> for pce@ietf.org; Wed, 07 Feb 2007 14:52:05 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD2001N7Z2SUT@szxga01-in.huawei.com> for pce@ietf.org; Wed, 07 Feb 2007 14:52:05 +0800 (CST) Received: from Z18605a ([10.111.12.125]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD2008J7Z2RD6@szxml04-in.huawei.com> for pce@ietf.org; Wed, 07 Feb 2007 14:52:04 +0800 (CST) Date: Wed, 07 Feb 2007 14:52:02 +0800 From: Zhang Renhai Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links To: Peng He Message-id: <006801c74a84$795a7ba0$7d0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0e3e01c74983$6aab40a0$76849ed9@your029b8cecfe> <56480CEA-78F0-4E10-BAF4-F471703444E3@cisco.com> <00ec01c749b7$bb2a1a90$7d0c6f0a@china.huawei.com> <406e32c00702061835s75d7911awd82c26b41d01c3e8@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: ccamp@ops.ietf.org, 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, Peng >I agreed with the following: > > "... we need to look more closely at the scenarios. I don't >>> think we have given enough thought to the nested domains case (i.e. >>> areas in ASes) given that both pd-path and brpc (largely) treat the >>> nested case as simply a flat sequence. >> >> Looking at the nested case, what would be the point of domain-scope >> since all TE-related info for the intra-area links have an area scope ?" > > I guess following the thinking line of this draft, we might need > another extension so as to advertising "inter-area" TE links into > non-backbone areas, or, just treat one area as a "domain"? Not sure if there really are inter-area TE links. Apart from the inter-AS links, all physical links exist exactly in one area for sure. > > And in Renhai's "[ZRH]I try to give an answer.", last line, how to > perform this inter-area computation? per-area? or Backward Recursive > Path Computation in a multi-area AS? Currently, there is no limitation of computation method, I think this is not what is intended to be discussed in this draft. However, this draft does provide the necessary info no matter which method is deployed. Thanks, Zhang Renhai > > Regards, > Peng > > On 2/6/07, Zhang Renhai wrote: >> Hi, JP >> >> See in-line please. >> >> > Hi Adrian, >> > >> > On Feb 5, 2007, at 7:11 PM, Adrian Farrel wrote: >> > >> >> Hi Greg, >> >> >> >>> - would you agree that usually ASBRs are eBGP speakers >> >>> and are fully mesh connected. In that case eBGP can be >> >>> viable solution for the inter-AS TE links computation by >> >>> ASBR. >> >> >> >> So the question has to be: >> >> Do other nodes apart from ASBRs need this information? >> >> >> >> What about an ingress LSR trying to compute a path out of the AS? >> >> >> >> If we require that the ingress LSR always consults an external PCE >> >> that is a BGP speaker, then I guess this is fine, but most LSRs >> >> today are capable of path computation and could handle this case >> >> (for example, for the pd-path scenario) without needing to consult >> >> an external PCE. >> >> >> >>> - I'm concerned with scaling aspect of flooding inter-AS TE >> >>> information throughout both AS and an area >> >> >> >> I have this concern, too, but I wonder how many TE links we are >> >> talking about, and how this compares with the number of TE links >> >> within an area. >> >> >> > >> > It is probably negligible ... Note that by contrast with the approach >> > proposing to flooding Inter-ASBR TE LSP, we're only looking at >> > flooding the TE information of the inter-ASBR *links*. >> > >> >>> and I see that you're concerned as well (SHOULD for Type >> >>> 10 and MAY for Type 11). I think that it would be >> >>> helpful if use of both Type 10 and Type 11 for inter-AS >> >>> TE Link advertisement be illustrated by scenarios. I think >> >>> that use of area scope makes these OSPF extensions less >> >>> applicable to inter-AS path computation by the head-end >> >>> LSR/LER. >> >> >> >> Yes, that would be the case. >> > >> >> I agree that we need to look more closely at the scenarios. I don't >> >> think we have given enough thought to the nested domains case (i.e. >> >> areas in ASes) given that both pd-path and brpc (largely) treat the >> >> nested case as simply a flat sequence. >> > >> > Looking at the nested case, what would be the point of domain-scope >> > since all TE-related info for the intra-area links have an area scope ? >> [ZRH]I try to give an answer. >> With a new sub-tlv(remote AS number)and a new link type >> (inter-AS link type) are specified, in a multi-areas AS, the entry ASBR >> when receving a path mesg can get the exit ASBR(in another area) with >> this AS-scope advertisement and the path mesg(downstream AS number >> is given in ERO). then, the inter-area computation can be performed. >> >> Regards, >> Zhang Renhai >> >> > >> >> >> >>> - Could you please illustrate which links are excluded by the >> >>> following: >> >>> " Routers or PCEs that are capable of processing advertisements of >> >>> inter-AS TE links SHOULD NOT use such links to compute paths that >> >>> exit an AS to a remote ASBR and then immediately re-enter the AS. >> >>> Such paths would constitute extremely rare occurrences and MUST >> >>> only >> >>> be allowed as the result of specific policy configuration at the >> >>> router or PCE computing the path." >> >>> Are there two links that interconnect a pair of ASBRs that belong >> >>> to two >> >>> different neighboring ASes? >> >> >> >> Renhai can comment, but I assumed that this meant that two ASes are >> >> linked by more than two TE links. The LSP should not under normal >> >> circumstances leave AS1 to AS2 through TE link 1 and return to AS1 >> >> from AS2 through TE link 2. >> >> >> >> The example you give (ASBR1 in AS1 connects to ASBR2 in AS2 with >> >> two links, the LSP goes out on one and back on the other) would be >> >> detected as a loop in RSVP-TE, and would not offer any benefit anyway. >> > >> > Thanks. >> > >> > JP. >> > >> >> >> >> Regards, >> >> Adrian >> > >> > >> >> > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 07 07:41:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEm70-0002sr-Tb; Wed, 07 Feb 2007 07:41:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEm6z-0002sg-C5 for pce@ietf.org; Wed, 07 Feb 2007 07:41:21 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEm6x-0001Fd-6W for pce@ietf.org; Wed, 07 Feb 2007 07:41:21 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Feb 2007 04:41:17 -0800 X-IronPort-AV: i="4.13,294,1167638400"; d="scan'208"; a="52439212:sNHT56802028" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l17CfGks019931; Wed, 7 Feb 2007 07:41:16 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l17CfEOA028907; Wed, 7 Feb 2007 07:41:14 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 07:41:14 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 07:41:12 -0500 In-Reply-To: <406e32c00702061835s75d7911awd82c26b41d01c3e8@mail.gmail.com> References: <0e3e01c74983$6aab40a0$76849ed9@your029b8cecfe> <56480CEA-78F0-4E10-BAF4-F471703444E3@cisco.com> <00ec01c749b7$bb2a1a90$7d0c6f0a@china.huawei.com> <406e32c00702061835s75d7911awd82c26b41d01c3e8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links Date: Wed, 7 Feb 2007 07:41:17 -0500 To: Peng He X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Feb 2007 12:41:12.0363 (UTC) FILETIME=[3FD247B0:01C74AB5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5546; t=1170852076; x=1171716076; 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]=20A=20New=20Internet-Draft=20on=20Advertising=2 0of=20inter-AS=20TE=20links |Sender:=20 |To:=20Peng=20He=20; bh=vk+63sriIzR6iKrcA1/J0c4ndfFxcaY/ttdA7S52skI=; b=DVJDeVkQKw+iUy0IMxzLk/JGetbhJ1wzAAACWoUq7EjEY2pbnj8aaUqk3annZDImxiq3jcwA NWklcO1AJk2sKaId6xNX+AEOYlfwo5sR/4BHa4jKwXkrTl7i1Lg+/TQA; 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: 3fbd9b434023f8abfcb1532abaec7a21 Cc: ccamp@ops.ietf.org, 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 ** with no PCE co-chair hat ** On Feb 6, 2007, at 9:35 PM, Peng He wrote: > I agreed with the following: > > "... we need to look more closely at the scenarios. I don't >>> think we have given enough thought to the nested domains case (i.e. >>> areas in ASes) given that both pd-path and brpc (largely) treat the >>> nested case as simply a flat sequence. >> >> Looking at the nested case, what would be the point of domain-scope >> since all TE-related info for the intra-area links have an area >> scope ?" > > I guess following the thinking line of this draft, we might need > another extension so as to advertising "inter-area" TE links into > non-backbone areas, or, just treat one area as a "domain"? !!! I firmly disagree ... this would mean doing TE aggregation for inter-area MPLS TE. Please refer to my previous email wrt to this type of solution, that has been discussed in length and rejected (please refer to RFC4105 + MLs archives). There is a fundamental difference between flooding the Inter-AS TE links and what you call the inter-area TE links (TE aggregation). > > And in Renhai's "[ZRH]I try to give an answer.", last line, how to > perform this inter-area computation? per-area? Looks like we're in a loop here ... pd-domain path computation and PCE-based have been designed for that. Thanks. JP. > or Backward Recursive > Path Computation in a multi-area AS? > > Regards, > Peng > > On 2/6/07, Zhang Renhai wrote: >> Hi, JP >> >> See in-line please. >> >> > Hi Adrian, >> > >> > On Feb 5, 2007, at 7:11 PM, Adrian Farrel wrote: >> > >> >> Hi Greg, >> >> >> >>> - would you agree that usually ASBRs are eBGP speakers >> >>> and are fully mesh connected. In that case eBGP can be >> >>> viable solution for the inter-AS TE links computation by >> >>> ASBR. >> >> >> >> So the question has to be: >> >> Do other nodes apart from ASBRs need this information? >> >> >> >> What about an ingress LSR trying to compute a path out of the AS? >> >> >> >> If we require that the ingress LSR always consults an external PCE >> >> that is a BGP speaker, then I guess this is fine, but most LSRs >> >> today are capable of path computation and could handle this case >> >> (for example, for the pd-path scenario) without needing to consult >> >> an external PCE. >> >> >> >>> - I'm concerned with scaling aspect of flooding inter-AS TE >> >>> information throughout both AS and an area >> >> >> >> I have this concern, too, but I wonder how many TE links we are >> >> talking about, and how this compares with the number of TE links >> >> within an area. >> >> >> > >> > It is probably negligible ... Note that by contrast with the >> approach >> > proposing to flooding Inter-ASBR TE LSP, we're only looking at >> > flooding the TE information of the inter-ASBR *links*. >> > >> >>> and I see that you're concerned as well (SHOULD for Type >> >>> 10 and MAY for Type 11). I think that it would be >> >>> helpful if use of both Type 10 and Type 11 for inter-AS >> >>> TE Link advertisement be illustrated by scenarios. I think >> >>> that use of area scope makes these OSPF extensions less >> >>> applicable to inter-AS path computation by the head-end >> >>> LSR/LER. >> >> >> >> Yes, that would be the case. >> > >> >> I agree that we need to look more closely at the scenarios. I >> don't >> >> think we have given enough thought to the nested domains case >> (i.e. >> >> areas in ASes) given that both pd-path and brpc (largely) treat >> the >> >> nested case as simply a flat sequence. >> > >> > Looking at the nested case, what would be the point of domain-scope >> > since all TE-related info for the intra-area links have an area >> scope ? >> [ZRH]I try to give an answer. >> With a new sub-tlv(remote AS number)and a new link type >> (inter-AS link type) are specified, in a multi-areas AS, the entry >> ASBR >> when receving a path mesg can get the exit ASBR(in another area) with >> this AS-scope advertisement and the path mesg(downstream AS number >> is given in ERO). then, the inter-area computation can be performed. >> >> Regards, >> Zhang Renhai >> >> > >> >> >> >>> - Could you please illustrate which links are excluded by the >> >>> following: >> >>> " Routers or PCEs that are capable of processing >> advertisements of >> >>> inter-AS TE links SHOULD NOT use such links to compute paths >> that >> >>> exit an AS to a remote ASBR and then immediately re-enter >> the AS. >> >>> Such paths would constitute extremely rare occurrences and MUST >> >>> only >> >>> be allowed as the result of specific policy configuration at >> the >> >>> router or PCE computing the path." >> >>> Are there two links that interconnect a pair of ASBRs that belong >> >>> to two >> >>> different neighboring ASes? >> >> >> >> Renhai can comment, but I assumed that this meant that two ASes >> are >> >> linked by more than two TE links. The LSP should not under normal >> >> circumstances leave AS1 to AS2 through TE link 1 and return to AS1 >> >> from AS2 through TE link 2. >> >> >> >> The example you give (ASBR1 in AS1 connects to ASBR2 in AS2 with >> >> two links, the LSP goes out on one and back on the other) would be >> >> detected as a loop in RSVP-TE, and would not offer any benefit >> anyway. >> > >> > Thanks. >> > >> > JP. >> > >> >> >> >> Regards, >> >> Adrian >> > >> > >> >> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Feb 07 10:11:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEoSF-0005Vv-EV; Wed, 07 Feb 2007 10:11:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEoDk-0006TI-R9 for pce@ietf.org; Wed, 07 Feb 2007 09:56:28 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEoDh-0006Ox-Qk for pce@ietf.org; Wed, 07 Feb 2007 09:56:28 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2007 09:56:25 -0500 X-IronPort-AV: i="4.13,295,1167627600"; d="scan'208,217"; a="113324593:sNHT154334288" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l17EuPj9026641; Wed, 7 Feb 2007 09:56:25 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l17EuPOA026193; Wed, 7 Feb 2007 09:56:25 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 09:56:25 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 09:56:21 -0500 In-Reply-To: <002501c73957$1718aea0$16600337@AOFR11476> References: <3329AB0B-19C1-4481-9EE4-4A9226FE01FA@cisco.com> <002501c73957$1718aea0$16600337@AOFR11476> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <89EEBB9A-17A1-45B6-8C3C-D255723ECB2F@cisco.com> From: JP Vasseur Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-pcep-05.txt Date: Wed, 7 Feb 2007 09:56:26 -0500 To: "fabien.verhaeghe" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Feb 2007 14:56:21.0437 (UTC) FILETIME=[2134C6D0:01C74AC8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=43886; t=1170860185; x=1171724185; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20I-D=20ACTION=3Adraft-ietf-pce-pcep-05.txt=20 |Sender:=20 |To:=20=22fabien.verhaeghe=22=20; bh=GSsMa+Muwf4T26/e56UGVDLeD5y1xcyaBI8H/msNOyY=; b=ly2AHwAH2LCanK4kVuVY12cwE8BWDkOaFySBqTGH0Z4qbktfo9GsRENRdg49mvd2bgDtf9f0 e3X7pkQx6192e11p3nCKGokI05DX5NLB/dgw1eNBtcu996M5xzqXemMW; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: afbb91703506ab43c817903f0dd6f23d X-Mailman-Approved-At: Wed, 07 Feb 2007 10:11:26 -0500 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="===============1627988545==" Errors-To: pce-bounces@lists.ietf.org --===============1627988545== Content-Type: multipart/alternative; boundary=Apple-Mail-220--720541214 --Apple-Mail-220--720541214 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Fabien, On Jan 16, 2007, at 5:14 AM, fabien.verhaeghe wrote: > Hello JP, All, > > I have a question about the PCntf message format: > > ::= > > ::= [] > ::= [] > > :== > := > > It seems to mean that we have the following kind of relation > between RP and NOTFICATION object: > RP --(0..n)--------(1..n)--NOTIFICATION > > While reading the description of the NOTIFICATION object it seems > to me that it should be > RP --(0..n)--------(1..1)--NOTIFICATION > > Shouldn't we have the following description? > > ::= > > ::= [] > ::= [] > > :== > > Or is it to offer some flexibility? > Indeed, because you may have more than one NOTIFICATION obj for a set. > Note that the same question/remark applies to Error message. > > By the way I just noticed a typo in 7.13 NOTIFICATION > > "If a new PCEP session is established while the PCE is in > congested state, the PCE MUST immediately send a PCErr with > Notification-type=2, Notification-value=1 along with the > optional CONGESTION-DURATION TLV." > Seems PCErr should be replaced by PCntf. Thanks. JP. > > Thanks > Fabien > > ----- Original Message ----- > From: JP Vasseur > To: pce@ietf.org > Sent: Saturday, January 13, 2007 12:57 AM > Subject: Fwd: [Pce] I-D ACTION:draft-ietf-pce-pcep-05.txt > > Here are the minor changes: > > 1) Change in the OPEN object format to align the field on byte > boundaries, > > 2) Addition of a new Reason for closing in the CLOSE object. > > In rev-04 we had: > > Reasons > Value Meaning > 1 No explanation provided > 2 DeadTimer expired > 3 PCEP session characteristics negotiation failure > > New: > 4 Reception of a malformed packet > > 3) Typo > > Thanks. > > JP. > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: January 12, 2007 6:50:01 PM EST >> To: i-d-announce@ietf.org >> Cc: pce@ietf.org >> Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-05.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Path Computation Element Working >> Group of the IETF. >> >> Title : Path Computation Element (PCE) communication Protocol >> (PCEP) - Version 1 >> Author(s) : J. Le Roux, J. Vasseur >> Filename : draft-ietf-pce-pcep-05.txt >> Pages : 66 >> Date : 2007-1-12 >> >> This document specifies the Path Computation Element communication >> Protocol (PCEP) for communications between a Path Computation >> Client >> (PCC) and a Path Computation Element (PCE), or between two PCEs. >> Such interactions include path computation requests and path >> computation replies as well as notifications of specific states >> related to the use of a PCE in the context of MPLS and GMPLS >> Traffic >> Engineering. The PCEP protocol is designed to be flexible and >> extensible so as to easily allow for the addition of further >> messages >> and objects, should further requirements be expressed in the >> future. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-05.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-ietf-pce-pcep-05.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-pce-pcep-05.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2007-1-12152022.I-D@ietf.org> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-220--720541214 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Fabien,

On = Jan 16, 2007, at 5:14 AM, fabien.verhaeghe wrote:

Hello JP, = All,
=A0
=A0
=A0=A0 <notify-list>::=3D<notify> = [<notify-list>]
=A0=A0 <notify>::=3D = [<request-id-list>]
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <notification-list>
=A0=A0 = <request-id-list>:=3D=3D<RP><request-id-list>
=A0
=A0 RP = --(0..n)--------(1..n)--NOTIFICATION
=A0
While reading the description of the NOTIFICATION = object it seems to me=A0that it=A0should = be
=A0
Shouldn't we have the = following=A0description?
=A0
=A0=A0 <PCNtf = Message>::=3D<Common Header>
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <notify-list>
Or is it to offer some flexibility?
Indeed, because you may = have more than one NOTIFICATION obj for a set.

Note that the same question/remark applies to Error = message.
=A0
By the way I just noticed a typo in 7.13 = NOTIFICATION
=A0
"If a new PCEP session is established while = the PCE is in
=A0=A0=A0=A0=A0=A0=A0=A0 congested state, the PCE = MUST immediately send a PCErr with
=A0=A0=A0=A0=A0=A0=A0=A0 = Notification-type=3D2, Notification-value=3D1 along with the

Thanks.

JP.

=A0
Thanks
Fabien
----- Original = Message -----

Here are the minor changes:

1) Change in the OPEN = object format=A0to align the field on byte = boundaries,

2) Addition of a new Reason for closing in = the CLOSE object.=A0

In rev-04 we had:=A0

Reasons
=A0 =A0 Value=A0 =A0 =A0 =A0 = Meaning
=A0 =A0 =A0 1=A0 =A0 =A0 =A0 =A0 = No explanation provided
=A0 =A0 =A0 2=A0 = =A0 =A0 =A0 =A0 DeadTimer expired
=A0 =A0 = =A0 3=A0 =A0 =A0 =A0 =A0 PCEP session characteristics negotiation = failure

New:
=A0 =A0=A0 =A04 =A0 =A0=A0 =A0=A0 = =A0Reception of a malformed packet

3) Typo

Thanks.

JP.

Begin forwarded message:

Date: = January 12, 2007 6:50:01 PM = EST
Subject: [Pce] I-D = ACTION:draft-ietf-pce-pcep-05.txt
A New = Internet-Draft is available from the on-line Internet-Drafts=A0

Title : Path Computation Element (PCE) = communication Protocol (PCEP) - Version 1
Author(s) : J. Le Roux, J. Vasseur
Filename : draft-ietf-pce-pcep-05.txt
Pages : 66
: 2007-1-12

This document specifies the Path Computation Element = communication
=A0=A0 = Protocol (PCEP) for communications between a Path Computation = Client
=A0=A0 (PCC) and a = Path Computation Element (PCE), or between two PCEs.
=A0=A0 Such = interactions include path computation requests and path
=A0=A0 computation = replies as well as notifications of specific states
=A0=A0 related to = the use of a PCE in the context of MPLS and GMPLS = Traffic
=A0=A0 =A0 = The PCEP protocol is designed to be flexible = and
=A0=A0 extensible = so as to easily allow for the addition of further = messages
=A0=A0 and = objects, should further requirements be expressed in the = future.

A URL for = this Internet-Draft is:



or =





__________________________________= _____________
Pce mailing list
Pce@lists.ietf.org
https://www1.= ietf.org/mailman/listinfo/pce


= --Apple-Mail-220--720541214-- --===============1627988545== 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 --===============1627988545==-- From pce-bounces@lists.ietf.org Thu Feb 08 11:23:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFC38-000817-8l; Thu, 08 Feb 2007 11:23:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFC37-0007zA-DR for pce@ietf.org; Thu, 08 Feb 2007 11:23:05 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFC34-0000ou-GL for pce@ietf.org; Thu, 08 Feb 2007 11:23:05 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2007 08:23:02 -0800 X-IronPort-AV: i="4.13,302,1167638400"; d="scan'208,217"; a="52533158:sNHT138614356" 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 l18GN2bE015220 for ; Thu, 8 Feb 2007 11:23:02 -0500 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 l18GN1VT013032 for ; Thu, 8 Feb 2007 11:23:01 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 11:23:01 -0500 Received: from [161.44.71.112] ([161.44.71.112]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 11:23:01 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <43D949CA-EAC5-42CD-BA33-52C91A838941@cisco.com> References: From: JP Vasseur Date: Thu, 8 Feb 2007 11:23:05 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Feb 2007 16:23:01.0284 (UTC) FILETIME=[66F83640:01C74B9D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=36109; t=1170951782; x=1171815782; 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:=20Fwd=3A=20Important=3A=20Remember=20to=20use=20latest=20boiler plate=20in=20drafts=20 |Sender:=20 |To:=20pce@ietf.org; bh=2DNfTcVaYbN3UUaO9q/P9Yo8UMPlgUzL5suYoMwItrE=; b=aElqZW8n7TzECgmVUk6xxlYUZO2tvcjcGVRXJckXvpKUrlgWx3KHnXXX1UShNg6BPuJhYnsy 9WtM099cwZ4rAwVpyL/o8T7MqWyVsguDhzuHeaxYowDGdEcJHeiamEl0; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 5f85cf2baaf973610992c2604e7b6057 Cc: Subject: [Pce] Fwd: Important: Remember to use latest boilerplate in drafts 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="===============0879392714==" Errors-To: pce-bounces@lists.ietf.org --===============0879392714== Content-Type: multipart/alternative; boundary=Apple-Mail-246--628942577 --Apple-Mail-246--628942577 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: IETF Chair > Date: February 8, 2007 5:15:20 AM EST > To: IETF Announcement list > Subject: Important: Remember to use latest boilerplate in drafts > > Hi, > > With the submission deadlines before the Prague meeting coming up, > please remember that all drafts need to use the latest boilerplate > text (see below for details). > > February 26, Monday - Internet Draft Cut-off for initial document > (-00) > submission by 09:00 ET (14:00 UTC/GMT) > > March 5, Monday - Internet Draft final submission cut-off by 09:00 ET > (14:00 UTC/GMT) > > Thanks > > Brian Carpenter > > -------- Original Message -------- > Subject: Internet-Draft Boilerplate Reminder > Date: Mon, 15 Jan 2007 11:51:16 -0500 > From: IETF Secretariat > To: IETF Announcement list > CC: iesg@ietf.org > > This message is to remind you that as of February 1, 2007 the IETF > Secretariat will no longer accept Internet-Drafts with the old > (i.e. pre RFC 4748) boilerplate. For your convenience, below is > the text of the message that was sent to the IETF Announcement > List by the IETF Chair on October 26, 2006 with Subject: Update to > Internet Draft and RFC Boilerplate. > > The IETF Secretariat. > -------------------------------------------------------------- > A small update to BCP 78 was recently approved by the IESG as RFC > 4748, > to update the boilerplate (i.e., standard legal text) in RFCs and > Internet-Drafts to recognize the IETF Trust as a rights holder, > instead of ISOC. > > The actual boilerplate changes are given below this message. > > Starting as soon as reasonably possible, all authors of Internet- > Drafts > are requested to use the new boilerplate. The RFC Editor will in any > case be inserting it in all RFCs issued from 2006-11-01. (The rights > held by ISOC in older RFCs will be administratively transferred to > the IETF Trust.) > > The public ID Nits checker already accepts I-Ds with old or new > boilerplate. The Secretariat has started accepting I-Ds with old or > new boilerplate. > > XML2RFC version 1.32 will generate the new boilerplate. > Users of I-D templates are requested to update them appropriately. > > http://www.ietf.org/ID-Checklist.html and > http://www.ietf.org/ietf/1id-guidelines.html are being updated. > > Starting December, the public ID Nits checker will issue warnings > for old > boilerplate. > > Starting February 2007, the Secretariat will refuse the old > boilerplate > in Internet-Drafts. > > We are sorry for the inconvenience, but this change cannot be avoided. > > IETF Chair > IETF Secretariat > TOOLS Team > > -------- > > Copyright Notice (required for all IETF Documents) > > (Normally placed at the end of the IETF Document.) > > NOTE: by convention, the first line of the copyright statement is > usually > placed near the beginning of each document. This must also be updated. > > OLD > "Copyright (C) The Internet Society (year). > > This document is subject to the rights, licenses and > restrictions > contained in BCP 78, and except as set forth therein, the > authors > retain all their rights. > > NEW > "Copyright (C) The IETF Trust (year). > > This document is subject to the rights, licenses and > restrictions > contained in BCP 78, and except as set forth therein, the > authors > retain all their rights. > > > Disclaimer (required in all IETF Documents) > > (Normally placed at the end of the IETF Document after the > copyright > notice.) > > > OLD > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY > THAT > THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY > RIGHTS OR > ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE." > > > NEW > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, > THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT > INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR > FITNESS > FOR A PARTICULAR PURPOSE." > > Exceptions > > In MIB modules, PIB modules and similar material commonly > extracted from IETF Documents, except for material that is being > placed under IANA maintenance, the following abbreviated notice > shall be included in the body of the material that will be > extracted in lieu of the notices otherwise required by > Section 5: > > OLD > "Copyright (C) The Internet Society . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > NEW > "Copyright (C) The IETF Trust . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > When the MIB or PIB module is the initial version of a module > that > is to be maintained by the IANA, the following abbreviated > notice > shall be included: > > OLD > "Copyright (C) The Internet Society . The initial > version of this MIB module was published in RFC XXXX; for > full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > > NEW > "Copyright (C) The IETF Trust . The initial > version of this MIB module was published in RFC XXXX; for > full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-246--628942577 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = IETF Chair <chair@ietf.org>
Date: = February 8, 2007 5:15:20 AM EST
To: IETF = Announcement list <ietf-announce@ietf.org>
Subject: Important: Remember to use latest = boilerplate in drafts=A0


With the submission deadlines before the Prague = meeting coming up,
please remember that all = drafts need to use the latest boilerplate
text = (see below for details).

February 26, Monday - Internet = Draft Cut-off for initial document (-00)

March 5, = Monday - Internet Draft final submission cut-off by 09:00 ET
(14:00 UTC/GMT)

Thanks

=A0 =A0 Brian Carpenter

-------- = Original Message --------
Subject: = Internet-Draft Boilerplate Reminder
Date: Mon, 15 = Jan 2007 11:51:16 -0500
From: IETF = Secretariat <ietf-secretariat@ietf.org>= ;
To: IETF Announcement list <ietf-announce@ietf.org>

This = message is to remind you that as of February 1, 2007 the IETF
Secretariat will no longer accept Internet-Drafts = with the old=A0
(i.e. pre RFC 4748) boilerplate.=A0 For your convenience, below = is=A0
the text of the message that was sent to the IETF = Announcement=A0
List by the IETF Chair on October 26, 2006 with = Subject: Update to
Internet Draft and RFC = Boilerplate.

The IETF Secretariat.
A small update to BCP 78 was recently approved by = the IESG as RFC 4748,=A0
to = update the boilerplate (i.e., standard legal text) in RFCs and=A0
=A0
instead = of ISOC.

The actual boilerplate changes are given below this = message.

Starting as soon as reasonably possible, all authors = of Internet-Drafts=A0
are requested to use the new boilerplate. The RFC = Editor will in any=A0
case be inserting it in all RFCs issued from = 2006-11-01. (The rights=A0
held by = ISOC in older RFCs will be administratively transferred to=A0
the IETF = Trust.)

The public ID Nits checker already accepts I-Ds with = old or new
boilerplate. The Secretariat has = started accepting I-Ds with old or=A0
new = boilerplate.

XML2RFC version 1.32 will generate the new = boilerplate.
Users of I-D templates are = requested to update them appropriately.


Starting = December, the public ID Nits checker will issue warnings for = old
boilerplate.

Starting = February 2007, the Secretariat will refuse the old boilerplate
in Internet-Drafts.

We are sorry = for the inconvenience, but this change cannot be avoided.

=A0 =A0 IETF Chair
=A0 =A0 = IETF Secretariat
=A0 =A0 TOOLS Team


Copyright Notice (required for all IETF = Documents)

=A0=A0 = (Normally placed at the end of the IETF Document.)

NOTE: by = convention, the first line of the copyright statement is = usually
placed near the beginning of = each document. This must also be updated.

OLD
=A0 =A0 =A0 = "Copyright (C) The Internet Society (year).

=A0 =A0 =A0 This document is = subject to the rights, licenses and restrictions
=A0 =A0 =A0 = contained in BCP 78, and except as set forth therein, the = authors
=A0 =A0 =A0 retain all their = rights.

NEW
=A0 =A0 =A0 "Copyright (C) The = IETF Trust (year).
=A0 =A0 =A0 This document is = subject to the rights, licenses and restrictions
=A0 =A0 =A0 = contained in BCP 78, and except as set forth therein, the = authors
=A0 =A0 =A0 retain all their = rights.



=A0=A0 (Normally placed at the = end of the IETF Document after the copyright
=A0=A0 = notice.)


=A0 =A0 =A0 "This document and = the information contained herein are provided
=A0 =A0 =A0 = on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION = HE/SHE
=A0 =A0 =A0 REPRESENTS OR IS = SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
=A0 =A0 =A0 = THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL = WARRANTIES,
=A0 =A0 =A0 EXPRESS OR IMPLIED, = INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
=A0 =A0 =A0 = THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS = OR
=A0 =A0 =A0= ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR = A
=A0 =A0 =A0= PARTICULAR PURPOSE."


NEW
=A0 =A0 =A0 "This document and = the information contained herein are provided
=A0 =A0 =A0 = on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION = HE/SHE
=A0 =A0 =A0 REPRESENTS OR IS = SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE=A0
=A0 =A0 =A0 IETF TRUST AND THE = INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
=A0 =A0 =A0 = WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO = ANY
=A0 =A0 =A0 WARRANTY THAT THE USE = OF THE INFORMATION HEREIN WILL NOT INFRINGE
=A0 =A0 =A0 ANY RIGHTS OR ANY = IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
=A0 =A0 =A0 = FOR A PARTICULAR PURPOSE."

Exceptions

=A0 =A0 =A0 In MIB modules, PIB = modules and similar material commonly
=A0 =A0 =A0 extracted from IETF = Documents, except for material that is being
=A0 =A0 =A0 = placed under IANA maintenance, the following abbreviated = notice
=A0 =A0 =A0 shall be included in = the body of the material that will be
=A0 =A0 =A0 extracted in lieu of = the notices otherwise required by Section 5:

=A0=A0 =A0 =A0 =A0 "Copyright (C) = The Internet Society <year>.=A0= This version of
=A0=A0 =A0 =A0 =A0 this MIB = module is part of RFC XXXX; see the RFC itself for
=A0=A0 =A0 =A0 = =A0 full legal notices."

NEW
=A0=A0 =A0 =A0 =A0 "Copyright (C) = The IETF Trust <year>.=A0 = This version of
=A0=A0 =A0 =A0 =A0 this MIB = module is part of RFC XXXX; see the RFC itself for
=A0=A0 =A0 =A0 = =A0 full legal notices."

=A0 =A0 =A0 When the MIB or PIB = module is the initial version of a module that
=A0 =A0 =A0 = is to be maintained by the IANA, the following abbreviated = notice
=A0 =A0 =A0 shall be = included:

OLD
=A0=A0 =A0 =A0 =A0 "Copyright (C) = The Internet Society <year>.=A0= The initial
=A0=A0 =A0 =A0 =A0 version of = this MIB module was published in RFC XXXX; for full
=A0=A0 =A0 =A0 = =A0 legal notices see the RFC itself.=A0 Supplementary = information
=A0=A0 =A0 =A0 =A0 may be = available at:

NEW
=A0=A0 =A0 =A0 =A0 "Copyright (C) = The IETF Trust <year>.=A0 = The initial
=A0=A0 =A0 =A0 =A0 version of = this MIB module was published in RFC XXXX; for full
=A0=A0 =A0 =A0 = =A0 legal notices see the RFC itself.=A0 Supplementary = information
=A0=A0 =A0 =A0 =A0 may be = available at:

IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=

= --Apple-Mail-246--628942577-- --===============0879392714== 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 --===============0879392714==-- From pce-bounces@lists.ietf.org Thu Feb 08 15:09:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFFZe-0002HF-3B; Thu, 08 Feb 2007 15:08:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFFZc-0002HA-Vn for pce@ietf.org; Thu, 08 Feb 2007 15:08:52 -0500 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 1HFFZa-0005z9-LP for pce@ietf.org; Thu, 08 Feb 2007 15:08:52 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2007 12:08:50 -0800 X-IronPort-AV: i="4.13,302,1167638400"; d="scan'208"; a="463214067:sNHT43931952" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l18K8oGg008532; Thu, 8 Feb 2007 12:08:50 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l18K8JEI027035; Thu, 8 Feb 2007 12:08:49 -0800 (PST) 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, 8 Feb 2007 15:08:25 -0500 Received: from [161.44.71.112] ([161.44.71.112]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 15:08:25 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9111AFAC-16C7-47D9-AF34-C35D2A34F7AE@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 8 Feb 2007 15:08:28 -0500 To: Adrian Farrel , Eiji Oki X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Feb 2007 20:08:25.0871 (UTC) FILETIME=[E44069F0:01C74BBC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=584; t=1170965330; x=1171829330; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Proposal=20to=20move=20the=20F=20bit=20in=20draft-oki-pce-pce p-xro |Sender:=20; bh=+/q6MLirJIMD/fA9lY/T3dkJcT0dCm/cpk+muyMjAPs=; b=bcjsy3aE/mqMQfIu1FdDHgnZgHT/Rlbg7LRvzn6lkNy6JhOpJZTC5MAEQ7EAD0wdLMDnRUIC T8HK2WrH9dVGi1Qhf+/HqJeyepo5vC9BU6SZEDAdolCNNBECUefRgCKn; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: pce@ietf.org Subject: [Pce] Proposal to move the F bit in draft-oki-pce-pcep-xro X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, In the current PCEP revision, we have defined an F bit in the RP object set by the PCC to request the computation of a new TE LSP after a failure the aim of which is for the PCE to recompute a new path while (1) Giving the bandwidth back to the TED before computing the new path and (2) Exclude the link that has failed by adding an XRO object (of course, this is useful if the TED has not been yet updated by the IGP). Because, we're using an XRO object, it probably makes more sense to define the F bit in your ID. What do you think ? Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Feb 08 19:31:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJf3-0005j3-OA; Thu, 08 Feb 2007 19:30:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJf2-0005il-2e for pce@ietf.org; Thu, 08 Feb 2007 19:30:44 -0500 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFJet-0000n8-Ot for pce@ietf.org; Thu, 08 Feb 2007 19:30:44 -0500 Received: from 57-97.dsl.data.net.uk ([80.68.57.97] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1HFJBA-0008JU-00 for pce@ietf.org; Thu, 08 Feb 2007 23:59:53 +0000 Received: from your029b8cecfe ([217.158.132.235] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 23:59:56 +0000 Message-ID: <01c201c74bdd$3811e160$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "JP Vasseur" , "Eiji Oki" References: <9111AFAC-16C7-47D9-AF34-C35D2A34F7AE@cisco.com> Date: Thu, 8 Feb 2007 23:54:01 -0000 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: 08 Feb 2007 23:59:57.0663 (UTC) FILETIME=[3C67A6F0:01C74BDD] X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: pce@ietf.org Subject: [Pce] Re: Proposal to move the F bit in draft-oki-pce-pcep-xro 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 Works for me. Or move the XRO into the main I-D ;-) A ----- Original Message ----- From: "JP Vasseur" To: "Adrian Farrel" ; "Eiji Oki" Cc: Sent: Thursday, February 08, 2007 8:08 PM Subject: Proposal to move the F bit in draft-oki-pce-pcep-xro > Hi, > > In the current PCEP revision, we have defined an F bit in the RP object > set by the PCC to request the computation of a new TE LSP after a failure > the aim of which is for the PCE to recompute a new path while (1) Giving > the bandwidth back to the TED before computing the new path and (2) > Exclude the link that has failed by adding an XRO object (of course, this > is useful if the TED has not been yet updated by the IGP). Because, we're > using an XRO object, it probably makes more sense to define the F bit in > your ID. What do you think ? > > Thanks. > > JP. > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Feb 09 02:13:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFPvy-0007wR-AI; Fri, 09 Feb 2007 02:12:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFPvx-0007wJ-EU for pce@ietf.org; Fri, 09 Feb 2007 02:12:37 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFPvv-0000R4-KY for pce@ietf.org; Fri, 09 Feb 2007 02:12:37 -0500 Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l197CXMY005353; Fri, 9 Feb 2007 16:12:33 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 5321A20AE33; Fri, 9 Feb 2007 16:12:32 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id BF30820AE2A; Fri, 9 Feb 2007 16:12:31 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l197CVJi028569; Fri, 9 Feb 2007 16:12:31 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l197CUq7026364; Fri, 9 Feb 2007 16:12:30 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l197CUHG026360; Fri, 9 Feb 2007 16:12:30 +0900 (JST) Received: from [129.60.80.139] ([129.60.80.139]) by imb.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l197CTTW017000; Fri, 9 Feb 2007 16:12:29 +0900 (JST) Date: Fri, 09 Feb 2007 16:12:27 +0900 From: Eiji Oki To: JP Vasseur In-Reply-To: <9111AFAC-16C7-47D9-AF34-C35D2A34F7AE@cisco.com> References: <9111AFAC-16C7-47D9-AF34-C35D2A34F7AE@cisco.com> Message-Id: <20070209161202.040A.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: pce@ietf.org Subject: [Pce] Re: Proposal to move the F bit in draft-oki-pce-pcep-xro 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 JP, It is good to me. Eiji On Thu, 8 Feb 2007 15:08:28 -0500 JP Vasseur wrote: > Hi, > > In the current PCEP revision, we have defined an F bit in the RP > object set by the PCC to request the computation of a new TE LSP > after a failure the aim of which is for the PCE to recompute a new > path while (1) Giving the bandwidth back to the TED before computing > the new path and (2) Exclude the link that has failed by adding an > XRO object (of course, this is useful if the TED has not been yet > updated by the IGP). Because, we're using an XRO object, it probably > makes more sense to define the F bit in your ID. What do you think ? > > Thanks. > > JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Feb 13 10:14:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzMg-0005se-2p; Tue, 13 Feb 2007 10:14:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyPZ-0005vs-Pl for pce@ietf.org; Tue, 13 Feb 2007 09:13:37 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGyPV-0000bZ-Ey for pce@ietf.org; Tue, 13 Feb 2007 09:13:37 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Feb 2007 09:13:33 -0500 X-IronPort-AV: i="4.14,163,1170651600"; d="scan'208,217"; a="113789055:sNHT239002184" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1DEDXcV010651; Tue, 13 Feb 2007 09:13:33 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1DEDUOA027293; Tue, 13 Feb 2007 09:13:31 -0500 (EST) 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, 13 Feb 2007 09:13:30 -0500 Received: from [161.44.113.90] ([161.44.113.90]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 09:13:30 -0500 In-Reply-To: <0e3a01c70819$a4134780$5a418182@your029b8cecfe> References: <0afd01c707f5$a1b20950$5a418182@your029b8cecfe> <3C58B997-6693-4E26-AA06-192047FFB464@cisco.com> <0e3a01c70819$a4134780$5a418182@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <5812962B-54B8-49E5-803E-CCB631B3DF8A@cisco.com> From: JP Vasseur Date: Tue, 13 Feb 2007 09:13:28 -0500 To: "Adrian Farrel" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Feb 2007 14:13:30.0157 (UTC) FILETIME=[231515D0:01C74F79] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=93635; t=1171376013; x=1172240013; 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=20High=20level=20PCEP=20Review |Sender:=20 |To:=20=22Adrian=20Farrel=22=20; bh=kqZMJM34eBjR9fmWHKNqxgptIRBtc4GBqcHXTVYLSUQ=; b=HXHxWxOzl8+8HIAJWcWy5o7HCcT5o44AJnv+Hq4jq3vQ9HAPBArATF2fEiuZO5O3fGnloLT5 2fCuZubpjgjzw3TYdQbY5sQpfyPs/o6FN/ONn3UKvyPLD9tSuCAGc7Dw; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.6 (/) X-Scan-Signature: 5202c26de58d3fc190f3a726de2288e3 X-Mailman-Approved-At: Tue, 13 Feb 2007 10:14:39 -0500 Cc: Eiji Oki , Arthi Ayyangar , pce@ietf.org, Kenji Kumaki , akatlas@alum.mit.edu Subject: [Pce] Re: High level PCEP Review 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="===============1005348882==" Errors-To: pce-bounces@lists.ietf.org --===============1005348882== Content-Type: multipart/alternative; boundary=Apple-Mail-22--204719750 --Apple-Mail-22--204719750 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Adrian, Thanks for the review, very useful comments. I skipped some addressed comments. On Nov 14, 2006, at 1:18 PM, Adrian Farrel wrote: > Hi, > > As discussed, it is time to review PCEP from outside the design > team. JP asked (well, OK, he begged :-) that at this review I > limit myself to major protocol issues, and leave other > documentation issues to a later review. I have mainly done that, > but I have also included a few process-related comments that I > think you should > resolve in the next revision. > > Cheers, > Adrian > > === > Any reason why the Open, Close, and Keepalive messages do not > conform to the naming convention "PCXxxx" of all other messages? Not really ... We just kept the Open, Close and Keepalive terminology as it is widely used in many protocols with the same meaning (other messages are PCEP specific). > === > PCErr is missing from section 5. Right, thanks, a section has been added. > Indeed, the use of PCNtfy as shown in figure 5 to express > cancellation of a request by a PCE would seem to be the correct > usage of PCErr. > I suggest a bit of a rationalisation (and perhaps the creation of > a new message - PCCncl). > Thus PCNtfy becomes a benign notification message, PCErr is used > by the PCE to report an error (but not a failure), PCCncl is used > by the PCC to cancel a PCReq. > It is best if we can resist overloading the semantics of the > different messages. This is a valid comment but we're afraid of seeing a message inflation ... After PCCncl, we could see PCCong (PCE Congestion) and many other ones, thus we'd prefer to keep the PCNtf as a generic mechanism to notify of various events. In term of semantic, the PCErr is exclusively used to report a protocol error condition. In the request cancellation case, the PCE experiencing congestion would notify the PCC that it had to cancel some requests. > === > Section 5.2.5 would benefit from a statement that it is your > intention that the TCP connection can be re-established and > recover the context of a session without further exchange of Open > messages. I think this is what you intend. We initially went in that direction but stepped back since this is probably not the best approach. Thus, we changed the text to specify that a TCP connection failure MUST trigger the PCEP session failure (clearing all related states), but that section had not been updated. Text updated now, thanks. > I am not sure it is good, and would prefer that the session was > also re-established with the exchange of a list of PCReq I-Ds > still outstanding OR that a failed TCP connection automatically > cleared the session. Exactly, we chose the second option, we're in sync. > Otherwise you complicate the protocol and the implementation with > handling duplicate request I-Ds and lost requests/responses. Absolutely (for a very minor benefit). > === > In section 6 you imply that a malformed PCErr will cause the > generation of a PCErr. I suggest you need to avoid this behavior > to prevent duelling error messages! We now differentiate the case of a PCEP message received with a missing object (in which case a PCErr message is sent with Error- Type=6) and the case of a malformed message that triggers the closing of the PCEP session with Reason=4. > === > Can you include a reference to the definition of BNF in section 6 > === ISO 14977? > In 6.1 you need to describe the default settings of the Flags and > Reserved fields Indeed, added. > === > Do you really support 2^32 byte messages? If this is a conscious > decision, then maybe OK. We changed for 65K (16 bits), thus the header has been reduced from 8 bytes to 4 bytes. New Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Flags |Message-Type| Message- Lenght | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver: 3 bits Flags: 5 bits Message Type: 8 bits Message Length: 16 bits > === > 6.3 doesn't mention the use of keepalive to detect TCP connection > failure. I think it should. I think that we should not mention the use of the PCEP Keepalive to detect a TCP failure though. The Keepalive is really used to detect a PCEP session failure that may or may not be triggered by a TCP failure. Thus, as stated in the document, it is used for PCEP session aliveness detection. Agree ? > === > In 6.4 the End-Points object is described as mandatory, but the > BNF has it optional Good catch, thanks. Fixed. > === > In 6.7 > The PCErr message may be sent by a PCC or a PCE in response to a > request or in an unsolicited manner. > "may"? Reworded: "The PCErr message is either sent by a PCC or a PCE in response to a request or in an unsolicited manner" > === > In the objects you define reserved fields as MUST be set to zero. > I think you need: > - SHOULD be set to zero > - MUST be ignored on receipt Now specified (for all objects): Reserved: This field MUST be set to zero on transmission and MUST be ignored on receipt. > === > In 7.1 it is unclear, but I think the P flag would only have > meaning on a request, and the I flag on a response. > So actually, you only need one flag (or you have some > clarification text to write) We could use a single bit, which would mean that the flag, say P is cleared for an optional object in a PCReq and set for an optional object that has been taken into account in a PCRep: so to interpret the bit we need to also remember the PCEP message type. Not a problem though ... Note that I was tempted to generalize the concept to the processing of an object in general (that could be in a PCReq or PCRep message) but without strong use case, it is not worth adding complexity. Let me know which option you prefer, I've got no preference (1 or 2 bits), well a slight preference for keeping two bits (easier to interpret). > === > You will also need to explain what it means when a PCRep has the I > flag set for an object that had the P flag set on the PCReq. As > currently phrased this is an encoding error that would require a > PCErr, but that would clearly be a waste of time. Yes, text has been added "The I flag has no meaning in a PCRep message when the P flag had been set in the corresponding PCRep message." > === > In fact, why would you ever send a PCErr in response to a PCRep? There are such cases. For example: 6 Mandatory Object missing Error-value=1: RP object missing > === > At the end of 7.1 you need to explain padding rules Object are all aligned to 32-bits. > === > Why does the Open need a protocol version number? This is in the > message header so we all know what protocol is being used/supported. > in fact, I think you need to re-write the protocol version support > processing and negotiation. The idea is to not set up a PCEP session if the supported PCEP version do not match. > === > Dead timer. > Should it be "SHOULD be set to zero, and MUST be ignored if the > keepalive timer is zero" Don't you prefer to set it to 0 if the Keepalive is itself set to 0 (less prone to misinterpretation)? > === > The fields in the Open object are a mess! > Can you bring the flags up with the version to improve the byte- > alignment? > === Yes ! It was fixed in a revision post to rev-03. > Note that in the message header the version is four bits but in > the Open object it is three bits. > === Fixed, thanks. > In the Open object > SID (PCEP session-ID - 8 bits): specifies a 2 octet unsigned PCEP > session number that identifies the current session. > Are you using bit compression? Nope. > === > Open object TLVs may be out of the scope of this doc (7.2) but the > format needs to be defined here. > === mmm ... It is no different than future objects that may be carried in PCEP messages ? > When present in an Open message, the OPEN object specifies the > proposed PCEP session characteristics. Upon receiving unacceptable > PCEP session characteristics during the PCEP session initialization > phase, the receiving PCEP peer (PCE) MAY include a PCEP object > within > the PCErr message so as to propose alternative session > characteristic > values. > Isn't there an issue with duelling Open messages? > You seem to have an independent Open in each direction, each of > which is responded with a PCErr, leading to a new Open in each > direction. > Is it necessary to have this symmetry? After all, the TCP > connection is always initiated by the PCC, so can't we also have > the Open initiated by the PCC and responded with a PCErr or an > Open by the PCE. Keepalives then follow. We could but introducing such asymmetry also adds complexity to the FSM. > === > 7.3 > Why is the P flag set in an RP object carried in a PCNtf or PCErr? > No computation action is required. Good catch, it now reads: "The P flag of the RP object MUST be set in PCReq and PCReq messages and MUST be cleared in PCNtf and PCErr messages." > === > Why is there a reserved piece of the RP object? Is there a > difference between the unused flags bits and the reserved field? > === Clarified. > 7.3.1 > Note that it is not required for a PCE to > support the priority field: in this case, it is RECOMMENDED to set > the priority field to 0 by the PCC in the RP object. > Why would it matter what value is set if it is not supported by > the PCE? Just a recommendation ... if the PCC learns via IGP discovery that the PCE does not support the priority field, it is desirable to have it set to 0. But the information may not be available of course, thus the recommendation. Another way to discover whether this is supported is for the PCC to set it to <>0, and have the PCE reset the field. Note that these are recommendations, not required. > Wouldn't it possibly be helpful if the PCE forwards the request to > another PCE? I think that this should be exclusively triggered by the PCC (after discovering the non support of prioritization) and is application specific but having the PCE redirecting the requesting to another PCE itself may lead to undesirable consequences. > === > 7.3.1 > As described here there is no difference between the R and the F > bit. Both are used to recompute a path allowing re-use of > resources already used by the path. Presumably in the case of the > F bit, some information about the failure is also supplied through > an exclusion, but this is not mentioned. The behavior at the PCE > for these two bits would seem to be identical so unless you can > give better separation of the meanings, I suggest you merge the bits. You're right that the text is not explicit. In the case of the F bit, the information can be used by the PCE to exclude some links should the updated IGP LSA be received after the path computation request. As discussed on the list, let's move that bit to the XRO draft. Section removed. > === > 7.3.1 > The description of the O-bit is very confusing. > I think the problem lies with the definition of "explicit path" > Loose means that it is acceptable to include loose hops > You have no term to distinguish the use of abstract nodes that > contain more than one network node > Explicit just means an ERO > Strict means that only strict hops are allowed There were some typos/issues in the text indeed ... New Text: "O (strict/lOose - 1 bit): when set, in a PCReq message, this indicates that a loose path is acceptable. Otherwise, when cleared, this indicates to the PCE that a path exclusively made of strict hops is required. In a PCRep message, when the O bit is set this indicates that the returned path is a loose path, otherwise (the O bit is cleared), the returned path is made of strict hops." > === > 7.3.1 > You need to think about how the Request ID is handled when the PCC > restarts. Are you requiring the PCC to have persistent memory to > avoid re-use of a Request ID? (That is how the text reads!) Yes, an implementation issue where the PCC may either tear down the session upon restart or checkpoints. > === > 7.3.2 > The description of R-bit handling looks broken. > The previous setting of the O-bit is not important because the PCC > is able to use RRO to collect information from the network. Thus, > the question is actually about how detailed the RRO is. The point > you are making remains (that it is hard to compute a proper make- > before-break resource-sharing path if you don't know the previous > path. [Those of you looking at the inter-area/AS PCE problem space > will recognise this as impossible to solve unless stateful PCEs > are used or the PCE is provided with a way to issue an enquiry to > the ABR/ASBR.] I don't think that the definition is broken. Few cases here: 1) Provide the RRO with strict hops and set the R flag to avoid double bw booking 2) If the PCC does not know the RRO with all strict hops, provides what it knows + set the R flag In all cases the PCC MUST provide the RRO which may contain loose hops (in which case double bandwidth booking cannot be guaranteed). > === > 7.3.2 > If the PCC receives a PCRep message that contains a RP object > referring to an unknown Request-ID-Number, the PCC MUST send a PCErr > message with Error-Type="Unknown request reference". > This feels like at most a "MAY". Why is there a requirement to > respond? Because actions are very likely required on the PCE, thus we mandate the PCC to respond so that the PCE detects the issue. Makes sense ? > === > 7.4 > I don't think the description on the inclusion of "failed" > constraints in the PCRep message is in agreement with the BNF in > section 6.5. The BNF appears to imply that an ERO must be present > in order to include, for example, a Metric object. > [By the way: I continue to believe that this business of reporting > the failed constraints is extremely dubious. Where there are two > absolute constraints to be satisfied, it is often impossible to > state which of them led to the failure to compute a path.] In that case, the PCE may either to decide to indicate none of them or both. But the case where only one constraint is not satisfied is by itself a clear motivation for this feature (pretty common situation). Not sure to see the issue with the BNF since the path- list is optional ? > === > 7.4 > How does a PCC tell the difference between a PCRep that contains > the "failed" constraints echoed from the PCReq, and modified > constraints that could have been satisfied? Just by comparing the original values sent by the PCC to the values returned by the PCE: if they differ, suggestions are provided by the PCE. > From the text it appears that you intend the C-bit to make this > distinction, but the description of the C-bt does not say this. The C bit is set when the PCE indicates the set of non satisfied constraints. > === > 7.4 > Wouldn't it be a good idea to put a reason code in the No-Path object? Yes this was added to a post rev-03 revision (NO-PATH-VECTOR TLV). > === > 7.5 > Can you add a note to say where the end points of the LSP *are* > encoded. > That is, although this PCReq is computing a segment only, it is > important (at least for policy) to know the LSP end points as well. As pointed out in the text "The END-POINTS object is used in a PCReq message to specify the source IP address and the destination IP address of the path for which a path computation is requested. Note that the source and destination addresses specified in the END-POINTS object may or may not correspond to the source and destination IP address of the TE LSP but rather to a path segment." In the second case, the LSP end-points are not provided. If an application requires this information (as you said for policy, .. ) it should be defined in another ID. > === > 7.6 > First paragraph is hard to parse, but I think it says that the > Bandwidth object must always be present in a PCReq! But the second > paragraph explains what it means if it is absent. OK so I reworded it: " The BANDWIDTH object is used to specify the requested bandwidth for a TE LSP. If the requested bandwidth is equal to 0, the BANDWIDTH object is optional. Conversely, if the requested bandwidth is non equal to 0, the PCReq message MUST contain a BANDWIDTH object. In the case of the reoptimization of a TE LSP, the bandwidth of the existing TE LSP MUST also be included in addition to the requested bandwidth if and only if the two values differ. Consequently, two Object-Type are defined that refer to the requested bandwidth and the bandwidth of the TE LSP for which a reoptimization is being performed. " > === > 7.6 > Can you give a references to the IEEE FP definition. Sounds pretty well-known, no ? > === > 7.7 > Please add a third metric: hop count Good idea, added. > I think you need to allow the Metric object to be present multiple > times, and you have this in the text, but it is missing in the BNF. Good catch. I also fixed the BNF for the PCReq message (same purpose) > On the other hand, you need to describe how to interpret multiple > Metric objects for the same Type setting Text added "There MUST be at most one instance of the METRIC object for each metric type. In two or more instances of a METRIC object are present for a metric type, only the first instance MUST be considered and other instances MUST be ignored." > === > 7.7 > Why do you need the B-bit? The metric value is set to zero with > the same semantic. This is because the metric-value is used to report the metric of a TE LSP for a reoptimization request. Thus, we need the B-bit to indicate whether the metric-value corresponds to the metric of the TE LSP to be reoptimized or to a bound. That said, I'm realizing that this was not written down and the text had to be reworded. New text: "A METRIC object used to indicate the metric to optimize during the path computation MUST have the B-Flag cleared and the T-Flag set to the appropriate value. When the path computation relates to the reoptimization of an exiting TE LSP (in which case R-Flag of the RP object is set) an implementation MAY decide to set the metric-value field to the cost of the TE LSP to be reoptimized with regards to a specific metric type.)" I also fixed a few other issues in the paragraph. > === > 7.7 > The text appears to say that only one Metric object may be present > with the B-flag cleared. Why? I think that we should relax that constraint indeed. *That said*, how should the PCE interpret the request to optimize a path based on Metric-1 and Metric-2 ? Without further indication (hierarchical constraint, weighting function, ...) this has no meaning. Proposal: we relaxed the constraint but the text required to fully cover those aspects will be covered in another ID, as discussed months ago on the list. OK ? > === > 7.8 and 7.9 (and everywhere) > A real nit, but when you write "ERO object" or "RRO object" do you > mean EROO and RROO? :-) ;-) Fixed ... sorry for the tautology > === > 7.8 > You say that the ERO is bounded by 3209, 3473 and 3477 which is > fine, but how will an MPLS-TE LSR handle an ERO with an explicit > label in it? You also allow future extensions to subobjects. > I think this means that the PCReq must include a way for the > requester to limit the subobjects that will be returned. Do you think that we should limit these objects ? Indeed some ERO sub- objects may be defined in the future that might be of interest ? > === > 7.9 > RRO is also used for reporting the path of a failed LSP? See comment above, this will be covered in the XRO ID. > === > 7.10 > What are optional TLVs for? > Perhaps to carry the additional attributes as defined in RFC4420? Yes I added a reference. > === > 7.10 > Why do you need an LSPA object without resource affinities? This > is pointless. It only exists in 3209 for backwards compatibility. Absolutely ! Text modified to define one object (w/ affinity). > === > 7.10 > What is the meaning of holding priority with respect to path > computation? This can be taken into account by the PCE when computing the path(s). > === > 7.10 > Why are the Flags and Reserved fields different sizes in the two > objects? Only one object now. > === > 7.10 > When computing a path to satisfy a request with the L-bit set, how > will the PCE know which links are protected with FRR? This can be obtained from draft-ietf-isis-link-attr for example, or locally available in a database. > === > 7.11 > Good to see the IRO > Why is there no XRO? > Exclusion is a standard part of the MPLS-TE MIB (RFC3812 see > mplsTunnelHopInclude). If the exclusion can be configured on the > headend LSR, I think we need to be able to compute the path. > Besides, this is a requirement in RC4657. Covered in draft-oki-pce-pcep-xro-00.txt > === > 7.11 > Why is it necessary to list the subobjects for the IRO but not for > the ERO or the RRO? We listed them since the IRO is a new object by contrast with the ERO and RRO for which we re-use existing object formats (we just define a PCEP codepoint). > === > 7.12.1 > I urge caution in the use of "simultaneously" in this section. Agree since this can never be true ;-) Reworded: "Independent versus dependent path computation requests: path computation requests are said to be independent if they are not related to each other. Conversely a set of dependent path computation requests is such that their computations cannot be performed independently of each other (a typical example of dependent requests is the computation of a set of diverse paths)." > === > 7.12.1 > At the end of this section, you suddenly introduce the term > "bundle". I think this is supposed to refer to the presence of > multiple requests in a single PCReq message. Note that the SVEC > can apply across messages. It would, perhaps be better to explain > that requests in the same message are not necessarily associated > by an SVEC, and that requests in separate messages may be > associated by an SVEC. This is detailed in 7.12.3. > === > 7.12 > You are missing text to describe the use of the SVEC on a PCRep > (allowed according to 6.5). > It feels like you would only use SVEC in the case of an RP, but > the BNF has them as independent. > Please clarify BNF has been fixed, there's no reason to have the SVEC in PCRep, thanks. > === > 7.12.2 > You have MUST NOT for each of your diversity characteristics. > I think you also need "desired" so that you can get "as much > diversity as possible". > How will you handle the overlap between (for example) node and > link diversity? Just needs some text to explain. Yes, this is a topic that we discussed a few times, we could define a "desired" bit along with various constraint relaxation strategy but this would lead to adding much complexity. So we decided to keep the simple rule here and add more functionality in a separate ID. The overlap case is quite simple here: in this example, link two LSP are link *and* node diverse they cannot have any link/node in common. Node diverse => link diverse, not the opposite of course. > === > 7.12 > Is it possible to end up with a nasty mesh of synchronized > requests? Are there any rules to resolve this? Good implementation ;-) (thus the timer-based approach suggested), but this is implementation-specific. > === > 10 > The state machine is quite hard to parse for reviewing purposes. > It would be good to at least name the arrows on the figure. My > personal preference is to draw the FSM as a grid because this > shows up missing state/event combinations far more easily. > > Is the OpenRetry counter just a substate of OpenWait? > > The description of OpenRetry is at odds with the error used (1:5). > The error says a second unacceptable Open has been received, but > the text says that OpenRetry is incremented if the Open is > anything except malformed. Can I suggest that the use of a > separate state and not a substate would help you resolve this type > of issue. > > LocalOK also looks like a substate. Ditto RemoteOK. Please don't > use substates, they are evil! YEs, they are not sub-state but variables. > The flip flop between OpenWait and KeepWait caused by these two > variables and the negotiation of parameters is ghastly. > > I think that what the state machine shows us is that we do not > need independent Open messages in each direction. Anyway, if we > *do* need them, we need correct states to manage them. We'll need a piece of paper ... In prague .. > === > 10 > If a malformed PCEP message is received or the TCP connection fails, > the systems sends a PCEP CLOSE message, the system releases the PCEP > resources for that PCEP peer, closes the TCP connection and moves to > the Idle State. > This seems to be in contradiction with text in the main body of > the draft and with the existence of error code 6. Yes we decided to close the TCP connection upon receiving a malformed packet. Not sure which section you're referring to here ? > === > App A > Is this appendix just present to help you track the requirements > you still need to satisfy, or do you intend to leave some > requirements unanswered? This was requested a few IETF meetings ago to keep track of the requirements to be satisfied. All unanswered MUST requirements will be listed there. Text updated. > > BTW, I don't think this is a full list. Route exclusions is not > listed. Reference added. > > What are you doing to ensure that the list is complete? > === > I think Kenji's email address may have changed > Same for Jean-Louis Thanks! JP. --Apple-Mail-22--204719750 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Adrian,

Thanks for the review, very = useful comments. I skipped some addressed = comments.

On Nov 14, 2006, at 1:18 PM, Adrian = Farrel wrote:

Hi,

As discussed, = it is time to review PCEP from outside the design=A0 team. JP asked (well, OK, he = begged :-) that at this review I limit=A0 myself to major protocol = issues, and leave other documentation issues to a later review. I have = mainly done that, but I have also included a few process-related = comments that I think you should
resolve in = the next revision.
Cheers,
Adrian

=3D=3D=3D
=
Any reason why the Open, Close, and Keepalive = messages do not=A0 conform = to the naming convention "PCXxxx" of all other = messages?

Not really ... We just kept = the Open, Close and Keepalive terminology as it is widely used in many = protocols with the same meaning (other messages are PCEP = specific).

PCErr is missing from section = 5.

Right, thanks, a section = has been added.

Indeed, the use of PCNtfy as shown in figure 5 to = express=A0 cancellation of = a request by a PCE would seem to be the correct=A0 usage of PCErr.
I suggest a bit of a rationalisation (and perhaps = the creation of a=A0 new = message - PCCncl).
Thus PCNtfy becomes a = benign notification message, PCErr is used by=A0 the PCE to report an error = (but not a failure), PCCncl is used by=A0 the PCC to cancel a = PCReq.
It is best if we can resist = overloading the semantics of the=A0 = different messages.

This is a valid comment but = we're afraid of seeing a message inflation ... After PCCncl, we could = see PCCong (PCE Congestion) and many other ones, thus we'd prefer to = keep the PCNtf as a generic mechanism to notify of various events. In = term of semantic, the PCErr is exclusively used to report a protocol = error condition. In the request cancellation case, the PCE experiencing = congestion would notify the PCC that it had to cancel some = requests.

Section 5.2.5 would benefit from = a statement that it is your=A0 = intention that the TCP connection can be re-established and = recover=A0 the context of a = session without further exchange of Open messages.=A0 I think this is what you = intend.

We initially went in that = direction but stepped back since this is probably not the best approach. = Thus, we changed the text to specify that a TCP connection failure MUST = trigger the PCEP session failure (clearing all related states), but that = section had not been updated. Text updated now, = thanks.

I am not = sure it is good, and=A0 = would prefer that the session was also re-established with = the=A0 exchange of a list = of PCReq I-Ds still outstanding OR that a failed=A0 TCP connection automatically = cleared the session.

Exactly, we chose the = second option, we're in sync.

Otherwise you=A0= complicate the protocol and the implementation with = handling=A0 duplicate = request I-Ds and lost requests/responses.

Absolutely (for a very = minor benefit).

=3D=3D=3D
In section 6 = you imply that a malformed PCErr will cause the=A0 generation of a PCErr. I = suggest you need to avoid this behavior to=A0 prevent duelling error = messages!

We now differentiate the = case of a PCEP message received with a missing object (in which case a = PCErr message is sent with Error-Type=3D6) and the case of a malformed = message that triggers the closing of the PCEP session with = Reason=3D4.

Can you include a reference to = the definition of BNF in section 6
ISO = 14977?

In 6.1 = you need to describe the default settings of the Flags and=A0 Reserved = fields

Indeed, = added.

=3D=3D=3D
=
Do you really support 2^32 byte messages? If this is = a conscious=A0 decision, = then maybe OK.

We changed for 65K (16 = bits), thus the header has been reduced from 8 bytes to 4 = bytes.

New = Header:=A0

0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
| Ver =A0 |=A0 Flags =A0 =A0 |Message-Type| =A0 =A0 =A0 = Message-Lenght=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+

Ver: 3 bits
Flags: 5 = bits
Message Type: 8 bits
Message Length: 16 bits


=3D=3D=3D
6.3 doesn't = mention the use of keepalive to detect TCP connection=A0 failure. I think it = should.

I think that we should not = mention the use of the PCEP Keepalive to detect a TCP failure = though.
The Keepalive is really used to detect a PCEP session = failure that may or may not be triggered by
a TCP failure. = Thus, as stated in the document, it is used for PCEP session aliveness = detection.
Agree ?

=3D=3D=3D
In 6.4 the = End-Points object is described as mandatory, but the BNF=A0 has it = optional

Good catch, thanks. = Fixed.

=3D=3D=3D
=
In 6.7
=A0The PCErr message may be sent = by a PCC or a PCE in response to a
=A0request or in an unsolicited = manner.

Reworded: "The PCErr = message is either sent by a PCC or a PCE in response to a request or in = an unsolicited manner"

=3D=3D=3D
In the = objects you define reserved fields as MUST be set to zero.
I think you need:
- SHOULD = be set to zero
- MUST be ignored on = receipt

Now specified (for all = objects):

Reserved: This field MUST = be set to zero on transmission and MUST be ignored on = receipt.

In 7.1 it is unclear, but I = think the P flag would only have=A0 = meaning on a request, and the I flag on a response.
So actually, you only need one flag (or you have = some clarification=A0 text = to write)

We could use a single bit, = which would mean that the flag, say P is cleared for an optional object = in a PCReq and set for=A0an optional object that has been taken into = account in a PCRep: so to interpret the bit we need to also remember the = PCEP message type. Not a problem though ... Note that I was tempted to = generalize the concept to the processing of an object in general (that = could be in a PCReq or PCRep message) but without strong use case, it is = not worth adding complexity. Let me know which option you prefer, I've = got no preference (1 or 2 bits), well a slight preference for keeping = two bits (easier to interpret).

=3D=3D=3D
You will also = need to explain what it means when a PCRep has the I=A0 flag set for an object that = had the P flag set on the PCReq. As=A0= currently phrased this is an encoding error that would require = a=A0 PCErr, but that would = clearly be a waste of time.

Yes, text has been added = "The I flag has no meaning in a PCRep message when the P flag had been = set in the=A0corresponding PCRep message."

=3D=3D=3D
In fact, why would you ever send a PCErr in response = to a PCRep?

There are such cases. For = example:

=A06=A0= =A0 =A0 =A0 =A0 Mandatory Object missing
=A0 =A0 =A0 =A0 =A0 = =A0 =A0=A0 Error-value=3D1: RP object missing

=3D=3D=3D
At the end of 7.1 you need to explain padding = rules

Object are all aligned to = 32-bits.

Why does the Open need a = protocol version number? This is in the=A0 message header so we all know = what protocol is being used/supported.
in fact, = I think you need to re-write the protocol version support=A0 processing and = negotiation.

The idea is to not set up a = PCEP session if the supported PCEP version do not = match.

=3D=3D=3D
=
Dead timer.
Should it be = "SHOULD be set to zero, and MUST be ignored if the=A0 keepalive timer is = zero"

Don't you prefer to set it = to 0 if the Keepalive is itself set to 0 (less prone to = misinterpretation)?

=3D=3D=3D
The fields in = the Open object are a mess!
Can you bring = the flags up with the version to improve the byte- alignment?
=3D=3D=3D

Yes ! It was fixed in a = revision post to rev-03.

Note that in the message header the version is four = bits but in the=A0 Open = object it is three bits.
Fixed, = thanks.

In the = Open object
=A0SID (PCEP session-ID - 8 = bits): specifies a 2 octet unsigned PCEP
=A0session number that identifies = the current session.
Are you using bit = compression?

Nope.

=3D=3D=3D
Open object TLVs may be out of the scope of this doc = (7.2) but the=A0 format = needs to be defined here.
mmm ... It is no different = than future objects that may be carried in PCEP messages = ?

=A0When present in an Open = message, the OPEN object specifies the
=A0proposed PCEP session = characteristics.=A0 Upon = receiving unacceptable
=A0PCEP session characteristics = during the PCEP session initialization
=A0phase, the receiving PCEP peer = (PCE) MAY include a PCEP object=A0 = within
=A0the PCErr message so as to = propose alternative session=A0 = characteristic
=A0values.
Isn't there an issue with duelling Open = messages?
You seem to have an independent = Open in each direction, each of=A0 = which is responded with a PCErr, leading to a new Open in = each=A0 = direction.
Is it necessary to have this = symmetry? After all, the TCP=A0 = connection is always initiated by the PCC, so can't we also = have=A0 the Open initiated = by the PCC and responded with a PCErr or an Open=A0 by the PCE. Keepalives then = follow.

We could but introducing = such=A0asymmetry also adds=A0complexity to the FSM.=A0


=3D=3D=3D
7.3
Why is the P flag set in an RP object carried in a = PCNtf or PCErr?=A0 No = computation action is required.

Good catch, it now reads: = "The P flag of the RP object MUST be set in PCReq and PCReq messages and = MUST be cleared in PCNtf and PCErr messages."

=3D=3D=3D
Why is there a reserved piece of the RP object? Is = there a=A0 difference = between the unused flags bits and the reserved field?
=3D=3D=3D

Clarified.

7.3.1
=A0Note = that it is not required for a PCE to
=A0support the priority field: in = this case, it is RECOMMENDED to set
=A0the priority field to 0 by the = PCC in the RP object.
Why would it matter what = value is set if it is not supported by the=A0 = PCE?

Just a recommendation ... = if the PCC learns via IGP discovery that the PCE does not support the = priority field, it
is desirable to have it set to 0. But the = information may not be available of course, thus the recommendation. = Another way=A0to discover whether this is supported is for the PCC to = set it to <>0, and have the PCE reset the field. Note that=A0these = are recommendations, not required.

Wouldn't it possibly be helpful if the PCE forwards = the request to=A0 another = PCE?

I think that this should be = exclusively triggered by the PCC (after discovering the non support of = prioritization)
and is application specific but having the PCE = redirecting the requesting to another PCE itself may lead = to
undesirable consequences.

=3D=3D=3D
7.3.1
As described = here there is no difference between the R and the F=A0 bit. Both are used to = recompute a path allowing re-use of resources=A0 already used by the path. = Presumably in the case of the F bit, some=A0 information about the failure = is also supplied through an=A0 = exclusion, but this is not mentioned. The behavior at the PCE = for=A0 these two bits would = seem to be identical so unless you can give=A0 better separation of the = meanings, I suggest you merge the bits.

You're right that the text = is not explicit. In the case of the F bit, the information can be used = by the PCE to exclude some links should the updated IGP LSA be received = after the path computation request. As discussed on the list, let's move = that bit to the XRO draft. Section removed.

=3D=3D=3D
7.3.1
The = description of the O-bit is very confusing.
I think = the problem lies with the definition of "explicit path"
Loose means that it is acceptable to include loose = hops
You have no term to distinguish = the use of abstract nodes that=A0 = contain more than one network node
Explicit = just means an ERO
Strict means that only strict = hops are allowed

There were some = typos/issues in the text indeed ... New Text: "O (strict/lOose - 1 bit): = when set, in a PCReq message, this indicates that a loose path is = acceptable. Otherwise, when cleared, this indicates to the PCE that a = path exclusively made of strict hops is required. In a PCRep message, = when the O bit is set this indicates that the returned path is a loose = path, otherwise (the O bit is cleared), the returned path is made of = strict hops."

7.3.1
You need to think about how the Request ID is = handled when the PCC=A0 = restarts. Are you requiring the PCC to have persistent memory = to=A0 avoid re-use of a = Request ID? (That is how the text reads!)

Yes, an implementation = issue where the PCC may either tear down the session upon restart or = checkpoints.

7.3.2
The description of R-bit handling looks = broken.
The previous setting of the = O-bit is not important because the PCC=A0 is able to use RRO to collect = information from the network. Thus,=A0= the question is actually about how detailed the RRO is. The = point=A0 you are making = remains (that it is hard to compute a proper make- before-break = resource-sharing path if you don't know the previous=A0 path. [Those of you looking = at the inter-area/AS PCE problem space=A0 will recognise this as = impossible to solve unless stateful PCEs are=A0 used or the PCE is provided = with a way to issue an enquiry to the=A0 = ABR/ASBR.]

I don't think that the = definition is broken.=A0
Few cases here:=A0
1) = Provide the RRO with strict hops and set the R flag to avoid double bw = booking
2) If the PCC does not know the RRO with all strict = hops, provides what it knows + set the R flag=A0
In all cases = the PCC MUST provide the RRO which may contain loose hops (in which = case=A0
double bandwidth booking cannot be = guaranteed).

7.3.2
=A0If = the PCC receives a PCRep message that contains a RP object
=A0referring to an unknown = Request-ID-Number, the PCC MUST send a PCErr
=A0messag= e with Error-Type=3D"Unknown request reference".
This feels like at most a "MAY". Why is there a = requirement to=A0 = respond?

Because actions are very = likely required on the PCE, thus we mandate the PCC to = respond
so that the PCE detects the issue. Makes sense = ?

=3D=3D=3D
=
7.4
I don't think = the description on the inclusion of "failed"=A0 constraints in the PCRep = message is in agreement with the BNF in=A0 section 6.5. The BNF appears = to imply that an ERO must be present=A0 in order to include, for = example, a Metric object.
[By the way: = I continue to believe that this business of reporting=A0 the failed constraints is = extremely dubious. Where there are two=A0 absolute constraints to be = satisfied, it is often impossible to=A0 state which of them led to = the failure to compute a path.]

In that case, the PCE may = either to decide to indicate none of them or both. But the case where = only one constraint is not satisfied is by itself a clear motivation for = this feature (pretty common situation). Not sure to see the issue with = the BNF since the path-list is optional ?

=3D=3D=3D
7.4
How does a = PCC tell the difference between a PCRep that contains=A0 the "failed" constraints = echoed from the PCReq, and modified=A0= constraints that could have been = satisfied?

Just by comparing the = original values sent by the PCC to the values returned by the PCE: if = they differ, suggestions are provided by the PCE.

=46rom the text it=A0 appears that you intend the = C-bit to make this distinction, but the=A0 description of the C-bt does = not say this.

The C bit is set when the = PCE indicates the set of non satisfied constraints.

=3D=3D=3D
7.4
Wouldn't it = be a good idea to put a reason code in the No-Path = object?

Yes this was added to a = post rev-03 revision (NO-PATH-VECTOR TLV).

=3D=3D=3D
7.5
Can you add a = note to say where the end points of the LSP *are*=A0 encoded.
That is, although this PCReq is computing a segment = only, it is=A0 important = (at least for policy) to know the LSP end points as = well.

As pointed out in the text "The END-POINTS = object is used in a PCReq message to specify the source IP address and = the destination IP address of the path for which a path computation is = requested. Note that the source and destination addresses specified in = the END-POINTS object may or may not correspond to the source and = destination IP address of the TE LSP but rather to a path segment." In = the second case, the LSP end-points are not provided. If an application = requires this information (as you said for policy, .. ) it should be = defined in another ID.=A0

=3D=3D=3D
7.6
First paragraph is hard to parse, but I think it = says that the=A0 Bandwidth = object must always be present in a PCReq! But the second=A0 paragraph explains what it = means if it is absent.

OK so I reworded = it:

"
The BANDWIDTH = object is used to specify the requested bandwidth for a TE = LSP.
If the requested bandwidth is equal to 0, the BANDWIDTH = object is optional. Conversely, if the requested bandwidth is non equal = to 0, the PCReq message MUST contain a BANDWIDTH object.
In = the case of the reoptimization of a TE LSP, the bandwidth of the = existing TE LSP MUST also be included in addition to the requested = bandwidth if and only if the two values differ. Consequently, two = Object-Type are defined that refer to the requested bandwidth and the = bandwidth of the TE LSP for which a reoptimization is being = performed.=A0
"

=3D=3D=3D
7.6
Can you give a references to the IEEE FP = definition.

Sounds pretty well-known, = no ?

=3D=3D=3D
=
7.7
Please add a = third metric: hop count

Good idea, = added.

I think you = need to allow the Metric object to be present multiple=A0 times, and you have this in = the text, but it is missing in the BNF.

Good catch. I also fixed = the BNF for the PCReq message (same purpose)

On the other hand, you need to = describe how to interpret multiple=A0= Metric objects for the same Type = setting

Text added "There MUST be = at most one instance of the METRIC object for each metric type. In two = or more instances of a METRIC object are present for a metric type, only = the first=A0instance MUST be considered and other instances MUST be = ignored."

7.7
Why do = you need the B-bit? The metric value is set to zero with the=A0 same = semantic.

This is because the = metric-value is used to report the metric of a TE LSP for a = reoptimization request. Thus, we need the B-bit to indicate whether the = metric-value corresponds to the metric of the TE LSP to be reoptimized = or to a bound. That said, I'm realizing that this was not written down = and the text had to be reworded. New text:

"A METRIC object used to = indicate the metric to optimize during the path computation MUST have = the B-Flag cleared and the T-Flag set to the appropriate value. When the = path computation relates to the reoptimization of an exiting TE LSP (in = which case=A0R-Flag of the RP object is set) an implementation MAY = decide to set the metric-value field to the cost of the TE LSP to be = reoptimized with regards to a specific metric type.)"

I also fixed a few other = issues in the paragraph.

=3D=3D=3D
7.7
The text appears to say that only one Metric object = may be present=A0 with the = B-flag cleared. Why?

I think that we should = relax that constraint indeed. *That said*, how should the PCE interpret = the request to optimize a path based on Metric-1 and Metric-2 ? Without = further indication (hierarchical constraint, weighting function, ...) = this has no meaning. Proposal: we relaxed the constraint but the text = required to fully cover those aspects will be covered in another ID, as = discussed months ago on the list. OK ?

=3D=3D=3D
7.8 and 7.9 (and everywhere)
A real nit, but when you write "ERO object" or "RRO = object" do you=A0 mean EROO = and RROO? :-)

;-) Fixed ... sorry for the = tautology=A0

7.8
You say = that the ERO is bounded by 3209, 3473 and 3477 which is=A0 fine, but how will an MPLS-TE = LSR handle an ERO with an explicit=A0= label in it? You also allow future extensions to = subobjects.
I think this means that the = PCReq must include a way for the=A0 = requester to limit the subobjects that will be = returned.

Do you think that we should = limit these objects ? Indeed some ERO sub-objects may be defined in the = future that might be of interest ?

=3D=3D=3D
7.9
RRO is also used for reporting the path of a failed = LSP?

See comment above, this = will be covered in the XRO ID.

=3D=3D=3D
What are optional TLVs = for?
Perhaps to carry the additional = attributes as defined in RFC4420?

Yes I added a = reference.

7.10
Why do you need an LSPA object without resource = affinities? This is=A0 = pointless. It only exists in 3209 for backwards = compatibility.

Absolutely ! Text modified = to define one object (w/ affinity).

=3D=3D=3D
7.10
What is the = meaning of holding priority with respect to path=A0 = computation?

This can be taken into = account by the PCE when computing the path(s).

=3D=3D=3D
7.10
Why are the = Flags and Reserved fields different sizes in the two=A0 = objects?

Only one object = now.

=3D=3D=3D
=
7.10
When = computing a path to satisfy a request with the L-bit set, how=A0 will the PCE know which links = are protected with FRR?

This can be obtained from = draft-ietf-isis-link-attr for example, or locally available in a = database.

7.11
Good to see the IRO
Why is = there no XRO?
Exclusion is a standard part of = the MPLS-TE MIB (RFC3812 see=A0 = mplsTunnelHopInclude). If the exclusion can be configured on = the=A0 headend LSR, I think = we need to be able to compute the path.
Besides, = this is a requirement in RC4657.

Covered = in=A0draft-oki-pce-pcep-xro-00.txt

=3D=3D=3D
Why is it necessary to list the = subobjects for the IRO but not for=A0= the ERO or the RRO?

We listed them since the = IRO is a new object by contrast with the ERO and RRO for which we re-use = existing object formats (we just define a PCEP = codepoint).

7.12.1
I urge caution in the use of "simultaneously" in = this section.

Agree since this can never = be true ;-) Reworded: "Independent versus dependent path computation = requests: path computation requests are said to be independent if they = are not related to each other. Conversely a set of dependent path = computation requests is such that their computations cannot be performed = independently of each other (a typical example of dependent requests is = the computation of a set of diverse paths)."

=3D=3D=3D
7.12.1
At the end of = this section, you suddenly introduce the term=A0 "bundle". I think this is = supposed to refer to the presence of=A0 multiple requests in a single = PCReq message. Note that the SVEC can=A0 apply across messages. It = would, perhaps be better to explain that=A0 requests in the same message = are not necessarily associated by an=A0 SVEC, and that requests in = separate messages may be associated by=A0 an = SVEC.

This is detailed in = 7.12.3.

7.12
You are missing text to describe the use of the SVEC = on a PCRep=A0 (allowed = according to 6.5).
It feels like you would = only use SVEC in the case of an RP, but the=A0 BNF has them as = independent.
Please = clarify

BNF has been fixed, there's = no reason to have the SVEC in PCRep, thanks.

=3D=3D=3D
7.12.2
You have MUST = NOT for each of your diversity characteristics.
I think you also need "desired" so that you can get = "as much=A0 diversity as = possible".
How will you handle the overlap = between (for example) node and link=A0= diversity? Just needs some text to = explain.

Yes, this is a topic that = we discussed a few times, we could define a "desired" bit along with = various constraint relaxation strategy but this would lead to adding = much complexity. So we decided to keep the simple rule here and add more = functionality in a separate ID. The overlap case is quite simple here: = in this example, link two LSP are link *and* node diverse they cannot = have any link/node in common. Node diverse =3D> link diverse, not the = opposite of course.

=3D=3D=3D
Is it possible to end up with a = nasty mesh of synchronized=A0 = requests? Are there any rules to resolve = this?

Good implementation ;-) = (thus the timer-based approach suggested), but this is = implementation-specific.

=3D=3D=3D
10
The state machine is quite hard to parse for = reviewing purposes. It=A0 = would be good to at least name the arrows on the figure. My=A0 personal preference is to = draw the FSM as a grid because this shows=A0 up missing state/event = combinations far more easily.

Is the OpenRetry counter just a = substate of OpenWait?
The description of OpenRetry is = at odds with the error used (1:5).=A0= The error says a second unacceptable Open has been received, = but=A0 the text says that = OpenRetry is incremented if the Open is anything=A0 except malformed. Can I = suggest that the use of a separate state=A0 and not a substate would help = you resolve this type of issue.

LocalOK also looks like a = substate. Ditto RemoteOK. Please don't=A0 use substates, they are = evil!

YEs, they are not sub-state = but variables.

The flip flop between OpenWait and=A0 KeepWait caused by these two = variables and the negotiation of=A0 = parameters is ghastly.

I think that what the state = machine shows us is that we do not need=A0 independent Open messages in = each direction. Anyway, if we *do*=A0= need them, we need correct states to manage = them.

We'll need a piece of paper = ... In prague ..=A0

=3D=3D=3D
10
=A0If a = malformed PCEP message is received or the TCP connection = fails,
=A0the systems sends a PCEP CLOSE = message, the system releases the PCEP
=A0resources for that PCEP peer, = closes the TCP connection and moves to
=A0the Idle State.
This seems to be in contradiction with text in the = main body of the=A0 draft = and with the existence of error code 6.

Yes we decided to close the = TCP connection upon receiving a malformed packet.
Not sure = which section you're referring to here ?

=3D=3D=3D
App A
Is this = appendix just present to help you track the requirements=A0 you still need to satisfy, or = do you intend to leave some=A0 = requirements unanswered?

This was requested a few = IETF meetings ago to keep track of the requirements to be satisfied. All = unanswered MUST requirements will be listed there. Text = updated.


BTW, I don't = think this is a full list. Route exclusions is not=A0 = listed.

Reference = added.


What are you doing to ensure = that the list is complete?
=3D=3D=3D
=
I think Kenji's email address may have = changed
Same for Jean-Louis
=

 

We mean that those inter-ASBR TE = LSPs which are permitted by policy/scaling configuration to be propagated = outside can be flooded by BGP.

 This may be a sub-set of TE = LSPs specifically provisioned for carrying inter-AS TE traffic and may be a = full mesh. If all the ASes support such a mechanism then the itner-AS TE path = can be calc07-1-22 =20 The ability to compute an optimal path for setting up Traffic=20 engineering Label Switched Paths spanning multiple autonomous=20 systems managed by different operators has been a key requirement in=20 MPLS and GMPLS networks. This document specifies a method of=20 computing inter-AS paths consisting of a list of ASes to be=20 traversed and a list of TE-Tunnels to be traversed in each AS. The=20 method described here uses BGP speakers in the PCEs of each AS to=20 distribute the inter-AS connectivity information and the TE-Tunnels=20 in each AS to its neighbors to facilitate the construction of an=20 inter-AS topology graph which can be used for computing inter-AS paths. =20 A URL for this Internet-Draft is: =20 http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-interas-te -path-01.txt =20 =20 =20 DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- =20 The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. =20 ------------------------------------------------------------------------ ----------------------------------------------- =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 =20 ------_=_NextPart_001_01C748E7.D3FF557B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

We mean that those inter-ASBR TE = LSPs which are permitted by policy/scaling configuration to be propagated = outside can be flooded by BGP.

 This may be a sub-set of TE = LSPs specifically provisioned for carrying inter-AS TE traffic and may be a = full mesh. If all the ASes support such a mechanism then the itner-AS TE path = can be calculated using the inter-AS graph of such LSPs and inter-AS = links.

 

But, this may not be always = possible though because of policy and scaling constraints.In such situations we = can only find the possible AS paths after eliminating the paths through inter-AS = links which are not feasible and then use methods like BRPC to complete the = path setup.

 

Regards

Vijay

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Saturday, February 03, 2007 4:05 AM
To: Vijayanand C - TLS, = Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: = I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =

 

Hi,

 

Let me first try to make sure of something here. When you write = "The PCE shall learn the TE 

   = attributes of the inter-AS TE links and the TE tunnels that = exist 

   = between the ASBRs in the domain."

 

Are you suggesting to flood via BGP the intra-domain TE LSPs ? = In other words, suppose the following scenario:

 

AS1---AS2---AS3

ulated using the inter-AS graph of such LSPs and inter-AS = links.

 

But, this may not be always = possible though because of policy and scaling constraints.In such situations we = can only find the possible AS paths after eliminating the paths through inter-AS = links which are not feasible and then use methods like BRPC to complete the = path setup.

 

Regards

Vijay

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Saturday, February 03, 2007 4:05 AM
To: Vijayanand C - TLS, = Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: = I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =

 

Hi,

 

Let me first try to make sure of something here. When you write = "The PCE shall learn the TE 

   = attributes of the inter-AS TE links and the TE tunnels that = exist 

   = between the ASBRs in the domain."

 

Are you suggesting to flood via BGP the intra-domain TE LSPs ? = In other words, suppose the following scenario:

 

AS1---AS2---AS3

You have a mesh of intra-domain TE LSPs between all ASBRs within = AS2.

 

Are you suggesting to flood in AS1 these TE LSPs (and this for = all other ASes that might be between AS1 and the destination domain) = ?

 

Thanks.

 

JP.

 

On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. = wrote:



Are = you suggesting that  BGP should propagate all possible next-hops/As = paths and regular path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ?

 

The inter-AS TE link information can be made aware only to the ASes on = either side of the inter-AS link by the IGP. It may not be possible to propagate it = beyond that ( or can it ?).

So some of the possible AS paths found by BGP( if we propagate all = next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of = violation of some TE constraint.

 

In our proposal we can pick the paths which are really feasible, since we have = the inter-AS graph, and then invoke methods like = BRPC

 

Regards

You have a mesh of intra-domain TE LSPs between all ASBRs within = AS2.

 

Are you suggesting to flood in AS1 these TE LSPs (and this for = all other ASes that might be between AS1 and the destination domain) = ?

 

Thanks.

 

JP.

 

On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. = wrote:



Are = you suggesting that  BGP should propagate all possible next-hops/As = paths and regular path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ?

 

The inter-AS TE link information can be made aware only to the ASes on = either side of the inter-AS link by the IGP. It may not be possible to propagate it = beyond that ( or can it ?).

So some of the possible AS paths found by BGP( if we propagate all = next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of = violation of some TE constraint.

 

In our proposal we can pick the paths which are really feasible, since we have = the inter-AS graph, and then invoke methods like = BRPC

 

Regards

Vijay

 

 

 

 

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com] =
Sent: Thursday, February 01, 2007 1:19 AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

 

Hi,

 

On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. = wrote:

 

 

Hello all,

We have submitted the following I-D, please send in = your

Vijay

 

 

 

 

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com] =
Sent: Thursday, February 01, 2007 1:19 AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

 

Hi,

 

On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. = wrote:

 

 

Hello all,

We have submitted the following I-D, please send in = your

comments/suggestions

 

* speaking as a technical contributor = *

 

   In [BRPC], a method to optimally compute a = inter-domain TE 

   path for MPLS and GMPS LSPs using the PCE architecture detailed in 

   [PCE_ARCH] is described. However the method = described requires the 

   list of Autonomous systems or domains to be determined apriori. 

   Determining the list of ASes/domains to be = traversed to reach a 

   destination, satisfying the TE constraints is non-trivial. It 

   requires knowledge of the inter-AS = connectivity and the TE 

   characteristics of the inter-AS links along = with the knowledge of 

   the available paths within each of the = ASes/domains. BGP contains 

   information on the list of ASes to be = traversed to reach a 

comments/suggestions

 

* speaking as a technical contributor = *

 

   In [BRPC], a method to optimally compute a = inter-domain TE 

   path for MPLS and GMPS LSPs using the PCE architecture detailed in 

   [PCE_ARCH] is described. However the method = described requires the 

   list of Autonomous systems or domains to be determined apriori. 

   Determining the list of ASes/domains to be = traversed to reach a 

   destination, satisfying the TE constraints is non-trivial. It 

   requires knowledge of the inter-AS = connectivity and the TE 

   characteristics of the inter-AS links along = with the knowledge of 

   the available paths within each of the = ASes/domains. BGP contains 

   information on the list of ASes to be = traversed to reach a 

   destination, however BGP route selection and = decision process 

   truncates most of the feasible paths, and it = also does not carry 

   the TE characteristics of the inter-AS links = and path availability 

   within a domain. =  

 

What does prevent you from relying on BGP to provide you = all possible paths toward 

a specific destination skipping the regular path selection = process for specific routes (see

proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE

link could easily be obtained via the IGP with minor = additions.

 

This is in my opinion a fundamental question that must = first be addressed before 

moving forward.

 

Thanks.

   destination, however BGP route selection and = decision process 

   truncates most of the feasible paths, and it = also does not carry 

   the TE characteristics of the inter-AS links = and path availability 

   within a domain. =  

 

What does prevent you from relying on BGP to provide you = all possible paths toward 

a specific destination skipping the regular path selection = process for specific routes (see

proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE

link could easily be obtained via the IGP with minor = additions.

 

This is in my opinion a fundamental question that must = first be addressed before 

moving forward.

 

Thanks.

 

JP.

 

 

Regards

Vijay

 

-----Original Message-----

Sent: Tuesday, January 23, 2007 2:20 = AM

Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt 

 

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

 

JP.

 

 

Regards

Vijay

 

-----Original Message-----

Sent: Tuesday, January 23, 2007 2:20 = AM

Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt 

 

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

directories.

 

 

          =   Title           &n= bsp;      : A BGP based method to compute inter-AS = Traffic

engineering Label Switched Paths with = PCE

          =   Author(s)          : C. = Vijayanand, S. Bhattacharya

          =   Filename           = :

draft-vijay-somen-pce-bgp-interas-te-path-01.txt

          =   Pages           &n= bsp;   : 26

          =   Date           &nb= sp;     : 2007-1-22

     &nbs= p;     

The ability to compute an optimal path for setting up Traffic 

   engineering Label Switched Paths spanning = multiple autonomous 

oman">directories.

 

 

          =   Title           &n= bsp;      : A BGP based method to compute inter-AS = Traffic

engineering Label Switched Paths with = PCE

          =   Author(s)          : C. = Vijayanand, S. Bhattacharya

          =   Filename           = :

draft-vijay-somen-pce-bgp-interas-te-path-01.txt

          =   Pages           &n= bsp;   : 26

          =   Date           &nb= sp;     : 2007-1-22

     &nbs= p;     

The ability to compute an optimal path for setting up Traffic 

   engineering Label Switched Paths spanning = multiple autonomous 

   systems managed by different operators has = been a key requirement in 

   MPLS and GMPLS networks. This document = specifies a method of 

   computing inter-AS paths consisting of a list = of ASes to be 

   traversed and a list of TE-Tunnels to be = traversed in each AS. The 

   method described here uses BGP speakers in the = PCEs of each AS to 

   distribute the inter-AS connectivity = information and the TE-Tunnels 

   in each AS to its neighbors to facilitate the construction of an 

   inter-AS topology graph which can be used for computing inter-AS

    paths.

 

A URL for this Internet-Draft is:

-path-01.txt

   systems managed by different operators has = been a key requirement in 

   MPLS and GMPLS networks. This document = specifies a method of 

   computing inter-AS paths consisting of a list = of ASes to be 

   traversed and a list of TE-Tunnels to be = traversed in each AS. The 

   method described here uses BGP speakers in the = PCEs of each AS to 

   distribute the inter-AS connectivity = information and the TE-Tunnels 

   in each AS to its neighbors to facilitate the construction of an 

   inter-AS topology graph which can be used for computing inter-AS

    paths.

 

A URL for this Internet-Draft is:

-path-01.txt

 

 

 

DISCLAIMER:

------------------------------------------------------------= -----------------------------------------------------------=

 

The contents of this e-mail and any attachment(s) are = confidential and intended for the named recipient(s) only.

It shall not attach any liability on the originator or HCL = or its affiliates. Any views or opinions presented = in 

this email are solely those of the author and may not = necessarily reflect the opinions of HCL or its affiliates.

Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication = of 

this message without the prior written consent of the = author of this e-mail is strictly prohibited. If you = have 

received this email in error please delete it and notify = the sender immediately. Before opening any mail = and 

attachments please check them for viruses and = defect.

&nbsDblack face=3D"Times New Roman"> 

 

 

DISCLAIMER:

------------------------------------------------------------= -----------------------------------------------------------=

 

The contents of this e-mail and any attachment(s) are = confidential and intended for the named recipient(s) only.

It shall not attach any liability on the originator or HCL = or its affiliates. Any views or opinions presented = in 

this email are solely those of the author and may not = necessarily reflect the opinions of HCL or its affiliates.

Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication = of 

this message without the prior written consent of the = author of this e-mail is strictly prohibited. If you = have 

received this email in error please delete it and notify = the sender immediately. Before opening any mail = and 

attachments please check them for viruses and = defect.

 

------------------------------------------------------------= -----------------------------------------------------------=

 

_______________________________________________

Pce mailing list

 



 

------_=_NextPart_001_01C748E7.D3FF557B-- --===============1581161213== 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 --===============1581161213==-- From pce-bounces@lists.ietf.org Mon Feb 05 05:48:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1No-00055I-Rj; Mon, 05 Feb 2007 05:47:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDx25-0005yq-Ct for pce@ietf.org; Mon, 05 Feb 2007 01:08:53 -0500 Received: from gws03.hcl.in ([203.105.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDx1n-00086T-TR for pce@ietf.org; Mon, 05 Feb 2007 01:08:53 -0500 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 6C96B37C090; Mon, 5 Feb 2007 11:38:33 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTPid 1D30D37C08B; Mon, 5 Feb 2007 11:38:33 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 11:38:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-patp;

------------------------------------------------------------= -----------------------------------------------------------=

 

_______________________________________________

Pce mailing list

 



 

------_=_NextPart_001_01C748E7.D3FF557B-- --===============1581161213== 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 --===============1581161213==-- From pce-bounces@lists.ietf.org Mon Feb 05 05:48:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1No-00055I-Rj; Mon, 05 Feb 2007 05:47:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDx25-0005yq-Ct for pce@ietf.org; Mon, 05 Feb 2007 01:08:53 -0500 Received: from gws03.hcl.in ([203.105.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDx1n-00086T-TR for pce@ietf.org; Mon, 05 Feb 2007 01:08:53 -0500 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 6C96B37C090; Mon, 5 Feb 2007 11:38:33 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTPid 1D30D37C08B; Mon, 5 Feb 2007 11:38:33 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 11:38:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Date: Mon, 5 Feb 2007 11:37:47 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Thread-Index: AcdHGmIK+WmdESo5RRqVCKhKwCokxgB0OQNA From: "Vijayanand C - TLS, Chennai." To: "JP Vasseur" X-OriginalArrivalTime: 05 Feb 2007 06:08:32.0683 (UTC) FILETIME=[1054E7B0:01C748EC] X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-25.9600 TC:1F TRN:96 TV:3.6.1039(14974.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: bbce2a5190d5ae338d8dbf3fc72f2c89 X-Mailman-Approved-At: Mon, 05 Feb 2007 05:47:33 -0500 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="===============0186145142==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0186145142== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C748EB.F8629B46" This is a multi-part message in MIME format. ------_=_NextPart_001_01C748EB.F8629B46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 We mean that those inter-ASBR TE LSPs which are permitted by policy/scaling configuration to be propagated outside can be propogated to PCEs in neighbouring ASes by BGP.This information is not flooded to all BGP speakers of neighbouring ASes but only to speakers which are on PCEs or which propogate them to PCEs ( which support the new AFI/SAFI). =20 These LSPs may be a sub-set of TE LSPs specifically provisioned for carrying inter-AS TE traffic and may be a full mesh. If all the ASes support such a mechanism then the itner-AS TE path can be calculated using the inter-AS graph of such LSPs and inter-AS links. =20 But, this kind of itner-ASBR LSP propogation may not be always possible because of policy and scaling constraints. In such situations we have only the ASes and their inter-AS links in the form of an inter-AS graph and we can only find the 'possible' AS paths after eliminating the paths through inter-AS links which are not feasible and then use methods like BRPC to complete the path setup. =20 Regards Vijay =20 =20 -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Saturday, February 03, 2007 4:05 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 Hi, =20 Let me first try to make sure of something here. When you write "The PCE shall learn the TE=20 attributes of the inter-AS TE links and the TE tunnels that exist=20 between the ASBRs in the domain." =20 Are you suggesting to flood via BGP the intra-domain TE LSPs ? In other words, suppose the following scenario: =20 AS1---AS2---AS3 You have a mesh of intra-domain TE LSPs between all ASBRs within AS2. =20 Are you suggesting to flood in AS1 these TE LSPs (and this for all other ASes that might be between AS1 and the destination domain) ? =20 Thanks. =20 JP. =20 On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. wrote: Are you suggesting that BGP should propagate all possible next-hops/As paths and regular path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ? =20 The inter-AS TE link inh-01.txt Date: Mon, 5 Feb 2007 11:37:47 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Thread-Index: AcdHGmIK+WmdESo5RRqVCKhKwCokxgB0OQNA From: "Vijayanand C - TLS, Chennai." To: "JP Vasseur" X-OriginalArrivalTime: 05 Feb 2007 06:08:32.0683 (UTC) FILETIME=[1054E7B0:01C748EC] X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-25.9600 TC:1F TRN:96 TV:3.6.1039(14974.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: bbce2a5190d5ae338d8dbf3fc72f2c89 X-Mailman-Approved-At: Mon, 05 Feb 2007 05:47:33 -0500 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="===============0186145142==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0186145142== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C748EB.F8629B46" This is a multi-part message in MIME format. ------_=_NextPart_001_01C748EB.F8629B46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 We mean that those inter-ASBR TE LSPs which are permitted by policy/scaling configuration to be propagated outside can be propogated to PCEs in neighbouring ASes by BGP.This information is not flooded to all BGP speakers of neighbouring ASes but only to speakers which are on PCEs or which propogate them to PCEs ( which support the new AFI/SAFI). =20 These LSPs may be a sub-set of TE LSPs specifically provisioned for carrying inter-AS TE traffic and may be a full mesh. If all the ASes support such a mechanism then the itner-AS TE path can be calculated using the inter-AS graph of such LSPs and inter-AS links. =20 But, this kind of itner-ASBR LSP propogation may not be always possible because of policy and scaling constraints. In such situations we have only the ASes and their inter-AS links in the form of an inter-AS graph and we can only find the 'possible' AS paths after eliminating the paths through inter-AS links which are not feasible and then use methods like BRPC to complete the path setup. =20 Regards Vijay =20 =20 -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Saturday, February 03, 2007 4:05 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 Hi, =20 Let me first try to make sure of something here. When you write "The PCE shall learn the TE=20 attributes of the inter-AS TE links and the TE tunnels that exist=20 between the ASBRs in the domain." =20 Are you suggesting to flood via BGP the intra-domain TE LSPs ? In other words, suppose the following scenario: =20 AS1---AS2---AS3 You have a mesh of intra-domain TE LSPs between all ASBRs within AS2. =20 Are you suggesting to flood in AS1 these TE LSPs (and this for all other ASes that might be between AS1 and the destination domain) ? =20 Thanks. =20 JP. =20 On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. wrote: Are you suggesting that BGP should propagate all possible next-hops/As paths and regular path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ? =20 The inter-AS TE link information can be made aware only to the ASes on either side of the inter-AS link by the IGP. It may not be possible to propagate it beyond that ( or can it ?). So some of the possible AS paths found by BGP( if we propagate all next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of violation of some TE constraint. =20 In our proposal we can pick the paths which are really feasible, since we have the inter-AS graph, and then invoke methods like BRPC =20 Regards Vijay =20 =20 =20 =20 -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Thursday, February 01, 2007 1:19 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =20 Hi, =20 On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: =20 =20 Hello all, We have submitted the following I-D, please send in your comments/suggestions =20 * speaking as a technical contributor * =20 In [BRPC], a method to optimally compute a inter-domain TE=20 path for MPLS and GMPS LSPs using the PCE architecture detailed in=20 [PCE_ARCH] is described. However the method described requires the=20 list of Autonomous systems or domains to be determined apriori.=20 Determining the list of ASes/domains to be traversed to reach a=20 destination, satisfying the TE constraints is non-trivial. It=20 requires knowledge of the inter-AS connectivity and the TE=20 characteristics of the inter-AS links along with the knowledge of=20 the available paths within each of the ASes/domains. BGP contains=20 information on the list of ASes to be traversed to reach a=20 destination, however BGP route selection and decision process=20 truncates most of the feasible paths, and it also does not carry=20 the TE characteristics of the inter-AS links and path availability=20 within a domain. =20 =20 What does prevent you from relying on BGP to provide you all possible paths toward=20 a specific destination skipping the regular path selection process for specific routes (see proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE link could easily be obtained via the IGP with minor additions. =20 This is in my opinion a fundamental question that must first be addressed before=20 moving forward. =20 Thanks. =20 JP. =20 =20 Regards Vijay =20 -----Original Message----- From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, January 23, 2007 2:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =20 =20 Title : A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-bgp-interas-te-path-01.txt Pages : 26 Date : 2007-1-22 =20 The ability to compute an optimal path for setting up Traffic=20 engineering Label Switched Paths spanning multiple autonomous=20 systems managed by different operators has been a key requirement in=20 MPLS and GMPLS networks. This document specifies a method of=20 computing inter-AS paths consisting of a list of ASes to be=20 traversed and a list of TE-Tunnels to be traversed in each AS. The=20 method described here uses BGP speakers in the PCEs of each AS to=20 distribute the inter-AS connectivity information and the TE-Tunnels=20 in each AS to its neighbors to facilitate the construction of an=20 inter-AS topology graph which can be used for computing inter-AS paths. =20 A URL for this Internet-Draft is: =20 http://www.ietf.orgformation can be made aware only to the ASes on either side of the inter-AS link by the IGP. It may not be possible to propagate it beyond that ( or can it ?). So some of the possible AS paths found by BGP( if we propagate all next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of violation of some TE constraint. =20 In our proposal we can pick the paths which are really feasible, since we have the inter-AS graph, and then invoke methods like BRPC =20 Regards Vijay =20 =20 =20 =20 -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Thursday, February 01, 2007 1:19 AM To: Vijayanand C - TLS, Chennai. Cc: pce@ietf.org Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =20 Hi, =20 On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: =20 =20 Hello all, We have submitted the following I-D, please send in your comments/suggestions =20 * speaking as a technical contributor * =20 In [BRPC], a method to optimally compute a inter-domain TE=20 path for MPLS and GMPS LSPs using the PCE architecture detailed in=20 [PCE_ARCH] is described. However the method described requires the=20 list of Autonomous systems or domains to be determined apriori.=20 Determining the list of ASes/domains to be traversed to reach a=20 destination, satisfying the TE constraints is non-trivial. It=20 requires knowledge of the inter-AS connectivity and the TE=20 characteristics of the inter-AS links along with the knowledge of=20 the available paths within each of the ASes/domains. BGP contains=20 information on the list of ASes to be traversed to reach a=20 destination, however BGP route selection and decision process=20 truncates most of the feasible paths, and it also does not carry=20 the TE characteristics of the inter-AS links and path availability=20 within a domain. =20 =20 What does prevent you from relying on BGP to provide you all possible paths toward=20 a specific destination skipping the regular path selection process for specific routes (see proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE link could easily be obtained via the IGP with minor additions. =20 This is in my opinion a fundamental question that must first be addressed before=20 moving forward. =20 Thanks. =20 JP. =20 =20 Regards Vijay =20 -----Original Message----- From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, January 23, 2007 2:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =20 =20 Title : A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-bgp-interas-te-path-01.txt Pages : 26 Date : 2007-1-22 =20 The ability to compute an optimal path for setting up Traffic=20 engineering Label Switched Paths spanning multiple autonomous=20 systems managed by different operators has been a key requirement in=20 MPLS and GMPLS networks. This document specifies a method of=20 computing inter-AS paths consisting of a list of ASes to be=20 traversed and a list of TE-Tunnels to be traversed in each AS. The=20 method described here uses BGP speakers in the PCEs of each AS to=20 distribute the inter-AS connectivity information and the TE-Tunnels=20 in each AS to its neighbors to facilitate the construction of an=20 inter-AS topology graph which can be used for computing inter-AS paths. =20 A URL for this Internet-Draft is: =20 http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-interas-te -path-01.txt =20 =20 =20 DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- =20 The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. =20 ------------------------------------------------------------------------ ----------------------------------------------- =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 =20 ------_=_NextPart_001_01C748EB.F8629B46 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

We mean that those inter-ASBR TE = LSPs which are permitted by policy/scaling configuration to be propagated = outside can be propogated to PCEs in neighbouring ASes by BGP.This information = is not flooded to all BGP speakers of neighbouring ASes but only to speakers = which are on PCEs or which propogate them to PCEs ( which support the new = AFI/SAFI).

 

 These LSPs may be a sub-set = of TE LSPs specifically provisioned for carrying inter-AS TE traffic and may be a = full mesh. If all the ASes support such a mechanism then the itner-AS TE path = can be calculated using the inter-AS graph of such LSPs and inter-AS = links.

 

But, this kind of itner-ASBR LSP = propogation may not be always possible because of policy and scaling constraints. In = such situations we have only the ASes and their int/internet-drafts/draft-vijay-somen-pce-bgp-interas-te -path-01.txt =20 =20 =20 DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- =20 The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. =20 ------------------------------------------------------------------------ ----------------------------------------------- =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 =20 ------_=_NextPart_001_01C748EB.F8629B46 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

We mean that those inter-ASBR TE = LSPs which are permitted by policy/scaling configuration to be propagated = outside can be propogated to PCEs in neighbouring ASes by BGP.This information = is not flooded to all BGP speakers of neighbouring ASes but only to speakers = which are on PCEs or which propogate them to PCEs ( which support the new = AFI/SAFI).

 

 These LSPs may be a sub-set = of TE LSPs specifically provisioned for carrying inter-AS TE traffic and may be a = full mesh. If all the ASes support such a mechanism then the itner-AS TE path = can be calculated using the inter-AS graph of such LSPs and inter-AS = links.

 

But, this kind of itner-ASBR LSP = propogation may not be always possible because of policy and scaling constraints. In = such situations we have only the ASes and their inter-AS links in the form of = an inter-AS graph and we can only find the ‘possible’ AS paths = after eliminating the paths through inter-AS links which are not feasible and = then use methods like BRPC to complete the path setup.

 

Regards

Vijay

 

 

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Saturday, February 03, 2007 4:05 AM
To: Vijayanand C - TLS, = Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: = I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =

 

Hi,

 

Let me first try to make sure of something here. When you write = "The PCE shall learn the TE 

   = attributes of the inter-AS TE links and the TE tunnels that = exist 

   = between the ASBRs in the domain."

 

Are you suggesting to flood via BGP the intra-domain TE LSPs ? = In other words, suppose the following scenario:

 

AS1---AS2---AS3

er-AS links in the form of = an inter-AS graph and we can only find the ‘possible’ AS paths = after eliminating the paths through inter-AS links which are not feasible and = then use methods like BRPC to complete the path setup.

 

Regards

Vijay

 

 

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Saturday, February 03, 2007 4:05 AM
To: Vijayanand C - TLS, = Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: = I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt =

 

Hi,

 

Let me first try to make sure of something here. When you write = "The PCE shall learn the TE 

   = attributes of the inter-AS TE links and the TE tunnels that = exist 

   = between the ASBRs in the domain."

 

Are you suggesting to flood via BGP the intra-domain TE LSPs ? = In other words, suppose the following scenario:

 

AS1---AS2---AS3

You have a mesh of intra-domain TE LSPs between all ASBRs within = AS2.

 

Are you suggesting to flood in AS1 these TE LSPs (and this for = all other ASes that might be between AS1 and the destination domain) = ?

 

Thanks.

 

JP.

 

On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, = Chennai. wrote:



Are = you suggesting that  BGP should propagate all possible next-hops/As = paths and regular path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ?

 

The inter-AS TE link information can be made aware only to the ASes on = either side of the inter-AS link by the IGP. It may not be possible to propagate it = beyond that ( or can it ?).

So some of the possible AS paths found by BGP( if we propagate all = next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of = violation of some TE constraint.

 

In our proposal we can pick the paths which are really feasible, since we have = the inter-AS graph, and then invoke methods like = BRPC

 

Regards

 

Are you suggesting to flood in AS1 these TE LSPs (and this for = all other ASes that might be between AS1 and the destination domain) = ?

 

Thanks.

 

JP.

 

On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, = Chennai. wrote:



Are = you suggesting that  BGP should propagate all possible next-hops/As = paths and regular path selection process avoided for all prefixes which can be destinations of inter-AS TE tunnels ?

 

The inter-AS TE link information can be made aware only to the ASes on = either side of the inter-AS link by the IGP. It may not be possible to propagate it = beyond that ( or can it ?).

So some of the possible AS paths found by BGP( if we propagate all = next-hops/aspaths in bgp) may not be worth trying for path setup (by BRPC) because of = violation of some TE constraint.

 

In our proposal we can pick the paths which are really feasible, since we have = the inter-AS graph, and then invoke methods like = BRPC

 

Regards

Vijay

 

 

 

 

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com] =
Sent: Thursday, February 01, 2007 1:19 AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

 

Hi,

 

On Jan 25, = 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote:

 

Vijay

 

 

 

 

-----Original Message-----
From: JP Vasseur [mailto:jvasseur@cisco.com] =
Sent: Thursday, February 01, 2007 1:19 AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org
Subject: Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

 

Hi,

 

On Jan 25, = 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote:

 

 

Hello all,

We have submitted the following I-D, please send in = your

comments/suggestions

 

* speaking as a technical contributor = *

 

   In [BRPC], a method to optimally compute a = inter-domain TE 

   path for MPLS and GMPS LSPs using the PCE architecture detailed in 

   [PCE_ARCH] is described. However the method = described requires the 

   list of Autonomous systems or domains to be determined apriori. 

   Determining the list of ASes/domains to be = traversed to reach a 

   destination, satisfying the TE constraints is non-trivial. It 

   requires knowledge of the inter-AS = connectivity and the TE 

   characteristics of the i>

 

Hello all,

We have submitted the following I-D, please send in = your

comments/suggestions

 

* speaking as a technical contributor = *

 

   In [BRPC], a method to optimally compute a = inter-domain TE 

   path for MPLS and GMPS LSPs using the PCE architecture detailed in 

   [PCE_ARCH] is described. However the method = described requires the 

   list of Autonomous systems or domains to be determined apriori. 

   Determining the list of ASes/domains to be = traversed to reach a 

   destination, satisfying the TE constraints is non-trivial. It 

   requires knowledge of the inter-AS = connectivity and the TE 

   characteristics of the inter-AS links along = with the knowledge of 

   the available paths within each of the = ASes/domains. BGP contains 

   information on the list of ASes to be = traversed to reach a 

   destination, however BGP route selection and = decision process 

   truncates most of the feasible paths, and it = also does not carry 

   the TE characteristics of the inter-AS links = and path availability 

   within a domain. =  

 

What does prevent you from relying on BGP to provide you = all possible paths toward 

a specific destination skipping the regular path selection = process for specific routes (see

proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE

link could easily be obtained via the IGP with minor = additions.

 

This is in my opinion a fundamental question that must = first be addressed before 

   the available paths within each of the = ASes/domains. BGP contains 

   information on the list of ASes to be = traversed to reach a 

   destination, however BGP route selection and = decision process 

   truncates most of the feasible paths, and it = also does not carry 

   the TE characteristics of the inter-AS links = and path availability 

   within a domain. =  

 

What does prevent you from relying on BGP to provide you = all possible paths toward 

a specific destination skipping the regular path selection = process for specific routes (see

proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE

link could easily be obtained via the IGP with minor = additions.

 

This is in my opinion a fundamental question that must = first be addressed before 

moving forward.

 

Thanks.

 

JP.

 

 

Regards

Vijay

 

-----Original Message-----

Sent: Tuesday, January 23, = 2007 2:20 AM

To: i-d-announce@ietf.orgmoving forward.

 

Thanks.

 

JP.

 

 

Regards

Vijay

 

-----Original Message-----

Sent: Tuesday, January 23, = 2007 2:20 AM

Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt 

 

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

directories.

 

 

          =   Title           &n= bsp;      : A BGP based method to compute inter-AS = Traffic

engineering Label Switched Paths with = PCE

          =   Author(s)          : C. = Vijayanand, S. Bhattacharya

          =   Filename           = :

draft-vijay-somen-pce-bgp-interas-te-path-01.txt

          =   Pages           &n= bsp;   : 26

          =   Date  &nb>

Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt 

 

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

directories.

 

 

          =   Title           &n= bsp;      : A BGP based method to compute inter-AS = Traffic

engineering Label Switched Paths with = PCE

          =   Author(s)          : C. = Vijayanand, S. Bhattacharya

          =   Filename           = :

draft-vijay-somen-pce-bgp-interas-te-path-01.txt

          =   Pages           &n= bsp;   : 26

          =   Date           &nb= sp;     : 2007-1-22

     &nbs= p;     

The ability to compute an optimal path for setting up Traffic 

   engineering Label Switched Paths spanning = multiple autonomous 

   systems managed by different operators has = been a key requirement in 

   MPLS and GMPLS networks. This document = specifies a method of 

   computing inter-AS paths consisting of a list = of ASes to be 

   traversed and a list of TE-Tunnels to be = traversed in each AS. The 

   method described here uses BGP speakers in the = PCEs of each AS to 

   distribute the inter-AS connectivity = information and the TE-Tunnels 

   in each AS to its neighbors to facilitate the construction of an 

   inter-AS topology graph which can be used for computing inter-AS

    paths.

 

     &nbs= p;     

The ability to compute an optimal path for setting up Traffic 

   engineering Label Switched Paths spanning = multiple autonomous 

   systems managed by different operators has = been a key requirement in 

   MPLS and GMPLS networks. This document = specifies a method of 

   computing inter-AS paths consisting of a list = of ASes to be 

   traversed and a list of TE-Tunnels to be = traversed in each AS. The 

   method described here uses BGP speakers in the = PCEs of each AS to 

   distribute the inter-AS connectivity = information and the TE-Tunnels 

   in each AS to its neighbors to facilitate the construction of an 

   inter-AS topology graph which can be used for computing inter-AS

    paths.

 

A URL for this Internet-Draft is:

-path-01.txt

 

 

 

DISCLAIMER:

------------------------------------------------------------= -----------------------------------------------------------=

 

The contents of this e-mail and any attachment(s) are = confidential and intended for the named recipient(s) only.

It shall not attach any liability on the originator or HCL = or its affiliates. Any views or opinions presented = in 

this email are solely those of the author and may not = necessarily reflect the opinions of HCL or its affiliates.

Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication = of 

A URL for this Internet-Draft is:

-path-01.txt

 

 

 

DISCLAIMER:

------------------------------------------------------------= -----------------------------------------------------------=

 

The contents of this e-mail and any attachment(s) are = confidential and intended for the named recipient(s) only.

It shall not attach any liability on the originator or HCL = or its affiliates. Any views or opinions presented = in 

this email are solely those of the author and may not = necessarily reflect the opinions of HCL or its affiliates.

Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication = of 

this message without the prior written consent of the = author of this e-mail is strictly prohibited. If you = have 

received this email in error please delete it and notify = the sender immediately. Before opening any mail = and 

attachments please check them for viruses and = defect.

 

------------------------------------------------------------= -----------------------------------------------------------=

 

_______________________________________________

Pce mailing list

 



 

------_=_NextPart_001_01C748EB.F8629B46-- --===============0186145142== 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 --===============0186145142==-- :12.0pt; color:black'>this message without the prior written consent of the = author of this e-mail is strictly prohibited. If you = have 

received this email in error please delete it and notify = the sender immediately. Before opening any mail = and 

attachments please check them for viruses and = defect.

 

------------------------------------------------------------= -----------------------------------------------------------=

 

_______________________________________________

Pce mailing list

 



 

------_=_NextPart_001_01C748EB.F8629B46-- --===============0186145142== 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 --===============0186145142==-- From pce-bounces@lists.ietf.org Mon Feb 05 05:48:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE1Np-00055N-3X; Mon, 05 Feb 2007 05:47:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0xY-000328-7j for pce@ietf.org; Mon, 05 Feb 2007 05:20:28 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE0xW-0001Rb-Mf for pce@ietf.org; Mon, 05 Feb 2007 05:20:28 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Feb 2007 02:20:27 -0800 X-IronPort-AV: i="4.13,282,1167638400"; d="scan'208,217"; a="52265110:sNHT243251662" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l15AKQhX014986; Mon, 5 Feb 2007 05:20:26 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l15AKQOA029466; Mon, 5 Feb 2007 05:20:26 -0500 (EST) 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); Mon, 5 Feb 2007 05:20:25 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 05:20:22 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Date: Mon, 5 Feb 2007 05:20:25 -0500 To: "Vijayanand C - TLS, Chennai." X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 05 Feb 2007 10:20:22.0634 (UTC) FILETIME=[3E9074A0:01C7490F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=86147; t=1170670826; x=1171534826; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20RE=3A=20I-D=20=20=20ACTION=3Adraft-vijay-some n-pce-bgp-interas-te-path-01.txt=20 |Sender:=20 |To:=20=22Vijayanand=20C=20-=20TLS,=20Chennai.=22=20; bh=Re24TmCvHAKm2QoHpNvj2saPB+kbmPNq+MrazAiSYu8=; b=h6r/SjMV3P7koHExl1tkt3dFBSRUB8fzoPDDkGWQotMtSYg3Bt/i6NMQ52u43NvVFAB84sVf paE8mOkCTyfSGIShSCA2VSBVS+K+Snk2k+AtiFyBNqstMG5SC25veN6j; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 66f400f61005d4d0a97f265bc4a7a9ca X-Mailman-Approved-At: Mon, 05 Feb 2007 05:47:33 -0500 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="===============1531711168==" Errors-To: pce-bounces@lists.ietf.org --===============1531711168== Content-Type: multipart/alternative; boundary=Apple-Mail-175--909902535 --Apple-Mail-175--909902535 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Vijay, On Feb 5, 2007, at 1:07 AM, Vijayanand C - TLS, Chennai. wrote: > > We mean that those inter-ASBR TE LSPs which are permitted by policy/=20= > scaling configuration to be propagated outside can be propogated to =20= > PCEs in neighbouring ASes by BGP.This information is not flooded to =20= > all BGP speakers of neighbouring ASes but only to speakers which =20 > are on PCEs or which propogate them to PCEs ( which support the new =20= > AFI/SAFI). > > > These LSPs may be a sub-set of TE LSPs specifically provisioned =20 > for carrying inter-AS TE traffic and may be a full mesh. If all the =20= > ASes support such a mechanism then the itner-AS TE path can be =20 > calculated using the inter-AS graph of such LSPs and inter-AS links. > > Then I've got a much major concern then. Back to when the inter-=20 domain TE discussion started (a few years back), several potential =20 candidates have been investigated including the TE aggregation =20 technique that you propose and that has been excluded for a number of =20= reasons (see also RFC4105 and RFC4216). Thus we proposed two =20 techniques: per-domain and the PCE (where no aggregated TE data is =20 leaked between domains !). You may want to refer to the lists =20 archives for details but TE aggregation has been rejected, this is =20 precisely why we developed PCE-based computation for inter-domain TE. I certainly do not want to re-open the debate for the Nth time, but =20 just consider that in your proposal you would not have to flood just =20 one TE LSP per pair of ASBR but one TE LSP per attribute per pair of =20 ASBRs (combining affinity, CTs, metric, ... ) and for all domains + =20 this would of course be dynamic (based on the TE LSP when they get =20 rerouted because of failures, reoptimization, ...). > > But, this kind of itner-ASBR LSP propogation may not be always =20 > possible because of policy and scaling constraints. In such =20 > situations we have only the ASes and their inter-AS links in the =20 > form of an inter-AS graph and we can only find the =91possible=92 AS =20= > paths after eliminating the paths through inter-AS links which are =20 > not feasible and then use methods like BRPC to complete the path =20 > setup. But in this case, it is probably not worth the work: you do not have =20 the 'possible' AS since you do not have any information about the =20 resource available within each AS. Hope this helps. Thanks. JP. > > Regards > > Vijay > > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Saturday, February 03, 2007 4:05 AM > To: Vijayanand C - TLS, Chennai. > Cc: pce@ietf.org > Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-=20= > te-path-01.txt > > > Hi, > > > Let me first try to make sure of something here. When you write =20 > "The PCE shall learn the TE > > attributes of the inter-AS TE links and the TE tunnels that exist > > between the ASBRs in the domain." > > > Are you suggesting to flood via BGP the intra-domain TE LSPs ? In =20 > other words, suppose the following scenario: > > > AS1---AS2---AS3 > > You have a mesh of intra-domain TE LSPs between all ASBRs within AS2. > > > Are you suggesting to flood in AS1 these TE LSPs (and this for all =20 > other ASes that might be between AS1 and the destination domain) ? > > > Thanks. > > > JP. > > > On Feb 1, 2007, at 12:48 AM, Vijayanand C - TLS, Chennai. wrote: > > > > > Are you suggesting that BGP should propagate all possible next-=20 > hops/As paths and regular path selection process avoided for all =20 > prefixes which can be destinations of inter-AS TE tunnels ? > > > The inter-AS TE link information can be made aware only to the ASes =20= > on either side of the inter-AS link by the IGP. It may not be =20 > possible to propagate it beyond that ( or can it ?). > > So some of the possible AS paths found by BGP( if we propagate all =20 > next-hops/aspaths in bgp) may not be worth trying for path setup =20 > (by BRPC) because of violation of some TE constraint. > > > In our proposal we can pick the paths which are really feasible, =20 > since we have the inter-AS graph, and then invoke methods like BRPC > > > Regards > > Vijay > > > > > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, February 01, 2007 1:19 AM > To: Vijayanand C - TLS, Chennai. > Cc: pce@ietf.org > Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-=20= > te-path-01.txt > > > Hi, > > > On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: > > > > Hello all, > > We have submitted the following I-D, please send in your > > comments/suggestions > > > * speaking as a technical contributor * > > > In [BRPC], a method to optimally compute a inter-domain TE > > path for MPLS and GMPS LSPs using the PCE architecture detailed in > > [PCE_ARCH] is described. However the method described requires the > > list of Autonomous systems or domains to be determined apriori. > > Determining the list of ASes/domains to be traversed to reach a > > destination, satisfying the TE constraints is non-trivial. It > > requires knowledge of the inter-AS connectivity and the TE > > characteristics of the inter-AS links along with the knowledge of > > the available paths within each of the ASes/domains. BGP contains > > information on the list of ASes to be traversed to reach a > > destination, however BGP route selection and decision process > > truncates most of the feasible paths, and it also does not carry > > the TE characteristics of the inter-AS links and path availability > > within a domain. > > > What does prevent you from relying on BGP to provide you all =20 > possible paths toward > > a specific destination skipping the regular path selection process =20 > for specific routes (see > > proposals made in the past) and then use BRPC as currently =20 > specified? The Inter-AS TE > > link could easily be obtained via the IGP with minor additions. > > > This is in my opinion a fundamental question that must first be =20 > addressed before > > moving forward. > > > Thanks. > > > JP. > > > > Regards > > Vijay > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, January 23, 2007 2:20 AM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : A BGP based method to compute =20 > inter-AS Traffic > > engineering Label Switched Paths with PCE > > Author(s) : C. Vijayanand, S. Bhattacharya > > Filename : > > draft-vijay-somen-pce-bgp-interas-te-path-01.txt > > Pages : 26 > > Date : 2007-1-22 > > > The ability to compute an optimal path for setting up Traffic > > engineering Label Switched Paths spanning multiple autonomous > > systems managed by different operators has been a key =20 > requirement in > > MPLS and GMPLS networks. This document specifies a method of > > computing inter-AS paths consisting of a list of ASes to be > > traversed and a list of TE-Tunnels to be traversed in each AS. The > > method described here uses BGP speakers in the PCEs of each AS to > > distribute the inter-AS connectivity information and the TE-Tunnels > > in each AS to its neighbors to facilitate the construction of an > > inter-AS topology graph which can be used for computing inter-AS > > paths. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-=20 > interas-te > > -path-01.txt > > > > > DISCLAIMER: > > ----------------------------------------------------------------------=20= > ------------------------------------------------- > > > The contents of this e-mail and any attachment(s) are confidential =20 > and intended for the named recipient(s) only. > > It shall not attach any liability on the originator or HCL or its =20 > affiliates. Any views or opinions presented in > > this email are solely those of the author and may not necessarily =20 > reflect the opinions of HCL or its affiliates. > > Any form of reproduction, dissemination, copying, disclosure, =20 > modification, distribution and / or publication of > > this message without the prior written consent of the author of =20 > this e-mail is strictly prohibited. If you have > > received this email in error please delete it and notify the sender =20= > immediately. Before opening any mail and > > attachments please check them for viruses and defect. > > > ----------------------------------------------------------------------=20= > ------------------------------------------------- > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > --Apple-Mail-175--909902535 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Vijay,

On = Feb 5, 2007, at 1:07 AM, Vijayanand C - TLS, Chennai. wrote:

We mean that those inter-ASBR TE LSPs which are permitted = by policy/scaling configuration to be propagated outside can be = propogated to PCEs in neighbouring ASes by BGP.This information is not = flooded to all BGP speakers of neighbouring ASes but only to speakers = which are on PCEs or which propogate them to PCEs ( which support the = new AFI/SAFI).

=A0

=A0These LSPs may be a = sub-set of TE LSPs specifically provisioned for carrying inter-AS TE = traffic and may be a full mesh. If all the ASes support such a mechanism = then the itner-AS TE path can be calculated using the inter-AS graph of = such LSPs and inter-AS links.

Then I've got = a=A0much=A0major concern then. Back to when the inter-domain TE = discussion started (a few years back), several potential candidates have = been investigated including the TE aggregation technique that you = propose and that has been excluded for a=A0number=A0of reasons = (see also RFC4105 and RFC4216). Thus we proposed two techniques: = per-domain and the PCE (where no aggregated TE data is leaked between = domains !). You may want to refer to the lists archives for details but = TE aggregation has been rejected, this is precisely why = we=A0developed=A0PCE-based computation for inter-domain = TE.=A0

I = certainly do not want to re-open the debate for the Nth time, but just = consider that in your proposal you would not have to flood just one TE = LSP per pair of ASBR but one TE LSP per attribute per pair of ASBRs = (combining affinity, CTs, metric, ... ) and for all domains + this would = of course be dynamic (based on the TE LSP when they get rerouted because = of failures, reoptimization, ...).

But, this kind of itner-ASBR LSP propogation may not be = always possible because of policy and scaling constraints. In such = situations we have only the ASes and their inter-AS links in the form of = an inter-AS graph and we can only find the =91possible=92 AS paths after = eliminating the paths through inter-AS links which are not feasible and = then use methods like BRPC to complete the path = setup.


But in this case, it is = probably not worth the work: you do not have the 'possible' AS since you = do not have any information about the resource available within each = AS.

Hope this = helps.

Thanks.

JP.

Regards

-----Original Message-----
JP Vasseur [mailto:jvasseur@cisco.com] =
= Saturday, February 03, = 2007 4:05 = AM Vijayanand C - = TLS, Chennai.
pce@ietf.org
Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

=A0

Let = me first try to make sure of something here. When you write = "The PCE shall learn the = TE=A0

=A0=A0 = attributes of the inter-AS TE links and the TE tunnels that = exist=A0

=A0=A0 between = the ASBRs in the = domain."

=A0

Are = you suggesting to flood via BGP the intra-domain TE LSPs ? In other = words, suppose the following = scenario:

=A0

You = have a mesh of intra-domain TE LSPs between all ASBRs within = AS2.

=A0

Are = you suggesting to flood in AS1 these TE LSPs (and this for all other = ASes that might be between AS1 and the destination domain) = ?

=A0

=A0

=A0

On = Feb 1, 2007, at 12:48 AM, = Vijayanand C - TLS, Chennai. wrote:



Are you suggesting that =A0BGP should = propagate all possible next-hops/As paths and regular path selection = process avoided for all prefixes which can be destinations of inter-AS = TE tunnels ?

=A0

The inter-AS TE link information can be made aware only to = the ASes on either side of the inter-AS link by the IGP. It may not be = possible to propagate it beyond that ( or can it = ?).

So some of the possible AS paths found by BGP( if we = propagate all next-hops/aspaths in bgp) may not be worth trying for path = setup (by BRPC) because of violation of some TE = constraint.

=A0

In our proposal we can pick the paths which are really = feasible, since we have the inter-AS graph, and then invoke methods like = BRPC

=A0

Regards

Vijay

=A0
=A0
=A0
=A0

-----Original = Message-----
JP Vasseur = [mailto:jvasseur@cisco.com]
= Thursday, February 01, = 2007 1:19 = AM
To: Vijayanand C - TLS, Chennai.
Cc: pce@ietf.org
Re: [Pce] RE: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt

=A0

Hi,

=A0

On = Jan 25, 2007, at = 9:32 AM, Vijayanand C - TLS, Chennai. = wrote:

=A0
=A0

Hello = all,

We have submitted the following I-D, please send in = your

=A0

* speaking as a technical = contributor *

=A0

=A0 =A0In [BRPC], a method to optimally compute a = inter-domain TE=A0

=A0=A0 path for MPLS and GMPS LSPs using the PCE = architecture detailed in=A0

=A0=A0 [PCE_ARCH] is described. However the method = described requires the=A0

=A0=A0 list of Autonomous systems or domains to be = determined apriori.=A0

=A0=A0 Determining the list of ASes/domains to be = traversed to reach a=A0

=A0=A0 destination, satisfying the TE constraints is = non-trivial. It=A0

=A0=A0 requires knowledge of the inter-AS = connectivity and the TE=A0

=A0=A0 characteristics of the inter-AS links along = with the knowledge of=A0

=A0=A0 the available paths within each of the = ASes/domains. BGP contains=A0

=A0=A0 information on the list of ASes to be = traversed to reach a=A0

=A0=A0 destination, however BGP route selection and = decision process=A0

=A0=A0 truncates most of the feasible paths, and it = also does not carry=A0

=A0=A0 the TE characteristics of the inter-AS links = and path availability=A0

=A0=A0 within a domain. = =A0

=A0

What does prevent you from = relying on BGP to provide you all possible paths = toward=A0

a specific destination skipping the regular path = selection process for specific routes = (see

proposals made in the past) and then use BRPC as = currently specified? The Inter-AS = TE

link could easily be obtained via the IGP with minor = additions.

=A0

This is in my opinion a = fundamental question that must first be addressed = before=A0

moving = forward.

=A0

=A0

=A0

=A0

Vijay

=A0

-----Original = Message-----