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

From: [email-masked]
Date: Wed, 02 May 2007 15:50:02 -0400

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		: Preserving Topology Confidentiality in Inter-Domain Path Computation using a key based mechanism 
	Author(s)	: R. Bradford, et al.
	Filename	: draft-ietf-pce-path-key-00.txt
	Pages		: 
	Date		: 2007-5-2
	
   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 (e.g. 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-ietf-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-ietf-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-ietf-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.
_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Peng He" <[email-masked]>
Date: Fri, 11 May 2007 18:52:49 -0400

Hello Rich,

Regarding your recent draft "Preserving Topology Confidentiality in
Inter-Domain Path Computation using a key based mechanism", Section 3
Path-Key Solution, in the middle of the first paragraph,

"The entry and boundary LSR of
   each CPS SHOULD be specified as hops in the returned path
   immediately preceding the PKS, but where two PKSs are supplied in
   sequence the entry node to the second MAY be encoded within the
   first."

Does that mean you use the number of hops as the only metric to choose
the best inter-AS end-to-end path among the several computed  (by the
cooperation among PCEs) candidate end-to-end paths? Or the only
property of the PKS is the number of hops, no any other TE metrics?

Particularly, "specified as hops in the returned path  immediately
preceding the PKS" What does the "path" here refer to, "sub-path" or
"path segment" , or "end-to-end inter-AS path"?

Thanks,
Peng

---

From: "Rich Bradford \(rbradfor\)" <[email-masked]>
Date: Mon, 14 May 2007 15:42:37 -0400

Hi Peng,

   The number of hops is only one metric. Other TE metrics are still
valid for EROs containing PKSs.

   The term "path" in this context generally refers to the path as
returned by the PCE, but is most relevant to the ERO portion of that
path. A PCE returns a path-list which may contain more than one path.
Each path consists of an ERO optionally followed objects like BANDWIDTH
and METRICS. The presence of a PKS within a particular ERO is
independent of the presence or absence of any metrics associated with
the path.

  Does that answer your question?

  Best Regards,

    Rich

> -----Original Message-----

> From: Peng He [mailto:[email-masked]]

> Sent: Friday, May 11, 2007 6:53 PM

> To: Rich Bradford (rbradfor)

> Cc: [email-masked]

> Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-path-key-00.txt

> > This draft is a work item of the Path Computation Element Working
Group of the

> IETF.

> >         Title           : Preserving Topology Confidentiality in
Inter-Domain Path

> Computation using a key based mechanism

> > You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Peng He" <[email-masked]>
Date: Wed, 16 May 2007 10:46:44 -0400

Hello Rich,

Please see in line.

On 5/14/07, Rich Bradford (rbradfor) <[email-masked]> wrote:
>
>
>
>
> Hi Peng,
> >    The number of hops is only one metric. Other TE metrics are still valid
>>     for EROs containing PKSs.
>

I think this is mainly because path key can be considered as kind of
"label" or "index" with only local meaning. The purpose of it is only
to mask (all of or part of) explicit sequence of nodes within a
PCE-computed path.

There is no particular property with the path key, like TE metrics,
etc. But there are properties WITH the ERO that contains the path
key(s), which should be enough.

>    The term "path" in this context generally refers to the path as returned
> by the PCE, but is most relevant to the ERO portion of that path. A PCE
> returns a path-list which may contain more than one path. Each path consists
> of an ERO optionally followed objects like BANDWIDTH and METRICS. The
> presence of a PKS within a particular ERO is independent of the presence or
> absence of any metrics associated with the path.
>

Agreed.

But I just guess you might need to define/distinguish the "path" and
"end-to-end path" somewhere, especially when taking about
inter-AS/multi-AS path computing, which need close cooperation among
PCEs and each PCE just computes a "segment" of the overall path
actually.

>   Does that answer your question?

Yes.

Thanks,
Peng

> > > This draft is a work item of the Path Computation Element Working Group
> of the
>
> > IETF.
>
> > >
>
> > >         "FILE et/intern-drafts/draft-ietf-pce-path-key-00.txt".
>
> > >
>