idnits 2.17.1 draft-ietf-bess-mvpn-evpn-sr-p2mp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 09, 2021) is 1022 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 769 -- Looks like a reference, but probably isn't: '2' on line 772 -- Looks like a reference, but probably isn't: '3' on line 774 -- Looks like a reference, but probably isn't: '4' on line 776 -- Looks like a reference, but probably isn't: '5' on line 778 -- Looks like a reference, but probably isn't: '6' on line 780 -- Looks like a reference, but probably isn't: '7' on line 782 -- Looks like a reference, but probably isn't: '8' on line 784 -- Looks like a reference, but probably isn't: '9' on line 786 -- Looks like a reference, but probably isn't: '10' on line 788 -- Looks like a reference, but probably isn't: '11' on line 790 -- Looks like a reference, but probably isn't: '12' on line 793 -- Looks like a reference, but probably isn't: '13' on line 795 == Missing Reference: 'RFC 7538' is mentioned on line 592, but not defined ** Obsolete undefined reference: RFC 7538 (Obsoleted by RFC 9110) == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-07 == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-02 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-04 == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-08 == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-irb-mcast-05 == Outdated reference: A later version (-06) exists of draft-ietf-bess-evpn-mvpn-seamless-interop-02 == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-06 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Parekh 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track A. Venkateswaran 5 Expires: January 10, 2022 Cisco Systems, Inc. 6 H. Bidgoli 7 Nokia 8 D. Voyer 9 Bell Canada 10 Z. Zhang 11 Juniper Networks 12 July 09, 2021 14 Multicast and Ethernet VPN with Segment Routing P2MP 15 draft-ietf-bess-mvpn-evpn-sr-p2mp-03 17 Abstract 19 A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries 20 traffic from a Root to a set of Leaves. This document describes 21 extensions to BGP encodings and procedures for P2MP trees and Ingress 22 Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment 23 Routing domain. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 10, 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. SR P2MP P-Tunnels . . . . . . . . . . . . . . . . . . . . . . 3 67 3. PMSI Tunnel Attribute for SR P2MP . . . . . . . . . . . . . . 4 68 3.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. MVPN Auto-Discovery and Binding Procedures for P2MP Trees . . 5 71 4.1. Intra-AS I-PMSI . . . . . . . . . . . . . . . . . . . . . 6 72 4.1.1. Originating Intra-AS I-PMSI routes . . . . . . . . . 6 73 4.1.2. Receiving Intra-AS I-PMSI A-D routes . . . . . . . . 6 74 4.2. Using S-PMSIs for binding customer flows to P2MP Segments 7 75 4.2.1. Originating S-PMSI A-D routes . . . . . . . . . . . . 7 76 4.2.2. Receiving S-PMSI A-D routes . . . . . . . . . . . . . 8 77 4.3. Inter-AS P-tunnels using P2MP Segments . . . . . . . . . 8 78 4.3.1. Advertising Inter-AS I-PMSI routes into iBGP . . . . 8 79 4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP . . . . 9 80 4.4. Leaf A-D routes for P2MP Segment Leaf Discovery . . . . . 9 81 4.4.1. Originating Leaf A-D routes . . . . . . . . . . . . . 9 82 4.4.2. Receiving Leaf A-D routes . . . . . . . . . . . . . . 9 83 5. MVPN with Ingress Replication over Segment Routing . . . . . 10 84 5.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 5.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 5.2.1. SRv6 Multicast Endpoint Behaviors . . . . . . . . . . 11 87 6. Dampening of MVPN routes . . . . . . . . . . . . . . . . . . 12 88 7. SR P2MP Trees for EVPN . . . . . . . . . . . . . . . . . . . 12 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 92 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 95 12.2. Informative References . . . . . . . . . . . . . . . . . 16 96 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 Multicast in MPLS/BGP IP VPNs [RFC6513] and BGP Encodings and 102 Procedures for Multicast in MPLS/BGP IP VPNs [RFC6514] specify 103 procedures that allow a Service Provider to provide Multicast VPN 104 (MVPN) service to its customers. Multicast traffic from a customer 105 is tunneled across the service provider network over Provider Tunnels 106 (P-Tunnels). P-Tunnels can be instantiated via different 107 technologies. A service provider network that uses Segment Routing 108 can use a Point-to-Multipoint (SR P2MP) tree 109 [I-D.ietf-pim-sr-p2mp-policy] or P2MP Ingress Replication to 110 instantiate P-Tunnels for MVPN. SR P2MP P-Tunnels can be realized 111 both for SR-MPLS [RFC8660] and SRv6 [RFC8986][RFC8754]. 113 In a Segment Routing network, a P2MP tree allows efficient delivery 114 of traffic from a Root to set of Leaf nodes. A SR P2MP tree is 115 defined by a SR P2MP Policy and instantiated via a PCE. A P2MP 116 Policy consists of a Root, a Set of Leaf Nodes and a set of candidate 117 paths with optional set of constraints and/or optimization objectives 118 to be satisfied by the P2MP tree. A unique Identifier, called Tree- 119 SID, is associated with a P2MP tree. This Tree-SID can be an MPLS 120 label or an IPv6 address. 122 This document describes extensions to BGP Auto-Discovery procedures 123 specified in RFC 6514 for SR P2MP P-Tunnels. Use of PIM for Auto- 124 Discovery is outside scope of this document. Support for customer 125 BIDIR-PIM is outside the scope of this document. 127 For BGP MPLS Ethernet VPN specified in [RFC7432] and extensions to 128 this document, P-Tunnels are advertised for handling multi- 129 destination traffic. These P-Tunnels can be realized by SR-MPLS or 130 SRv6 P2MP trees. SRv6 P2MP trees can also be used to support 131 Multicast in Network Virtualization over Layer 3 [RFC8293]. 133 The reader is expected to be familiar with concepts and terminology 134 of RFC 6513, RFC 6514 and SR P2MP drafts. 136 2. SR P2MP P-Tunnels 138 For MVPN or EVPN, Provider Edge(PE) routers steer customer traffic 139 into a P-Tunnel that can be instantiated by a SR-MPLS or SRv6 P2MP. 140 A SR P2MP tree is defined by a SR P2MP policy 141 [I-D.ietf-pim-sr-p2mp-policy]. 143 Given a SR P2MP policy, a PCE computes and instantiates the SR P2MP 144 tree on the nodes that are part of the tree by stitching Replication 145 segments [I-D.ietf-spring-sr-replication-segment] at Root, Leaf and 146 intermediate replication nodes. Tree-SID is an unique identifier for 147 the tree. A Replication segment of a SR P2MP tree can be initiated 148 by various methods (BGP, PCEP, others) which are outside the scope of 149 this document. 151 A PCE provides conceptual APIs, listed below, to define and modify SR 152 P2MP policies SR P2MP Policy Section 4.1.1 [1]. These APIs are 153 invoked by a PCC, which is the root of P2MP tree, using various 154 methods (BGP, PCEP, etc.) which are outside the scope of this 155 document. 157 CreatePolicy: CreateSRP2MPPolicy 159 DeletePolicy: DeleteSRP2MPPolicy 161 UpdateLeafSet: SRP2MPPolicyLeafSetModify 164 The Root of a P2MP tree imposes the Tree-SID to steer the customer 165 payload into the P2MP tree. Provider (P) routers replicate customer 166 payload, using Replication segments, towards the Leaf nodes of the 167 P2MP tree. Leaf nodes of the P2MP tree deliver the customer payload 168 after disposing the Tree-SID. 170 An Ingress PE can deliver payload to egress PEs of the service using 171 Ingress Replication. This payload is encapsulated in SR-MPLS or SRv6 172 and replicated to each egress PE. 174 3. PMSI Tunnel Attribute for SR P2MP 176 BGP PMSI Tunnel Attribute (PTA) is defined in RFC 6514 to identify 177 the P-Tunnel that is used to instantiate a Provider Multicast Service 178 Interface (PMSI). The PTA is carried in Intra-AS I-PMSI, Inter-AS 179 I-PMSI, Selective PMSI, and Leaf Auto-Discovery routes. 181 A P2MP tree PTA is constructed as specified below. 183 o Tunnel Type: The IANA assigned codepoint 0x0C for "SR-MPLS P2MP 184 Tree" or codepoint [[CREF1: TBD]]for "SRv6 P2MP Tree", from the 185 "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" 186 registry. 188 o Flags: See Section 4 for use of "Leaf Info Required bit". 190 o MPLS Label: See Section 3.1 191 o Tunnel Identifier: The SR P2MP P-Tunnel is identified by where, 194 * Tree-ID is a 32-bit unsigned value that identifies a unique 195 P2MP tree at a Root. 197 * Root is an IP address identifying the Root of a P2MP tree. 198 This can be either an IPv4 or IPv6 address and can be inferred 199 from the PTA length. 201 When a P-Tunnel is non-segmented, the PTA is created by PE router at 202 the Root of a SR P2MP tree. For segmented P-Tunnels, each segment 203 can be instantiated by a different technology. If a segment is 204 instantiated using P2MP tree, the router at the root of a P2MP tree 205 creates the PTA. 207 3.1. MPLS Label 209 [RFC6514] allows a PE to aggregate two or more MVPNs onto one 210 P-Tunnel by advertising the same P-Tunnel in PTA of Auto-Discovery 211 routes of different MVPNs. This section specifies how the "MPLS 212 Label" field of PTA is filled to provide a context bound to a 213 specific MVPN. Aggregating MVPNs on one SRv6 P2MP P-Tunnel will be 214 addressed in future revision of this document. For EVPN 215 considerations, see SR P2MP Trees for EVPN section. 217 3.1.1. SR-MPLS 219 When a SR P2MP P-Tunnel, shared across different MVPNs, is 220 instantiated in a SR MPLS domain [RFC8660], "MPLS Field" of a PTA 221 advertised in a Auto-Discovery route MUST contain an upstream- 222 assigned MPLS label that the advertising PE has bound to the MVPN, or 223 a label assigned from a global context such as "Domain- wide Common 224 Block" (DCB) as specified in 225 [I-D.ietf-bess-mvpn-evpn-aggregation-label]. 227 When a customer payload is steered into a shared SR P2MP P-Tunnel, 228 this MPLS label MUST be imposed before the MPLS label representing 229 the Tree-SID. 231 4. MVPN Auto-Discovery and Binding Procedures for P2MP Trees 233 RFC 6514 defines procedures for discovering PEs participating in a 234 given MVPN and binding customer multicast flows to specific 235 P-Tunnels. This section specifies modifications to these procedures 236 for SR P2MP tree P-Tunnels. In this section, the term "SR P2MP" 237 refers to both SR-MPLS and SRv6. 239 4.1. Intra-AS I-PMSI 241 Intra-AS I-PMSI A-D routes are exchanged to discover PEs 242 participating in a MVPN within an AS, or across different ASes when 243 non-segmented P-Tunnels are used for inter-AS MVPNs. 245 4.1.1. Originating Intra-AS I-PMSI routes 247 RFC 6514 Section 9.1.1 [2] describes procedures for originating 248 Intra-AS I-PMSI A-D routes. For SR P2MP P-Tunnels, these procedures 249 remain unchanged except as described in the following paragraphs. 251 When a PE originates an Intra-AS I-PMSI A-D route with a PTA having 252 SR P2MP P-Tunnel Type, it MUST create a P2MP policy by invoking 253 CreatePolicy API of the PCE. When the PCE instantiates the P2MP tree 254 on the PE, the Tree-SID MUST be imposed for customer flow(s) steered 255 into the P2MP tree. The Leaf nodes of P2MP tree are discovered using 256 procedures described in Section 4.1.2. 258 For a PE in "Receiver Sites set", condition (c) is modified to 259 include P2MP tree; such a PE MUST originate an Intra-AS I-PMSI A-D 260 route when some PEs of the MVPN have VRFs that use SR P2MP tree but 261 MUST NOT create a SR P2MP policy as described above. 263 When a PE withdraws an Intra-AS I-PMSI A-D route, advertised with a 264 PTA having SR P2MP P-Tunnel Type, the Tree-SID imposition state at 265 the PE MUST be removed. 267 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 268 onto the same SR P2MP P-Tunnel. When a PE withdraws the last Intra- 269 AS I-PMSI A-D route, advertised with a PTA identifying a SR P2MP 270 P-Tunnel , it SHOULD remove the SR P2MP policy by invoking 271 DeletePolicy API of the PCE. 273 4.1.2. Receiving Intra-AS I-PMSI A-D routes 275 Procedure for receiving Intra-AS I-PMSI A-D routes, as described in 276 RFC 6514 Section 9.1.2 [3], remain unchanged for SR P2MP P-Tunnels 277 except as described in the following paragraphs. 279 When a PE that advertises a SR P2MP P-Tunnel in the PTA of its Intra- 280 AS I-PMSI A-D route, imports an Intra-AS I-PMSI A-D route from some 281 PE, it MUST add that PE as a Leaf node of the P2MP tree. The 282 Originating IP Address of the Intra-AS i-PMSI A-D route is used as 283 the Leaf Address when invoking UpdateLeafSet API of the PCE. This 284 procedure MUST also be followed for all Intra-AS I-PMSI routes that 285 are already imported when the PE advertises a SR P2MP P-Tunnel in PTA 286 of its Intra-AS I-PMSI A-D route. 288 A PE that imports and processes an Intra-AS I-PMSI A-D route from 289 another PE with PTA having SR P2MP P-Tunnel MUST program the Tree-SID 290 of the P2MP tree identified in the PTA of the route for disposition. 291 Note that an Intra-AS I-PMSI A-D route from another PE can be 292 imported before the P2MP tree identified in the PTA of the route is 293 instantiated by the PCE at the importing PE. In such case, the PE 294 MUST correctly program Tree-SID for disposition. A PE in "Sender 295 Sites set" MAY avoid programming the Tree-SID for disposition. 297 When an Intra-AS I-PMSI A-D route, advertised with a PTA having SR 298 P2MP P-Tunnel Type is withdrawn, a PE MUST remove the disposition 299 state of the Tree-SID associated with P2MP tree. 301 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 302 onto the same SR P2MP P-Tunnel. When a remote PE withdraws an Intra- 303 AS I-PMSI A-D route from a MVPN, and if this is the last MVPN sharing 304 a SR P2MP P-Tunnel, a PE must remove the originating PE as a Leaf 305 from the P2MP tree, by invoking UpdateLeafSet API. 307 4.2. Using S-PMSIs for binding customer flows to P2MP Segments 309 RFC 6514 specifies procedures for binding (C-S,C-G) customer flows to 310 P-Tunnels using S-PMSI A-D routes. Wildcards in Multicast VPN Auto- 311 Discovery Routes [RFC6625] specifies additional procedures to binding 312 aggregate customer flows to P-Tunnels using "wildcard" S-PMSI A-D 313 routes. This section describes modification to these procedures for 314 SR P2MP P-Tunnels. 316 4.2.1. Originating S-PMSI A-D routes 318 RFC 6514 Section 12.1 [4] describes procedures for originating S-PMSI 319 A-D routes. For SR P2MP P-Tunnels, these procedures remain unchanged 320 except as described in the following paragraphs. 322 When a PE originates S-PMSI A-D route with a PTA having SR P2MP 323 P-Tunnel Type, it MUST set the "Leaf Info Required bit" in the PTA. 324 The PE MUST create a SR P2MP policy by invoking1 API of the PCE. 325 When the PCE instantiates the P2MP tree on the PE, the Tree-SID MUST 326 be imposed for customer flows steered into the SR P2MP P-Tunnel. 328 The Leaf nodes of P2MP tree are discovered by Leaf A-D routes using 329 procedures described in Section 4.4.2. When a PE originates S-PMSI 330 A-D route with a PTA having SR P2MP P-Tunnel Type, it is possible the 331 PE might have imported Leaf A-D routes whose route keys match the 332 S-PMSI A-D route. The PE MUST re-apply procedures of Section 4.4.2 333 to these Leaf A-D routes. 335 When a PE withdraws a S-PMSI A-D route, advertised with PTA having 336 P2MP tree P-Tunnel type, the Tree-SID imposition state MUST be 337 removed. 339 A PE MAY aggregate two or more S-PMSIs onto the same SR P2MP 340 P-Tunnel. When a PE withdraws the last S-PMSI A-D route, advertised 341 with a PTA identifying a specific SR P2MP P-Tunnel , it SHOULD remove 342 the SR P2MP policy by invoking DeletePolicy API of the PCE. 344 4.2.2. Receiving S-PMSI A-D routes 346 RFC 6514 Section 12.3 [5] describes procedures for receiving S-PMSI 347 A-D routes. For SR P2MP P-Tunnels, these procedures remain unchanged 348 except as described in the following paragraphs. 350 The procedure to join SR P2MP P-Tunnel of S-PMSI A-D route by using a 351 Leaf A-D route is described in Section 4.4.1. If P2MP tree 352 identified in PTA of S-PMSI A-D route is already instantiated by PCE, 353 the PE MUST program Tree-SID for disposition. If the P2MP tree is 354 instantiated later, the Tree-SID MUST be programmed for disposition 355 at that time. 357 When a S-PMSI A-D route, whose SR P2MP P-Tunnel has been joined by a 358 PE, is withdrawn, or when conditions (see RFC 6514 Section 12.3 [6]) 359 required to join that P-Tunnel are no longer satisfied, the PE MUST 360 leave the P-Tunnel. The PE MUST withdraw the Leaf A-D route it had 361 originated and remove the Tree-SID disposition state. 363 4.3. Inter-AS P-tunnels using P2MP Segments 365 A segmented inter-AS P-Tunnel consists of one or more intra-AS 366 segments, one in each AS, connected by inter-AS segments between 367 ASBRs of different ASes . These segments are constructed by PEs/ASBRs originating or re- 369 advertising Inter-AS I-PMSI A-D routes. This section describes 370 procedures for instantiating intra-AS segments using SR P2MP trees. 372 4.3.1. Advertising Inter-AS I-PMSI routes into iBGP 374 RFC 6514 Section 9.2.3.2 [7] specifies procedures for advertising an 375 Inter-AS I-PMSI A-D route to construct an intra-AS segment. The PTA 376 of the route identifies the type and identifier of the P-Tunnel 377 instantiating the intra-AS segment. The procedure for creating SR 378 P2MP P-Tunnel for intra-AS segment are same as specified in 379 Section 4.2.1 except that instead of S-PMSI A-D routes, the 380 procedures apply to Inter-AS I-PMSI A-D routes. 382 4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP 384 RFC 6514 Section 9.2.3.2 [8] specifies procedures for processing an 385 Inter-AS I-PMSI A-D route received via iBGP. If the PTA of the 386 Inter-AS I-PMSI A-D route has SR P2MP P-Tunnel Type, the procedures 387 are same as specified in Section 4.2.2 except that instead of S-PMSI 388 A-D routes, the procedures apply to Inter-AS I-PMSI A-D routes. If 389 the receiving router is an ASBR, the Tree-SID is stitched to the 390 inter-AS segments to ASBRs in other ASes. 392 4.4. Leaf A-D routes for P2MP Segment Leaf Discovery 394 This section describes procedures for originating and processing Leaf 395 A-D routes used for Leaf discovery of SR P2MP trees. 397 4.4.1. Originating Leaf A-D routes 399 The procedures for originating Leaf A-D route in response to 400 receiving a S-PMSI or Inter-AS I-PMSI A-D route with PTA having SR 401 P2MP P-Tunnel Type are same as specified in RFC 6514 402 Section 9.2.3.4.1 [9]. 404 4.4.2. Receiving Leaf A-D routes 406 Procedures for processing a received Leaf A-D route are specified in 407 RFC 6514 Section 9.2.3.5 [10]. These procedures remain unchanged for 408 discovering Leaf nodes of P2MP trees except for considerations 409 described in following paragraphs. These procedures apply to Leaf 410 A-D routes received in response to both S-PMSI and Inter-AS I-PMSI 411 A-D routes, shortened to "A-D routes" in this section 413 A Root PE/ASBR MAY use the same SR P2MP P-Tunnel in PTA of two or 414 more A-D routes. For such aggregated P2MP trees, the PE/ASBR may 415 receive multiple Leaf A-D routes from a Leaf PE. The P2MP tree for 416 which a Leaf A-D is received can be identified by examining the P2MP 417 tunnel Identifier in the PTA of A-D route that matches "Route Key" 418 field of the Leaf A-D route. When the PE receives the first Leaf A-D 419 route from a Leaf PE, identified by the Originating Router's IP 420 address field, it MUST add that PE as Leaf of the P2MP tree by 421 invoking the UpdateLeafSet API of the PCE. 423 When a Leaf PE withdraws the last Leaf A-D route for a given SR P2MP 424 P-Tunnel, the Root PE MUST remove the Leaf PE from the P2MP tree by 425 invoking UpdateLeafSet API of PCE. Note that Root PE MAY remove the 426 P2MP tree, via the DeletePolicyAPI, before the last Leaf A-D is 427 withdrawn. In this case, the Root PE MAY decide to not invoke the 428 UpdateLeafSet API. 430 5. MVPN with Ingress Replication over Segment Routing 432 A PE can provide MVPN service using Ingress Replication over Segment 433 Routing. Customer payload is encapsulated in SR-MPLS or IPv6 (SRv6) 434 at Ingress PE. The encapsulated payload is replicated and a unicast 435 copy is sent to each egress PE. 437 Ingress Replication Tunnels in Multicast VPN [RFC7988] specifies 438 procedures that can be used to provide MVPN service with Ingress 439 Replication in a Segment Routing domain. A PE advertises Intra-AS, 440 Inter-AS, Selective PMSI BGP Auto-Discovery routes with PTA for 441 Ingress Replication. Egress PEs join asLeaf Nodes using Intrra-AS 442 I-PMSI or Leaf Auto-Discovery routes. 444 5.1. SR-MPLS 446 Procedures of RFC 7988 are sufficient to create a SR-MPLS Ingress 447 Replication for MVPN service. 449 5.2. SRv6 451 Procedures of RFC 7988, along with modifications described in this 452 Section, are sufficient to create a SRv6 Ingress Replication for MVPN 453 service. 455 The PTA carried in Intra-AS, Inter-AS, Selective PMSI and Leaf Auto- 456 Discovery routes is constructed as specified in RFC 7988 with 457 modifications as below: 459 o Tunnel Type: "Ingress Replication" as per RFC 6514. 461 o MPLS Label: This 24-bit field carries the whole or a portion of 462 the Function part of the SRv6 Multicast Service SID when ingress 463 replication is used and the Transposition Scheme of encoding as 464 defined in Section 4 of SRv6 BGP based Overlay Services [11] is 465 used. Otherwise, it is set as defined in RFC 6514. When using 466 the Transposition Scheme, the Transposition Length MUST be less 467 than or equal to 24 and less than or equal to the Function Length. 469 Section 6 and 7 of RFC 7988 [12] describe considerations and 470 procedures for allocating MPLS labels for IR P-Tunnel. For SRv6 471 Ingress Replication, these sections apply to SRv6 Multicast Service 472 SID. 474 To join a SRv6 Ingres Replication P-Tunnel advertised in PTA of Inra- 475 AS, Inter-AS, or Selective S-PMSI A-D routes, an egress PE constructs 476 a Leaf A-D or Intra-AS I-PMSI route as described in RFC 7988 with 477 modified PTA above. The egress PE attaches a BGP Prefix-SID 478 attribute [RFC8669] in Leaf A-D or Intra-AS I-PMSI route with SRv6 L3 479 Service TLV [I-D.ietf-bess-srv6-services] to signal SRv6 Multicast 480 Service SID . The SRv6 SID Information Sub-TLV carries the SRv6 481 Multicast Service SID in SRv6 SID Value field. The SRv6 Endpoint 482 Behavior of the SRv6 SID Information Sub-TLV encodes one of End.DTM4, 483 End.DTM6, or End.DTM46 codepoint value. The SRv6 SID Structure Sub- 484 Sub-TLV encodes the structure of SRv6 Multicast Service SID. If 485 Transposition scheme is used, the offset and length of SRv6 Multicast 486 Endpoint function of SRv6 Multicast Service SID is set in 487 Transposition Length and Transposition Offset fields of this sub-sub 488 TLV. Otherwise, the Transposition Length and Offset fields MUST be 489 set to zero. 491 The BGP Prefix SID attribute with SRv6 L3 Service TLV in Intra-AS 492 I-PMSI or Leaf A-D route indicates to ingress PE that egress PE 493 supports SRv6. The ingress PE MUST encapsulate payload in an outer 494 IPv6 header with the SRv6 Multicast Service SID provided by the 495 egress PE as the destination address. If Transposition scheme is 496 used, ingress PE MUST merge Function in MPLS field of PTA with SRv6 497 SID in SID Information TLV using the Transposition Offset and Length 498 fields from SID structure sub-sub TLV to create SRv6 Multicast 499 Service SID 501 5.2.1. SRv6 Multicast Endpoint Behaviors 503 The following behaviors can be associated with SRv6 Multicast Service 504 SID. 506 5.2.1.1. End.DTM4: Decapsulation and Specific IPv4 Multicast 507 Table Lookup 509 The "Endpoint with decapsulation and specific IPv4 Multicast table 510 lookup" behavior ("End.DTM4" for short) is similar to End.DT4 511 behavior of RFC 8986 except the lookup is in IPv4 multicast table. 513 5.2.1.2. End.DTM6: Decapsulation and Specific IPv6 Multicast 514 Table Lookup 516 The "Endpoint with decapsulation and specific IPv6 Multicast table 517 lookup" behavior ("End.DTM6" for short) is similar to End.DT6 518 behavior of RFC 8986 except the lookup is in IPv6 multicast table. 520 5.2.1.3. End.DTM46: Decapsulation and Specific IP Multicast 521 Table Lookup 523 The "Endpoint with decapsulation and specific IP Multicast table 524 lookup" behavior ("End.DTM46" for short) is similar to End.DT4 and 525 End.DT6 behaviors of RFC 8986 except the lookup is in IP multicast 526 table. 528 6. Dampening of MVPN routes 530 When P2MP trees are used as P-Tunnels for S-PMSI A-D routes, change 531 in group membership of receivers connected to PEs has direct impact 532 on the Leaf node set of a P2MP tree. If group membership changes 533 frequently for a large number of groups with a lot of receivers 534 across sites connected to different PEs, it can have an impact on the 535 interaction between PEs and the PCE. 537 Since Leaf A-D routes are used to discover Leaf PE of a P2MP tree, it 538 is RECOMMENDED that PEs SHOULD damp Leaf A-D routes as described in 539 Section 6.1 of RFC 7899 [RFC7899]. PEs MAY also implement procedures 540 for damping other Auto-Discovery and BGP C-multicast routes as 541 described in [RFC7899]. 543 7. SR P2MP Trees for EVPN 545 BGP MPLS Ethernet VPN specified in RFC 7432 specifies Inclusive 546 Multicast Ethernet Tag route to support Broadcast, Unknown Unicast 547 and Multicast (BUM) traffic. This IMET route is the equivalent of 548 MVPN Intra-AS I-PMSI route and is advertised with a PMSI Tunnel 549 Attribute (PTA) as specified in RFC 6514 to advertise the inclusive 550 P-Tunnels. 552 [I-D.ietf-bess-evpn-bum-procedure-updates] updates BUM procedures to 553 support selective P-Tunnels and P-Tunnel segmentation in EVPN. That 554 document specifies new route types that are advertised with PTA, 555 including Selective PMSI (S-PMSI) Auto-Discovery route. 557 These inclusive/selective P-Tunnels can be realized by SR P2MP trees. 558 As with other types of P2MP P-Tunnels, the ESI label used for split 559 horizon MUST be either upstream assigned by PE advertising the IMET 560 or S-PMSI route, or assigned from a global context such as "Domain- 561 wide Common Block" (DCB) as specified in 562 [I-D.ietf-bess-mvpn-evpn-aggregation-label]. 564 [I-D.ietf-bess-evpn-irb-mcast] specifies procedures to support Inter- 565 Subnet Multicast. [I-D.ietf-bess-evpn-mvpn-seamless-interop] 566 specifies how MVPN SAFI routes can be used to support Inter-Subnet 567 Multicast. The P-Tunnels advertised in PTA of either EVPN and MVPN 568 routes as specified in these documents respectively can be realized 569 by SR P2MP trees. 571 SRv6 P2MP trees can serve as an underlay multicast as described in 572 RFC 8293 Section 3.4 [13]. A NVE encapsulates a tenant packet in an 573 SRv6 header and deliver it over SRv6 P2MP trees to other NVEs. 575 The same procedures specified for MVPN are used to collect the leaf 576 information of corresponding SR P2MP tree (either based on IMET route 577 or Leaf A-D routes in response to x-PMSI routes), to pass the tree 578 information to the PCE controller, and to get back tree forwarding 579 state used for customer multicast traffic forwarding. 581 8. IANA Considerations 583 IANA has assigned the value 0x0C for "SR-MPLS P2MP Tree" in the 584 "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" 585 registry [RFC 7538] in the "Border Gateway 587 Protocol (BGP) Parameters" registry. 589 IANA is requested to assign codepoint for "SRv6 P2MP Tree" in the 590 "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" 591 registry [RFC 7538] in the "Border Gateway 593 Protocol (BGP) Parameters" registry. A proposed value is 0x0D. 595 This document requires registration of End.DT4M, End.DTM6 and 596 End.DTM46 behaviors in "SRv6 Endpoint Behaviors" sub-registry of 597 "Segment Routing Parameters" top-level registry. 599 +-------+-----+-------------------+-----------+ 600 | Value | Hex | Endpoint behavior | Reference | 601 +-------+-----+-------------------+-----------+ 602 | TBD | TBD | End.DTM4 | [This.ID] | 603 | TBD | TBD | End.DTM6 | [This.ID] | 604 | TBD | TBD | End.DTM46 | [This.ID] | 605 +-------+-----+-------------------+-----------+ 607 Table 1: IETF - SRv6 Endpoint Behaviors 609 9. Security Considerations 611 The procedures in this document do not introduce any additional 612 security considerations beyond those mentioned in [RFC6513] and 613 [RFC6514]. For general security considerations applicable to P2MP 614 trees, please refer to [I-D.ietf-pim-sr-p2mp-policy] . 616 10. Acknowledgements 618 The authors would like to acknowledge Luc Andre Burdett reviewing the 619 document.. 621 11. Contributors 623 Zafar Ali 624 Cisco Systems, Inc. 625 US 627 Email: zali@cisco.com 629 Ehsan Hemmati 630 Cisco Systems, Inc. 631 US 633 Email: ehemmati@cisco.com 635 Jayant Kotalwar 636 Nokia 637 Mountain View 638 US 640 Email: jayant.kotalwar@nokia.com 642 Tanmoy Kundu 643 Nokia 644 Mountain View 645 US 647 Email: tanmoy.kundu@nokia.com 649 Clayton Hassen 650 Bell Canada 651 Vancouver 652 CA 654 Email: clayton.hassen@bell.ca 656 12. References 658 12.1. Normative References 660 [I-D.ietf-bess-srv6-services] 661 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 662 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 663 Overlay Services", draft-ietf-bess-srv6-services-07 (work 664 in progress), April 2021. 666 [I-D.ietf-pim-sr-p2mp-policy] 667 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 668 Zhang, "Segment Routing Point-to-Multipoint Policy", 669 draft-ietf-pim-sr-p2mp-policy-02 (work in progress), 670 February 2021. 672 [I-D.ietf-spring-sr-replication-segment] 673 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 674 Zhang, "SR Replication Segment for Multi-point Service 675 Delivery", draft-ietf-spring-sr-replication-segment-04 676 (work in progress), February 2021. 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, 680 DOI 10.17487/RFC2119, March 1997, 681 . 683 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 684 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 685 2012, . 687 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 688 Encodings and Procedures for Multicast in MPLS/BGP IP 689 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 690 . 692 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 693 Replication Tunnels in Multicast VPN", RFC 7988, 694 DOI 10.17487/RFC7988, October 2016, 695 . 697 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 698 Decraene, B., Litkowski, S., and R. Shakir, "Segment 699 Routing with the MPLS Data Plane", RFC 8660, 700 DOI 10.17487/RFC8660, December 2019, 701 . 703 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 704 A., and H. Gredler, "Segment Routing Prefix Segment 705 Identifier Extensions for BGP", RFC 8669, 706 DOI 10.17487/RFC8669, December 2019, 707 . 709 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 710 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 711 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 712 . 714 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 715 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 716 (SRv6) Network Programming", RFC 8986, 717 DOI 10.17487/RFC8986, February 2021, 718 . 720 12.2. Informative References 722 [I-D.ietf-bess-evpn-bum-procedure-updates] 723 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 724 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 725 bess-evpn-bum-procedure-updates-08 (work in progress), 726 November 2019. 728 [I-D.ietf-bess-evpn-irb-mcast] 729 Lin, W., Zhang, Z., Drake, J., Rosen, E. C., Rabadan, J., 730 and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast 731 (OISM) Forwarding", draft-ietf-bess-evpn-irb-mcast-05 732 (work in progress), October 2020. 734 [I-D.ietf-bess-evpn-mvpn-seamless-interop] 735 Sajassi, A., Thiruvenkatasamy, K., Thoria, S., Gupta, A., 736 and L. Jalil, "Seamless Multicast Interoperability between 737 EVPN and MVPN PEs", draft-ietf-bess-evpn-mvpn-seamless- 738 interop-02 (work in progress), February 2021. 740 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 741 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 742 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 743 ietf-bess-mvpn-evpn-aggregation-label-06 (work in 744 progress), April 2021. 746 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 747 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 748 RFC 6625, DOI 10.17487/RFC6625, May 2012, 749 . 751 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 752 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 753 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 754 2015, . 756 [RFC7899] Morin, T., Ed., Litkowski, S., Patel, K., Zhang, Z., 757 Kebler, R., and J. Haas, "Multicast VPN State Damping", 758 RFC 7899, DOI 10.17487/RFC7899, June 2016, 759 . 761 [RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R. 762 Krishnan, "A Framework for Multicast in Network 763 Virtualization over Layer 3", RFC 8293, 764 DOI 10.17487/RFC8293, January 2018, 765 . 767 12.3. URIs 769 [1] https://tools.ietf.org/html/draft-ietf-pim-sr-p2mp-policy- 770 00#section-4.1.1 772 [2] https://tools.ietf.org/html/rfc6514#section-9.1.1 774 [3] https://tools.ietf.org/html/rfc6514#section-9.1.2 776 [4] https://tools.ietf.org/html/rfc6514#section-12.1 778 [5] https://tools.ietf.org/html/rfc6514#section-12.3 780 [6] https://tools.ietf.org/html/rfc6514#section-12.3 782 [7] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 784 [8] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 786 [9] https://tools.ietf.org/html/rfc6514#section-9.2.3.4.1 788 [10] https://tools.ietf.org/html/rfc6514#section-9.2.3.5 790 [11] https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6- 791 services-07#section-4 793 [12] https://datatracker.ietf.org/doc/html/rfc7988#section-6 795 [13] https://tools.ietf.org/html/rfc8293#section-3.4 797 Authors' Addresses 798 Rishabh Parekh 799 Cisco Systems, Inc. 800 170 W. Tasman Drive 801 San Jose, CA 95134 802 USA 804 Email: riparekh@cisco.com 806 Clarence Filsfils 807 Cisco Systems, Inc. 808 Brussels 809 BE 811 Email: cfilsfil@cisco.com 813 Arvind Venkateswaran 814 Cisco Systems, Inc. 815 170 W. Tasman Drive 816 San Jose, CA 95134 817 USA 819 Email: arvvenka@cisco.com 821 Hooman Bidgoli 822 Nokia 823 Ottawa 824 CA 826 Email: hooman.bidgoli@nokia.com 828 Daniel Voyer 829 Bell Canada 830 Montreal 831 CA 833 Email: daniel.voyer@bell.ca 835 Zhaohui Zhang 836 Juniper Networks 838 Email: zzhang@juniper.net