Hello Rich,
Please see in line.
On 5/14/07, Rich Bradford (rbradfor) <[EMAIL PROTECTED]> 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
Best Regards,
Rich
> -----Original Message-----
> From: Peng He [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 11, 2007 6:53 PM
> To: Rich Bradford (rbradfor)
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-path-key-00.txt
>
> 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
>
>
>
>
>
>
>
>
> On 5/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 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 PROTECTED] 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 PROTECTED]
> > In the body type:
> > "FILE et/intern-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 protected]
> > https://www1.ietf.org/mailman/listinfo/pce
> >
> >
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
