 1/draftietfpcepcepinterdomainp2mpprocedures04.txt 20130714 14:14:36.856360710 0700
+++ 2/draftietfpcepcepinterdomainp2mpprocedures05.txt 20130714 14:14:36.900361810 0700
@@ 1,57 +1,57 @@
PCE Working Group Q. Zhao
InternetDraft D. Dhody
Intended status: Experimental Huawei Technology
Expires: 15 November 2013 Z. Ali
+Expires: January 14, 2014 Z. Ali
Cisco Systems
D. King
Old Dog Consulting
R. Casellas
CTTC  Centre Tecnologic de
Telecomunicacions de Catalunya
 15 May 2013
+ July 14, 2013
PCEbased Computation Procedure To Compute Shortest Constrained P2MP
Interdomain Traffic Engineering Label Switched Paths
 draftietfpcepcepinterdomainp2mpprocedures04
+ draftietfpcepcepinterdomainp2mpprocedures05
Abstract
The ability to compute paths for constrained pointtomultipoint
(P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across
multiple domains has been identified as a key requirement for the
 deployment of P2MP services in MPLS and GMPLS networks. The Path
 Computation Element (PCE) has been recognized as an appropriate
 technology for the determination of interdomain paths of P2MP TE
 LSPs.
+ deployment of P2MP services in MPLS and GMPLScontrolled networks.
+ The Path Computation Element (PCE) has been recognized as an
+ appropriate technology for the determination of interdomain paths of
+ P2MP TE LSPs.
This document describes an experiment to provide procedures and
extensions to the PCE communication Protocol (PCEP) for the
computation of interdomain paths for P2MP TE LSPs.
Status of This Memo
This InternetDraft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as InternetDrafts. The list of current Internet
Drafts is at http://datatracker.ietf.org/drafts/current/.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
 This InternetDraft will expire on November 15, 2013.
+ This InternetDraft will expire on July 14, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/licenseinfo) in effect on the date of
publication of this document. Please review these documents
@@ 61,79 +61,79 @@
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .3
1.2. Requirements Language . . . . . . . . . . . . . . . . . .3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . .5
 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .7
+ 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .7
 6. Objective Functions . . . . . . . . . . . . . . . . . . . . .8
 7. P2MP Path Computation Procedures . . . . . . . . . . . . . . .9
 7.1. Core Trees . . . . . . . . . . . . . . . . . . . . . . . .9
 7.2. Core Tree Computation Procedures . . . . . . . . . . . . .11
 7.3. Sub Tree Computation Procedures . . . . . . . . . . . . .12
 7.4. PCEP Protocol Extensions . . . . . . . . . . . . . . . . .13
 7.4.1. The Extension of RP Object . . . . . . . . . . . . . .13
 7.4.2. Domain and PCE Sequence . . . . . . . . . . . . . . .14
 7.5. Relationship with Hierarchical PCE . . . . . . . . . . . .14
 7.6. Parallelism . . . . . . . . . . . . . . . . . . . . . . .14
 8. Protection . . . . . . . . . . . . . . . . . . . . . . . . . .15
 8.1. Endtoend Protection . . . . . . . . . . . . . . . . . .15
 8.2. Domain Protection . . . . . . . . . . . . . . . . . . . .15
 9. Manageability Considerations . . . . . . . . . . . . . . . . .15
 9.1. Control of Function and Policy . . . . . . . . . . . . . .15
 9.2. Information and Data Models . . . . . . . . . . . . . . .16
 9.3. Liveness Detection and Monitoring . . . . . . . . . . . .16
 9.4. Verifying Correct Operation . . . . . . . . . . . . . . .16
+ 6. Objective Functions and Constraints. . . . . . . . . . . . . . 8
+ 7. P2MP Path Computation Procedures . . . . . . . . . . . . . . . 8
+ 7.1. Core Trees . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 7.2. Core Tree Computation Procedures . . . . . . . . . . . . .10
+ 7.3. Subtree Computation Procedures . . . . . . . . . . . . .11
+ 7.4. PCEP Protocol Extensions . . . . . . . . . . . . . . . . .12
+ 7.4.1. The Extension of RP Object . . . . . . . . . . . . . .12
+ 7.4.2. Domain and PCE Sequence . . . . . . . . . . . . . . .12
+ 7.5. Relationship with Hierarchical PCE . . . . . . . . . . . .13
+ 7.6. Parallelism . . . . . . . . . . . . . . . . . . . . . . .13
+ 8. Protection . . . . . . . . . . . . . . . . . . . . . . . . . .13
+ 8.1. Endtoend Protection . . . . . . . . . . . . . . . . . .14
+ 8.2. Domain Protection . . . . . . . . . . . . . . . . . . . .14
+ 9. Manageability Considerations . . . . . . . . . . . . . . . . .14
+ 9.1. Control of Function and Policy . . . . . . . . . . . . . .14
+ 9.2. Information and Data Models . . . . . . . . . . . . . . .15
+ 9.3. Liveness Detection and Monitoring . . . . . . . . . . . .15
+ 9.4. Verifying Correct Operation . . . . . . . . . . . . . . .15
9.5. Requirements on Other Protocols and Functional
 Components . . . . . . . . . . . . . . . . . . . . . . . .16
 9.6. Impact on Network Operation . . . . . . . . . . . . . . .17
 9.7. Policy Control . . . . . . . . . . . . . . . . . . . . . .17
 10. Security Considerations . . . . . . . . . . . . . . . . . . .17
 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .18
 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .18
 13. References . . . . . . . . . . . . . . . . . . . . . . . . . .18
 13.1. Normative References . . . . . . . . . . . . . . . . . . .18
 13.2. Informative References . . . . . . . . . . . . . . . . . .18
