Subject: [Pce] I-D Action:draft-ietf-pce-path-key-04.txt

From: [email-masked]
Date: Mon, 17 Nov 2008 05:00:01 -0800 (PST)

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-04.txt
	Pages           : 19
	Date            : 2008-11-17

Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
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 (ASes), 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 ASes 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
AS-internal topology information. This issue may be circumvented
by returning a loose hop and by invoking a new path computation
from the domain boundary Label Switching Router (LSR) during TE
LSP setup as the signaling message enters the second domain, but
this technique has several issues including the problem of
maintaining path diversity.

Bradford, Vasseur and Farrel

[page 1]

draft-ietf-pce-path-key-04.txt

  November 2008

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 TE (RSVP-TE) explicit route object.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC-2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-path-key-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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://www.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Nov 2008 13:07:52 -0000

This new version addresses review comments from GenArt.

The totality of the changes is...

> Section 2.1, paragraph 3:
OLD
   The PKS MUST be preceded by an ERO subobject that
   identifies the LSR that must expand the PKS, so the PKS will not
   be encountered in ERO processing until the LSR that can process
   it.
NEW
   The PKS MUST be preceded by an ERO subobject that
   identifies the LSR that must expand the PKS. This means that
   (following the rules for ERO processing set out in [RFC3209])
   the PKS will not be encountered in ERO processing until the ERO
   is being processed by the LSR that is capable of correctly handling
   the PKS.

> Section 4:
OLD
   The retrieval of the explicit path (the CPS) associated with a PKS
   by a PCC is no different than any other path computation request
   with the exception that the PCReq message MUST contain a PATH_KEY
   object and the Path Key bit of the RP object MUST the set.
NEW
   The retrieval of the explicit path (the CPS) associated with a PKS
   by a PCC is no different than any other path computation request
   with the exception that the PCReq message MUST contain a PATH_KEY
   object and the Path Key bit of the RP object MUST the set. On
   receipt of a PCRep containing a CPS, the requesting PCC SHOULD
   use insert the CPS into the ERO that it will signal, in accordance
   with local policy.

> Section 5, third bullet point in first list:
s/DNS attacks/DoS attacks/

> Section 6.1, paragraphs 2 and 3:
Para 2: yes. Should ref Section 2.1
Para 4: Should ref Section 2.1

> References:
Update references 

Adrian