--- 1/draft-ietf-teas-pcecc-use-cases-08.txt 2022-03-07 10:14:50.097910096 -0800 +++ 2/draft-ietf-teas-pcecc-use-cases-09.txt 2022-03-07 10:14:50.149910768 -0800 @@ -1,62 +1,53 @@ TEAS Working Group Z. Li Internet-Draft D. Dhody Intended status: Informational Huawei Technologies -Expires: 28 April 2022 Q. Zhao +Expires: 8 September 2022 Q. Zhao Etheric Networks K. Ke Tencent Holdings Ltd. B. Khasanov Yandex LLC - L. Fang - Expedia, Inc. - C. Zhou - HPE - B. Zhang - Telus Communications - A. Rachitskiy - Mobile TeleSystems JLLC - A. Gulida - LLC "Lifetech" - 25 October 2021 + 7 March 2022 The Use Cases for Path Computation Element (PCE) as a Central Controller (PCECC). - draft-ietf-teas-pcecc-use-cases-08 + draft-ietf-teas-pcecc-use-cases-09 Abstract The Path Computation Element (PCE) is a core component of a Software- Defined Networking (SDN) system. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. - This document describes general considerations for PCECC deployment - and examines its applicability and benefits, as well as its - challenges and limitations, through a number of use cases. PCEP - extensions required for stateful PCE usage are covered in separate - documents. + A PCE as a Central Controller (PCECC) can simplify the processing of + a distributed control plane by blending it with elements of SDN and + without necessarily completely replacing it. This document describes + general considerations for PCECC deployment and examines its + applicability and benefits, as well as its challenges and + limitations, through a number of use cases. PCEP extensions required + for stateful PCE usage are covered in separate documents. Requirements Language - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -64,89 +55,113 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts 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 Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 28 April 2022. + This Internet-Draft will expire on 8 September 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + Copyright (c) 2022 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 (https://trustee.ietf.org/ license-info) 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. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Use Cases of PCECC for Label Management . . . . . . . . . 4 + 3.1. Use Cases of PCECC for Label Management . . . . . . . . . 5 3.2. Using PCECC for SR . . . . . . . . . . . . . . . . . . . 6 - 3.2.1. PCECC SID Allocation . . . . . . . . . . . . . . . . 7 - 3.2.2. Use Cases of PCECC for SR Best Effort (BE) Path . . . 8 + 3.2.1. PCECC SID Allocation . . . . . . . . . . . . . . . . 8 + 3.2.2. Use Cases of PCECC for SR Best Effort (BE) Path . . . 9 3.2.3. Use Cases of PCECC for SR Traffic Engineering (TE) - Path . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2.4. SR Policy . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3. Use Cases of PCECC for TE LSP . . . . . . . . . . . . . . 9 - 3.3.1. PCECC Load Balancing (LB) Use Case . . . . . . . . . 11 - 3.3.2. PCECC and Inter-AS TE . . . . . . . . . . . . . . . . 13 - 3.4. Use Cases of PCECC for Multicast LSPs . . . . . . . . . . 16 - 3.4.1. Using PCECC for P2MP/MP2MP LSPs' Setup . . . . . . . 17 + Path . . . . . . . . . . . . . . . . . . . . . . . . 9 + + 3.2.4. SR Policy . . . . . . . . . . . . . . . . . . . . . . 10 + 3.3. Use Cases of PCECC for TE LSP . . . . . . . . . . . . . . 11 + 3.3.1. PCECC Load Balancing (LB) Use Case . . . . . . . . . 13 + 3.3.2. PCECC and Inter-AS TE . . . . . . . . . . . . . . . . 15 + 3.4. Use Cases of PCECC for Multicast LSPs . . . . . . . . . . 18 + 3.4.1. Using PCECC for P2MP/MP2MP LSPs' Setup . . . . . . . 18 3.4.2. Use Cases of PCECC for the Resiliency of P2MP/MP2MP - LSPs . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.5. Use Cases of PCECC for LSP in the Network Migration . . . 20 - 3.6. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . 22 - 3.7. Using PCECC for Traffic Classification Information . . . 23 - 3.8. Use Cases of PCECC for SRv6 . . . . . . . . . . . . . . . 23 - 3.9. Use Cases of PCECC for SFC . . . . . . . . . . . . . . . 25 - 3.10. Use Cases of PCECC for Native IP . . . . . . . . . . . . 26 - 3.11. Use Cases of PCECC for Local Protection (RSVP-TE) . . . . 26 - 3.12. Use Cases of PCECC for BIER . . . . . . . . . . . . . . . 26 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + LSPs . . . . . . . . . . . . . . . . . . . . . . . . 20 + 3.5. Using PCECC for Traffic Classification Information . . . 22 + 3.6. Use Cases of PCECC for SRv6 . . . . . . . . . . . . . . . 23 + 3.7. Use Cases of PCECC for SFC . . . . . . . . . . . . . . . 24 + 3.8. Use Cases of PCECC for Native IP . . . . . . . . . . . . 25 + 3.9. Use Cases of PCECC for BIER . . . . . . . . . . . . . . . 26 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1. Normative References . . . . . . . . . . . . . . . . . . 27 7.2. Informative References . . . . . . . . . . . . . . . . . 28 - Appendix A. Using reliable P2MP TE based multicast delivery for - distributed computations (MapReduce-Hadoop) . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + Appendix A. Other Use Cases of PCECC . . . . . . . . . . . . . . 33 + A.1. Use Cases of PCECC for LSP in the Network Migration . . . 33 + A.2. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . 34 + A.3. Use Cases of PCECC for Local Protection (RSVP-TE) . . . . 35 + A.4. Using reliable P2MP TE based multicast delivery for + distributed computations (MapReduce-Hadoop) . . . . . . . 36 + Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction - An Architecture for Use of PCE and PCEP [RFC5440] in a Network with - Central Control [RFC8283] describes SDN architecture where the Path - Computation Element (PCE) determines paths for variety of different - usecases, with PCEP as a general southbound communication protocol - with all the nodes along the path.. + The Path Computation Element (PCE) [RFC4655] was developed to offload + the path computation function from routers in an MPLS traffic- + engineered (TE) network. It can compute optimal paths for traffic + across a network and can also update the paths to reflect changes in + the network or traffic demands. Since then, the role and function of + the PCE have grown to cover a number of other uses (such as GMPLS + [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated + use of network resources [RFC8281]. + + According to [RFC7399], Software-Defined Networking (SDN) refers to a + separation between the control elements and the forwarding components + so that software running in a centralized system, called a + controller, can act to program the devices in the network to behave + in specific ways. A required element in an SDN architecture is a + component that plans how the network resources will be used and how + the devices will be programmed. It is possible to view this + component as performing specific computations to place traffic flows + within the network given knowledge of the availability of network + resources, how other forwarding devices are programmed, and the way + that other flows are routed. This is the function and purpose of a + PCE, and the way that a PCE integrates into a wider network control + system (including an SDN system) is presented in [RFC7491]. + + [RFC8283] introduces the architecture for the PCE as a central + controller as an extension to the architecture described in [RFC4655] + and assumes the continued use of PCEP as the protocol used between + the PCE and PCC. [RFC8283] further examines the motivations and + applicability for PCEP as a Southbound Interface (SBI) and introduces + the implications for the protocol. [RFC9050] introduces the procedures and extensions for PCEP to support the PCECC architecture [RFC8283]. - This draft describes the various usecases for the PCECC architecture. - - This is a living document to catalog the use cases for PCECC. There - is currently no intention to publish this work as an RFC. [Update: - Chairs are evaluating if the document should be published instead.] + This draft describes the various other usecases for the PCECC + architecture. 2. Terminology The following terminology is used in this document. IGP: Interior Gateway Protocol. Either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS). PCC: Path Computation Client: any client application requesting a @@ -176,40 +191,39 @@ ranges to the router using PCEP. [RFC9050] describe a mode where LSPs are provisioned as explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label forwarding instructions to program and what resources to reserve. The controller uses PCEP to communicate with each router along the path of the end-to-end LSP. For this to work, the PCE- based controller will take responsibility for managing some part of the MPLS label space for each of the routers that it controls. An extension to PCEP could be done to - allow a PCC to inform the PCE of such a label space to control. + allow a PCC to inform the PCE of such a label space to control. (See + [I-D.li-pce-controlled-id-space] for a possible PCEP extension to + support advertisement of the MPLS label space to the PCE to control.) [RFC8664] specifies extensions to PCEP that allow a stateful PCE to compute, update or initiate SR-TE paths. [I-D.ietf-pce-pcep-extension-pce-controller-sr] describes the mechanism for PCECC to allocate and provision the node/prefix/ adjacency label (SID) via PCEP. To make such allocation PCE needs to be aware of the label space from Segment Routing Global Block (SRGB) or Segment Routing Local Block (SRLB) [RFC8402] of the node that it controls. A mechanism for a PCC to inform the PCE of such a label space to control is needed within PCEP. The full SRGB/SRLB of a node could be learned via existing IGP or BGP-LS mechanism too. - [I-D.li-pce-controlled-id-space] defines a PCEP extension to support - advertisement of the MPLS label space to the PCE to control. - - There have been various proposals for Global Labels, the PCECC - architecture could be used as means to learn the label space of - nodes, and could also be used to determine and provision the global - label range. + Further, there have been various proposals for Global Labels in MPLS, + the PCECC architecture could be used as means to learn the label + space of nodes, and could also be used to determine and provision the + global label range. +------------------------------+ +------------------------------+ | PCE DOMAIN 1 | | PCE DOMAIN 2 | | +--------+ | | +--------+ | | | | | | | | | | | PCECC1 | ---------PCEP---------- | PCECC2 | | | | | | | | | | | | | | | | | | | +--------+ | | +--------+ | | ^ ^ | | ^ ^ | @@ -255,24 +270,24 @@ (and PCECC) could be one such means. [RFC8664] specify the SR specific PCEP extensions. PCECC may further use PCEP protocol for SR SID (Segment Identifier) distribution to the SR nodes (PCC) with some benefits. If the PCECC allocates and maintains the SID in the network for the nodes and adjacencies; and further distributes them to the SR nodes directly via the PCEP session has some advantage over the configurations on each SR node and flooding via IGP, especially in a SDN environment. - When the PCECC is used for the distribution of the node segment ID - and adjacency segment ID, the node segment ID is allocated from the - SRGB of the node. For the allocation of adjacency segment ID, the - allocation is from the SRLB of the node as described in + When the PCECC is used for the distribution of the node SID and + adjacency SID, the node SID is allocated from the SRGB of the node. + For the allocation of adjacency SID, the allocation is from the SRLB + of the node as described in [I-D.ietf-pce-pcep-extension-pce-controller-sr]. [RFC8355] identifies various protection and resiliency usecases for SR. Path protection lets the ingress node be in charge of the failure recovery (used for SR-TE). Also protection can be performed by the node adjacent to the failed component, commonly referred to as local protection techniques or fast-reroute (FRR) techniques. In case of PCECC, the protection paths can be pre-computed and setup by the PCE. @@ -316,31 +331,31 @@ in the domain, it enforces the ECMP-aware shortest-path forwarding of the packet towards the related node. For each adjacency in the network, PCECC can allocate an Adj-SID. The PCECC sends PCInitiate message to update the label map of each Adj to the corresponding nodes in the domain. Each node (PCC) download the label forwarding instructions accordingly. The forwarding behavior and the end result is similar to IGP based "Adj- SID" in SR. - The various mechanism are described in + These mechanism are described in [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 3.2.2. Use Cases of PCECC for SR Best Effort (BE) Path In this mode of the solution, the PCECC just need to allocate the - node segment ID and adjacency ID (without calculating the explicit - path for the SR path). The ingress of the forwarding path just need - to encapsulate the destination node segment ID on top of the packet. - All the intermediate nodes will forward the packet based on the - destination node SID. It is similar to the LDP LSP. + node SID (without calculating the explicit path for the SR path). + The ingress of the forwarding path just need to encapsulate the + destination node SID on top of the packet. All the intermediate + nodes will forward the packet based on the destination node SID. It + is similar to the LDP LSP. R1 may send a packet to R8 simply by pushing an SR header with segment list {1008} (Node SID for R8). The path would be the based on the routing/nexthop calculation on the routers. 3.2.3. Use Cases of PCECC for SR Traffic Engineering (TE) Path SR-TE paths may not follow an IGP SPT. Such paths may be chosen by a PCECC and provisioned on the ingress node of the SR-TE path. The SR header consists of a list of SIDs (or MPLS labels). The header has @@ -396,22 +411,69 @@ list {1004, 1008}. The path could be : R1-R2-R4-R3-R8. * When node R2 receives the packet from R1 which has the header of {1004, 1008}, and also finds out there is a node failure for node4, then it can enforce the traffic over the bypass and send out the packet with header of {1005, 1008} to node5 instead of node4. 3.2.4. SR Policy - [TODO: BORIS - will be added in next version to be published after - the blockade is lifted :) ] + [RFC8402] defines Segment Routing architecture, which uses a SR + Policy to steer packets from a node through a ordered list of + segments. The SR Policy could be configured on the headed or + instantiated by an SR controller. The SR architecture does not + restrict how the controller programs the network. The options are + Network Configuration Protocol (NETCONF), PCEP, and BGP. SR Policy + can be based on either SR-MPLS or SRv6 dataplane. + + A SR Policy architecture is described in + [I-D.ietf-spring-segment-routing-policy]. An SR Policy is a + framework that enables the instantiation of an ordered list of + segments on a node for implementing a source routing policy for the + steering of traffic for a specific purpose (e.g. for a specific SLA) + from that node. + + A SR Policy is identified through the tuple . In the context of a specific headend, one may identify an + SR policy by the tuple. + + The headend is the node where the policy is instantiated/implemented. + The endpoint indicates the destination of the policy. The color is a + 32-bit numerical value that associates the SR Policy with an intent + or objective. + + A SR Policy should have one or more Candidate Paths. A candidate + path is the unit for signaling of an SR Policy to a headend via + protocol extensions like [I-D.ietf-pce-segment-routing-policy-cp] or + BGP SR Policy [I-D.ietf-idr-segment-routing-te-policy]. Each + candidate path must have one or mode Segment-Lists. A Segment- List + represents a specific source-routed path to send traffic from the + headend to the endpoint of the corresponding SR Policy. + + A candidate path is either dynamic, explicit, or composite. For + PCECC use case a candidate path should be either dynamic (i.e. when + PCE provides its according to specific optimization objective) or + composite (a composite candidate path construct enables the + combination of SR Policies, each with explicit candidate paths and/or + dynamic candidate paths with potentially different optimization + objectives and constraints). + + [I-D.ietf-pce-segment-routing-policy-cp] defines a new ASSOCIATION + type that binds previously separated LSPs in the PCEP (Candidate + Paths) into common SR Policy hierarchy. This is applicable in the + PCECC scenario as well. + + Further one could also use the PCECC mechanism directly to create an + SR policy container at the PCC by defining a new CCI for it. The + advantage of that approach would be to allow SR Policy to be created + without signaling candidate paths. 3.3. Use Cases of PCECC for TE LSP In the Section 3.2 the case of SR path via PCECC is discussed. Although those cases give the simplicity and scalability, but there are existing functionalities for the traffic engineering path such as the bandwidth guarantee, monitoring where SR based solution are complex. Also there are cases where the depth of the label stack is an issue for existing deployment and certain vendors. @@ -535,44 +597,43 @@ manual intervention. * Provide flexibility for Service Router placement (anywhere in the network by creation of transport LSPs to them). Since other tasks are already considered by other PCECC use cases, in this section, the focus is on load balancing (LB) task. LB task could be solved by means of PCECC in the following way: * After application or network service or operator can ask SDN - controller (PCECC) for LSP based LB between AGG X and AGG N/AGG - N-1 (egress AGG routers which have connections to core) via North - Bound Interface (NBI). Each of these would have associated - constrains (i.e. Path Setup Type (PST), bandwidth, inclusion or - exclusion specific links or nodes, number of paths, objective - function (OF), need for disjoint LSP paths etc.). + controller (PCECC) for LSP based load balancing between AGG X and + AGG N/AGG N-1 (egress AGG routers which have connections to core). + Each of these would have associated constrains (i.e. bandwidth, + inclusion or exclusion specific links or nodes, number of paths, + objective function (OF), need for disjoint LSP paths etc.). - * PCECC could calculate multiple (Say N) LSPs according to given + * PCECC could calculate multiple (say N) LSPs according to given constrains, calculation is based on results of Objective Function (OF) [RFC5541], constraints, endpoints, same or different bandwidth (BW) , different links (in case of disjoint paths) and other constrains. * Depending on given LSP Path setup type (PST), PCECC would use download instructions to the PCC. At this stage it is assumed the PCECC is aware of the label space it controls and in case of SR the SID allocation and distribution is already done. - * PCECC would send PCInitiate PCEP message [RFC8281] towards ingress - AGG X router(PCC) for each of N LSPs and receives PCRpt PCEP - message [RFC8231] back from PCCs. If the PST is PCECC-SR, the - PCECC would include the SID stack as per [RFC8664]. If the PST is - PCECC (basic), then the PCECC would assigns labels along the - calculated path; and set up the path by sending central controller + * PCECC would send PCInitiate message [RFC8281] towards ingress AGG + X router(PCC) for each of N LSPs and receives PCRpt PCEP message + [RFC8231] back from PCCs. If the PST is PCECC-SR, the PCECC would + include the SID stack as per [RFC8664]. If the PST is PCECC + (basic), then the PCECC would assigns labels along the calculated + path; and set up the path by sending central controller instructions in PCEP message to each node along the path of the LSP as per [RFC9050] and then send PCUpd message to the ingress AGG X router with information about new LSP and AGG X(PCC) would respond with PCRpt with LSP status. * AGG X as ingress router now have N LSPs towards AGG N and AGG N-1 which are available for installing to router's forwarding and LB of traffic between them. Traffic distribution between those LSPs depends on particular realization of hash-function on that router. @@ -684,50 +745,50 @@ including those from [RFC5376]: priority, AS sequence, preferred ASBR, disjoint paths, protection. On this step we would have two paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3 * Depending on given LSP PST (PCECC or PCECC-SR), PCECC would use central control download instructions to the PCC. At this stage it is assumed the PCECC is aware of the label space it controls and in case of SR the SID allocation and distribution is already done. - * PCECC would send PCInitiate PCEP message [RFC8281] towards ingress + * PCECC would send PCInitiate message [RFC8281] towards ingress router R1 (PCC) in AS1 and receives PCRpt PCEP message [RFC8231] back from PCC. If the PST is PCECC-SR, the PCECC would include the SID stack as per [RFC8664]. It may also include binding SID based on AS boundary. The backup SID stack could also be installed at ingress but more importantly each node along the SR path could also do local protection just based on the top segment. If the PST is PCECC (basic), then the PCECC would assigns labels along the calculated paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3); and set up the path by sending central controller instructions in PCEP message to each node along the path of the LSPs as per [RFC9050] and then send PCUpd message to the ingress R1 router with information about new LSPs and R1 would respond with PCRpt with LSP(s) status. * After that step R1 now have primary and backup TEs (LSP1 and LSP2) towards R3. It is up to router implementation how to make switchover to backup LSP2 if LSP1 fails. 3.4. Use Cases of PCECC for Multicast LSPs - The current multicast LSPs are setup either using the RSVP-TE P2MP or - mLDP protocols. The setup of these LSPs may require manual - configurations and complex signaling when the protection is - considered. By using the PCECC solution, the multicast LSP can be - computed and setup through centralized controller which has the full - picture of the topology and bandwidth usage for each link. It not - only reduces the complex configurations comparing the distributed - RSVP-TE P2MP or mLDP signaling, but also it can compute the disjoint - primary path and secondary P2MP path efficiently. + The multicast LSPs can be setup via the RSVP-TE P2MP or mLDP + protocols. The setup of these LSPs may require manual configurations + and complex signaling when the protection is considered. By using + the PCECC solution, the multicast LSP can be computed and setup + through centralized controller which has the full picture of the + topology and bandwidth usage for each link. It not only reduces the + complex configurations comparing the distributed RSVP-TE P2MP or mLDP + signaling, but also it can compute the disjoint primary path and + secondary P2MP path efficiently. 3.4.1. Using PCECC for P2MP/MP2MP LSPs' Setup It is assumed the PCECC is aware of the label space it controls for all nodes and make allocations accordingly. +----------+ | R1 | Root node of the multicast LSP +----------+ |6000 @@ -762,22 +823,23 @@ constrains (i.e.bandwidth). * PCECC would provision each node along the path and assign incoming and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000}, {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3, 9005}, {9004, R6}, {9005, R8}. The main difference is in the branch node instruction at R2 where two copies of packet are sent towards R4 and R5 with 9001 and 9002 labels respectively. The packet forwarding involves - - Step1: R1 may send a packet P1 to R2 simply by pushing an label of - 6000 to the packet. + + Step 1: R1 may send a packet P1 to R2 simply by pushing an label + of 6000 to the packet. Step2: After R2 receives the packet with label 6000, it will forwarding to R4 by swapping label to 9001 and by swapping label of 9002 towards R5. Step3: After R4 receives the packet with label 9001, it will forwarding to R3 by swapping to 9003. After R5 receives the packet with label 9002, it will forwarding to R6 by swapping to 9004. @@ -879,156 +941,56 @@ R50}. Both the these two primary forwarding path and secondary bypass forwarding path will be downloaded to each routers along the primary path and the secondary bypass path. The traffic will be forwarded through the R10->R20->{R40, R50} path normally, and when there is a node failure for node R20, then the PLR node R10 will switch the flow to the backup path, which is R10->R30->{R40, R50}. By using the PCECC, the path computation and forwarding path downloading can all be done without the complex signaling used in the P2MP RSVP-TE or mLDP. -3.5. Use Cases of PCECC for LSP in the Network Migration - - One of the main advantages for PCECC solution is that it has backward - compatibility naturally since the PCE server itself can function as a - proxy node of MPLS network for all the new nodes which may no longer - support the signaling protocols. - - As it is illustrated in the following example, the current network - could migrate to a total PCECC controlled network gradually by - replacing the legacy nodes. During the migration, the legacy nodes - still need to signal using the existing MPLS protocol such as LDP and - RSVP-TE, and the new nodes setup their portion of the forwarding path - through PCECC directly. With the PCECC function as the proxy of - these new nodes, MPLS signaling can populate through network as - normal. - - Example described in this section is based on network configurations - illustrated using the following figure: - - +------------------------------------------------------------------+ - | PCE DOMAIN | - | +-----------------------------------------------------+ | - | | PCECC | | - | +-----------------------------------------------------+ | - | ^ ^ ^ ^ | - | | PCEP | | PCEP | | - | V V V V | - | +--------+ +--------+ +--------+ +--------+ +--------+ | - | | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | - | | |...| |...| |...| |...| | | - | | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | | - | | Node | | Node | |Enabled | |Enabled | | Enabled| | - | +--------+ +--------+ +--------+ +--------+ +--------+ | - | | - +------------------------------------------------------------------+ - - Example: PCECC Initiated LSP Setup In the Network Migration - - In this example, there are five nodes for the TE LSP from head end - (Node1) to the tail end (Node5). Where the Node4 and Node5 are - centrally controlled and other nodes are legacy nodes. - - * Node1 sends a path request message for the setup of LSP - destinating to Node5. - - * PCECC sends to node1 a reply message for LSP setup with the path: - (Node1, if1),(Node2, if2), (Node3, if3), (Node4, if4), Node5. - - * Node1, Node2, Node3 will setup the LSP to Node5 using the local - labels as usual. Node 3 with help of PCECC could proxy the - signaling. - - * Then the PCECC will program the out-segment of Node3, the in- - segment/ out-segment of Node4, and the in-segment for Node5. - -3.6. Use Cases of PCECC for L3VPN and PWE3 - - As described in [RFC8283], various network services may be offered - over a network. These include protection services (including Virtual - Private Network (VPN) services (such as Layer 3 VPNs [RFC4364] or - Ethernet VPNs [RFC7432]); or Pseudowires [RFC3985]. Delivering - services over a network in an optimal way requires coordination in - the way that network resources are allocated to support the services. - A PCE-based central controller can consider the whole network and all - components of a service at once when planning how to deliver the - service. It can then use PCEP to manage the network resources and to - install the necessary associations between those resources. - - In the case of L3VPN, VPN labels can be assigned and distributed - through the PCECC PCEP among the PE router instead of using the BGP - protocols. - - Example described in this section is based on network configurations - illustrated using the following figure: - - +-------------------------------------------+ - | PCE DOMAIN | - | +-----------------------------------+ | - | | PCECC | | - | +-----------------------------------+ | - | ^ ^ ^ | - |PWE3/L3VPN | PCEP PCEP|LSP PWE3/L3VPN|PCEP | - | V V V | - +--------+ | +--------+ +--------+ +--------+ | +--------+ - | CE | | | PE1 | | NODE x | | PE2 | | | CE | - | |...... | |...| |...| |.....| | - | Legacy | |if1 | PCECC |if2|PCCEC |if3| PCECC |if4 | Legacy | - | Node | | | Enabled| |Enabled | |Enabled | | | Node | - +--------+ | +--------+ +--------+ +--------+ | +--------+ - | | - +-------------------------------------------+ - - Example: Using PCECC for L3VPN and PWE3 - - In the case PWE3, instead of using the LDP signaling protocols, the - label and port pairs assigned to each pseudowire can be assigned - through PCECC among the PE routers and the corresponding forwarding - entries will be distributed into each PE routers through the extended - PCEP protocols and PCECC mechanism. - -3.7. Using PCECC for Traffic Classification Information +3.5. Using PCECC for Traffic Classification Information As described in [RFC8283], traffic classification is an important part of traffic engineering. It is the process of looking at a packet to determine how it should be treated as it is forwarded through the network. It applies in many scenarios including MPLS traffic engineering (where it determines what traffic is forwarded onto which LSPs); segment routing (where it is used to select which set of forwarding instructions to add to a packet); and SFC (where it indicates along which service function path a packet should be forwarded). In conjunction with traffic engineering, traffic classification is an important enabler for load balancing. Traffic classification is closely linked to the computational elements of planning for the network functions just listed because it determines how traffic load is balanced and distributed through the network. Therefore, selecting what traffic classification should be performed by a router is an important part of the work done by a PCECC. Instructions can be passed from the controller to the routers using PCEP. These instructions tell the routers how to map traffic to - paths or connections. Refer [I-D.ietf-pce-pcep-flowspec]. + paths or connections. Refer [RFC9168]. Along with traffic classification, there are few more question that needs to be considered once the path is setup - * how to use it * Whether it is a virtual link * Whether to advertise it in the IGP as a virtual link * What bits of this information to signal to the tail end These are out of scope of this document. -3.8. Use Cases of PCECC for SRv6 +3.6. Use Cases of PCECC for SRv6 As per [RFC8402], with Segment Routing (SR), a node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the IPv6 architecture with the Segment Routing Header (SRH) [RFC8754]. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address of the packet. Upon completion of a segment, a pointer in the new routing header is incremented and indicates the next segment. @@ -1070,21 +1032,21 @@ In this case, PCECC could assign the SRv6 SID (in form of a IPv6 address) to be used for node and adjacency. Later SRv6 path in form of list of SRv6 SID could be used at the ingress. Some examples - * SRv6 SID-List={2001:db8::8} - The best path towards R8 * SRv6 SID-List={2001:db8::5, 2001:db8::8} - The path towards R8 via R5 -3.9. Use Cases of PCECC for SFC +3.7. Use Cases of PCECC for SFC Service Function Chaining (SFC) is described in [RFC7665]. It is the process of directing traffic in a network such that it passes through specific hardware devices or virtual machines (known as service function nodes) that can perform particular desired functions on the traffic. The set of functions to be performed and the order in which they are to be performed is known as a service function chain. The chain is enhanced with the locations at which the service functions are to be performed to derive a Service Function Path (SFP). Each packet is marked as belonging to a specific SFP, and that marking @@ -1116,51 +1079,36 @@ forwarding instructions to each SFFs along the way so that they could process the NSH and forward accordingly. Instructions to the service classifier handle the context header, meta data etc. It is also possible to support SFC with SR in conjunction with or without NSH such as [I-D.ietf-spring-nsh-sr] and [I-D.ietf-spring-sr-service-programming]. PCECC technique can also be used for service function related segments and SR service policies. -3.10. Use Cases of PCECC for Native IP +3.8. Use Cases of PCECC for Native IP [RFC8735] describes the scenarios, and suggestions for the "Centrally Control Dynamic Routing (CCDR)" architecture, which integrates the merit of traditional distributed protocols (IGP/BGP), and the power of centrally control technologies (PCE/SDN) to provide one feasible traffic engineering solution in various complex scenarios for the - service provider. [I-D.ietf-teas-pce-native-ip] defines the - framework for CCDR traffic engineering within Native IP network, - using Dual/Multi-BGP session strategy and CCDR architecture. PCEP - protocol can be used to transfer the key parameters between PCE and - the underlying network devices (PCC) using PCECC technique. The - central control instructions from PCECC to identify which prefix - should be advertised on which BGP session. - -3.11. Use Cases of PCECC for Local Protection (RSVP-TE) - - [I-D.cbrt-pce-stateful-local-protection] describes the need for the - PCE to maintain and associate the local protection paths for the - RSVP-TE LSP. Local protection requires the setup of a bypass at the - PLR. This bypass can be PCC-initiated and delegated, or PCE- - initiated. In either case, the PLR MUST maintain a PCEP session to - the PCE. The Bypass LSPs need to mapped to the primary LSP. This - could be done locally at the PLR based on a local policy but there is - a need for a PCE to do the mapping as well to exert greater control. - - This mapping can be done via PCECC procedures where the PCE could - instruct the PLR to the mapping and identify the primary LSP for - which bypass should be used. + service provider. [RFC8821] defines the framework for CCDR traffic + engineering within Native IP network, using Dual/Multi-BGP session + strategy and CCDR architecture. PCEP protocol can be used to + transfer the key parameters between PCE and the underlying network + devices (PCC) using PCECC technique. The central control + instructions from PCECC to identify which prefix should be advertised + on which BGP session. -3.12. Use Cases of PCECC for BIER +3.9. Use Cases of PCECC for BIER Bit Index Explicit Replication (BIER) [RFC8279] defines an architecture where all intended multicast receivers are encoded as a bitmask in the multicast packet header within different encapsulations. A router that receives such a packet will forward the packet based on the bit position in the packet header towards the receiver(s) following a precomputed tree for each of the bits in the packet. Each receiver is represented by a unique bit in the bitmask. BIER-TE [I-D.ietf-bier-te-arch] shares architecture and packet @@ -1178,26 +1126,46 @@ router with various parameters used in the BIER encapsulation such as BIER subdomain-ID, BFR-ID, BIER Encapsulation etc etc for both node and adjacency. 4. IANA Considerations This document does not require any action from IANA. 5. Security Considerations - TODO: DHRUV - we plan to add this in the next revision after the - draft submission blockade is lifted. + [RFC8283] describes how the security considerations for a PCE-based + controller are little different from those for any other PCE system. + That is, the operation relies heavily on the use and security of + PCEP, so due consideration should be given to the security features + discussed in [RFC5440] and the additional mechanisms described in + [RFC8253]. It further lists the vulnerability of a central + controller architecture, such as a central point of failure, denial + of service, and a focus for interception and modification of messages + sent to individual Network Elements (NEs). + + As per [RFC9050], the use of Transport Layer Security (TLS) in PCEP + is recommended, as it provides support for peer authentication, + message encryption, and integrity. It further provides mechanisms + for associating peer identities with different levels of access and/ + or authoritativeness via an attribute in X.509 certificates or a + local policy with a specific accept-list of X.509 certificates. This + can be used to check the authority for the PCECC operations. + + It is expected that each new document that is produced for a specific + use case will also include considerations of the security impacts of + the use of a PCE-based central controller on the network type and + services being managed. 6. Acknowledgments - We would like to thank Adrain Farrel, Aijun Wang, Robert Tao, + We would like to thank Adrian Farrel, Aijun Wang, Robert Tao, Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Elperin and Evgeniy Brodskiy for their useful comments and suggestions. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, @@ -1212,37 +1180,48 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, December 2017, . + [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, + "PCEPS: Usage of TLS to Provide a Secure Transport for the + Path Computation Element Communication Protocol (PCEP)", + RFC 8253, DOI 10.17487/RFC8253, October 2017, + . + 7.2. Informative References [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, . [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . + [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path + Computation Element (PCE)-Based Architecture", RFC 4655, + DOI 10.17487/RFC4655, August 2006, + . + [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, . [RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter- Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, DOI 10.17487/RFC5151, February @@ -1253,25 +1232,40 @@ Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, . [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, DOI 10.17487/RFC5376, November 2008, . + [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. + Margaria, "Requirements for GMPLS Applications of PCE", + RFC 7025, DOI 10.17487/RFC7025, September 2013, + . + + [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path + Computation Element Architecture", RFC 7399, + DOI 10.17487/RFC7399, October 2014, + . + [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . + [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for + Application-Based Network Operations", RFC 7491, + DOI 10.17487/RFC7491, March 2015, + . + [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . @@ -1313,86 +1307,83 @@ [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, "Hierarchical Stateful Path Computation Element (PCE)", RFC 8751, DOI 10.17487/RFC8751, March 2020, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . + [RFC8821] Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based + Traffic Engineering (TE) in Native IP Networks", RFC 8821, + DOI 10.17487/RFC8821, April 2021, + . + [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs", RFC 9050, DOI 10.17487/RFC9050, July 2021, . - [I-D.ietf-pce-pcep-flowspec] - Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow - Specification", Work in Progress, Internet-Draft, draft- - ietf-pce-pcep-flowspec-13, 14 October 2021, - . + [RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation + Element Communication Protocol (PCEP) Extension for Flow + Specification", RFC 9168, DOI 10.17487/RFC9168, January + 2022, . [I-D.ietf-pce-pcep-extension-pce-controller-sr] Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, - "PCEP Procedures and Protocol Extensions for Using PCE as - a Central Controller (PCECC) for Segment Routing (SR) MPLS - Segment Identifier (SID) Allocation and Distribution.", - Work in Progress, Internet-Draft, draft-ietf-pce-pcep- - extension-pce-controller-sr-03, 30 September 2021, + "Path Computation Element Communication Protocol (PCEP) + Procedures and Extensions for Using PCE as a Central + Controller (PCECC) for Segment Routing (SR) MPLS Segment + Identifier (SID) Allocation and Distribution.", Work in + Progress, Internet-Draft, draft-ietf-pce-pcep-extension- + pce-controller-sr-04, 6 March 2022, . + extension-pce-controller-sr-04.txt>. [I-D.li-pce-controlled-id-space] Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE Controlled ID Space", Work in Progress, Internet-Draft, - draft-li-pce-controlled-id-space-09, 22 August 2021, + draft-li-pce-controlled-id-space-10, 24 February 2022, . + id-space-10.txt>. [I-D.ietf-pce-stateful-interdomain] Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP Extension for Stateful Inter-Domain Tunnels", Work in Progress, Internet-Draft, draft-ietf-pce-stateful- - interdomain-02, 12 July 2021, + interdomain-03, 4 March 2022, . + interdomain-03.txt>. [I-D.cbrt-pce-stateful-local-protection] Barth, C. and R. Torvi, "PCEP Extensions for RSVP-TE Local-Protection with PCE-Stateful", Work in Progress, Internet-Draft, draft-cbrt-pce-stateful-local-protection- 01, 29 June 2018, . [I-D.ietf-pce-segment-routing-ipv6] Li, C., Negi, M., Sivabalan, S., Koldychev, M., Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment Routing leveraging the IPv6 data plane", Work in Progress, - Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, 27 - May 2021, . - - [I-D.ietf-teas-pce-native-ip] - Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based - Traffic Engineering (TE) in Native IP Networks", Work in - Progress, Internet-Draft, draft-ietf-teas-pce-native-ip- - 17, 1 February 2021, . + Internet-Draft, draft-ietf-pce-segment-routing-ipv6-11, 10 + January 2022, . [I-D.ietf-bier-te-arch] Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering for Bit Index Explicit Replication (BIER-TE)", Work in Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9 July 2021, . [I-D.chen-pce-bier] Chen, R., Zhang, Z., Chen, H., Dhanaraj, S., Qin, F., and @@ -1407,38 +1398,182 @@ S. Salsano, "Service Programming with Segment Routing", Work in Progress, Internet-Draft, draft-ietf-spring-sr- service-programming-05, 10 September 2021, . [I-D.ietf-spring-nsh-sr] Guichard, J. N. and J. Tantsura, "Integration of Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)", Work in Progress, Internet- - Draft, draft-ietf-spring-nsh-sr-09, 26 July 2021, + Draft, draft-ietf-spring-nsh-sr-10, 13 December 2021, . + 10.txt>. + + [I-D.ietf-idr-segment-routing-te-policy] + Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., + Jain, D., and S. Lin, "Advertising Segment Routing + Policies in BGP", Work in Progress, Internet-Draft, draft- + ietf-idr-segment-routing-te-policy-14, 10 November 2021, + . + + [I-D.ietf-spring-segment-routing-policy] + Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and + P. Mattes, "Segment Routing Policy Architecture", Work in + Progress, Internet-Draft, draft-ietf-spring-segment- + routing-policy-18, 17 February 2022, + . + + [I-D.ietf-pce-segment-routing-policy-cp] + Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. + Bidgoli, "PCEP extension to support Segment Routing Policy + Candidate Paths", Work in Progress, Internet-Draft, draft- + ietf-pce-segment-routing-policy-cp-06, 22 October 2021, + . [MAP-REDUCE] Lee, K., Choi, T., Ganguly, A., Wolinsky, D., Boykin, P., and R. Figueiredo, "Parallel Processing Framework on a P2P System Using Map and Reduce Primitives", , May 2011, . [MPLS-DC] Afanasiev, D. and D. Ginsburg, "MPLS in DC and inter-DC networks: the unified forwarding mechanism for network programmability at scale", , March 2014, . -Appendix A. Using reliable P2MP TE based multicast delivery for - distributed computations (MapReduce-Hadoop) +Appendix A. Other Use Cases of PCECC + + This section list some more advanced use cases of PCECC that were + discussed and could be worked on in future. + +A.1. Use Cases of PCECC for LSP in the Network Migration + + One of the main advantages for PCECC solution is that it has backward + compatibility naturally since the PCE server itself can function as a + proxy node of MPLS network for all the new nodes which may no longer + support the signaling protocols. + + As it is illustrated in the following example, the current network + could migrate to a total PCECC controlled network gradually by + replacing the legacy nodes. During the migration, the legacy nodes + still need to signal using the existing MPLS protocol such as LDP and + RSVP-TE, and the new nodes setup their portion of the forwarding path + through PCECC directly. With the PCECC function as the proxy of + these new nodes, MPLS signaling can populate through network as + normal. + + Example described in this section is based on network configurations + illustrated using the following figure: + + +------------------------------------------------------------------+ + | PCE DOMAIN | + | +-----------------------------------------------------+ | + | | PCECC | | + | +-----------------------------------------------------+ | + | ^ ^ ^ ^ | + | | PCEP | | PCEP | | + | V V V V | + | +--------+ +--------+ +--------+ +--------+ +--------+ | + | | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | + | | |...| |...| |...| |...| | | + | | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | | + | | Node | | Node | |Enabled | |Enabled | | Enabled| | + | +--------+ +--------+ +--------+ +--------+ +--------+ | + | | + +------------------------------------------------------------------+ + + Example: PCECC Initiated LSP Setup In the Network Migration + + In this example, there are five nodes for the TE LSP from head end + (Node1) to the tail end (Node5). Where the Node4 and Node5 are + centrally controlled and other nodes are legacy nodes. + + * Node1 sends a path request message for the setup of LSP + destinating to Node5. + + * PCECC sends to node1 a reply message for LSP setup with the path: + (Node1, if1),(Node2, if2), (Node3, if3), (Node4, if4), Node5. + + * Node1, Node2, Node3 will setup the LSP to Node5 using the local + labels as usual. Node 3 with help of PCECC could proxy the + signaling. + + * Then the PCECC will program the out-segment of Node3, the in- + segment/ out-segment of Node4, and the in-segment for Node5. + +A.2. Use Cases of PCECC for L3VPN and PWE3 + + As described in [RFC8283], various network services may be offered + over a network. These include protection services (including Virtual + Private Network (VPN) services (such as Layer 3 VPNs [RFC4364] or + Ethernet VPNs [RFC7432]); or Pseudowires [RFC3985]. Delivering + services over a network in an optimal way requires coordination in + the way that network resources are allocated to support the services. + A PCE-based central controller can consider the whole network and all + components of a service at once when planning how to deliver the + service. It can then use PCEP to manage the network resources and to + install the necessary associations between those resources. + + In the case of L3VPN, VPN labels can be assigned and distributed + through the PCECC PCEP among the PE router instead of using the BGP + protocols. + + Example described in this section is based on network configurations + illustrated using the following figure: + + +-------------------------------------------+ + | PCE DOMAIN | + | +-----------------------------------+ | + | | PCECC | | + | +-----------------------------------+ | + | ^ ^ ^ | + |PWE3/L3VPN | PCEP PCEP|LSP PWE3/L3VPN|PCEP | + | V V V | + +--------+ | +--------+ +--------+ +--------+ | +--------+ + | CE | | | PE1 | | NODE x | | PE2 | | | CE | + | |...... | |...| |...| |.....| | + | Legacy | |if1 | PCECC |if2|PCCEC |if3| PCECC |if4 | Legacy | + | Node | | | Enabled| |Enabled | |Enabled | | | Node | + +--------+ | +--------+ +--------+ +--------+ | +--------+ + | | + +-------------------------------------------+ + + Example: Using PCECC for L3VPN and PWE3 + + In the case PWE3, instead of using the LDP signaling protocols, the + label and port pairs assigned to each pseudowire can be assigned + through PCECC among the PE routers and the corresponding forwarding + entries will be distributed into each PE routers through the extended + PCEP protocols and PCECC mechanism. + +A.3. Use Cases of PCECC for Local Protection (RSVP-TE) + + [I-D.cbrt-pce-stateful-local-protection] describes the need for the + PCE to maintain and associate the local protection paths for the + RSVP-TE LSP. Local protection requires the setup of a bypass at the + PLR. This bypass can be PCC-initiated and delegated, or PCE- + initiated. In either case, the PLR MUST maintain a PCEP session to + the PCE. The Bypass LSPs need to mapped to the primary LSP. This + could be done locally at the PLR based on a local policy but there is + a need for a PCE to do the mapping as well to exert greater control. + + This mapping can be done via PCECC procedures where the PCE could + instruct the PLR to the mapping and identify the primary LSP for + which bypass should be used. + +A.4. Using reliable P2MP TE based multicast delivery for distributed + computations (MapReduce-Hadoop) MapReduce model of distributed computations in computing clusters is widely deployed. In Hadoop (https://hadoop.apache.org/) 1.0 architecture MapReduce operations on big data in the Hadoop Distributed File System (HDFS), where NameNode has the knowledge about resources of the cluster and where actual data (chunks) for particular task are located (which DataNode). Each chunk of data (64MB or more) should have 3 saved copies in different DataNodes based on their proximity. @@ -1542,82 +1677,81 @@ Phase 3. NameNode SHOULD send this information to client, PCECC informs client about optimal P2MP path towards DataNodes via PCEP message. Phase 4. Client sends data blocks to those DataNodes for writing via created P2MP tunnel. When this task will be finished, P2MP tunnel could be turned down. +Appendix B. Contributor Addresses +Following authors contributed text for this document and should be considered as co-authors: + + Luyuan Fang + Expedia, Inc. + United States of America + + Email: luyuanf@gmail.com + + Chao Zhou + HPE + + Email: chaozhou_us@yahoo.com + + Boris Zhang + Telus Communications + + Email: Boris.zhang@telus.com + + Artem Rachitskiy + Mobile TeleSystems JLLC + Nezavisimosti ave., 95 + 220043, Minsk + Belarus + + Email: arachitskiy@mts.by + + Anton Gulida + LLC "Lifetech" + Krasnoarmeyskaya str., 24 + 220030, Minsk + Belarus + + Email: anton.gulida@life.com.by + Authors' Addresses Zhenbin (Robin) Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China - Email: lizhenbin@huawei.com Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore Karnataka 560066 India - Email: dhruv.ietf@gmail.com Quintin Zhao Etheric Networks 1009 S CLAREMONT ST SAN MATEO, CA 94402 United States of America - Email: qzhao@ethericnetworks.com King Ke Tencent Holdings Ltd. Shenzhen China - Email: kinghe@tencent.com + Boris Khasanov Yandex LLC Ulitsa Lva Tolstogo 16 Moscow - Email: bhassanov@yahoo.com - - Luyuan Fang - Expedia, Inc. - United States of America - - Email: luyuanf@gmail.com - - Chao Zhou - HPE - - Email: chaozhou_us@yahoo.com - - Boris Zhang - Telus Communications - - Email: Boris.zhang@telus.com - - Artem Rachitskiy - Mobile TeleSystems JLLC - Nezavisimosti ave., 95 - 220043, Minsk - Belarus - - Email: arachitskiy@mts.by - - Anton Gulida - LLC "Lifetech" - Krasnoarmeyskaya str., 24 - 220030, Minsk - Belarus - - Email: anton.gulida@life.com.by