+ Components . . . . . . . . . . . . . . . . . . . . . . . .15
+ 9.6. Impact on Network Operation . . . . . . . . . . . . . . .16
+ 9.7. Policy Control . . . . . . . . . . . . . . . . . . . . . .16
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . .16
+ 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .17
+ 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .17
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . .17
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . .17
+ 13.2. Informative References . . . . . . . . . . . . . . . . . .17
14. Contributors' Addresses . . . . . . . . . . . . . . . . . . .19
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .19
1. Introduction
Multicast services are increasingly in demand for highcapacity
applications such as multicast Virtual Private Networks (VPNs), IP
television (IPTV) which may be ondemand or streamed, and content
rich media distribution (for example, software distribution,
financial streaming, or databasereplication). The ability to
compute constrained Traffic Engineering Label Switched Paths (TE
LSPs) for pointtomultipoint (P2MP) LSPs in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks across
 multiple domains is therefore required.
+ multiple domains are therefore required.
The applicability of the Path Computation Element (PCE) [RFC4655] for
the computation of such paths is discussed in [RFC5671], and the
requirements placed on the PCE communications Protocol (PCEP) for
this are given in [RFC5862].
This document details the requirements for interdomain P2MP path
computation, it then describes the experimental procedure
"coretree" path computation, developed to address the requirements
and objectives for interdomain P2MP path computation.
1.2. Scope
The interdomain P2MP path computation procedures described in this
 document are experimental. The experiment is intended to enable
+ document is experimental. The experiment is intended to enable
research for the Path Computation Element (PCE) to support
interdomain P2MP path computation.
This document is not intended to replace the intradomain P2MP path
computation approach supported by [RFC6006], and will not impact
existing PCE procedures and operations.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ 146,291 +145,256 @@
MPLS/GMPLS and PCE documents [RFC4461], [RFC4655], [RFC4875],
[RFC5376], [RFC5440], [RFC5441], [RFC5671] and [RFC5862].
ABR: Area Border Router. Router used to connect two IGP domains
(areas in OSPF or levels in ISIS).
ASBR: Autonomous System Border Router. Router used to connect
together ASes of the same or different Service Providers via one or
more InterAS links.
 Boundary Node (BN): a boundary node is either an ABR in the context
+ Boundary Node (BN): is either an ABR in the context
of interarea Traffic Engineering or an ASBR in the context of
interAS Traffic Engineering.
 Core Tree: the core tree is a P2MP tree where the root is the ingress
+ Core Tree: a P2MP tree where the root is the ingress
LSR, and the leaf nodes are the entry BNs of the leaf domains.
Domain: a collection of network elements within a common sphere of
address management or path computational responsibility such as an
IGP area or an Autonomous System (AS).
Entry BN of domain(n): a BN connecting domain(n1) to domain(n) along
a determined sequence of domains.
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along
a determined sequence of domains.
Leaf Domain: a domain with one or more leaf nodes.
 Leaf Boundary Nodes: the entry boundary node in the leaf domain.

 LSR: Label Switching Router.

 LSP: Label Switched Path.

 OF: Objective Function. A set of one or more optimization criterion
+ OF: Objective Function. a set of one or more optimization criterion
(criteria) used for the computation of paths either for single or for
synchronized requests (e.g. path cost minimization), or the
synchronized computation of a set of paths (e.g. aggregate bandwidth
consumption minimization, etc.). See [RFC4655] and [RFC5541].
 P2MP LSP Path Tree: A set of LSRs and TE links that comprise the path
 of a P2MP TE LSP from its ingress LSR to all of its egress LSRs.
+ Path Tree: a set of LSRs and TE links that comprise the path
+ of a P2MP TE LSP from the ingress LSR to all egress LSRs.
 Path Domain Sequence: The known sequence of domains for a path
+ Path Domain Sequence: the known sequence of domains for a path
between root and leaf.
 Path Domain Tree: The tree formed by the domains that the P2MP path
+ Path Domain Tree: the tree formed by the domains that the P2MP path
crosses, where the source (ingress) domain is the root domain.
 PCC: Path Computation Client. Any client application requesting a
 path computation to be performed by the Path Computation Element.

 PCE (Path Computation Element): an entity (component, application or
 network node) that is capable of computing a network path or route
 based on a network graph and applying computational constraints.

PCE(i): a PCE that performs path computations for domain(i).
Root Domain: the domain that includes the ingress (root) LSR.
 TED: Traffic Engineering Database.
+ Subtree: used to minimize packet duplication when P2P
+ TE subLSPs traverse common links.
Transit/branch Domain: a domain that has an upstream and one or more
 downstream neighbour domain.
+ downstream neighbor domain.
+
VSPT: Virtual Shortest Path Tree [RFC5441].
3. Problem Statement
The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a
network graph, and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be
computed.
[RFC4875] describes how to set up P2MP TE LSPs for use in MPLS and
 GMPLS networks. The PCE is identified as a suitable application for
 the computation of paths for P2MP TE LSPs [RFC5671].
+ GMPLScontrolled networks. The PCE is identified as a suitable
+ application for the computation of paths for P2MP TE LSPs [RFC5671].
[RFC5441] specifies a procedure relying on the use of multiple PCEs
to compute (P2P) interdomain constrained shortest paths across a
predetermined sequence of domains, using a Backward Recursive Path
Computation (BRPC) technique. The technique can be combined with the
use of path keys [RFC5520] to preserve confidentiality across
domains, which is sometimes required when domains are managed by
different Service Providers.
The PCE communication Protocol (PCEP) [RFC5440] is extended for
pointtomultipoint(P2MP) path computation requests in [RFC6006].
However, [RFC6006] does not provide the necessary mechanisms and
procedures to request the computation of interdomain P2MP TE LSPs.
As discussed in [RFC4461], a P2MP tree is a graphical representation
 of all TE links that are committed for a particular P2MP LSP. In
+ of all TE links that are committed for a particular P2MP TE LSP. In
other words, a P2MP tree is a representation of the corresponding
 P2MP tunnel on the TE network topology. A subtree is a part of the
 P2MP tree describing how the root or an intermediate P2MP LSPs
 minimizes packet duplication when P2P TE subLSPs traverse common
+ P2MP tunnel on the TE network topology. A subtree is used to
+ minimize packet duplication when P2P TE subLSPs traverse common
links. As described in [RFC5671] the computation of a P2MP tree
requires three major pieces of information. The first is the path
 from the ingress LSR of a P2MP LSP to each of the egress LSRs, the
+ from the ingress LSR of a P2MP TE LSP to each of the egress LSRs, the
second is the traffic engineering related parameters, and the third
is the branch capability information.
Generally, an interdomain P2MP tree (i.e., a P2MP tree with source
and at least one destination residing in different domains) is
particularly difficult to compute even for a distributed PCE
 architecture. For instance, while the BRPC recursive path
 computation may be wellsuited for P2P paths, P2MP path computation
 involves multiple branching path segments from the source to the
 multiple destinations. As such, interdomain P2MP path computation
 may result in a plurality of perdomain path options that may be
 difficult to coordinate efficiently and effectively between domains.
+ architecture. For instance, while the BRPC may be wellsuited for
+ P2P paths, P2MP path computation involves multiple branching path
+ segments from the source to the multiple destinations. As such,
+ interdomain P2MP path computation may result in a plurality of
+ perdomain path options that may be difficult to coordinate
+ efficiently and effectively between domains.
That is, when one or more domains have multiple ingress and/or egress
 border nodes, there is currently no known technique for one domain to
 determine which border routers another domain will utilize for the
 interdomain P2MP tree, and no way to limit the computation of the
 P2MP tree to those utilized border nodes.
+ boundary nodes, there is currently no known technique for one domain
+ to determine which boundary node of another domain will be utilized
+ for the interdomain P2MP tree, and no way to limit the computation
+ of the P2MP tree to those utilized boundary nodes.
A trivial solution to the computation of interdomain P2MP tree would
be to compute shortest interdomain P2P paths from source to each
destination and then combine them to generate an interdomain,
shortestpathtodestination P2MP tree. This solution, however,
cannot be used to trade cost to destination for overall tree cost
(i.e., it cannot produce a Minimum Cost Tree (MCT)) and in the
 context of inter domain P2MP LSPs it cannot be used to reduce the
 number of domain border nodes that are transited.
+ context of inter domain P2MP TE LSPs it cannot be used to reduce the
+ number of domain boundary nodes that are transited. Computing P2P TE
+ LSPs individually is not an acceptable solution for computing a P2MP
+ tree.
 Computing P2P LSPs individually is not an acceptable solution for
 computing a P2MP tree. Even per domain path computation [RFC5152]
+ Even per domain path computation [RFC5152]
can be used to compute P2P multidomain paths, but it does not
guarantee to find the optimal path which crosses multiple domains.
Furthermore, constructing a P2MP tree from individual source to leaf
 P2P LSPs does not guarantee to produce a leastcost tree. This
 approach may also be considered to have scaling issues during LSP
 setup. That is, the LSP to each leaf is signaled separately, and
 each border node must perform path computation for each leaf.
+ P2P TE LSPs does not guarantee to produce a Minimum Cost Tree (MCT).
+ This approach may also be considered to have scaling issues during
+ LSP setup. That is, the LSP to each leaf is signaled separately, and
+ each boundary node must perform path computation for each leaf.
P2MP Minimum Cost Tree (MCT), i.e. a computation which guarantees the
least cost resulting tree, is an NPcomplete problem. Moreover,
adding and/or removing a single destination to/from the tree may
result in an entirely different tree. In this case, frequent MCT
path computation requests may prove computationally intensive, and
the resulting frequent tunnel reconfiguration may even cause network
destabilization.
 This document presents a solution, and procedures and extensions to
