Protocol Action: 'Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Preserving Topology Confidentiality in Inter-Domain Path Computation 
   Using a Key-Based Mechanism '
   <draft-ietf-pce-path-key-05.txt> as a Proposed Standard

This document is the product of the Path Computation Element Working 
Group. 

The IESG contact persons are Ross Callon and David Ward.

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

Technical Summary

   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.

   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.

Working Group Summary

   WG has good consensus with no disputes or disagreements. An IPR
   disclosure has been filed, but the WG has decided to proceed with
   this I-D. WG last call issues were limited to editorial and minor
   functional nits.

Document Quality

   The document has been updated in response to Gen-Art comments. The
   responsible AD is not aware of any implementations. 

Personnel

   Adrian Farrel is the Document Shepherd for this document. Ross
   Callon is the responsible Area Director.  

RFC Editor Note

   Please update the title of this document as follows:

     OLD

       Preserving Topology Confidentiality in Inter-Domain
       Path Computation Using a Key-Based Mechanism

     NEW

       Preserving Topology Confidentiality in Inter-Domain
       Path Computation Using a Path-Key-Based Mechanism

   Section 3.1.1, paragraph under "PCE ID", first sentence. Please
   update as follows:

     OLD

       A 32-bit identifier of the PCE that can decode this key.

     NEW

       A 32-bit identifier of the PCE that can decode this path-key.

   Section 3.1.2, paragraph under "PCE ID", first sentence. Please
   update as follows:

     OLD
 
       A 128-bit identifier of the PCE that can decode this key.
 
     NEW

       A 128-bit identifier of the PCE that can decode this path-key.

   Please change every occurance in the document of "path key" to 
   instead be "path-key".

   Please add the following paragraph as the second to last paragraph 
   of section 1 (before section 1.1, and immediately before the one-
   sentence paragraph that begins "The BNF in this document..."): 

     Please note that the term "path-key" used in this document
     refers to an identifier allocated by a PCE to represent a
     segment of a computed path. This term has no relation to the
     term "cryptographic key" used in some documents that describe
     security mechanisms.


IANA Note

   The document defines small protocol enhancements to PCEP (which
   was recently approved by the IESG). This I-D requests further
   allocations from the PCEP registry. The IANA section of this 
   I-D uses the same language as the PCEP specification and, in 
   particular, uses the same sub-registry names.

_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce