 1/draftietfpcepcepinterdomainp2mpprocedures05.txt 20140511 07:14:19.672404141 0700
+++ 2/draftietfpcepcepinterdomainp2mpprocedures06.txt 20140511 07:14:19.720405394 0700
@@ 1,26 +1,25 @@
PCE Working Group Q. Zhao
InternetDraft D. Dhody
Intended status: Experimental Huawei Technology
Expires: January 14, 2014 Z. Ali
 Cisco Systems
 D. King
+Expires: November 11, 2014 D. King
Old Dog Consulting
+ Z. Ali
+ Cisco Systems
R. Casellas
 CTTC  Centre Tecnologic de
 Telecomunicacions de Catalunya
 July 14, 2013
+ CTTC
+ May 11, 2014
PCEbased Computation Procedure To Compute Shortest Constrained P2MP
Interdomain Traffic Engineering Label Switched Paths
 draftietfpcepcepinterdomainp2mpprocedures05
+ draftietfpcepcepinterdomainp2mpprocedures06
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 GMPLScontrolled networks.
The Path Computation Element (PCE) has been recognized as an
appropriate technology for the determination of interdomain paths of
P2MP TE LSPs.
@@ 37,76 +36,74 @@
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 July 14, 2013.
+ This InternetDraft will expire on November 11, 2014.
Copyright Notice

 Copyright (c) 2013 IETF Trust and the persons identified as the
+ Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
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
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . .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
+ 7.1. CoreTrees . . . . . . . . . . . . . . . . . . . . . . . .9
+ 7.2. Optimal CoreTree Computation Procedure. . . . . . . . . .12
+ 7.3. Subtree Computation Procedures . . . . . . . . . . . . .13
+ 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 . . . . . . . . . . . . . . . . .16
+ 9.1. Control of Function and Policy . . . . . . . . . . . . . .16
+ 9.2. Information and Data Models . . . . . . . . . . . . . . .16
+ 9.3. Liveness Detection and Monitoring . . . . . . . . . . . .16
+ 9.4. Verifying Correct Operation . . . . . . . . . . . . . . .16
+ 9.5. Requirements on Other Protocols and Functional Components.17
+ 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 . . . . . . . . . . . . . . . . . .19
+ 14. Contributors' Addresses . . . . . . . . . . . . . . . . . . .21
+ 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .21
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
@@ 116,20 +113,24 @@
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.
+ When results of implementation and deployment are available, this
+ document will be updated and refined, and then moved from
+ Experimental status to Standards Track.
+
1.2. Scope
The interdomain P2MP path computation procedures described in this
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.
@@ 149,279 +151,305 @@
(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): is either an ABR in the context
of interarea Traffic Engineering or an ASBR in the context of
interAS Traffic Engineering.
 Core Tree: a P2MP tree where the root is the ingress
 LSR, and the leaf nodes are the entry BNs of the leaf domains.
+ CoreTree: a P2MP tree where the root is the ingress Label Switching
+ Router (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).
+ Interior Gateway Protocol (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.
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].
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.
+ of a P2MP TE LSP from the ingress LSR to all egress LSRs (the leaf
+ nodes).
Path Domain Sequence: the known sequence of domains for a path
 between root and leaf.
+ between the root domain and a leaf domain.
Path Domain Tree: the tree formed by the domains that the P2MP path
crosses, where the source (ingress) domain is the root domain.
PCE(i): a PCE that performs path computations for domain(i).
Root Domain: the domain that includes the ingress (root) LSR.
 Subtree: used to minimize packet duplication when P2P
 TE subLSPs traverse common links.