+ This document presents a solution, procedures and extensions to
PCEP to support P2MP interdomain path computation.
4. Assumptions
 It is assumed that, due to deployment and commercial limitations
 (e.g., interAS peering agreements), the sequence of domains for a
 path (the path domain tree) will be known in advance.

 [DOMAINSEQ] describes the use of domain path tree in P2MP scenarios.
 In the figure below, the P2MP tree spans 6 domains, with D1 being the
 root domain. The corresponding domain sequences which are assumed
 known would be: D1D3D6, D1D3D5 and D1D2D4.

 D1
 / \
 D2 D3
 / / \
 D4 D5 D6

 Figure 1: Domain Sequence Tree

 The examples and scenarios used in this document are also based on
 the following assumptions:
+ Within this document we make the following assumptions:
 o PCC is either aware of the domain sequence for each of the P2MP
 destination as described in [DOMAINSEQ] or PCE sequence (i.e.
 PCE that serves each domain in the path domain tree). The set of
 PCEs and their relationships is propagated to each PCE during the
 first exchange of path computation requests.
+ o Due to deployment and commercial limitations (e.g., interAS
+ peering agreements), the path domain tree will be known in
+ advance;
o Each PCE knows about any leaf LSRs in the domain it serves;
 o The boundary nodes to use on the LSP are predetermined. In this
 document we do not consider multihomed domains.

 Additional assumptions are documented in [RFC5441] and will not be
 repeated here.
+ Additional assumptions are documented in [RFC5441] and will
+ not be repeated here.
5. Requirements
This section summarizes the requirements specific to computing inter
domain P2MP paths. In these requirements we note that the actual
 computation times by any PCE implementation are outside the scope of
 this document, but we observe that reducing the complexity of the
+ computation time taken by any PCE implementation is outside the scope
+ of this document, but we observe that reducing the complexity of the
required computations has a beneficial effect on the computation time
regardless of implementation. Additionally, reducing the number of
message exchanges and the amount of information exchanged will reduce
the overall computation time for the entire P2MP tree. We refer to
 the "Complexity of the computation" as the impact on these aspects of
+ the "complexity of the computation" as the impact on these aspects of
path computation time as various parameters of the topology and the
 P2MP LSP are changed.
+ P2MP TE LSP are changed.
 Its also important that the solution preserves confidentiality across
 domains, which is required when domains are managed by different
 Service Providers.
+ It is also important that the solution preserves confidentiality
+ across domains, which is required when domains are managed by
+ different Service Providers.
 Other than the requirements specified in [RFC5376], a number of
+ Other than the requirements specified in [RFC5862], a number of
requirements specific to P2MP are detailed below:
 1. The computed P2MP LSP should be optimal when only considering the
 paths among the BNs.
+ 1. The computed P2MP TE LSP SHOULD be optimal when only considering
+ the paths among the BNs.
 2. Grafting and pruning of multicast destinations in a domain should
+ 2. Grafting and pruning of multicast destinations in a domain SHOULD
have no impact on other domains and on the paths among BNs.
3. The complexity of the computation for each subtree within each
 domain should be dependent only on the topology of the domain and
 it should be independent of the domain sequence.
+ domain SHOULD be dependent only on the topology of the domain and
+ it SHOULD be independent of the domain sequence.
 4. The number of PCEP request and reply messages should be
 independent of the number of multicast destinations in each
 domain.
+ 4. The number of PCReq and PCReq messages SHOULD be independent of
+ the number of multicast destinations in each domain.
 5. Specifying the domain entry and exit nodes.
+ 5. It SHOULD be possible to specify the domain entry and exit nodes.
 6. Specifying which nodes should be used as branch nodes.
+ 6. Specifying which nodes are be used as branch nodes SHOULD be
+ supported.
 7. Reoptimization of existing subtrees.
+ 7. Reoptimization of existing subtrees SHOULD be supported.
 8. Computation of P2MP paths that need to be diverse from existing
+ 8. It SHOULD be possible to compute diverse P2MP paths from existing
P2MP paths.
6. Objective Functions
+6. Objective Functions and Constraints
For the computation of a single or a set of P2MP TE LSPs, a request
to meet specific optimization criteria, called an Objective Function
 (OF) may be indicated.
+ (OF), may be used. Using an OF to select the "best" candidate path,
+ include:
 The computation of one or more P2MP TELSPs may be subject to an OF
 in order to select the "best" candidate paths. A variety of
 objective functions have been identified as being important during
 the computation of interdomain P2MP LSPs. These include:
+ o The subtree within each domain SHOULD be optimized using minimum
+ cost tree [RFC5862], or shortest path tree [RFC5862].
 1. The subtree within each domain should be optimized, which can be
 either the Minimum cost tree [RFC5862] or Shortest path tree
 [RFC5862].
+ In addition to the OFs, the following constraint optimization may
+ also be beneficial for P2MP path computation:
 2. The P2MP LSP path, formed by considering only the entry and exit
 nodes of the domains (the Core Tree) should be optimal.
+ 1. The core tree SHOULD be optimal.
 3. It should be possible to limit the number of entry points to a
