From pce-bounces@lists.ietf.org Tue Aug 01 15:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80Fj-00077C-Rp; Tue, 01 Aug 2006 15:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80Fe-000764-2N; Tue, 01 Aug 2006 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G80Fd-0008Rr-Lk; Tue, 01 Aug 2006 15:50:01 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9D0EB32872; Tue, 1 Aug 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G80Fd-0004z1-Gl; Tue, 01 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 01 Aug 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-policy-enabled-path-comp-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Policy-Enabled Path Computation Framework Author(s) : I. Bryskin, et al. Filename : draft-ietf-pce-policy-enabled-path-comp-00.txt Pages : 29 Date : 2006-8-1 The PCE architecture [PCE-ARCH] introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE Architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-policy-enabled-path-comp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-policy-enabled-path-comp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-policy-enabled-path-comp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-1141918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-policy-enabled-path-comp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-policy-enabled-path-comp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-1141918.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 Aug 04 04:39:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vDk-00050I-0e; Fri, 04 Aug 2006 04:39:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vDi-0004sq-E4 for pce@ietf.org; Fri, 04 Aug 2006 04:39:50 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8vDb-0000eQ-OI for pce@ietf.org; Fri, 04 Aug 2006 04:39:50 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3G00DAIU5MR5@szxga02-in.huawei.com> for pce@ietf.org; Fri, 04 Aug 2006 16:56:10 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3G00K5GU5KLR@szxga02-in.huawei.com> for pce@ietf.org; Fri, 04 Aug 2006 16:56:10 +0800 (CST) Received: from j36340 ([10.164.45.13]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3G000BETHYVD@szxml03-in.huawei.com> for pce@ietf.org; Fri, 04 Aug 2006 16:42:05 +0800 (CST) Date: Fri, 04 Aug 2006 16:38:45 +0800 From: XingFeng Jiang To: jvasseur@cisco.com Message-id: <000001c6b7a1$669dc0b0$0d2da40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: Aca3oWX9jqyn0p1BSA25Mg1+KvB3Dw== X-Spam-Score: 0.2 (/) X-Scan-Signature: 6a77dc8c5997955bff6a04ad06fce70d Cc: pce@ietf.org Subject: [Pce] a question on BRPC 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="===============0629003421==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0629003421== Content-type: multipart/alternative; boundary="Boundary_(ID_IY5k1CQl/rvBDa0FVCjY6Q)" This is a multi-part message in MIME format. --Boundary_(ID_IY5k1CQl/rvBDa0FVCjY6Q) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi, JP: I have read your draft, draft-vasseur-pce-brpc-01.txt, and I have a question. In Draft: Step 2: PCE(n) computes VSPT(n) made of the list of shortest constrained path(s) between every BR-en(j,n) and the TE LSP destination using a suitable path computation algorithm (e.g. CSPF) and returns the computed VSPT(n) to PCE(n-1). =20 My question is: How does PCE know who are the entry nodes or exit nodes = of a domain? Lack of this information, PCE can not compute the path in the domain. If the information is included in the predetermined domain path = set? Maybe the question is na=EFve and simple; could you give me some = explanations? =20 Thanks XingFeng Jiang =20 --Boundary_(ID_IY5k1CQl/rvBDa0FVCjY6Q) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi, = JP:

I have read your draft, draft-vasseur-pce-brpc-01.txt, and I = have a question.

In Draft:

=A0=A0 Step 2: PCE(n) computes = VSPT(n) made of the list of shortest

=A0=A0 constrained path(s) between = every BR-en(j,n) and the TE LSP

=A0=A0 destination using a suitable = path computation algorithm (e.g.=A0 CSPF)

=A0=A0 and returns the computed = VSPT(n) to PCE(n-1).

 

=A0My question is: How does PCE know = who are the entry nodes or exit nodes of a domain? Lack of this information, PCE can = not compute the path in the domain. If the information is included in the = predetermined domain path set?

Maybe the question is na=EFve and = simple; could you give me some explanations?

 

Thanks

=A0XingFeng = Jiang

 =

--Boundary_(ID_IY5k1CQl/rvBDa0FVCjY6Q)-- --===============0629003421== 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 --===============0629003421==-- From pce-bounces@lists.ietf.org Thu Aug 10 01:34:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3B9-000188-HJ; Thu, 10 Aug 2006 01:33:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3B7-00017m-Sr for pce@ietf.org; Thu, 10 Aug 2006 01:33:57 -0400 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB3B6-0001dx-7D for pce@ietf.org; Thu, 10 Aug 2006 01:33:57 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Aug 2006 11:03:54 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Aug 2006 11:03:54 +0530 Message-ID: <434F1CE611459F45BBC351FEB5A83F4301936782@kavithai.ctd.hcltech.com> From: "Vijayanand C - TLS, Chennai." To: Date: Thu, 10 Aug 2006 11:03:50 +0530 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 10 Aug 2006 05:33:54.0059 (UTC) FILETIME=[916ECDB0:01C6BC3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Cc: Subject: [Pce] Fwd:I-D ACTION:draft-vijay-somen-pce-disco-proto-bgp-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="===============1467047618==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1467047618== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BC3E.8F984525" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BC3E.8F984525 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Windows-1252" Hello all, Request your comments on the following draft. =20 Regards, Vijay =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 =20 Title : BGP Protocol extensions for PCE Discovery = across Autonomous systems Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-disco-proto-bgp-00.txt Pages : 1 Date : 2006-8-9 =20 It is desirable for a PCC to dynamically discover a PCE and its=20 capabilities for computing paths which span multiple areas and=20 autonomous systems. When the path to be computed spans across=20 multiple IGP domains or autonomous systems it is advantageous to use=20 BGP to distribute information about PCEs. This document describes=20 means to carry PCE discovery information using Multi-protocol=20 extensions of BGP(MP-BGP). =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-disco-proto-bgp= -00 .txt =20 =20 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 the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce =20 to change your subscription settings. =20 =20 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-vijay-somen-pce-disco-proto-bgp-00.txt". =20 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 =20 =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-vijay-somen-pce-disco-proto-bgp-00.txt". =20 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. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =20 =20 _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce =20 =20 DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 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=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 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=20 defect. ------_=_NextPart_001_01C6BC3E.8F984525 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 
Hello all,
Request your =
comments on the following draft.
 
Regards,

Vijay
 
 
A New =
Internet-Draft is available from the on-line Internet-Drafts =
directories.
 
 
        =
Title          : BGP =
Protocol extensions for PCE Discovery across Autonomous =
systems
        =
Author(s)      : C. Vijayanand, S. =
Bhattacharya
        =
Filename       : =
draft-vijay-somen-pce-disco-proto-bgp-00.txt
        =
Pages          : =
1
        =
Date           : =
2006-8-9
        =

It is =
desirable for a PCC to dynamically discover a PCE and its =

capabilities for computing paths which span =
multiple areas and 
autonomous systems. When the path to be =
computed spans across 
multiple =
IGP domains or autonomous systems it is advantageous to use =

BGP to =
distribute information about PCEs. This document describes =

means to =
carry PCE discovery information using Multi-protocol =

extensions of =
BGP(MP-BGP).
 
A URL for =
this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vijay-somen-pc=
e-disco-proto-bgp-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-vijay-somen-pce-disco-proto-bgp-00.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:
        =
mailserv at ietf.org.
In the =
body type:
        =
"FILE =
/internet-drafts/draft-vijay-somen-pce-disco-proto-bgp-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.
       &nbs=
p;       
       &nbs=
p;       
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-vijay-somen-= pce-disco-proto-bgp-00.txt> 

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

 

= ------_=_NextPart_001_01C6BC3E.8F984525-- --===============1467047618== 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 --===============1467047618==-- From pce-bounces@lists.ietf.org Fri Aug 11 18:59:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBfyP-0004dQ-Lm; Fri, 11 Aug 2006 18:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBfyP-0004d7-3Z for pce@ietf.org; Fri, 11 Aug 2006 18:59:25 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBfvV-00017U-4B for pce@ietf.org; Fri, 11 Aug 2006 18:56:26 -0400 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 1GBfvs-0004c5-00 for pce@ietf.org; Fri, 11 Aug 2006 23:56:48 +0100 Received: from your029b8cecfe ([217.158.132.126] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 23:56:22 +0100 Message-ID: <049701c6bd99$57ee7890$9b849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Fri, 11 Aug 2006 23:54:19 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 11 Aug 2006 22:56:22.0851 (UTC) FILETIME=[5DD4C930:01C6BD99] X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: [Pce] Fw: I-D ACTION:draft-bonica-tcp-auth-05.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, This work should be of interest to the PCEP designers. Thanks, Adrian ----- Original Message ----- From: To: Sent: Friday, August 11, 2006 8:50 PM Subject: I-D ACTION:draft-bonica-tcp-auth-05.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Authentication for TCP-based Routing and Management Protocols > Author(s) : R. Bonica, et al. > Filename : draft-bonica-tcp-auth-05.txt > Pages : 17 > Date : 2006-8-11 > > This memo describes a TCP extension that enhances security for BGP, > LDP and other TCP-based protocols. It is intended for applications > where secure administrative access to both the end-points of the TCP > connection is normally available. TCP peers can use this extension > to authenticate messages passed between one another. > > The strategy described herein improves upon current practice, which > is described in RFC 2385. Using this new strategy, TCP peers can > update authentication keys during the lifetime of a TCP connection. > TCP peers can also use stronger authentication algorithms to > authenticate routing messages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-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-bonica-tcp-auth-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-bonica-tcp-auth-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. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@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 From pce-bounces@lists.ietf.org Mon Aug 14 06:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZRs-0002KL-KI; Mon, 14 Aug 2006 06:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZRq-0002KF-VM for pce@ietf.org; Mon, 14 Aug 2006 06:13:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCY3s-0000BR-CY for pce@ietf.org; Mon, 14 Aug 2006 04:44:40 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCXvn-0001BY-MJ for pce@ietf.org; Mon, 14 Aug 2006 04:39:00 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3Z009USCC4DR@szxga03-in.huawei.com> for pce@ietf.org; Mon, 14 Aug 2006 16:45:40 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3Z004Y5CC3CN@szxga03-in.huawei.com> for pce@ietf.org; Mon, 14 Aug 2006 16:45:40 +0800 (CST) Received: from j36340 ([10.164.45.13]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3Z00D81CESSY@szxml04-in.huawei.com> for pce@ietf.org; Mon, 14 Aug 2006 16:47:20 +0800 (CST) Date: Mon, 14 Aug 2006 16:35:18 +0800 From: JiangXingFeng To: vijayc@hcl.in Message-id: <000001c6bf7c$92cdf960$0d2da40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: Aca/fJJNp984MG68RB6S4oAqbZ+BnA== X-Spam-Score: 0.7 (/) X-Scan-Signature: 800a60a6d139d15fdd4640055f94a486 Cc: pce@ietf.org Subject: [Pce] comments on draft-vijay-somen-pce-disco-proto-bgp-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="===============0923961308==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0923961308== Content-type: multipart/alternative; boundary="Boundary_(ID_CLRUxTEaEtKd9jeWAcVomA)" This is a multi-part message in MIME format. --Boundary_(ID_CLRUxTEaEtKd9jeWAcVomA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Vijayanand: I have read your draft, here are some comments. 1. >> The PCE information can be distributed across AS boundaries >> using E-BGP sessions. BGP policy can be used to control the import >> and export of PCE information similar to existing controls over the >> distribution of normal BGP routes. The normal BGP decision process >> will not be applied to the received PCE information. Comments: From the above, I can conclude that I-BGP sessions are not used to distribute information in one AS. It only depends on IGP extensions to redistribute the remote PCE information into the ASBR, and then it is the duty of ASBR to distribute it further. Do I understand correctly? Could you give me some clarifications? 2. antother question is : Up to now, the methods of path computation are mostly based on a predetermined domain path. The PCEs taking part in the computation mostly are statically configured. PCC or PCE may learn the pce information out of the AS, but I think the most important problem is to determine which PCEs will coooperate to achieve the computation. Could you give me some explanations about how to integrate your idea into the path computation process? Thanks. JiangXingFeng --Boundary_(ID_CLRUxTEaEtKd9jeWAcVomA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi, Vijayanand:

   I have read your draft, here are some comments.

1.

>>  The PCE information can be distributed across AS boundaries

>> using E-BGP sessions. BGP policy can be used to control the import

>> and export of PCE information similar to existing controls over the

>> distribution of normal BGP routes. The normal BGP decision process

>> will not be applied to the received PCE information.

Comments: From the above, I can conclude that I-BGP sessions are not used to distribute information in one AS.

It only depends on IGP extensions to redistribute the remote PCE information into the ASBR, and then it is the duty of ASBR to distribute it further.

Do I understand correctly? Could you give me some clarifications?

 

2. antother question is :  Up to now, the methods of path computation are mostly based on a predetermined domain path. The PCEs taking part in the  computation mostly are statically configured. PCC or PCE may learn the pce information out of the AS, but I think the most important problem is to determine which PCEs will coooperate to achieve the computation. Could you give me some explanations about how to integrate your idea into the path computation process?

 

Thanks.

JiangXingFeng

 

--Boundary_(ID_CLRUxTEaEtKd9jeWAcVomA)-- --===============0923961308== 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 --===============0923961308==-- From pce-bounces@lists.ietf.org Tue Aug 15 06:04:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCvmV-0005Af-Mz; Tue, 15 Aug 2006 06:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCvmT-0005Aa-PS for pce@lists.ietf.org; Tue, 15 Aug 2006 06:04:17 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCvmR-0007r0-0w for pce@lists.ietf.org; Tue, 15 Aug 2006 06:04:17 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4100HKKAPJ2K@szxga01-in.huawei.com> for pce@lists.ietf.org; Tue, 15 Aug 2006 18:05:43 +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 <0J4100C5YAPIJU@szxga01-in.huawei.com> for pce@lists.ietf.org; Tue, 15 Aug 2006 18:05:43 +0800 (CST) Received: from X57978 ([10.111.12.83]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J410004LB4IVB@szxml04-in.huawei.com> for pce@lists.ietf.org; Tue, 15 Aug 2006 18:14:43 +0800 (CST) Date: Tue, 15 Aug 2006 18:01:10 +0800 From: xiahongmiao To: pce@lists.ietf.org Message-id: <00a301c6c051$f321a430$530c6f0a@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 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Pce] a question about draft-vasseur-ccamp-ce-ce-te-01 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="===============1343482726==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1343482726== Content-type: multipart/alternative; boundary="Boundary_(ID_qmceULrkFrzNx5iVrU5n6w)" This is a multi-part message in MIME format. --Boundary_(ID_qmceULrkFrzNx5iVrU5n6w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, JP, In your draft draft-vasseur-ccamp-ce-ce-te-01, CE-to-CE LSP compute as follows: > Step 1: The ingress CE (e.g. CE1) selects a PCE (say PE1). > Step 2: Upon receiving the PCReq message from CE1, PE1 (acting as a > PCE) determines the set S of PEs with a PE-CE link to the destination > CE (e.g. CE2). The following VSPT is then computed: > VSPT computed by the ingress PE acting as a PCE > CE2 > / \ > PE1 PE2 > Step 3: The shortest constrained path is then returned to CE1 in the > form of a PCRep message (with loose hop). Here, I have a question and I think the PE should know just membership of PE-CE link, instead of PE-CE link TE attribute. Ingress PE looks for egress PE with this information. Could you tell me the truth? Thanks, xiahongmiao --Boundary_(ID_qmceULrkFrzNx5iVrU5n6w) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi, JP,
 
In your draft draft-vasseur-ccamp-ce-ce-te-01, CE-to-CE LSP compute as follows:
 
>   Step 1: The ingress CE (e.g.  CE1) selects a PCE (say PE1).
 
>   Step 2: Upon receiving the PCReq message from CE1, PE1 (acting as a
>   PCE) determines the set S of PEs with a PE-CE link to the destination
>   CE (e.g.  CE2).  The following VSPT is then computed:
 
>   VSPT computed by the ingress PE acting as a PCE
 
>                 CE2
>               /    \
>              PE1  PE2
 
>   Step 3: The shortest constrained path is then returned to CE1 in the
>   form of a PCRep message (with loose hop).
 
Here, I have a question and I think the PE should know just membership of PE-CE
link, instead of PE-CE link TE attribute. Ingress PE looks for egress PE with 
this information. Could you tell me the truth?
 
 
Thanks,
xiahongmiao
--Boundary_(ID_qmceULrkFrzNx5iVrU5n6w)-- --===============1343482726== 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 --===============1343482726==-- From pce-bounces@lists.ietf.org Thu Aug 17 02:45:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDbcR-0004sV-LA; Thu, 17 Aug 2006 02:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDbcQ-0004sQ-Cg for pce@ietf.org; Thu, 17 Aug 2006 02:44:42 -0400 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDbcO-00072i-SM for pce@ietf.org; Thu, 17 Aug 2006 02:44:42 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Aug 2006 12:13:33 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Aug 2006 12:13:33 +0530 Message-ID: <434F1CE611459F45BBC351FEB5A83F43019F337F@kavithai.ctd.hcltech.com> From: "Vijayanand C - TLS, Chennai." To: "JiangXingFeng" Date: Thu, 17 Aug 2006 12:13:32 +0530 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 17 Aug 2006 06:43:33.0433 (UTC) FILETIME=[756CEA90:01C6C1C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: b83962958e2d910ed948e2f9e138d171 Cc: pce@ietf.org, somen@avici.com Subject: [Pce] Re: comments on draft-vijay-somen-pce-disco-proto-bgp-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="===============1662432122==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1662432122== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C1C8.74D57426" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C1C8.74D57426 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Windows-1252" Hi. To answer your questions: =20 1. BGP is intended to carry the discovery information across IGP domains so usually it should get redistributed into the IGP, however, = the operator may decide when and how to effect this redistribution ( may be policy controlled) 2. The discovery mechanism provides information that 'this PCE can compute paths on behalf of this AS' and the other capabilities. Based on that the appropriate PCE has to be chosen. The destination or next AS on = the path should be known for this ( from configuration or other routing information) =20 Regards, Vijay =20 -----Original Message----- From: JiangXingFeng [mailto:jiang.x.f@huawei.com]=20 Sent: Monday, August 14, 2006 2:05 PM To: vijayc@hcl.in Cc: pce@ietf.org Subject: comments on draft-vijay-somen-pce-disco-proto-bgp-00.txt =20 Hi, Vijayanand: I have read your draft, here are some comments. 1. >> The PCE information can be distributed across AS boundaries=20 >> using E-BGP sessions. BGP policy can be used to control the import=20 >> and export of PCE information similar to existing controls over the=20 >> distribution of normal BGP routes. The normal BGP decision process=20 >> will not be applied to the received PCE information. Comments: From the above, I can conclude that I-BGP sessions are not = used to distribute information in one AS.=20 It only depends on IGP extensions to redistribute the remote PCE = information into the ASBR, and then it is the duty of ASBR to distribute it further. Do I understand correctly? Could you give me some clarifications?=20 =20 2. antother question is : Up to now, the methods of path computation = are mostly based on a predetermined domain path. The PCEs taking part in the computation mostly are statically configured. PCC or PCE may learn the = pce information out of the AS, but I think the most important problem is to determine which PCEs will coooperate to achieve the computation. Could = you give me some explanations about how to integrate your idea into the path computation process?=20 =20 Thanks. JiangXingFeng =20 DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 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=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 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=20 defect. ------_=_NextPart_001_01C6C1C8.74D57426 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="Windows-1252"

Hi.

To answer your questions:

 

  1. BGP = is intended to carry the discovery information across IGP domains so = usually it should get redistributed into the IGP, however, the operator may = decide when and how to effect this redistribution ( may be policy = controlled)
  2.  The discovery mechanism provides information that 'this PCE can compute paths on behalf of this AS' and the other capabilities. Based on = that the appropriate PCE has to be chosen. The destination or next AS on = the path should be known for this ( from configuration or other routing = information)

 

Regards,

Vijay=

 

-----Original Message-----
From: JiangXingFeng [mailto:jiang.x.f@huawei.com]
Sent: Monday, August 14, 2006 2:05 PM
To: vijayc@hcl.in
Cc: pce@ietf.org
Subject: comments on draft-vijay-somen-pce-disco-proto-bgp-00.txt

 

Hi, = Vijayanand:

   I have read = your draft, here are some comments.

1.

>>  The PCE = information can be distributed across AS boundaries

>> using E-BGP = sessions. BGP policy can be used to control the import

>> and export of PCE information similar to existing controls over the

>> distribution of = normal BGP routes. The normal BGP decision process

>> will not be applied = to the received PCE information.

Comments: >From the above, I can conclude that I-BGP sessions are not used to = distribute information in one AS.

It only depends on IGP extensions to redistribute the remote PCE = information into the ASBR, and then it is the duty of ASBR to distribute it = further.

Do I understand correctly? Could you give me some clarifications? =

 

2. antother question is : =  Up to now, the methods of path computation are mostly based on a = predetermined domain path. The PCEs taking part in the  computation mostly are statically configured. PCC or PCE may learn the pce information out of = the AS, but I think the most important problem is to determine which PCEs will coooperate to achieve the computation. Could you give me some = explanations about how to integrate your idea into the path computation process? =

 

Thanks.

JiangXingFeng

 

------_=_NextPart_001_01C6C1C8.74D57426-- --===============1662432122== 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 --===============1662432122==-- From pce-bounces@lists.ietf.org Thu Aug 17 03:28:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDcIQ-0005nX-GE; Thu, 17 Aug 2006 03:28:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDcIP-0005nS-1D for pce@ietf.org; Thu, 17 Aug 2006 03:28:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDcIL-0003uA-K4 for pce@ietf.org; Thu, 17 Aug 2006 03:28:05 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Aug 2006 00:28:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,134,1154934000"; d="scan'208,217"; a="36634527:sNHT43941276" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7H7S0jK022512; Thu, 17 Aug 2006 03:28:00 -0400 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7H7Rxg2002582; Thu, 17 Aug 2006 09:27:59 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 09:27:59 +0200 Received: from [192.168.0.3] ([10.58.48.50]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 09:27:58 +0200 In-Reply-To: <000001c6b7a1$669dc0b0$0d2da40a@china.huawei.com> References: <000001c6b7a1$669dc0b0$0d2da40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <0E931956-B791-4AF9-8F40-89B01573537B@cisco.com> From: JP Vasseur Date: Thu, 17 Aug 2006 09:27:55 +0200 To: XingFeng Jiang X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Aug 2006 07:27:58.0396 (UTC) FILETIME=[A9DDFFC0:01C6C1CE] DKIM-Signature: a=rsa-sha1; q=dns; l=12970; t=1155799681; x=1156663681; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20a=20question=20on=20BRPC |To:XingFeng=20Jiang=20; X=v=3Dcisco.com=3B=20h=3Dj6ahIA6IHiwewFDluhQ50p7RZt4=3D; b=jc3tIGZ6iaUvSlWAlu/wSH3EBVH2Yv+2bDU29CJwN3SIijHqd2ssI9trz/yRNqkteeFN8fjo gzYowGSTn2ZAFdjjRAoWuaNUz2VJ/Kc+39SpBjyfA20dwS9lzLDD2CoB; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 30 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 1.2 (+) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: pce@ietf.org Subject: [Pce] Re: a question on BRPC 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="===============1963399113==" Errors-To: pce-bounces@lists.ietf.org --===============1963399113== Content-Type: multipart/alternative; boundary=Apple-Mail-29--748667364 --Apple-Mail-29--748667364 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hi, On Aug 4, 2006, at 10:38 AM, XingFeng Jiang wrote: > Hi, JP: > > I have read your draft, draft-vasseur-pce-brpc-01.txt, and I have a =20= > question. > > In Draft: > > Step 2: PCE(n) computes VSPT(n) made of the list of shortest > > constrained path(s) between every BR-en(j,n) and the TE LSP > > destination using a suitable path computation algorithm (e.g. =20 > CSPF) > > and returns the computed VSPT(n) to PCE(n-1). > > > > My question is: How does PCE know who are the entry nodes or exit =20 > nodes of a domain? Lack of this information, PCE can not compute =20 > the path in the domain. If the information is included in the =20 > predetermined domain path set? > > Maybe the question is na=EFve and simple; could you give me some =20 > explanations? Sure, for inter-area, the answer is pretty straightforward (you can =20 easily monitor the set of ABR/L1L2 announcing a route for the =20 destination) and a similar approach can be used for Inter-AS (BGP). =20 Alternatively, the set of BN can be locally configured on the PCE =20 (note that some BN can be excluded by policy, providing that this may =20= prevent from finding the shortest constrained inter-domain path). Thanks. JP. > > > Thanks > > XingFeng Jiang > > > > --Apple-Mail-29--748667364 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi,

On Aug 4, = 2006, at 10:38 AM, XingFeng Jiang wrote:

Hi, JP:I = have read your draft,

In = Draft:

=C2=A0=C2=A0 = Step 2: PCE(n) computes VSPT(n) made of the list of shortest=C2=A0=C2=A0 constrained path(s) = between every BR-en(j,n) and the TE LSP

=C2=A0=C2=A0 = destination using a suitable path computation algorithm (e.g.=C2=A0 = CSPF)

=C2=A0=C2=A0 and returns the = computed VSPT(n) to PCE(n-1).

=C2=A0My question is: How does PCE = know who are the entry nodes or exit nodes of a domain? Lack of this = information, PCE can not compute the path in the domain. If the = information is included in the predetermined domain path set?Maybe the question is na=C3=AFve = and simple; could you give me some = explanations?

Sure, = for inter-area, the answer is pretty straightforward (you can easily = monitor the set of ABR/L1L2 announcing a route for the destination) and = a similar approach can be used for Inter-AS (BGP). Alternatively, the = set of BN can be locally configured on the PCE (note that some BN can be = excluded by policy, providing that this may prevent from finding the = shortest constrained inter-domain path).

Thanks.

JP.

=C2=A0

=

Thanks=C2=A0XingFeng Jiang


= --Apple-Mail-29--748667364-- --===============1963399113== 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 --===============1963399113==-- From pce-bounces@lists.ietf.org Thu Aug 17 03:43:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDcWx-0003zX-KS; Thu, 17 Aug 2006 03:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDcWw-0003zR-9N for pce@lists.ietf.org; Thu, 17 Aug 2006 03:43:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDcWu-0005zQ-S4 for pce@lists.ietf.org; Thu, 17 Aug 2006 03:43:06 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Aug 2006 00:43:00 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,134,1154934000"; d="scan'208,217"; a="36636133:sNHT38175920" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7H7gxPN024256; Thu, 17 Aug 2006 03:43:00 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7H7gxg2006066; Thu, 17 Aug 2006 09:42:59 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 09:42:59 +0200 Received: from [192.168.0.3] ([10.58.48.50]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 09:42:58 +0200 In-Reply-To: <00a301c6c051$f321a430$530c6f0a@china.huawei.com> References: <00a301c6c051$f321a430$530c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <6DC4EB3C-7FD1-44D1-AE26-7F9D1F1545EE@cisco.com> From: JP Vasseur Subject: Re: [Pce] a question about draft-vasseur-ccamp-ce-ce-te-01 Date: Thu, 17 Aug 2006 09:42:55 +0200 To: xiahongmiao X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Aug 2006 07:42:58.0748 (UTC) FILETIME=[C284CFC0:01C6C1D0] DKIM-Signature: a=rsa-sha1; q=dns; l=4820; t=1155800580; x=1156664580; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20[Pce]=20a=20question=20about=20draft-vasseur-ccamp-ce-ce-te-01 |To:xiahongmiao=20; X=v=3Dcisco.com=3B=20h=3DeO9iUoaunHz+M5fCsEnSdYl9c1o=3D; b=Hjbawuw9rsnJmSrb6V29R06cSbV1P1Ykx46kZztOoE22R+6kojtuDrMXP14cG3nhstRzDTbt YxKtmKhXr1nizY3Kf4BMwOeY5o8e3DdZ1cDSoVMyXluDyHk00/CeQ/yj; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 30 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: pce@lists.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="===============1775774551==" Errors-To: pce-bounces@lists.ietf.org --===============1775774551== Content-Type: multipart/alternative; boundary=Apple-Mail-34--747767083 --Apple-Mail-34--747767083 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Aug 15, 2006, at 12:01 PM, xiahongmiao wrote: > Hi, JP, > > In your draft draft-vasseur-ccamp-ce-ce-te-01, CE-to-CE LSP compute > as follows: > > > Step 1: The ingress CE (e.g. CE1) selects a PCE (say PE1). > > > Step 2: Upon receiving the PCReq message from CE1, PE1 (acting > as a > > PCE) determines the set S of PEs with a PE-CE link to the > destination > > CE (e.g. CE2). The following VSPT is then computed: > > > VSPT computed by the ingress PE acting as a PCE > > > CE2 > > / \ > > PE1 PE2 > > > Step 3: The shortest constrained path is then returned to CE1 > in the > > form of a PCRep message (with loose hop). > > Here, I have a question and I think the PE should know just > membership of PE-CE > link, instead of PE-CE link TE attribute. Ingress PE looks for > egress PE with > this information. Could you tell me the truth? > The ingress PE computes the shortest constrained TE LSP from CE to CE, thus the PE-CE TE Link attribute is required, not just the MPLS VPN membership. Thanks. JP. > > > Thanks, > xiahongmiao > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-34--747767083 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

On Aug 15, = 2006, at 12:01 PM, xiahongmiao wrote:

=
Hi, JP,
=A0
In your draft = draft-vasseur-ccamp-ce-ce-te-01, CE-to-CE LSP compute as = follows:
=A0
>=A0=A0 Step 1: The ingress CE (e.g.=A0 CE1) selects a PCE = (say PE1).
=A0
=
>=A0=A0 Step 2: Upon receiving the PCReq = message from CE1, PE1 (acting as a
>=A0=A0 PCE) determines the set = S of PEs with a PE-CE link to the destination
>=A0=A0 CE (e.g.=A0 = CE2).=A0 The following VSPT is then computed:
=A0
>=A0=A0 VSPT = computed by the ingress PE acting as a PCE
=A0
>=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 CE2
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 /=A0=A0=A0 \
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PE1=A0 = PE2
=A0
>=A0=A0 Step 3: The shortest constrained path is then = returned to CE1 in the
>=A0=A0 form of a PCRep message (with loose = hop).
=A0
Here, I have a question and I think the PE should know just = membership of PE-CE
link, = instead of PE-CE link TE attribute. Ingress = PE=A0looks for egress PE=A0with=A0
this= information. Could you=A0tell me the truth?


The ingress PE computes the = shortest constrained TE LSP from CE to CE, thus the PE-CE TE Link = attribute is required, not just the MPLS VPN membership.

Thanks.

JP.

=A0
=A0
=
Thanks,
xiahongmiao
Pce mailing list
=

= --Apple-Mail-34--747767083-- --===============1775774551== 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 --===============1775774551==-- From pce-bounces@lists.ietf.org Fri Aug 18 00:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDvZ6-0002yn-Gt; Fri, 18 Aug 2006 00:02:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDvZ5-0002yc-0U for pce@ietf.org; Fri, 18 Aug 2006 00:02:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDvZ4-0005bQ-Tb for pce@ietf.org; Fri, 18 Aug 2006 00:02:34 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDvNe-0007Wu-7C for pce@ietf.org; Thu, 17 Aug 2006 23:51:09 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J460037FDZD1J@szxga02-in.huawei.com> for pce@ietf.org; Fri, 18 Aug 2006 12:04:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4600A1XDZBEK@szxga02-in.huawei.com> for pce@ietf.org; Fri, 18 Aug 2006 12:04:25 +0800 (CST) Received: from j36340 ([10.164.45.13]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J46003V4DPUN6@szxml04-in.huawei.com> for pce@ietf.org; Fri, 18 Aug 2006 11:58:45 +0800 (CST) Date: Fri, 18 Aug 2006 11:46:39 +0800 From: JiangXingFeng In-reply-to: <0E931956-B791-4AF9-8F40-89B01573537B@cisco.com> To: 'JP Vasseur' Message-id: <000501c6c278$e9774650$0d2da40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbBzrDIevOf6su/R5+Ebus0vJtdSgAqhCgA X-Spam-Score: -0.7 (/) X-Scan-Signature: 8427182ba6fa72a12b6a04e63d6f913d Cc: pce@ietf.org Subject: [Pce] =?utf-8?b?562U5aSNOiBhIHF1ZXN0aW9uIG9uIEJSUEM=?= 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="===============0261886292==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0261886292== Content-type: multipart/alternative; boundary="Boundary_(ID_+xMYJcgra5xWOp22fPPrUw)" This is a multi-part message in MIME format. --Boundary_(ID_+xMYJcgra5xWOp22fPPrUw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi=EF=BC=8CJP=EF=BC=9A Thanks for your clarifications. With regard to BRPC, I have other = questions inline, please enlighten me.=20 =20 1. << Note that PCE(i) only considers the entry BNs that provide = connectivity from domain(i-1). =20 Comment: What does the *only* means? How does the PCE(i) learn the entry = BNs connected to domain(i-1)?=20 Is it locally configured on PCE(i)? =20 2.<< That is, the set BN-en(k,i-1) is only made of those BNs that = provide connectivity from domain (i-1) to domain(i). =20 Comments: Maybe there should be BN-en(k,i),not BN-en(k,i-1); = BN-en(k,i-1) provide connectivity from domain(i-2) to domain(i-1); =20 3. there is a scenario below. =20 <-- AS 1 ---> <------- AS 2 -----><--- AS 4 ----> R0----ASBR1-----ASBR2=E2=80=94R2---ASBR4----ASBR9----R6 \ / \ / \ /=20 \ ASBR3--R3-R4-ASBR5/ <------- AS 3 -----> =20 In the above figure, a TE-LSP tunnel between RO and R6 is requested. The = figure intends to illustrate. The relationship between ASs is more = complicated than it. Between RO and R6, there are two different domain path, AS1<->AS2<->AS4 = and AS1<->AS3<->AS4. Before the path computation, the domain path should = be determined. If the PCE choose any path among them, maybe the result of BRPC is not = the optimal path. In my opinion, all domain paths should be involved in = the computation process, if the policy is not considered. Maybe, a dynamically mechanism is required to facilitate the computation = of the optimal path.=20 =20 Thanks! =20 =20 JiangXingFeng _____ =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: JP Vasseur [mailto:jvasseur@cisco.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2006=E5=B9=B48=E6=9C=8817=E6=97=A5 = 15:28 =E6=94=B6=E4=BB=B6=E4=BA=BA: XingFeng Jiang =E6=8A=84=E9=80=81: pce@ietf.org =E4=B8=BB=E9=A2=98: Re: a question on BRPC =20 Hi, =20 On Aug 4, 2006, at 10:38 AM, XingFeng Jiang wrote: I have read your draft,=20 =C3=82 =C3=82 Step 2: PCE(n) computes VSPT(n) made of the list of = shortest =C3=82 =C3=82 destination using a suitable path computation algorithm = (e.g.=C3=82 CSPF) =C3=82=20 Maybe the question is na=C3=83=C2=AFve and simple; could you give me = some explanations? Sure, for inter-area, the answer is pretty straightforward (you can = easily monitor the set of ABR/L1L2 announcing a route for the = destination) and a similar approach can be used for Inter-AS (BGP). = Alternatively, the set of BN can be locally configured on the PCE (note = that some BN can be excluded by policy, providing that this may prevent = from finding the shortest constrained inter-domain path). =20 Thanks. =20 JP. =C3=82=20 =C3=82 XingFeng Jiang =C3=82=20 =20 --Boundary_(ID_+xMYJcgra5xWOp22fPPrUw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi=EF=BC=8CJP=EF=BC=9A

   Thanks for your = clarifications. With regard to BRPC, I have other questions inline, please enlighten me. =

 

1. <<  Note that PCE(i) only = considers the entry BNs that provide connectivity from domain(i-1).  =

Comme= nt: What does the *only* means? How does the PCE(i) = learn the entry BNs connected to domain(i-1)?

Is = it locally configured on PCE(i)?

 

2.<< That is, the set BN-en(k,i-1) = is only made of those BNs that provide connectivity from domain (i-1) to  = domain(i). 

Comme= nts: Maybe there should be BN-en(k,i),not BN-en(k,i-1); BN-en(k,i-1)  provide connectivity = from domain(i-2) to domain(i-1);

=  

3. there is a scenario = below.

=  

     <-- AS 1 = ---> <------- AS 2 -----><--- AS 4 ---->

    =  R0----ASBR1-----ASBR2=E2=80=94R2---ASBR4----AS= BR9----R6

  &nbs= p;          \            =             &= nbsp; /

  &nbs= p;           \             &= nbsp;          /

              &= nbsp;  \         &= nbsp;            /

\ = ASBR3--R3-R4-ASBR5/

<------- AS = 3 ----->

 

In the above figure, a TE-LSP tunnel = between RO and R6 is requested. The figure intends to illustrate. The relationship between ASs is more complicated than it.

Between RO and R6, there are two = different domain path, AS1<->AS2<->AS4 and AS1<->AS3<->AS4. Before the = path computation, the domain path should be = determined.

If the PCE choose any path among them, = maybe the result of BRPC is not the optimal path. In my opinion, all domain paths should be = involved in the computation process, if the policy is not = considered.

Maybe, a dynamically mechanism is = required to facilitate the computation of the optimal path.

 

Thanks!

=  

=  

JiangXingFeng

=E5=8F=91=E4=BB=B6=E4=BA= =BA: JP Vasseur [mailto:jvasseur@cisco.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4= : = 2006=E5=B9=B48=E6=9C=8817=E6=97=A5 15:28
=E6=94=B6=E4=BB=B6=E4=BA=BA: XingFeng Jiang
=E6=8A=84=E9=80=81: pce@ietf.org
=E4=B8=BB=E9=A2=98: Re: a question on BRPC

 

Hi,

 

On Aug 4, 2006, at 10:38 AM, XingFeng Jiang = wrote:



I = have read your draft,

=C3=82 =C3=82  Step 2: PCE(n) computes VSPT(n) made of the list of shortest=C3=82 =C3=82  destination using a suitable path computation algorithm = (e.g.=C3=82  CSPF)

=C3=82 

Maybe the question is na=C3=83=C2=AFve and simple; could you give me some = explanations?

Sure, for inter-area, the answer is pretty straightforward (you can easily monitor the set of ABR/L1L2 announcing a route for the destination) = and a similar approach can be used for Inter-AS (BGP). Alternatively, the set = of BN can be locally configured on the PCE (note that some BN can be excluded = by policy, providing that this may prevent from finding the shortest = constrained inter-domain path).

 

Thanks.

 

JP.

=C3=82 

=C3=82 XingFeng Jiang=C3=82 



 

--Boundary_(ID_+xMYJcgra5xWOp22fPPrUw)-- --===============0261886292== 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 --===============0261886292==-- From pce-bounces@lists.ietf.org Wed Aug 23 14:12:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxCP-0004xF-HM; Wed, 23 Aug 2006 14:11:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxCM-0004sZ-7M; Wed, 23 Aug 2006 14:11:30 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFxCK-0001sX-SD; Wed, 23 Aug 2006 14:11:30 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k7NIBSsh030136; Wed, 23 Aug 2006 11:11:28 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k7NIBSQ5030135; Wed, 23 Aug 2006 11:11:28 -0700 Date: Wed, 23 Aug 2006 11:11:28 -0700 Message-Id: <200608231811.k7NIBSQ5030135@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] RFC 4655 on A Path Computation Element (PCE)-Based Architecture X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4655 Title: A Path Computation Element (PCE)-Based Architecture Author: A. Farrel, J.-P. Vasseur, J. Ash Status: Informational Date: August 2006 Mailbox: adrian@olddog.co.uk, jpv@cisco.com, gash@att.com Pages: 40 Characters: 97561 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-architecture-05.txt URL: http://www.rfc-editor.org/rfc/rfc4655.txt Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. This document is a product of the Path Computation Element Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 29 17:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBQJ-00059W-P8; Tue, 29 Aug 2006 17:47:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBQH-00057e-Nj for pce@ietf.org; Tue, 29 Aug 2006 17:47:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBQF-0003g6-0G for pce@ietf.org; Tue, 29 Aug 2006 17:47:05 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Aug 2006 14:47:03 -0700 X-IronPort-AV: i="4.08,183,1154934000"; d="txt'?scan'208"; a="38813547:sNHT40057732" 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.20060308/8.12.11) with ESMTP id k7TLl2lf009678; Tue, 29 Aug 2006 17:47:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7TLl2dM001124; Tue, 29 Aug 2006 17:47:02 -0400 (EDT) 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, 29 Aug 2006 17:47:02 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 17:47:01 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-18-339676536 From: JP Vasseur Date: Tue, 29 Aug 2006 17:46:59 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 29 Aug 2006 21:47:01.0175 (UTC) FILETIME=[A8B6EC70:01C6CBB4] DKIM-Signature: a=rsa-sha1; q=dns; l=11692; t=1156888022; x=1157752022; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Draft=20PCE=20WG=20Meeting=20minutes=20-=20IETF-66 |To:pce@ietf.org; X=v=3Dcisco.com=3B=20h=3D8TTZeqxHPTmsOsPE9PSxHbIwvXw=3D; b=GNx8k650k/JQTdgpsjD/X+ayBHn5t8THe8tyvyzQWpwnkyMBjLi5kaHBN+pYaQWI5ui5hVdJ FqUFnsH7OpQ04vOPg1N4ogHzeAZaCTMSrfCOeFnOcQU0IvXGCqbWa0yV; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 35 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: Subject: [Pce] Draft PCE WG Meeting minutes - IETF-66 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 --Apple-Mail-18-339676536 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, Please find attached the PCE WG minutes - IETF-66. If you have any comment, please let us know by Sep 1. Thanks. JP and Adrian. --Apple-Mail-18-339676536 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name=PCE-WG-Minutes-IETF-66.txt Content-Disposition: attachment; filename=PCE-WG-Minutes-IETF-66.txt Draft PCE WG Minutes IETF-66 Montreal July-66 Many Thanks to Sherif Awad and Zafar Ali for having taken the minutes. 2) Working Group progress (Chairs - 10mn): see slides Comment from Jean Louis Le Roux (JL) : PCE Inter-area requirements ID is quite stable and last call is coming up. The policy section has been updated and the ID is ready for WG last call. 3) Update on Manageability Considerations (Adrian - 5mn) Adrian> After last IETF we talked about making a requirement for the IDs to have a Manageability considerations section. We received good feedback. Some resistance, as it makes process too heavy. We are talking to ADs about it in OPS. We have supports from them for this but we need to nail down the "what and how". Next step is to write an ID. Still needs to be discussed since might be to processes heavy. Adrian asked if some one thinks this is a bad idea. No objection raised. 4) Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) - draft-bitar-zhang-interas-pcecp-reqs-01.txt (Nabil - 10mn) Nabil requested for draft to be a WG draft and for WG feedback. JP> This a major rework since the previous revision had several sections that had to be reworded or removed (out of the scope). Now the draft is much better scoped. Show of hand on who read the doc. Very good. Who in favor; Good support. Anyone in opposition? No one opposed. Good support, we will confirm on the list. 5) Update on Path Computation Element (PCE) Communication Protocol (PCEP) draft-ietf-pce-pcep-02.txt (JL Le Roux - 10mn) Major update to this version is addition of the FSM. JL described the FSM. JL Asked for WG feedback especially on the recent updates. JP> We had some discussion on scoping of this document and the goal here is to freeze PCEP document changes at this stage to consolidate the basics before adding further extensions. There are 3-4 on going implementation. We would like to get interops results hopefully before LC. Adrian> The protocol spec is reaching a level of stability, on going implementations may find some holes. Dimitri asked for clarification on usage of P/ I flag. JL> this is clearly stated in the document. JP asked for more discussions on the Mailing List. Richard Rabat asked for some explanation on potential race condition on Two TCP connection requests at the same time. Explanation was provided. Adrian/JP suggested extensive WG review on the next revision. 6) Update on PCE Discovery protocol - draft-ietf-pce-disco-proto-igp-02.txt (Jean-Louis Le Roux - 10mn) JL> Requirement ID is stable and in final stage. JP: There is an implementation. JL requested WG LC. JP asked Ross (AD) for feedback on splitting the document into two: one for ISIS and one for OSPF. Ross> What are the possible deltas; if this doc is 40 pages, will we end up with two doc of 35 pages, each? JP> Delta is small, e.g., semantics are common. We expect two doc of approx. 25 pages each. Lou> There has to be two documents; when we claim implementations for the RFC-es, implementing for one protocol cannot claim implementation for other protocols. Ross> This is a good reason for the split. Makes more sense to Split. JL> Shall we make changes and do the split at the end? Or shall we split now. JP> Splitting at the very end makes more sense. Adrian> Split also makes it easier to do cross WG review easier. Emile Stefan> Split will impact the MIB document and lead to some duplicate work. Adrian> We have done similar split for the GMPLS Signaling Document in the past. Emile still showed concerns. Adrian asked to talk more off-line. 7) Definitions of Managed Objects for Path Computation Element Discovery Protocol (PCEDP) inside a Path Computation Client (PCC) draft-stephan-pce-pcedp-pcc-mib-00 JL> Congestion seems to be for PCE and not PCC MIB modules. Adrian> We should not flood the notification process. Adrian suggested moving textual conventions to a separate document and MIB module so they can be re-used. Emile brought up the point that have a new MIB module RFC for two textual convention might be a bit strange but Adrian pointed out this was fine and more textual conventions are still coming. Adrian asked that since the PCE might discover other PCE's in the same domain why not run the MIB module on the PCE. Emile commented that this scenario was possible and not excluded by his ID. JL commented that a PCC can run the MIB module. Adrian> Have you considered how this should or should not hook in to the IGP MIBs? Emile commented that not really although he was following the IGP MIBS closely and his MIBS are neutral with respect to the IGP protocol. Not requested to become a WG document. JL> splitting in two document should be started out pretty soon. Emile thinks MIB should be mandatory for protocol specifications. Its better done by protocol owner since they know exactly what to watch. JP> You did not ask the WG to take this as a WG doc. It will be a nice target to have protocol document and the MIB document together. No one objected. 8) Update on "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths" - draft-vasseur-pce-brpc-01.txt (JP Vasseur - 5mn) JP> This ID has a long history (presented and discussed many times). Implementation already exists; so only expect the editorial changes. Next steps is to add more details such as path diversity, GMPLS support and manageability. JP requested to adopt the ID as a WG document. Adrian> We will poll the WG (on the list). 9) Update on Inter-Layer Traffic Engineering (Eiji Oki - 10mn) - drat-ietf-pce-inter-layer-frwk-01.txt - draft-ietf-pce-inter-layer-req-02.txt 10) Definition of Virtual Network Topology Manager (VNTM) for PCE-based Inter-Layer MPLS and GMPLS Traffic Engineering - draft-oki-pce-vntm-def-00.txt (Eiji Oki - 5mn) Eiji Requested for WG feedback/ Q&A. No Q&A. JP> There was NOT much discussion on Multilayer on the mailing list. Please review the documents and provide your feedback. Eiji requested for feedback on these ID-es. Adrian> Are there any open issues with the draft or you only need review comments? Eiji> No open issues, just looking for comments. Dimitri> re: VNT This is not in the context of this WG. This group does not define PCE-VNT communication. PCE WG is only scoped to define PCE-PCC Communiction. JP Agreed. Anything related to VNT manager specification is out of the scope of the WG Dimitri> My comment also applies to VNT definition. Before considering it, we need to discuss the associated tradeoff. E.g., an LSR may communicate directly to VNT and NOT via PCE, which is not in scope of PCE WG. It's not good to have multiple architectures. Adrian> Clearly work to mange inter-layer management is done in CCAMP work. The scope here is to see how VNT fits in the context of PCE. Dimitri> If there is an interaction between VNT and PCE, we never scoped it. Eiji> VNT Manager description is in the context of PCE. Dimitri> On slide 6, what do you mean by lower layer setup? Eiji> PCE judges if lower layer path is needed. Same element is needed to setup a lower layer LSP. Dimitri> It's a policy decision; VNT can be triggered by signaling. Eiji> Framework document describes two triggered methods- Triggered signaling and non-triggered signaling. None-triggered signaling is VNT manager. Dimitri> Need to clearify if/ why VNT Manager should be open IF. Adrian> We are not clear if there is a requirement for a protocol. This is an exploration phase. Dimitri> If only exploration, why is this work not in CCAMP? Adrian> Generic exploration is welcomed in CCAMP, but I cannot force anyone to write an ID. Dimitri> MLN requirements also take into account VNT. JP> Full agreement that this is a exploration phase. There may not be any work needed in PCE. 11) Preserving Topology Confidentiality in Inter-Domain Path Computation and Signaling - draft-bradford-pce-path-key-00.txt (Adrian Farrel - 10mn) Adrian> Rich is the editor. Dimitri> On ERO extension, this work is to be done in CCAMP. Adrian> Yes, we need an ERO subobject, which should be in CCAMP. Lou> Your slide still show encryption as an option. Adrian> This is a typo. This option has been dropped. JL> Push model is to improve LSP setup time, but there is a price to pay as we need to push information to all ASBRs. Adrian> Yes, there is an associated tradeoff. Show of hand who thinks this is a good idea. Any objection to work? Some people thinks it's a good idea. No one objected. Adrian> We take it further to the list. Question (?): How do you identify which PCE generated which path key. Adrian> You encode the originating PCE in the path key. 12) Discussion on Policy-Enabled Path Computation Framework policy-enabled-path-comp - (Igor Bryskin, Lou Berger, Dimitri Papadimitrioui (TB C) - 10mn) Lou asked this doc to be accepted as a WG ID. Adrian asked the room, ~5 hands. Adrian asked for any objection/ if someone thinks it's a bad idea. No one objected. Adrian> We will take it to the list. 13) Framework for the Policy-Based Recovery Mechanism in GMPLS Network - draft-lee-ccamp-pce-policy-recovery-framework-00.txt (Young Lee - 10mn) Dimitri> Did you ask yourself why we worked for four years and did not go into usability of the tools? It's because usability is complex and up to the operator. Why should we do it now? No operator needs it and they told us they have their own tools. All these capabilities are already there and provided within the tools. This is outside the scope. Lee> This recovery policy is in the context of PCE and for communication between PCE and PCC. Lou> What is presented here does not modify the framework of policy within PCE. What is being talked about is a possible application of this framework. Whether it's a good one or now these guys disagree. JL> PCE computes path, it does not allocate bandwidth so why would the PCE need this information? Lee> PCE needs to update DB to mark that bandwidth has been assigned. PCE does not know if the signalling request has gone through. PCE needs accurate link information but agreed that some policy might not be applicable to PCE. Dimitri> Would we also need a provisioning policy. We were focusing the work on path computation and path computation polices. Are we entering into application that will make use the PCE. Second point is the policies were just an agreement within a given recovery domain. It's up to the operator to select the recovery policy for the domain. Igor> We are not taking about recovery policies but rather polices that effect path computation calculations. No updating PCE DB. Dimitri> We are assuming some sequences to be assumed from work on CCAMP. JL> This is a good start for discussion on the mailing list. Lou> We should ask service providers who would like to see this as a WG document. Adrian> Ask for room feed-back: 5 liked to see this as a WG document. Issue will be taken to the mailing list. --Apple-Mail-18-339676536 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 --Apple-Mail-18-339676536-- From pce-bounces@lists.ietf.org Tue Aug 29 18:25:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIC1B-00083r-Be; Tue, 29 Aug 2006 18:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIC0Y-0007gc-T5; Tue, 29 Aug 2006 18:24:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9dZ-0001fX-PH; Tue, 29 Aug 2006 15:52:41 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GI9bU-0002vG-G9; Tue, 29 Aug 2006 15:50:36 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 699B42AC81; Tue, 29 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GI9b0-0001lq-4m; Tue, 29 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 29 Aug 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-interas-pcecp-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) Author(s) : N. Bitar, et al. Filename : draft-ietf-pce-interas-pcecp-reqs-00.txt Pages : 11 Date : 2006-8-29 This document discusses requirements for the support of the Path Computation Element Communication Protocol (PCECP) in inter-AS applications. Its main objective is to present a set of requirements which would result in guidelines for the definition, selection and specification development for any technical solution(s) meeting these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-interas-pcecp-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-interas-pcecp-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-interas-pcecp-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-29132153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-interas-pcecp-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-interas-pcecp-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-29132153.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Thu Aug 31 13:30:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqMV-0000JU-Ar; Thu, 31 Aug 2006 13:29:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqMU-0000JO-9u for pce@ietf.org; Thu, 31 Aug 2006 13:29:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GImtk-00062i-7a for pce@ietf.org; Thu, 31 Aug 2006 09:48:00 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GImtO-0008LM-Qd for pce@ietf.org; Thu, 31 Aug 2006 09:47:41 -0400 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 1GImtK-0004Lu-00 for pce@ietf.org; Thu, 31 Aug 2006 14:47:34 +0100 Received: from your029b8cecfe ([217.158.132.59] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 14:47:34 +0100 Message-ID: <070d01c6cd03$febfb390$89849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Thu, 31 Aug 2006 14:46:37 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 31 Aug 2006 13:47:35.0562 (UTC) FILETIME=[03E636A0:01C6CD04] X-Spam-Score: -2.2 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: nabil.n.bitar@verizon.com, raymond.zhang@bt.infonet.com Subject: [Pce] Fw: I-D ACTION:draft-vasseur-pce-brpc-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, As requested, the authors have updated this I-D to address the comments previously received. This qualifies the I-D to be taken as a WG draft as per the consensus on the list. Authors, please submit as draft-ietf-pce-brpc-00.txt with no changes other than name and date. Thanks, Adrian ----- Original Message ----- From: To: Sent: Wednesday, August 30, 2006 8:50 PM Subject: I-D ACTION:draft-vasseur-pce-brpc-02.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Backward Recursive PCE-based Computation > (BRPC) procedure to compute shortest inter- > domain Traffic Engineering Label Switched Paths > Author(s) : J. Vasseur, et al. > Filename : draft-vasseur-pce-brpc-02.txt > Pages : 16 > Date : 2006-8-30 > > The ability to compute constrained shortest Traffic Engineering (TE) > Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) networks across multiple domains (where > a domain is referred to as a collection of network elements within a > common sphere of address management or path computational > responsibility such as IGP areas and Autonomous Systems) has been > identified as a key requirement . This document specifies a > procedure relying on the use of multiple Path Computation Elements > (PCEs) in order to compute such inter-domain shortest constraint > paths along a determined sequence of domains, using a backward > recursive path computation technique while preserving confidentiality > across domains, which is sometimes required when domains are managed > by different Service Providers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-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-vasseur-pce-brpc-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-vasseur-pce-brpc-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. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@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 From pce-bounces@lists.ietf.org Thu Aug 31 15:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsYU-0001WF-5Z; Thu, 31 Aug 2006 15:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsY6-0000iq-V6; Thu, 31 Aug 2006 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIsY6-0001tB-Lv; Thu, 31 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9D972328E7; Thu, 31 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GIsY6-0007iS-Gl; Thu, 31 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 31 Aug 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-brpc-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter- domain Traffic Engineering Label Switched Paths Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-brpc-00.txt Pages : 16 Date : 2006-8-31 The ability to compute constrained shortest Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-brpc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-brpc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-31113144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-brpc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-brpc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-31113144.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--