+ Subtree: a P2MP tree where the root is the selected entry BN of the
+ leaf domain and the leaf nodes are the destinations (leaves) in
+ that domain. The subtrees are grafted to the coretree.
Transit/branch Domain: a domain that has an upstream and one or more
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
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.
+ to compute Point to Point (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 PathKeys [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 TE LSP. In
 other words, a P2MP tree is a representation of the corresponding
 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 TE LSP to each of the egress LSRs, the
 second is the traffic engineering related parameters, and the third
 is the branch capability information.
+ As discussed in [RFC4461], a P2MP tree is the ordered 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. A P2MP LSP is set up with TE constraints
+ and allows efficient packet or data replication at various branching
+ points in the network. As per [RFC5671] branch point selection is
+ fundamental to the determination of the paths for a P2MP TE LSP. Not
+ only is this selection constrained by the network topology and
+ available network resources, but it is determined by the objective
+ functions (OF) that may be applied to path computation.
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 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
 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.
+ efficiently and effectively between domains. That is, when one or
+ more domains have multiple ingress and/or egress boundary nodes
+ (i.e., when the domains are multiply interconnected), existing
+ techniques may be convoluted when used 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 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.
+ LSPs individually does not guarantee the generation of an optimal
+ P2MP tree for every definition of "optimal" in every topology.
 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 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.
+ Per Domain path computation [RFC5152] may be used to compute P2MP
+ multidomain paths, but may encounter the issues previously
+ described. Furthermore, 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.
+ least cost resulting tree, typically 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, procedures and extensions to
PCEP to support P2MP interdomain path computation.
4. Assumptions
Within this document we make the following assumptions:
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;
 Additional assumptions are documented in [RFC5441] and will
 not be repeated here.
+ Additional assumptions are documented in [RFC5441] and are not
+ 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 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
path computation time as various parameters of the topology and the
P2MP TE LSP are changed.
 It is also important that the solution preserves confidentiality
+ It is also important that the solution can preserve confidentiality
across domains, which is required when domains are managed by
 different Service Providers.
+ different Service Providers via PathKey mechanism [RFC5520].
Other than the requirements specified in [RFC5862], a number of
 requirements specific to P2MP are detailed below:

 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
 have no impact on other domains and on the paths among BNs.
+ requirements specific to interdomain P2MP are detailed below:
 3. The complexity of the computation for each subtree within each
+ 1. 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.
 4. The number of PCReq and PCReq messages SHOULD be independent of
 the number of multicast destinations in each domain.
+ 2. The number of PCReq (Path Computation Request) and PCRep (Path
+ Computation Reply) messages SHOULD be independent of the number
+ of multicast destinations in each domain.
 5. It SHOULD be possible to specify the domain entry and exit nodes.
+ 3. It SHOULD be possible to specify the domain entry and exit nodes
+ in the PCReq.
 6. Specifying which nodes are be used as branch nodes SHOULD be
 supported.
+ 4. Specifying which nodes are be used as branch nodes SHOULD be
+ supported in the PCReq.
 7. Reoptimization of existing subtrees SHOULD be supported.
+ 5. Reoptimization of existing subtrees SHOULD be supported.
 8. It SHOULD be possible to compute diverse P2MP paths from existing
+ 6. It SHOULD be possible to compute diverse P2MP paths from existing
P2MP paths.
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 used. Using an OF to select the "best" candidate path,
include:
o The subtree within each domain SHOULD be optimized using 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:
+ In addition to the OFs, the following constraints may also be
+ beneficial for interdomain P2MP path computation:
 1. The core tree SHOULD be optimal.
+ 1. The computed P2MP "coretree" SHOULD be optimal when only
+ considering the paths to the leaf domain entry BNs.
 2. It SHOULD be possible to limit the number of entry points to a
 domain.
+ 2. Grafting and pruning of multicast destinations (subtree) within
+ a leaf domain SHOULD ensure minimal impact on other domains
+ and on the coretree.
 3. It SHOULD be possible to force the branches for all leaves within
 a domain to be in that domain.
+ 3. It SHOULD be possible to choose to optimize the coretree.
 4. It SHOULD be possible to combine the aforementioned OFs and
+ 4. It SHOULD be possible to choose optimize the entire tree (P2MP
+ LSP).
+
+ 5. It SHOULD be possible to combine the aforementioned OFs and
constraints for P2MP path computation.
+ When implementing and operating P2MP LSPs, following needs to be
+ taken into consideration:
+
+ o The complexity of computation.
+
+ o The optimality of the tree (coretree as well as full P2MP LSP
+ tree).
+
+ o The stability of the coretree.
+
+ The solution SHOULD allow these tradeoffs to be made at computation
+ time.
+
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 treebased procedures to
 satisfy the requirements specified in the previous section. A core
 treebased solution provides an optimal interdomain P2MP TE LSP.
+ A P2MP Path computation can be broken down into two steps of core
+ tree computation and grafting of subtrees. Breaking the procedure
+ into two steps has following impact 
7.1. Core Trees
+ o The coretree and subtree are smaller in comparison to
+ the full P2MP Tree and are thus easier to compute.
 A core tree is defined as a tree that satisfies the following
+ o An implementation may choose to keep the coretree fairly static
+ or computed offline (tradeoff with optimality).
+
+ o Adding/Pruning of leaves required changes to subtree in leaf
+ domain only.
+
+ o The PCEP message size is smaller in comparison.
+
+ The following sections describe the coretree based procedures to
+ satisfy the requirements specified in the previous section. A core
+ tree based solution provides an optimal interdomain P2MP TE LSP.
+
+7.1. CoreTrees
+
+ A coretree 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 root of the coretree is the ingress LSR in the root domain;
 o The leaves of the core tree are the entry nodes in the leaf
 domains.
+ o The leaves of the coretree are the entry boundary nodes in the
+ leaf domains.
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 1 below,
representing a domain tree of 6 domains, and part of the resulting
 core tree which satisfies the aforementioned conditions.
+ coretree which satisfies the aforementioned conditions.
++
 Domain D1
 R 
 
 A 
 
+BC+
/ \
/ \
/ \
Domain D2 / \ Domain D3
+D+ +E+
   
 F   
 G   H 
   
   
+I+ +JK+
 / / \
 / / \
 / / \
 / / \
 / / \
 / / \
 / Domain D4 Domain D5 / Domain D6 \
 +L+ +P+ +T+
+ /\ / \
+ / \ / \
+ / \ / \
+ / \ / \
+ / \ / \
+ / \ / \
+ / Domain D4 \ Domain D5 / Domain D6 \
+ +LW+ +P+ +T+
     
   Q   U 
 M O   S   
     V 
 N   R   
++ ++ ++
Figure 1: Domain Tree Example
(R)

@@ 431,113 +459,138 @@
(B) (C)
/ \
/ \
(D) (E)
/ 
/ 
(G) (H)
/ / \
/ / \
(I) (J) (K)
+ / \ / \
+ / \ / \
+ (L) (W) (P) (T)
+
+ Figure 2: CoreTree
+
+ A coretree is computed such that root of the tree is R and the leaf
+ node are the entry nodes of the destination domains (L, W, P and T).
+ Pathkey mechanism can be used to hide the internal nodes and links
+ (node G and H are hidden via PathKey PK1 and PK2 respectively) in
+ the final coretree as shown below for domain D2 and D3.
+
+ (R)
+ 
+ (A)
+ / \
+ / \
+ (B) (C)
+ / \
+ / \
+ (D) (E)
+ / 
+ / 
+ PK1 PK2
/ / \
/ / \
 (L) (P) (T)
+ (I) (J) (K)
+ / \ / \
+ / \ / \
+ (L) (W) (P) (T)
 Figure 2: Core Tree
+ Figure 3: CoreTree with PathKey
 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
 in the final core tree.
+7.2. Optimal CoreTree Computation Procedure
7.2. Core Tree Computation Procedures
+ Applying the coretree procedure to large groups of domains, such as
+ the Internet, is not considered feasible or desirable, and is out of
+ scope for this document.
 The algorithms to compute the optimal large core tree are outside
 scope of this document. The following extended BRPCbased procedure
 can be used to compute the core tree.
+ The following extended BRPCbased procedure can be used to compute
+ the coretree. Note that a root PCE may further use its own enhanced
+ optimization techniques in future to compute the coretree.
 A BRPCbased core tree path computation procedure is described below:
+ A BRPCbased coretree 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 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 coretree(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
 Tree.
+ 4. There will be M number coretrees computed from step3. An
+ optimal coretree is selected based on the OF and constraints.
Note that, since point to point BRPC procedure is used to compute
 VSPT, the path request and response messages as per [RFC5440] are
 used.
+ VSPT, the path request and response messages format 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 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.
+ downstream PCE are not necessarily pruned from the solution set
+ (extended VSPT) 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, the combination of these
+ single optimal subpaths into a coretree is not necessarily optimal
+ even if each S2L (SourcetoLeaf) subpath is optimal.
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.
+ subpaths set for the entry boundary nodes of the leaf domain. The
+ PCE will then, by looking through all the combinations and taking one
+ subpath from each set to build one tree, can select the optimal
+ coretree.
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.
+ paths for an optimal coretree.
 The proposed method may present a scalability problem for the dynamic
 computation of the core tree (by iterative checking of all
+ The proposed method may present a scalability problem for the
+ dynamic computation of the coretree (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 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).
+ 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 CE Q =
+ \prod E(k) x X(k).
 Consequently, it is expected that the Core Path will be typically
+ Consequently, it is expected that the coretree 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. 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
+ Once the coretree is built, the grafting of all the leaf nodes from
+ each domain to the coretree 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 (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.
+ coretree computed from section 7.2.
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
+ An 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.
The algorithms to compute the optimal large subtree are outside
scope of this document.
@@ 538,88 +591,84 @@
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.
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.
+ Parameters) object (defined in [RFC5440]) used in PCEP requests
+ and responses.
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 coretree or not.
The following flag is added in this draft:
 C bit ( P2MP Core Tree bit  1 bit):
+ C bit (CoreTree bit  1 bit):
 0: This indicates that this is normal PCReq/PCRrep for P2MP.
+ 0: This indicates that this is not for an interdomain P2MP
+ coretree.
 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 MUST contain the core tree passed along with the
 destinations to be grafted to the tree.
+ 1: This indicates that this is a PCEP request or a response
+ for the computation of a interdomain coretree or for the
+ grafting of a subtree to a interdomain coretree.
7.4.2. Domain and PCE Sequence
The procedure as described in this document requires the domaintree
 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.
+ to be known in advance. This information may be either
+ administratively predetermined or dynamically discovered by some
+ means such as Hierarchical PCE (HPCE) [RFC6805] framework, or
+ derived through the IGP/BGP routing information.
 [DOMAINSEQ] describes the representation of domain in P2MP
 scenarios. The use of PCE sequence rather than domainsequence, is
 based on deployment and implementation preference.
+ Examples of ways to encode the domain path tree include [RFC5886]
+ using PCEID Object and [DOMAINSEQ].
7.5. Using HPCE for Scalability
 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.
+ The ingress/root PCE is responsible for the coretree computation as
+ well as grafting of subtrees into the multidomain tree. Therefore,
+ the ingress/root PCE will receive all computed path segments from all
+ the involved domains. When the ingress/root PCE chooses to have a
+ PCEP session with all involved PCEs, this may cause an excessive
+ number of sessions or added complexity in implementations.
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.
+ responsible to request intradomain path computation request 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
+ can 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
 Tree is enabled.
+ 1. The BRPC procedure for each leaf boundary node can be launched in
+ parallel by the ingress/root PCE for dynamic computation of
+ coretree.
 2. Intradomain P2MP paths can also be computed in parallel by the
 PCEs once the entry and exit nodes within a domain are known
+ 2. The grafting of subtrees can be triggered in parallel once the
+ coretree is computed.
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.
+ "remote" PCEs at the same time and that may not be desirable.
8. Protection
It is envisaged that protection may be required when deploying and
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
@@ 652,32 +701,28 @@
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
PCEP, and most of manageability requirements mentioned in [RFC6006]
are already covered there.
9.1. Control of Function and Policy
 In addition to PCE configuration parameters listed in [RFC5440], the
 following additional parameters might be required:

 o The ability to enable or disable single domain P2MP path
 computations on the PCE.
+ In addition to PCE configuration parameters listed in [RFC5440] and
+ [RFC6006], the following additional parameters might be required:
o The ability to enable or disable multidomain P2MP path
computations on the PCE.
o The PCE may be configured to enable or disable the advertisement
 of its single domain and multidomain P2MP path computation
 capability.
+ of its multidomain P2MP path computation capability.
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.
@@ 721,29 +766,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 coretrees 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.
They are also applicable to Interdomain P2MP Path computation via
 the core tree mechanism.
+ the coretree 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
@@ 764,22 +809,29 @@
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
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.
+ IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
+ registry with the "RP Object Flag Field" subregistry.
+
+ IANA is requested to allocate a new bit from this registry as
+ follows:
+
+ Bit Description Reference
+
+ TBA Coretree computation (Cbit) [This.ID]
12. Acknowledgements
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
@@ 853,42 +905,46 @@
[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.
+ [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set
+ of Monitoring Tools for Path Computation Element
+ (PCE)Based Architecture", RFC 5886, June 2010.
+
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC6805] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the
Determination of a Sequence of Domains in MPLS and
GMPLS", RFC 6805, November 2012.
[PCEPMIB] Koushik, K., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "PCE communication protocol (PCEP)
Management Information Base (Work in Progress)",
 July 2012.
+ February 2014.
[PCEPP2MPMIB] Zhao, Q., Dhody, D., Palle, U., and D. King,
"Management Information Base for the PCE
Communications Protocol (PCEP) When Requesting
PointtoMultipoint Services (Work in Progress)",
Aug 2012.
[DOMAINSEQ] Dhody, D., Palle, U., and R. Casellas, "Standard
Representation Of Domain Sequence (Work in
 Progress)", Feb 2013.
+ Progress)", July 2014.
14. Contributor Addresses
Siva Sivabalan
Cisco Systems
2000 Innovation Drive
Kanata, Ontario K2K 3E8
CANADA
EMail: msiva@cisco.com
@@ 924,18 +981,17 @@
Kanata, Ontario K2K 3E8
CANADA
EMail: zali@cisco.com
Daniel King
Old Dog Consulting
UK
EMail: daniel@olddog.co.uk

Ramon Casellas
 CTTC  Centre Tecnologic de Telecomunicacions de Catalunya
+ CTTC
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
SPAIN
EMail: ramon.casellas@cttc.es