+ 2. It SHOULD be possible to limit the number of entry points to a
domain.
 4. It should be possible to force the branches for all leaves within
+ 3. It SHOULD be possible to force the branches for all leaves within
a domain to be in that domain.
+ 4. It SHOULD be possible to combine the aforementioned OFs and
+ constraints for P2MP path computation.
+
+ The algorithms used to compute optimal paths using a combination of
+ OFs and multiple constraints is out of scope of this document.
+
7. P2MP Path Computation Procedures
 The following sections describe the Core Tree based procedures to
+ The following sections describe the core treebased procedures to
satisfy the requirements specified in the previous section. A core
 tree based solution provides an optimal interdomain P2MP TE LSP.
+ treebased solution provides an optimal interdomain P2MP TE LSP.
7.1. Core Trees
 A Core Tree is defined as a tree, which satisfies the following
+ A core tree is defined as a tree that satisfies the following
conditions:
o The root of the core tree is the ingress LSR in the root domain;
o The leaves of the core tree are the entry nodes in the leaf
 domains;

 Note that PathKey Mechanism [RFC5520] MAY be used to hide internal
 nodes.
+ domains.
 An optimal coretree [based on the OF] will be computed with
 analyzing the nodes and links within the domains. To support
 confidentiality the same nodes and links can be hidden via a pathkey
 but they must be computed and be a part of coretree.
+ To support confidentiality these nodes and links may be hidden using
+ the pathkey mechanism [RFC5520], but they MUST be computed and be a
+ part of coretree.
 For example, consider the Domain Tree in Figure 2 below,
+ For example, consider the Domain Tree in Figure 1 below,
representing a domain tree of 6 domains, and part of the resulting
 Core Tree which satisfies the aforementioned conditions.
+ core tree which satisfies the aforementioned conditions.
++
 Domain D1
 R 
 
 A 
 
+BC+
/ \
/ \
@@ 451,198 +415,191 @@
/ / \
/ Domain D4 Domain D5 / Domain D6 \
+L+ +P+ +T+
     
   Q   U 
 M O   S   
     V 
 N   R   
++ ++ ++
 Figure 2: Domain Tree Example
+ Figure 1: Domain Tree Example
(R)

(A)
/ \
/ \
(B) (C)
/ \
/ \
(D) (E)
/ 
/ 
(G) (H)
/ / \
/ / \
(I) (J) (K)
/ / \
/ / \
(L) (P) (T)
 Figure 3: Core Tree
+ Figure 2: Core Tree
A core tree is computed such that root of the tree is R and the leaf
node are the entry nodes of the destination domains (L, P and T).
 Pathkey Mechanism can be used to hide the internal nodes and links
+ Pathkey mechanism can be used to hide the internal nodes and links
in the final core tree.
7.2. Core Tree Computation Procedures
The algorithms to compute the optimal large core tree are outside
 scope of this document. The following extended BRPC based procedure
+ scope of this document. The following extended BRPCbased procedure
can be used to compute the core tree.
 BRPC Based Core Tree Path Computation Procedure:
+ A BRPCbased core tree path computation procedure is described below:
1. Using the BRPC procedures to compute the VSPT(i) for each leaf
BN(i), i=1 to n, where n is the total number of entry nodes for
all the leaf domains. In each VSPT(i), there are a number of
P(i) paths.
2. When the root PCE has computed all the VSPT(i), i=1 to n, take
 one path from each VSPT and form a set of paths, we call it a
 PathSet(j), j=1 to M, where M=P(1)xP(2)...xP(n);
+ one path from each VSPT and form all possible sets of paths, we
+ call them PathSet(j), j=1 to M, where M=P(1)xP(2)...xP(n);
3. For each PathSet(j), there are n S2L (Source to Leaf BN) paths
 and form these n paths into a Core Tree(j);
+ and form these n paths into a core tree(j);
 4. There will be M number of Core Trees computed from step3. Apply
 the OF to each of these M Core Trees and find the optimal Core
+ 4. There will be M number of core trees computed from step3. Apply
+ the OF to each of these M core trees and find the optimal Core
Tree.
 Note that, since point to point, BRPC procedure is used to compute
 VSPT, the path request and response message is as per [RFC5440] is
+ Note that, since point to point BRPC procedure is used to compute
+ VSPT, the path request and response messages as per [RFC5440] are
used.
Also note that the application of BRPC in the aforementioned
procedure differs from the typical one since paths returned from a
 downstream PCE are not necessary pruned from the solution set by
 intermediate PCEs.

 The reason for this is that if the PCE in a downstream domain does
 the pruning and returns the single optimal subpath to its parent
 PCE, BRPC insures that the ingress PCE will get all the best optimal
 subpaths for each LN (Leaf Border Nodes), but the combination of
 these single optimal subpaths into a P2MP tree is not necessarily
 optimal even if each S2L (SourcetoLeaf) subpath is optimal.
+ downstream PCE are not necessarily pruned from the solution set by
+ intermediate PCEs. The reason for this is that if the PCE in a
+ downstream domain does the pruning and returns the single optimal
+ subpath to the upstream PCE, BRPC insures that the ingress PCE will
+ get all the best optimal subpaths for each LN (Leaf Boundary
+ Nodes), but the combination of these single optimal subpaths into
+ a P2MP tree is not necessarily optimal even if each S2L
+ (SourcetoLeaf) subpath is optimal.
 Without trimming, the ingress PCE will get all the possible S2L sub
 paths set for LN, and eventually by looking through all the
 combinations, and taking one subpath from each set to built one P2MP
 tree it finds the optimal tree.
+ Without trimming, the ingress PCE will obtain all the possible S2L
+ subpaths set for LN. The PCE will then, by looking through all
+ the combinations and taking one subpath from each set to build one
+ P2MP tree, can find the optimal tree.
 PCE MAY consider to also add equal cost paths in its domain while
 constructing extended VSPT. This way ingress PCE will have more
 options for an optimal P2MP tree.
+ A PCE MAY add equal cost paths within the domain while constructing
+ an extended VSPT. This will provide the ingress PCE more candidate
+ paths for an optimal P2MP tree.
The proposed method may present a scalability problem for the dynamic
 computation of the Core Tree (by iterative checking of all
+ computation of the core tree (by iterative checking of all
combinations of the solution space), specially with dense/meshed
domains. Considering a domain sequence D1, D2, D3, D4, where the
 Leaf border node is at domain D4, PCE(4) will return 1 path. PCE(3)
 will return N paths, where N is E(3) x X(3), where E(k) x X(k)
+ Leaf Boundary Node is at domain D4, PCE(4) will return 1 path.
+ PCE(3) will return N paths, where N is E(3) x X(3), where E(k) x X(k)
denotes the number of entry nodes times the number of exit nodes for
that domain. PCE(2) will return M paths, where M = E(2) x X(2) x N =
E(2) x X(2) x E(3) x X(3) x 1, etc. Generally speaking the number of
potential paths at the ingress PCE Q = \prod E(k) x X(k).
Consequently, it is expected that the Core Path will be typically
computed offline, without precluding the use of dynamic, online
mechanisms such as the one presented here, in which case it SHOULD be
possible to configure transit PCEs to control the number of paths
sent upstream during BRPC (trading trimming for optimality at the
point of trimming and downwards).
7.3. Sub Tree Computation Procedures
+7.3. Subtree Computation Procedures
Once the core tree is built, the grafting of all the leaf nodes from
each domain to the core tree can be achieved by a number of
algorithms. One algorithm for doing this phase is that the root PCE
 will send the request with C bit set for the path computation to the
 destination(s) directly to the PCE where the destination(s) belong(s)
 along with the core tree computed from the phase 1.
+ will send the request with C bit set (as defined in section 7.4.1 of
+ this document) for the path computation to the destination(s)
+ directly to the PCE where the destination(s) belong(s) along with the
+ core tree computed from section 7.1.
This approach requires that the root PCE manage a potentially large
number of adjacencies (either in persistent or nonpersistent mode),
including PCEP adjacencies to PCEs that are not within neighbor
domains.
A first alternative would involve establishing PCEP adjacencies that
correspond to the PCE domain tree. This would require that branch
PCEs forward requests and responses from the root PCE towards the
leaf PCEs and viceversa.
Note that the P2MP path request and response format is as per
[RFC6006], where Record Route Object (RRO) are used to carry the
coretree paths in the P2MP grafting request.
 Finally, another alternative would be to use a hierarchical PCE
 [RFC6805] architecture. The "hierarchical" parent PCE would request
 sub tree path computations.

 The algorithms to compute the optimal large sub tree are outside
 scope of this document. In the case that the number of destinations
 and the number of BNs within a domain are not big, the incremental
 procedure based on p2p path computation using the OSPF can be used.
+ The algorithms to compute the optimal large subtree are outside
+ scope of this document.
7.4. PCEP Protocol Extensions
7.4.1. The Extension of RP Object
This experiment will be carried out by extending the RP (Request
Parameters) object (defined in [RFC5440]) used in Path Request and
Reply messages.
The extended format of the RP object body to include the C bit is as
follows:
The C bit is added in the flag bits field of the RP object to signal
the receiver of the message that the request/reply is for inter
 domain P2MP Core Tree or not.
+ domain P2MP core tree or not.
The following flag is added in this draft:
C bit ( P2MP Core Tree bit  1 bit):
0: This indicates that this is normal PCReq/PCRrep for P2MP.
1: This indicates that this is PCReq or PCRep message for inter
 domain Core Tree P2MP. When the C bit is set, then the request
 message should contain the Core Tree passed along with the
+ domain core tree P2MP. When the C bit is set, then the request
+ message MUST contain the core tree passed along with the
destinations to be grafted to the tree.
7.4.2. Domain and PCE Sequence
The procedure as described in this document requires the domaintree
 to be known in advance. [DOMAINSEQ] describes the representation of
 domains in P2MP scenarios. Some situations may prefer the use of PCE
 sequence rather than the domainsequence.
+ to be known in advance. This information may be provided dynamically
+ as documented in the Hierarchical PCE (HPCE) [RFC6805] framework, or
+ obtained through the IGP/BGP routing information.
 The PCE MAY get this information dynamically via procedures like
 Hierarchical PCE [RFC6805] or they may be configured by an
 administrator, either way these mechanism are out of scope of this
 document.
+ [DOMAINSEQ] describes the representation of domain in P2MP
+ scenarios. The use of PCE sequence rather than domainsequence, is
+ based on deployment and implementation preference.
7.5. Relationship with Hierarchical PCE
+7.5. Using HPCE for Scalability
 The actual grafting of subtrees into the MultiDomain tree needs to
 be carried out by the source node. This means that the source node
 needs to get the computed subtrees from all the involved domains.
 This requires that the source node either has a PCEP session with all
 the PCEs, or PCEP messages are routed via the PCEP sessions. This
 may mean an excessive number of sessions or an added complexity in
 implementations.
+ The ingress/root PCE is responsible for the grafting of subtrees
+ into the multidomain tree. Therefore, the ingress/root PCE will
+ receive all computed subtrees from all the involved domains. This
+ will require the ingress/root PCE to have a PCEP session with all
+ PCEs providing subtrees. This may cause an excessive number of
+ sessions or added complexity in implementations.
 Alternatively, one may use an architecture based on the concept of
 hierarchical PCE [RFC6805]. The parent PCE would be responsible to
 request intradomain subtrees to the PCEs, combine them and return
 the overall P2MP tree.
+ The use of the HPCE framework [RFC6805] may be used to establish a
+ dedicated PCE with the capability (memory and CPU) and knowledge to
+ maintain the necessary PCEP sessions. The parent PCE would be
+ responsible to request intradomain subtrees to the PCEs, combine
+ them and return the overall P2MP tree.
7.6. Parallelism
In order to minimize latency in path computation in multidomain
networks, intradomain path segments and intradomain subtrees
SHOULD be computed in parallel when possible. The proposed
procedures in this draft present opportunities for parallelism:
1. The BRPC procedure for each leaf node can be launched in parallel
by the ingress/root PCE if the dynamic computation of the Core
@@ 653,47 +610,47 @@
One of the potential issues of parallelism is that the ingress PCE
would require a potentially high number of PCEP adjacencies to
"remote" PCEs and that may not be desirable, but a given PCE would
only receive requests for the destinations that are in its domain (+
the core nodes), without PCEs forwarding requests.
8. Protection
It is envisaged that protection may be required when deploying and
 using interdomain P2MP LSPs. The procedures and mechanisms defined
 in this document do not prohibit the use of existing and proposed
 types of protection, including: endtoend protection [RFC4875] and
 domain protection schemes.
+ using interdomain P2MP TE LSPs. The procedures and mechanisms
+ defined in this document do not prohibit the use of existing and
+ proposed types of protection, including: endtoend protection
+ [RFC4875] and domain protection schemes.
Segment or facility (link and node) protection is problematic in
interdomain environment due to the limit of Fastreroute (FRR)
[RFC4875] requiring knowledge of its nexthop across domain
boundaries whilst maintaining domain confidentiality. Although the
FRR protection might be implemented if nexthop information was known
in advance.
8.1. Endtoend Protection
 Endtoend protection (Node and Link Protection) principle can be
 applied for computing backup P2MP LSP. During computation of Core
 Tree and SubTree, endtoend protection can be taken into
 consideration. PCE may compute the Primary and backup P2MP LSP
 together or sequentially.
+ An endtoend protection (for nodes and links) principle can be
+ applied for computing backup P2MP TE LSPs. During computation of the
+ coretree and subtrees, may also be taken into consideration. A
+ PCE may compute the primary and backup P2MP TE LSP together or
+ sequentially.
8.2. Domain Protection
In this protection scheme, backup P2MP Tree can be computed which
excludes the transit/branch domain completely. A backup domain path
tree is needed with the same source domain and destinations domains
 and a new set of transit domains. The backup domain path tree can be
 applied to the above procedure to obtain the backup P2MP LSP with
+ and a new set of transit domains. The backup path tree can be
+ applied to the above procedure to obtain the backup P2MP TE LSP with
disjoint transit domains.
9. Manageability Considerations
[RFC5862] describes various manageability requirements in support of
P2MP path computation when applying PCEP. This section describes how
manageability requirements mentioned in [RFC5862] are supported in
the context of PCEP extensions specified in this document.
Note that [RFC5440] describes various manageability considerations in
@@ 718,23 +675,20 @@
9.2. Information and Data Models
A number of MIB objects have been defined for general PCEP control
and monitoring of P2P computations in [PCEPMIB]. [RFC5862]
specifies that MIB objects will be required to support the control
and monitoring of the protocol extensions defined in this document.
[PCEPP2MPMIB] describes managed objects for modeling of PCEP
communications between a PCC and PCE, and PCE to PCE, P2MP path
computation requests and responses.
 In case of offline Core tree computation and configuration MAYBE
 stored.

9.3. Liveness Detection and Monitoring
No changes are necessary to the liveness detection and monitoring
requirements as already embodied in [RFC4657].
It should be noted that multidomain P2MP computations are likely to
take longer than P2P computations, and single domain P2MP
computations. The liveness detection and monitoring features of the
PCEP SHOULD take this into account.
@@ 745,21 +699,21 @@
verification of the correct operation of the PCE and its algorithms
is out of scope for the protocol requirements, but a PCC MAY send the
same request to more than one PCE and compare the results.
9.5. Requirements on Other Protocols and Functional Components
A PCE operates on a topology graph that may be built using
information distributed by TE extensions to the routing protocol
operating within the network. In order that the PCE can select a
suitable path for the signaling protocol to use to install the P2MP
 LSP, the topology graph must include information about the P2MP
+ TE LSP, the topology graph MUST include information about the P2MP
signaling and branching capabilities of each LSR in the network.
Mechanisms for the knowledge of other domains, the discovery of
corresponding PCEs and their capabilities should be provided and that
this information MAY be collected by other mechanisms.
Whatever means is used to collect the information to build the
topology graph, the graph MUST include the requisite information. If
the TE extensions to the routing protocol are used, these SHOULD be
as described in [RFC5073].
@@ 767,29 +721,29 @@
9.6. Impact on Network Operation
The use of a PCE to compute P2MP paths is not expected to have
significant impact on network operations. However, it should be
noted that the introduction of P2MP support to a PCE that already
provides P2P path computation might change the loading of the PCE
significantly, and that might have an impact on the network behavior,
especially during recovery periods immediately after a network
failure.
 The dynamic computation of Core Trees might also have an impact on
+ The dynamic computation of core trees might also have an impact on
the load of the involved PCEs as well as path computation times.
9.7. Policy Control
[RFC5394] provides additional details on policy within the PCE
architecture and also provides context for the support of PCE Policy.
 The are also applicable to Interdomain P2MP Path computation via
 Core Tree mechanism.
+ They are also applicable to Interdomain P2MP Path computation via
+ the core tree mechanism.
10. Security Considerations
As described in [RFC5862], P2MP path computation requests are more
CPUintensive and also utilize more link bandwidth. In the event of
an unauthorized P2MP path computation request, or a denial of service
attack, the subsequent PCEP requests and processing may be disruptive
to the network. Consequently, it is important that implementations
conform to the relevant security requirements of [RFC5440] that
specifically help to minimize or negate unauthorized P2MP path
@@ 803,46 +757,57 @@
message is intact and sent from an authorized node (Section 10.3
of [RFC5440]).
o Providing policy control by explicitly defining which PCCs, via IP
accesslists, are allowed to send P2MP path requests to the PCE
(Section 10.6 of [RFC5440]).
PCEP operates over TCP, so it is also important to secure the PCE and
PCC against TCP denial of service attacks. Section 10.7.1 of
[RFC5440] outlines a number of mechanisms for minimizing the risk of
 TCP based denial of service attacks against PCEs and PCCs.
+ TCPbased denial of service attacks against PCEs and PCCs.
PCEP implementations SHOULD also consider the additional security
provided by the TCP Authentication Option (TCPAO) [RFC5925].
11. IANA Considerations
Due to the experimental status of this document. No IANA
considerations have been requested.
12. Acknowledgements
 The authors would like to thank Adrian Farrel, Dan Tappan and Olufemi
 Komolafe for their valuable comments on this document.
+ The authors would like to thank Adrian Farrel, Dan Tappan, Olufemi
+ Komolafe, Oscar Gonzalez de Dios and Julien Meuric for their
+ valuable comments on this document.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation
Element (PCE) Communication Protocol (PCEP)",
RFC 5440, March 2009.
+ [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux,
+ "A BackwardRecursive PCEBased Computation (BRPC)
+ Procedure to Compute Shortest Constrained Inter
+ Domain Traffic Engineering Label Switched Paths",
+ RFC 5441, April 2009.
+
+ [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
+ Objective Functions in the Path Computation Element
+ Communication Protocol (PCEP)", RFC 5541, June 2009.
+
[RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali,
Z., and J. Meuric, "Extensions to the Path
Computation Element Communication Protocol (PCEP)
for PointtoMultipoint Traffic Engineering Label
Switched Paths", RFC 6006, September 2010.
13.2. Informative References
[RFC4461] Yasukawa, S., "Signaling Requirements for Pointto
Multipoint TrafficEngineered MPLS Label Switched
@@ 873,35 +838,25 @@
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "InterAS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", RFC 5376,
November 2008.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J.
Ash, "PolicyEnabled Path Computation Framework",
RFC 5394, December 2008.
 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux,
 "A BackwardRecursive PCEBased Computation (BRPC)
 Procedure to Compute Shortest Constrained Inter
 Domain Traffic Engineering Label Switched Paths",
 RFC 5441, April 2009.

[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in InterDomain
Path Computation Using a PathKeyBased Mechanism",
RFC 5520, April 2009.
 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
 Objective Functions in the Path Computation Element
 Communication Protocol (PCEP)", RFC 5541, June 2009.

[RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the
Path Computation Element (PCE) to Pointto
Multipoint (P2MP) MPLS and GMPLS Traffic Engineering
(TE)", RFC 5671, October 2009.
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation
Clients (PCC)  Path Computation Element (PCE)
Requirements for PointtoMultipoint MPLSTE",
RFC 5862, June 2010.