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