Network Working group H. Bidgoli, Ed. Internet Draft Nokia Intended status: Standard Track D. Yoyer, Ed. Bell Canada S. Rajarathinam J. Kotalwar Nokia S. Sivabalan Cisco System, Inc. Expires: September 12, 2019 March 11, 2019 PCEP extensions for p2mp sr policy draft-dhs-spring-pce-sr-p2mp-policy-00 Abstract SR P2MP policies are set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaves. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Bidgoli, et al. Expires September 12, 2019 [Page 1] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 This Internet-Draft will expire on October 8, 2017. Copyright Notice Copyright (c) 2019 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/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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. Overview of PCEP Operation in SR P2MP Network . . . . . . . . . 3 3.1. P2MP Identification . . . . . . . . . . . . . . . . . . . . 4 3.2 High-Level Procedures for P2MP SR LSP Instantiation . . . . 4 3.2.1. New Objects for SR P2MP LSP instantiation . . . . . . . 5 3.3. High-Level Procedures for P2MP Global Optimization . . . . 5 3.4. High-Level Procedures for Fast Reroute . . . . . . . . . . 6 4. Object Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Open Message and Capability Exchange . . . . . . . . . . . 7 4.2. Symbolic Name in PCInitiate message from PCC . . . . . . . 7 4.3. PCE Update, Root Report message . . . . . . . . . . . . . . 8 4.3.1 Extension of the LSP Object, SR-P2MP-LSPID-TLV . . . . . 8 4.3.2 END-POINTS Objects . . . . . . . . . . . . . . . . . . . 9 4.4. PCInitiate Message and P2MP Tree Instantiation . . . . . . 12 4.4.1. New SR-P2MP-CCI Object . . . . . . . . . . . . . . . . 13 4.4.2. New Optional IPv4-ADDRESS TLV . . . . . . . . . . . . . 13 4.4.3. UNNUMBERED IPV4-ID-ADDRESS TLV: . . . . . . . . . . . . 15 4.4.4. New Optional IPv6-ADDRESS TLV . . . . . . . . . . . . . 15 4.5. Global Optimization and Make Before Break . . . . . . . . . 15 4.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 16 5. Example workflow . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 19 Bidgoli, et al. Expires September 12, 2019 [Page 2] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The draft draft-voyer-spring-sr-p2mp-policy defines a variant of the SR Policy [I-D. ietf-spring-segment-routing-policy] for constructing a P2MP segment to support multicast service delivery. We call it an SR Replication Policy. A Point-to-Multipoint (P2MP) segment connects a Root node to a set of Leaf nodes in a Segment Routing Domain. We define two types of a P2MP segment: Spray and Tree. Spray P2MP segment enables a Root node to directly replicate a packet using a SR path to each Leaf node. For a TreeSID P2MP segment, a controller computes a tree from a Root node to a set of Leaf nodes via a set of Replication nodes. A packet is replicated at the Root node and on Replication nodes towards each Leaf node. For a TreeSID the tree can be built manually via the PCE or PCC by indicating the root and the leaves or dynamically via MVPN procedures, where the root of a tree discovers the leafs via MVPN procedures and updates the PCE of the root and the set of leaves. In either case the PCE computes and programs the P2MP Tree on the PCCs. In all of above cases a set of new PCEP object and TLVs are needed to update and instantiate the P2MP tree. This draft explains the procedure needed to instantiate a P2MP TreeSID. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Overview of PCEP Operation in SR P2MP Network For a Tree P2MP SR policy, TreeSID network, a PCE calculates a P2MP tree and programs the Root, Replication and Leaf nodes with information needed to forward a multicast stream from the root to a set of leaves. The PCE discovers the Root and the set of the Leaves via manual configuration on the PCE or PCC providing the PCE with the relevant information. The PCC can discover the Root and the leaves via MVPN procedures or via manual configuration. Bidgoli, et al. Expires September 12, 2019 [Page 3] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 After discovering the Root and Leaves and computing the MPLS P2MP Tree and identifying the Replication routers, the PCE programs the PCCs with relevant information needed to create a P2MP Tree from the Root to the set of the Leaves. This information specifies label operation on the relevant nodes. As an example for a label Push operation, outgoing interface and their corresponding labels are programmed on the PCC via the PCE. In the case of swap operation, an incoming label and a set of outgoing interfaces and their corresponding labels are programmed on the PCCs. In the Case of pop operation, incoming label that needs to be removed is programmed. PCE could also calculate and download additional information such as next-hops for link/node protection or initiate a make-before-brake for P2MP Path optimization. 3.1. P2MP Identification The key to identify a P2MP LSP is in LSP object and is as follow: PLSP-ID: RFC 8231, is assigned by PCC and is unique per LSP that is constant for the lifetime of a PCEP session. When an LSP is being globally optimized it will maintain its PLSP-ID over the 2 instances of the LSP, the current LSP and the new optimized LSP. It is possible to establish standby P2MP LSPs to protect primary P2MP SR policies, and standby P2MP LSPs can be co-exist along with primary P2MP LSP. Since PLSP-ID is unique per LSP, each standby P2MP LSP has a unique PLSP-ID. LSP-ID: is assigned by PCE for each PLSP-ID. It is used for global optimization of an existing LSP via Make-Before-Break (MBB) procedures. An optimized P2MP LSP is instantiated with the same PLSP- ID but a unique LSP-ID. MBB procedures first switches traffic from the previous to the new P2MP LSP, and then destroys the previous P2MP LSP. P2MP-ID: is equivalent to Path Identifier which identifies a unique P2MP segment at a ROOT and is advertised via the PTA in the BGP AD route. IPv4/IPv6 Sender Address: is equivalent to the first MPLS node on the path, as per [RFC3209], Section 4.6.2.1 3.2 High-Level Procedures for P2MP SR LSP Instantiation A P2MP LSP's ROOT and Leaves can be discovered via MVPN procedures or static configuration of the ROOT and Leaves on the PCE or PCC. In case of MVPN Procedures, PCC will use Report messages to update Bidgoli, et al. Expires September 12, 2019 [Page 4] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 the PCE with discovered leaf or a set of leaves as per P2MP [draft- sr-mvpn-procedure or alike]. PCC will assign a PLSP-ID and use the P2MP-ID it had specified in the BGP MVPN PTA. PCC will update the PCE with the root and discovered leaves via a PCRpt message. Note the LSP-ID will be set to 0 or NA in this first report message as the PCE has not instantiated the P2MP LSP yet. PCE will instantiate the P2MP LSP and update PCC (root, transit and leaves) via a PCInit message. The PCInit message will contain a valid LSP-ID assigned by PCE for this P2MP path. It will also download the corresponding label and local protection (Fast Re-Route) information. In short, each P2MP LSP will have a unique PLSP-ID assigned by PCC and LSP-ID assigned by PCE. This is true for LSP redundancy where the Primary LSP is protected by one or multiple backup LSPs. The backup LSPs will have a unique PLSP-ID and LSP-ID. PCE will use the same PLSP-ID and LSP-ID for any new leaves that are discovered from here on. If these leaves are discovered on routers that are part of the P2MP LSP path, then PCUpd is sent from PCE to necessary PCCs (root, transit and leaves) with the PLSP-ID and LSP-ID. If the new leaves are discovered that are not part of the P2MP Tree yet, then an PCInit message is sent down to the relevant transit and/or leaf nodes with the current PLSP-ID and LSP-ID. 3.2.1. New Objects for SR P2MP LSP instantiation A new object is defined for the controller to specify the forwarding instructions (label instructions). This can be included in PcRpt, PcInitiate and PcUpd messages. It should be noted that every PcRpt, PcInitiate and PCUpd messages will contain full list of the Leaves and labels and forwarding information that is needed to build the P2MP LSP. They will never send the delta information related to the new leaves that need to be added or updated. This is necessary to ensure that PCE or any new discovered PCE is in sync with the PCC. As such when a PcReport, PcInitiate and PCUPdate messages is send via PCEP it maintains the previous instruction CC-IDs and create new CC- ID for the new instruction. This means the CC-IDs are maintained for each specific forwarding and label instructions until these instructions are deleted. 3.3. High-Level Procedures for P2MP Global Optimization When a P2MP LSP needs to be optimized for any reason (i.e. it is taking a FRR Path or new routers are added to the network) a global optimization is possible. After the optimized LSP is downloaded a MBB Bidgoli, et al. Expires September 12, 2019 [Page 5] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 procedure is performed and the previous instance of the LSP is deleted and removed from the corresponding PCCs. The globally optimized LSP is instantiated via the PCInitiate message. The PLSP-ID of this optimized LSP is same as the Current LSP which is being optimized. That said the LSP-ID of the optimize LSP is uniquely assigned by PCE and is different from that of thecurrent LSP which is being optimized. In short, the LSP-ID uniquely identifies sub- instances of an LSP for optimization. After the optimized LSP has been downloaded and verified via PCC PCRpt message, the MBB procedure can be performed to switch between the 2 instances of the LSP. The previous instance will be removed from PCCs. 3.4. High-Level Procedures for Fast Reroute Currently this draft identifies the Facility FRR procedures. In addition, only LINK Protection procedures are defined. How the Facility Path is built and instantiated is beyond the scope of this document. R | | T | --- | | L1 L2 Figure 1 R---F1 | | T---F2 | --- | | L1 L2 Figure 2 As an example, the bypass path (unicast bypass) between the PLR and MP can be constructed via SR. The PCE needs to only update the PLR PCC with bypass path outgoing label and nexthop information, also PCE needs to update the MP PCC with bypass path ILM information. This information is presented via a P bit in the optional IPv4/IPv6- Address object as per section 4.4.2, 4.4.3, 4.4.4. If one to one FRR is needed, then a second flag O should be defined Bidgoli, et al. Expires September 12, 2019 [Page 6] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 in the IPv4/IPv6-Address object in future. As an example, in figure 1 the detour path between R and T is the 2nd fiber between these nodes. As such the bypass path could be setup on the 2nd fiber using treeSID procedures. That said in figure 2 the bypass path is traversing multiple nodes and this example a unicast SR path might be ideal for setting up the detour path. The PCE can download the prefix SID for F2 as a bypass path for R-T to R. Downloading the prefix SID for F2 will ensure an LFA detour for R-T. In addition, PHP procedure and implicit null label on the bypass path can be implemented to reduce the PCE programming on the MP PCC. 4. Object Format 4.1. Open Message and Capability Exchange Format of the open object 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Flags | Keepalive | DeadTimer | SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All the nodes need to establish a PCEP connection with the PCE. During PCEP session establishment phase, PCEP Speakers advertise their capabilities to support PCECC extensions to include the new Path Setup Type as per draft-ietf-pce-pcep-extension-for-pce- controller-00. In addition they need to set flags N, M, P in the STATEFUL-PCE-CAPABILITY TLV as defined in draft-ietf-pce-stateful- pce-p2mp-08 section-5.2. We extend the PCEP OPEN object by defining an optional TLV to indicate the PCE's capability to perform SR-P2MP path computations, New IANA capability type. The inclusion of this TLV in an OPEN object indicates that the sender can perform SR-P2MP path computations. This will be similar to the P2MP-CAPABILITY defined in rfc8306 section- 3.1.2 and a new value needs to be defined for SR-P2MP. 4.2. Symbolic Name in PCInitiate message from PCC As per RFC8231 section 7.3.2. a Symbolic Path Name TLV should uniquely identify the P2MP path on the PCC. This symbolic path name is a human-readable string that identifies an P2MP LSP in the Bidgoli, et al. Expires September 12, 2019 [Page 7] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 network. It needs to be constant through the life time of the P2MP path. As an example in the case of P2MP LSP the symbolic name can be the source IP + P2MP-ID of the LSP. The P2MP-ID is a unique ID that identifies the P2MP on the Root (Source) as such the combination of Source IP + P2MP-ID will provide the P2MP LSP with a unique identification throughout the network. Depending on the Source IP, IPv4 vs. IPv6, the length of the TLV will vary. 4.3. PCE Update, Root Report message The Root node on reception of a P2MP path request, via MVPN procedures or manual Configuration on the PCCs, will initiates an Report to PCE through a PCRpt message. The format of the PC Report message is as follows: [] [ | ] 4.3.1 Extension of the LSP Object, SR-P2MP-LSPID-TLV The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies the PLSP-ID to uniquely identify an LSP that is constant for the life time of a PCEP session. Similarly for a P2MP tunnel, the PLSP-ID identify a P2MP TE LSP uniquely. The LSP Object MUST include the new SR-P2MP-LSPID-TLV (IPV4/IpV6). This is a variation to the P2MP object defined in draft-ietf-pce- stateful-pce-p2mp-08 SR-IPV4-P2MP-LSP-IDENTIFIER TLV: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length=12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Tunnel Sender Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID(color) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bidgoli, et al. Expires September 12, 2019 [Page 8] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 SR-IPV6-P2MP-LSP-IDENTIFIER TLV : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length=20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 tunnel sender address | + (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID(color) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type (16-bit) of the TLV is TBD (need allocation by IANA). LDS ID: is a unique ID assigned by PCE to indicate sub-instances of an P2MP LSP for global or local optimization IPv4/IPv6 Sender address: contains the sender node's IP address (Root Node) P2MP ID (Color): contains the 32-bit 'P2MP ID' identifier used in the PTA of BGP AD Route. 4.3.2 END-POINTS Objects In order for the Root to indicate the leaves and its corresponding operation (Add/Remove/Modify/DoNotModify), the PC Report message is extended to include P2MP End Point Object which is defined in rfc8306 IPV4-P2MP END-POINTS: Bidgoli, et al. Expires September 12, 2019 [Page 9] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPV6-P2MP END-POINTS: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Leaf Types (derived from RFC 8306 section 3.3.2) : 1.New leaves to add (leaf type = 1) 2.Old leaves to remove (leaf type = 2) 3.Old leaves whose path can be modified/reoptimized (leaf type = 3), Future reserved not used for tree SID as of now. 4.Old leaves whose path must be left unchanged (leaf type = 4) A given P2MP END-POINTS object gathers the leaves of a given type. Bidgoli, et al. Expires September 12, 2019 [Page 10] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 Note that a P2MP report can mix the different types of leaves by including several P2MP END-POINTS objects. The END-POINTS object body has a variable length. These are multiples of 4 bytes for IPv4, multiples of 16 bytes, plus 4 bytes, for IPv6. A sample Report message of a P2MP tunnel request, and leaf Add report is noted below: Note as it was mentioned before: P2MP-ID (color) = Tunnel Identifier color which identifies a unique P2MP segment at the Root and is advertised via the PTA (BGP) LSP ID is used for Global optimization of the P2MP Tree. contains the 16-bit 'LSP ID' identifier P2MP Tunnel Request, Report generated by the Root to the PCE. The Root should populate the Tunnel-sender Addr, P2MP-ID(color), PLSP-ID. While the LSP ID is set to 0 for the PCE to assign. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRP-ID-number = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = 28 (PathSetupType)| TLV Len = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PST = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLSP-ID = X | A:1,D:1,N:1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID = 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Tunnel Sender Address = x.y.z.w | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP_ID(color) = Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Report generated by the Root to the PCE for Leaf Add Bidgoli, et al. Expires September 12, 2019 [Page 11] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRP-ID-number = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = 28 (PathSetupType)| TLV Len = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PST = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLSP-ID = X | A:1,D:1,N:1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID = 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Tunnel Sender Address = x.y.z.w | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP_ID(color) = Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf type =1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 address = x.y.z.w | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address = a.b.c.d | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address = a.b.c.e | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.4. PCInitiate Message and P2MP Tree Instantiation In response to a new leaf add PCRpt message, the PCE calculates the path and assigns labels along the path and sets up the path by sending a PCInitiate Message(label download) to each node along the path (Root, transits nodes and leaves). A new object is defined for the controller to specify the forwarding instructions (label instructions). This can be included in PCRpt, PcInitiate and PcUpdate messages. For optimization it is recommended for the PCE to send the PCInitiate message starting from the LEAVES to the Transit nodes and finally the Root. The transit and leaf nodes generate a Path Computation State Report (PCRpt) with SR-P2MP-LSP-ID TLV and SR-P2MP-CCI object to indicate the state of the label download. Once the controller gets a report from all the leaves and transit nodes that the label download was Bidgoli, et al. Expires September 12, 2019 [Page 12] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 successful, it will send a PCInit Message with the SR-P2MP-CCI object(label instruction) to the Root node. A successful report (including SR-P2MP-CCI object and P2MP LSP ID TLV) back from the root for the label download, means the P2MP policy is successfully UP. The PLSP-ID used in the PCInitiate message is the original identifier used by the ingress PCC, so the transit LSR could have multiple central controller instructions that have the same PLSP-ID. The PLSP-ID in combination with the SR-P2MP-LSP-ID-TLV MUST be unique. Format of PC Initiate Message: Format of Pc Update Message: is like PC Initiate Message, but the Create Bit in the LSP Object will be Set to 0. 4.4.1. New SR-P2MP-CCI Object This is a variation of the CC-ID object defined in draft-ietf-pce- pcep-extension-for-pce-controller-00 SR-P2MP-CCI Object-Class is TBD. CCI Object-Type is 1 for the MPLS Label. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLV // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CC-ID: A PCEP-specific identifier for the CCI information. A PCE creates an CC-ID for each instruction, the value is unique within the scope of the PCE and is constant for the lifetime of a PCEP session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. Flags: O - 0 - Down - means label download was not successful 1 - Up - means label download was successful 4.4.2. New Optional IPv4-ADDRESS TLV Bidgoli, et al. Expires September 12, 2019 [Page 13] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 The IP-Address TLVs download the label and its instructions to the PCC. These instructions could include information about local Protection information or if the label is an incoming label or an outgoing label. Additionally they could identify a node as a BUD node or just a transit node. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | Rsvd | Flag|I|B|S|E|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: I - Incoming Label: If set means In Label, If not set means Out Label. B - Bud Node Label: If set this label is a bud node, the payload needs to be processed locally and also replicated if the S bit is set. In short if B is set then S needs to set also. S - SWAP label: 0: If I bit is set and S bit is 0 it means pop the label and if the label's S bit is set do a recursive lookup. 1 - If I bit is set and S bit is 1 it means swap this label with out label. P - Protection NextHop 0 - Label information is not w.r.t protection next-hop. 1 - Label information is w.r.t protection next-hop. Note: P flag is used at the PLR and MP to identify the facility tunnel. E - Protected LTN, This bit is usually set with the an outgoing label, when the outgoing label is protected via a Bidgoli, et al. Expires September 12, 2019 [Page 14] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 protection nextHop 0 - Label information does not have a protection next- hop. 1 - Label information has a protection next-hop. IPV4 address and Interface Id: correspond to the next-hop information in case of an OUT Label, and it corresponds to incoming interface information if it is an IN Label. 4.4.3. UNNUMBERED IPV4-ID-ADDRESS TLV: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | Rsvd | Flag|I|B|S|E|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.4.4. New Optional IPv6-ADDRESS TLV 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | Rsvd | Flag|I|B|S|E|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // IPv6 address (16 bytes) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.5. Global Optimization and Make Before Break If controller optimizes a tree for any reason, it will download the tree with same PLSP-ID and P2MP-ID (Color) but a new LSP-ID . Bidgoli, et al. Expires September 12, 2019 [Page 15] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 The new optimize LSP is downloaded via the same mechanisms explained above and a new LSP-ID for this instance of the LSP. After the new tree is established and the report messages arrive from the source, transit and leaf nodes confirming successful download, the previous tree is deleted starting from the root. This delete of the previous LSP-ID will force the root to do a switch (MBB) to the new LSP-ID P2MP tree. 4.6. Tree Deletion To delete the entire tree (P2MP LSP) , Root send a PCRpt message with the R bit of the LSP object set and all the fields of the SR-P2MP- LSP-ID TLV set to 0(indicating to remove all state associated with this P2MP tunnel). The controller in response sends a PCInitiate message with R bit in the SRP object SET to all nodes along the path to indicate deletion of a label entry. 4.7. Fragmentation The Fragmentation bit in the LSP object (F bit) can be used to indicate a fragmented PCEP message. 5. Example workflow In the workflow below after discovering the root and leaf nodes via MVPN procedures the root generates a PCRpt message to the PCE with the discovered root and leaves via the endpoint objects, which in order forces the PCE to compute the P2MP Tree and generates a PCInititate to the Root, downloading the label information to the Root, Bud/Transit and Leaves. A PC Initiate message on Root,transit and leaf nodes - indicates a new label instruction and the existing label instruction should remain unmodified(if any present). If the old instructions are no longer needed, a PC Update message indicating the old label instructions and the R bit in the LSP object SET is sent to the nodes(to remove the labels). A PCUpd message on any node (root, transit or leaf) - indicates an overwrite of the existing label instruction if any present. A sample message flow is depicted below: When leaves(C,D) are discovered, at R a PCInitiate with 2 label instruction is instantiated by the PCE. The two labels correspond to an egress label and a protection nextHop for FRR. The PCE will download a PCInitiate message with CC-ID X, egress label(A), flag Bidgoli, et al. Expires September 12, 2019 [Page 16] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 E(as the Protection NextHOP CCID will Follow) and a IPv4 nextHop of N1, in addition CC-ID Y = egress label (B), flag P(as it is a protection NextHOP) and IPv4 nextHop of N2, are instantiated by the PCE. The Root will use a PCRpt message to acknowledge this initiate. The PC will also download the necessary information to the BUD/Transit router. In case of the BUD/Transit router the flags are set. This means that for the incoming label the label should be swapped with an outgoing label, but also the payload should be replicated and a copy forwarded locally as there is a BUD present on this router. The BUD/Transit node will use a PCRpt message to acknowledge this update as well. The Leafs (not shown) will also get the PCInit message with Flag of only which indicates a pop and forward operation. Bidgoli, et al. Expires September 12, 2019 [Page 17] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 N4-------------------- | | | +-------+ +-------+ +-------+ | N3--|LEAF C | |LEAF D | | PCE | | | | | | | +-------+ +------| | | | | N2---- | | | | | |N1-- | Bud/ +-------+ +-------+ | | | | Transit| | | | +------| B | | | | |ROOT +--------+ | | | |A | | | | | +--------+ | | | | | | | | | | MVPN Procedures to discover the ROOT and the LEAVES | | | | | | |---PCRpt:SRP-ID=TBD,PLSP-ID=1,S=A,P2MP-ID=A,LSP-ID=NA | | endpoint=------------------->| | | | | | | | | | | |<--PCInit:SRP-ID=1,PLSP-ID=1,S=A,P2MP-ID=A,LSP-ID=1 | | | P2MPCCI:CCID=X,Flag=E,Label=A,IPv4=N1 -----| | | P2MPCCI:CCID=Y,Flag=P,Label=B,IPv4=N2 | | | | | | |---PCRpt:SRP-ID=1,PLSP-ID=1,S=A,P2MP-ID=1,LSP-ID=1 | | P2MPCCI:CCID=X,Y---------------------------->| | | | | | | | | | | | |<-PCInit:SRP-ID=2,PLSP-ID=1,S=A,P2MP-ID=A | | | | LSP-ID=1,---------------------- | | | | P2MPCCI:CCID=X2,FLAG=,Label=C | | | | P2MPCCI:CCID=Y2,FLAG=0,Label=D, | | | | IPv4=N3 | | | | P2MPCCI:CCID=Z2,FLAG=0,Label=E, | | | | IPv4=N4 | | | | | | | | PCRpt:SRP-ID=2,PLSP-ID=1,S=A,P2MP-ID=A, | | |------ LSP-ID=1,--------------------------->| | | | P2MPCCI:CCID=X2,Y2,Z2 | | | | | | 6. IANA Considerations This document contains no actions for IANA. 7. Security Considerations TBD Bidgoli, et al. Expires September 12, 2019 [Page 18] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 8. References 8.1. Normative References 8.2. Informative References [sr-p2mp-policy] D. Yoyer, Ed., C. Hassen, K. Gillis, C. Filsfils, R. Parekh, H.Bidgoli, "SR Replication Policy for P2MP Service Delivery", draft-voyer-spring-sr-p2mp-policy-01, April 2019. 7. Acknowledgments The authors would like to thank Tanmoy Kundu at Nokia for his feedback and major contribution to this draft. Authors' Addresses Hooman Bidgoli Nokia 600 March Rd. Ottawa, Ontario K2K 2E6 Canada Email: hooman.bidgoli@nokia.com Daniel Voyer Bell Canada Montreal CA Email: daniel.voyer@bell.ca Siva Sivabalan Cisco Systems Ottawa Canada Email: msiva@cisco.com Jayant Kotalwar Nokia 380 N Bernardo Ave, Mountain View, CA 94043 US Email: jayant.kotalwar@nokia.com Bidgoli, et al. Expires September 12, 2019 [Page 19] Internet-Draft MLDP Stitching Through BIER Core March 11, 2019 Saranya Rajarathinam Nokia 380 N Bernardo Ave, Mountain View, CA 94043 US Email: saranya.rajarathinam@nokia.com Bidgoli, et al. Expires September 12, 2019 [Page 20]