Subject: [Pce] FW: I-D ACTION:draft-bradford-pce-path-key-00.txt

From: "Rich Bradford \(rbradfor\)" <[email-masked]>
Date: Mon, 19 Jun 2006 20:10:45 -0400

Dear WG members,

Thanks to all on the excellent suggestions about
draft-rbradfor-ccamp-confidential-segment-00.txt. We've uploaded a
streamlined successor which describes just the use of Path Keys (to
replace the confidential path segments in the EROs returned by a PCE and
used for lsp setup).

The changes include:

-          This version focuses exclusively on the use of a Path Key in
the ERO rather using of encryption on segments of the ERO. 

-          Switched this to pce from ccamp since the Path Key solution
has more impact on this wg.

-          The mechanics of using Path Keys has been clarified.

-          Section 4 includes a description of handling multiple PKSs in
the same ERO.

-          An issue was identified regarding Path Key reuse.

-          The security section was expanded.

  The new draft can be found at:

http://www.ietf.org/internet-drafts/draft-bradford-pce-path-key-00.txt

Comments welcomed,

  Rich

Begin forwarded message:

From: [email-masked]

Date: June 16, 2006 6:50:01 PM EDT

To: [email-masked]

Subject: I-D ACTION:draft-bradford-pce-path-key-00.txt 

Reply-To: [email-masked]

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

     Title         : Preserving Topology Confidentiality in Inter-Domain
Path Computation and Signaling 

     Author(s) : R. Bradford, et al.

     Filename  : draft-bradford-pce-path-key-00.txt

     Pages         : 

     Date      : 2006-6-16

   Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) 

   Label Switched Paths (LSPs) may be computed by Path Computation 

   Elements (PCEs). Where the TE LSP crosses multiple domains, such 

   as Autonomous Systems (ASs), the path may be computed by multiple 

   PCEs that cooperate, with each responsible for computing a segment 

   of the path. 

   However, in some cases such as when ASs are administered by 

   separate Service Providers, it would break confidentiality rules 

   for a PCE to supply a path segment to a PCE in another domain, 

   thus disclosing internal topology information. This issue may be 

   circumvented by returning a loose hop and by invoking a new path 

   computation from the domain boundary LSR during TE LSP setup as 

   the LSP enters the second domain, but this technique has several 

   issues including the problem of maintaining path diversity. 

   This document defines a mechanism to hide the contents of a 

   segment of a path, called the Confidential Path Segment (CPS). The 

   CPS may be replaced by a Path Key that can be conveyed in the PCE 

   Communication Protocol (PCEP) and signaled within in a Resource 

   Reservation Protocol (RSVP) explicit route object. 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-bradford-pce-path-key-00.txt

To remove yourself from the I-D Announcement list, send a message to 

[email-masked] 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-bradford-pce-path-key-00.txt".

A list of Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html 

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:

     [email-masked].

In the body type:

     "FILE /internet-drafts/draft-bradford-pce-path-key-00.txt".

NOTE:     The mail server at ietf.org can return the document in

     MIME-encoded form by using the "mpack" utility.  To use this

     feature, insert the command "ENCODING mime" before the "FILE"

     command.  To decode the response(s), you will need "munpack" or

     a MIME-compliant mail reader.  Different MIME-compliant mail
readers

     exhibit different behavior, especially when dealing with

     "multipart" MIME messages (i.e. documents which have been split

     up into multiple messages), so check your local documentation on

     how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader

implementation to automatically retrieve the ASCII version of the

Internet-Draft.

Content-Type: text/plain

Content-ID: <[email-masked]>

_______________________________________________

I-D-Announce mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce