idnits 2.17.1 draft-ietf-bess-mvpn-evpn-sr-p2mp-01.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 (December 2, 2020) is 1240 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 610 -- Looks like a reference, but probably isn't: '2' on line 613 -- Looks like a reference, but probably isn't: '3' on line 615 -- Looks like a reference, but probably isn't: '4' on line 617 -- Looks like a reference, but probably isn't: '5' on line 619 -- Looks like a reference, but probably isn't: '6' on line 621 -- Looks like a reference, but probably isn't: '7' on line 623 -- Looks like a reference, but probably isn't: '8' on line 625 -- Looks like a reference, but probably isn't: '9' on line 627 -- Looks like a reference, but probably isn't: '10' on line 629 -- Looks like a reference, but probably isn't: '11' on line 631 == Missing Reference: 'RFC 7538' is mentioned on line 476, but not defined ** Obsolete undefined reference: RFC 7538 (Obsoleted by RFC 9110) == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-01 == 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-01 == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-04 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-03 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 12 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: June 5, 2021 Cisco Systems, Inc. 6 H. Bidgoli 7 Nokia 8 D. Voyer 9 Bell Canada 10 Z. Zhang 11 Juniper Networks 12 December 2, 2020 14 Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint 15 Trees 16 draft-ietf-bess-mvpn-evpn-sr-p2mp-01 18 Abstract 20 A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain 21 efficiently carries traffic from a Root to a set of Leaves. This 22 document describes extensions to BGP encodings and procedures for 23 P2MP trees used in BGP/MPLS IP VPNs and Ethernet VPNs. 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 June 5, 2021. 48 Copyright Notice 50 Copyright (c) 2020 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 . . . . . . . . . 5 71 4.1. Intra-AS I-PMSI . . . . . . . . . . . . . . . . . . . . . 5 72 4.1.1. Originating Intra-AS I-PMSI routes . . . . . . . . . 5 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 . . . . 8 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. Dampening of MVPN routes . . . . . . . . . . . . . . . . . . 9 84 6. SR P2MP Trees for EVPN . . . . . . . . . . . . . . . . . . . 10 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 88 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 11.2. Informative References . . . . . . . . . . . . . . . . . 12 92 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 Multicast in MPLS/BGP IP VPNs [RFC6513] and BGP Encodings and 98 Procedures for Multicast in MPLS/BGP IP VPNs [RFC6514] specify 99 procedures that allow a Service Provider to provide Multicast VPN 100 (MVPN) service to its customers. Multicast traffic from a customer 101 is tunneled across the service provider network over Provider Tunnels 102 (P-Tunnels). P-tunnels can be instantiated via different 103 technologies. A service provider network that uses Segment Routing 104 can use a Point-to-Multipoint (SR P2MP) tree 105 [I-D.ietf-pim-sr-p2mp-policy] to instantiate P-Tunnels for MVPN. 107 In a Segment Routing network, a P2MP tree allows efficient delivery 108 of traffic from a Root to set of Leaf nodes. A SR P2MP tree is 109 defined by a SR P2MP Policy and instantiated via a PCE. A P2MP 110 Policy consists of a Root, a Set of Leaf Nodes and a set of candidate 111 paths with optional set of constraints and/or optimization objectives 112 to be satisfied by the P2MP tree. A unique Identifier, called Tree- 113 SID, is associated with a P2MP tree. This Tree-SID can be an MPLS 114 label or an IPv6 address. 116 This document describes extensions to BGP Auto-Discovery procedures 117 specified in RFC 6514 for SR P2MP P-Tunnels. Use of PIM for Auto- 118 Discovery is outside scope of this document. Support for customer 119 BIDIR-PIM is outside the scope of this document. 121 For BGP MPLS Ethernet VPN specified in [RFC7432] and extensions to 122 this document, P-Tunnels are advertised for handling multi- 123 destination traffic. These P-tunnels can be realized by SR P2MP 124 trees. SRv6 P2MP trees can also be used to support Multicast in 125 Network Virtualization over Layer 3 [RFC8293]. 127 The reader is expected to be familiar with concepts and terminology 128 of RFC 6513, RFC 6514 and SR P2MP draft. 130 2. SR P2MP P-Tunnels 132 For MVPN or EVPN, Provider Edge(PE) routers steer customer traffic 133 into a P-Tunnel that can be instantiated by SR P2MP tree. A SR P2MP 134 tree is defined by a SR P2MP policy [I-D.ietf-pim-sr-p2mp-policy]. 136 SR P2MP P-tunnel can be instantiated by either SR-MPLS or SRv6 P2MP 137 trees. Details for SRv6 P2MP trees will be added in future revision 138 of this document. 140 Given a SR P2MP policy, a PCE computes and instantiates the SR P2MP 141 tree on the nodes that are part of the tree using Replication 142 segments and Tree-SID which a unique identifier for the tree 144 [I-D.ietf-spring-sr-replication-segment]. A Replication segment can 145 be initiated by various methods (BGP, PCEP, others) which are outside 146 the scope of this document. 148 A PCE provides conceptual APIs, listed below, to define and modify SR 149 P2MP policies SR P2MP Policy Section 4.1.1 [1]. These APIs are 150 invoked by a PCC, which is the root of P2MP tree, using various 151 methods (BGP, PCEP, etc.) which are outside the scope of this 152 document. 154 CreatePolicy: CreateSRP2MPPolicy 156 DeletePolicy: DeleteSRP2MPPolicy 158 UpdateLeafSet: SRP2MPPolicyLeafSetModify 161 The Root of a P2MP tree imposes the Tree-SID to steer the customer 162 payload into the P2MP tree. Provider (P) routers replicate customer 163 payload, using Replication segments, towards the Leaf nodes of the 164 P2MP tree. Leaf nodes of the P2MP tree deliver the customer payload 165 after dispoing the Tree-SID. 167 3. PMSI Tunnel Attribute for SR P2MP 169 A PMSI Tunnel Attribute (PTA) is defined in RFC 6514 to identify the 170 P-Tunnel that is used to instantiate a Provider Multicast Service 171 Interface (PMSI). The PTA is carried in Intra-AS I-PMSI, Inter-AS 172 I-PMSI, Selective PMSI, and Leaf Auto-Discovery routes. 174 A P2MP tree PTA is constructed as follows: 176 o Tunnel Type: The codepoint is set to [[CREF1: TBD]]for SR P2MP 177 tree from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) 178 Tunnel Types" registry. 180 o Flags: See Section 4 for use of "Leaf Info Required bit". 182 o MPLS Label: See Section 3.1 184 o Tunnel Identifier: The SR P2MP P-tunnel is identified by where, 187 * Tree-ID is a 32-bit unsigned value that identifies a unique 188 P2MP tree at a Root.. 190 * Root is an IP address identifying the Root of a P2MP tree. 191 This can be either an IPv4 or IPv6 address and can be inferred 192 from the PTA length. 194 When a P-Tunnel is non-segmented, the PTA is created by PE router at 195 the Root of a SR P2MP tree. For segmented P-tunnels, each segment 196 can be instantiated by a different technology. If a segment is 197 instantiated using P2MP tree, the router at the root of a P2MP tree 198 creates the PTA. 200 3.1. MPLS Label 202 [RFC6514] allows a PE to aggregate two or more MVPNs onto one 203 P-tunnel by advertising the same P-tunnel in PTA of Auto-Discovery 204 routes of different MVPNs. This section specifies how the "MPLS 205 Label" field of PTA is filled to provide a context bound to a 206 specific MPVN. For EVPN considerations, see SR P2MP Trees for EVPN 207 section. 209 3.1.1. SR MPLS 211 When a SR P2MP P-tunnel, shared across different MVPNs, is 212 instantiated in a SR MPLS domain [RFC8660], "MPLS Field" of a PTA 213 advertised in a Auto-Discovery route MUST contain an upstream- 214 assigned MPLS label that the advertising PE has bound to the MVPN. 216 When a customer payload is steered into a shared SR P2MP P-tunnel, 217 this MPLS label MUST be imposed before the MPLS label representing 218 the Tree-SID. 220 4. MVPN Auto-Discovery and Binding Procedures 222 RFC 6514 defines procedures for discovering PEs participating in a 223 given MVPN and binding customer multicast flows to specific 224 P-Tunnels. This section specifies modifications to these procedures 225 for SR P2MP P-Tunnels. 227 4.1. Intra-AS I-PMSI 229 Intra-AS I-PMSI A-D routes are exchanged to discover PEs 230 participating in a MVPN within an AS, or across different ASes when 231 non-segmented P-tunnels for inter-AS MVPNs. 233 4.1.1. Originating Intra-AS I-PMSI routes 235 RFC 6514 Section 9.1.1 [2] describes procedures for originating 236 Intra-AS I-PMSI A-D routes. For SR P2MP P-tunnels, these procedures 237 remain unchanged except as described in the following paragraphs. 239 When a PE originates an Intra-AS I-PMSI A-D route with a PTA having 240 SR P2MP P-tunnel Type, it MUST create a P2MP policy by invoking 241 CreatePolicy API of the PCE. When the PCE instantiates the P2MP tree 242 on the PE, the Tree-SID MUST be imposed for customer flow(s) steered 243 into the P2MP tree. The Leaf nodes of P2MP tree are discovered using 244 procedures described in Section 4.1.2. 246 For a PE in "Receiver Sites set", condition (c) is modified to 247 include P2MP tree i.e. such a PE MUST originate an Intra-AS I-PMSI 248 A-D route when some PEs of the MVPN have VRFs that use SR P2MP tree 249 but MUST NOT create a SR P2MP policy as described above. 251 When a PE withdraws an Intra-AS I-PMSI A-D route, advertised with a 252 PTA having SR P2MP P-tunnel Type, the Tree-SID imposition state at 253 the PE MUST be removed. 255 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 256 onto the same SR P2MP P-tunnel. When a PE withdraws the last Intra- 257 AS I-PMSI A-D route, advertised with a PTA identifying a SR P2MP 258 P-tunnel , it SHOULD remove the SR P2MP policy by invoking 259 DeletePolicy API of the PCE. 261 4.1.2. Receiving Intra-AS I-PMSI A-D routes 263 Procedure for receiving Intra-AS I-PMSI A-D routes, as described in 264 RFC 6514 Section 9.1.2 [3], remain unchanged for SR P2MP P-tunnels 265 except as described in the following paragraphs. 267 When a PE that advertises a SR P2MP P-tunnel in the PTA of its Intra- 268 AS I-PMSI A-D route, imports an Intra-AS I-PMSI A-D route from some 269 PE, it MUST add that PE as a Leaf node of the P2MP tree. The 270 Originating IP Address of the Intra-AS i-PMSI A-D route is used as 271 the Leaf Address when invoking UpdateLeafSet API of the PCE. This 272 procedure MUST also be followed for all Intra-AS I-PMSI routes that 273 are already imported when the PE advertises a SR P2MP P-tunnel in PTA 274 of its Intra-AS I-PMSI A-D route. 276 A PE that imports and processes an Intra-AS I-PMSI A-D route from 277 another PE with PTA having SR P2MP P-Tunnel MUST program the Tree-SID 278 of the P2MP tree identified in the PTA of the route for disposition. 279 Note that an Intra-AS I-PMSI A-D route from another PE can be 280 imported before the P2MP tree identified in the PTA of the route is 281 instantiated by the PCEat the importing PE. In such case, the PE 282 MUST correctly program Tree-SID for disposition. A PE in "Sender 283 Sites set" MAY avoid programming the Tree-SID for disposition. 285 When an Intra-AS I-PMSI A-D route, advertised with a PTA having SR 286 P2MP P-tunnel Type is withdrawn, a PE MUST remove the disposition 287 state of the Tree-SID associated with P2MP tree. 289 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 290 onto the same SR P2MP P-tunnel. When a remote PE withdraws an Intra- 291 AS I-PMSI A-D route from a MVPN, and if this is the last MVPN sharing 292 a SR P2MP P-tunnel, a PE must remove the originating PE as a Leaf 293 from the P2MP tree, by invoking UpdateLeafSet API. 295 4.2. Using S-PMSIs for binding customer flows to P2MP Segments 297 RFC 6514 specifies procedures for binding (C-S,C-G) customer flows to 298 P-tunnels using S-PMSI A-D routes. Wildcards in Multicast VPN Auto- 299 Discovery Routes [RFC6625] specifies additional procedures to binding 300 aggregate customer flows to P-tunnels using "wildcard" S-PMSI A-D 301 routes. This section describes modification to these procedures for 302 SR P2MP P-tunnels. 304 4.2.1. Originating S-PMSI A-D routes 306 RFC 6514 Section 12.1 [4] describes procedures for originating S-PMSI 307 A-D routes. For SR P2MP P-tunnels, these procedures remain unchanged 308 except as described in the following paragraphs. 310 When a PE originates S-PMSI A-D route with a PTA having SR P2MP 311 P-tunnel Type, it MUST set the "Leaf Info Required bit" in the PTA. 312 The PE MUST create a SR P2MP policy by invoking1 API of the PCE. 313 When the PCEinstantiates the P2MP tree on the PE, the Tree-SID MUST 314 be imposed for customer flows steered into the SR P2MP P-tunnel. 316 The Leaf nodes of P2MP tree are discovered by Leaf A-D routes using 317 procedures described in Section 4.4.2. When a PE originates S-PMSI 318 A-D route with a PTA having SR P2MP P-tunnel Type, it is possible the 319 PE might have imported Leaf A-D routes whose route keys match the 320 S-PMSI A-D route. The PE MUST re-apply procedures of Section 4.4.2 321 to these Leaf A-D routes. 323 When a PE withdraws a S-PMSI A-D route, advetised with PTA having 324 P2MP tree P-tunnle type, the Tree-SID imposition state MUST be 325 removed. 327 A PE MAY aggregate two or more S-PMSIs onto the same SR P2MP 328 P-tunnel. When a PE withdraws the last S-PMSI A-D route, advertised 329 with a PTA identifying a specific SR P2MP P-tunnel , it SHOULD remove 330 the SR P2MP policy by invoking DeletePolicy API of the PCE. 332 4.2.2. Receiving S-PMSI A-D routes 334 RFC 6514 Section 12.3 [5] describes procedures for receiving S-PMSI 335 A-D routes. For SR P2MP P-tunnels, these procedures remain unchanged 336 except as described in the following paragraphs. 338 The procedure to join SR P2MP P-tunnel of S-PMSI A-D route by using a 339 Leaf A-D route is described in Section 4.4.1. If P2MP tree 340 identified in PTA of S-PMSI A-D route is already instantiated by PCE, 341 the PE MUST program Tree-SID for disposition. If the P2MP tree is 342 instantiated later, the Tree-SID MUST be programmed for disposition 343 at that time. 345 When a S-PMSI A-D route, whose SR P2MP P-tunnel is joined by a PE, is 346 withdrawn, or when conditions (see RFC 6514 Section 12.3 [6]) 347 required to join that P-Tunnel are no longer satisfied, the PE MUST 348 leave the P-Tunnel. The PE MUST withdraw the Leaf A-D route it had 349 originated and remove the Tree-SID disposition state. 351 4.3. Inter-AS P-tunnels using P2MP Segments 353 A segmented inter-AS P-tunnel consists of one or more intra-AS 354 segments, one in each AS, connected by inter-AS segments between 355 ASBRs of different ASes . These segments are constructed by PEs/ASBRs originating or re- 357 advertising Inter-AS I-PMSI A-D routes. This section describes 358 procedures for instantiating intra-AS segments using SR P2MP trees. 360 4.3.1. Advertising Inter-AS I-PMSI routes into iBGP 362 RFC 6514 Section 9.2.3.2 [7] specifies procedures for advertising an 363 Inter-AS I-PMSI A-D route to construct an intra-AS segment. The PTA 364 of the route identifies the type and identifier of the P-tunnel 365 instantiating the intra-AS segment. The procedure for creating SR 366 P2MP P-tunnel for intra-AS segment are same as specified in 367 Section 4.2.1 except that instead of S-PMSI A-D routes, the 368 procedures apply to Inter-AS I-PMSI A-D routes. 370 4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP 372 RFC 6514 Section 9.2.3.2 [8] specifies procedures for processing an 373 Inter-AS I-PMSI A-D route received via iBGP. If the PTA of the 374 Inter-AS I-PMSI A-D route has SR P2MP P-tunnel Type, the procedures 375 are same as specified in Section 4.2.2 except that instead of S-PMSI 376 A-D routes, the procedures apply to Inter-AS I-PMSI A-D routes. If 377 the receiving router is an ASBR, the Tree-SID is stitched to the 378 inter-AS segments to ASBRs in other ASes. 380 4.4. Leaf A-D routes for P2MP Segment Leaf Discovery 382 This section describes procedures for originating and processing Leaf 383 A-D routes used for Leaf discovery of SR P2MP trees. 385 4.4.1. Originating Leaf A-D routes 387 The procedures for originating Leaf A-D route in response to 388 receiving a S-PMSI or Inter-AS I-PMSI A-D route with PTA having SR 389 P2MP P-tunnel Type are same as specified in RFC 6514 390 Section 9.2.3.4.1 [9]. 392 4.4.2. Receiving Leaf A-D routes 394 Procedures for processing a received Leaf A-D route are specified in 395 RFC 6514 Section 9.2.3.5 [10]. These procedures remain unchanged for 396 discovering Leaf nodes of P2MP trees except for considerations 397 described in following paragraphs. These procedures apply to Leaf 398 A-D routes received in response to both S-PMSI and Inter-AS I-PMSI 399 A-D routes, shortened to "A-D routes" in this section 401 A Root PE/ASBR MAY use the same SR P2MP P-tunnel in PTA of two or 402 more A-D routes. For such aggregated P2MP trees, the PE/ASBR MAY 403 receive multiple Leaf A-D routes from a Leaf PE. The P2MP tree for 404 which a Leaf A-D is received can be identified by examining the P2MP 405 tunnel Identifier in the PTA of A-D route that matches "Route Key" 406 field of the Leaf A-D route. When the PE receives the first Leaf A-D 407 route from a Leaf PE, identified by the Originating Router's IP 408 address field, it MUST add that PE as Leaf of the P2MP tree by 409 invoking the UpdateLeafSet API of the PCE. 411 When a Leaf PE withdraws the last Leaf A-D route for a given SR P2MP 412 P-tunnel, the Root PE MUST remove the Leaf PE from the P2MP tree by 413 invoking UpdateLeafSet API of PCE. Note that Root PE MAY remove the 414 P2MP tree, via the DeletePolicyAPI, before the last Leaf A-D is 415 withdrawn. In this case, the Root PE MAY decide to not invoke the 416 UpdateLeafSet API. 418 5. Dampening of MVPN routes 420 When P2MP trees are used as P-Tunnels for S-PMSI A-D routes, change 421 in group membership of receivers connected to PEs has direct impact 422 on the Leaf node set of a P2MP tree. If group membership changes 423 frequently for a large number of groups with a lot of receivers 424 across sites connected to different PEs, it can have an impact on the 425 interaction between PEs and the PCE. 427 Since Leaf A-D routes are used to discover Leaf PE of a P2MP tree, it 428 is RECOMMENDED that PEs SHOULD damp Leaf A-D routes as described in 429 Section 6.1 of RFC 7899 [RFC7899]. PEs MAY also implement procedures 430 for damping other Auto-Discovery and BGP C-multicast routes as 431 described in [RFC7899]. 433 6. SR P2MP Trees for EVPN 435 BGP MPLS Ethernet VPN specified in RFC 7432 specifies Inclusive 436 Multicast Ethernet Tag route to support Broadcast, Unknown Unicast 437 and Multicast (BUM) traffic. This IMET route is the equivalent of 438 MVPN Intra-AS I-PMSI route and is advertised with a PMSI Tunnel 439 Attribute (PTA) as specified in RFC 6514 to advertise the inclusive 440 P-tunnels. 442 [I-D.ietf-bess-evpn-bum-procedure-updates] updates BUM procedures to 443 support selective P-tunnels and P-tunnel segmentation in EVPN. That 444 document specifies new route types that are advertised with PTA, 445 including Selective PMSI (S-PMSI) Auto-Discovery route. 447 These inclusive/selective P-tunnels can be realized by SR P2MP trees. 448 As with other types of P2MP P-tunnels, the ESI label used for split 449 horizon MUST be either upstream assigned by PE advertising the IMET 450 or S-PMSI route, or assigned from a global context such as "Domain- 451 wide Common Block" (DCB) as specified in 452 [I-D.ietf-bess-mvpn-evpn-aggregation-label]. 454 [I-D.ietf-bess-evpn-irb-mcast] specifies procedures to support Inter- 455 Subnet Multicast. [I-D.ietf-bess-evpn-mvpn-seamless-interop] 456 specifies how MVPN SAFI routes can be used to support Inter-Subnet 457 Multicast. The P-tunnels advertised in PTA of either EVPN and MVPN 458 routes as specified in these documents respectively can be realized 459 by SR P2MP trees. 461 SRv6 P2MP trees can serve as an underlay multicast as described in 462 RFC 8293 Section 3.4 [11]. A NVE encapsuates a tenant packet in an 463 SRv6 header and deliver it over SRv6 P2MP trees to other NVEs. 465 The same procedures specified for MVPN are used to collect the leaf 466 information of corresponding SR P2MP tree (either based on IMET route 467 or Leaf A-D routes in response to x-PMSI routes), to pass the tree 468 information to the PCE controller, and to get back tree forwarding 469 state used for customer multicast traffic forwarding. 471 7. IANA Considerations 473 IANA is requested assign codepoint for "SR-MPLS P2MP Tree" in the 474 "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" 475 registry [RFC 7538] in the "Border Gateway 477 Protocol (BGP) Parameters" registry. A proposed value is 0x0C. 479 8. Security Considerations 481 The procedures in this document do not introduce any additional 482 security considerations beyond those mentioned in [RFC6513] and 483 [RFC6514]. For general security considerations applicable to P2MP 484 trees, please refer to [I-D.ietf-pim-sr-p2mp-policy] . 486 9. Acknowledgements 488 The authors would like to acknowledge Luc Andre Burdett reviweing the 489 document.. 491 10. Contributors 493 Zafar Ali 494 Cisco Systems, Inc. 495 US 497 Email: zali@cisco.com 499 Ehsan Hemmati 500 Cisco Systems, Inc. 501 US 503 Email: ehemmati@cisco.com 505 Jayant Kotalwar 506 Nokia 507 Mountain View 508 US 510 Email: jayant.kotalwar@nokia.com 512 Tanmoy Kundu 513 Nokia 514 Mountain View 515 US 517 Email: tanmoy.kundu@nokia.com 518 Clayton Hassen 519 Bell Canada 520 Vancouver 521 CA 523 Email: clayton.hassen@bell.ca 525 11. References 527 11.1. Normative References 529 [I-D.ietf-pim-sr-p2mp-policy] 530 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 531 Zhang, "Segment Routing Point-to-Multipoint Policy", 532 draft-ietf-pim-sr-p2mp-policy-01 (work in progress), 533 October 2020. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, 537 DOI 10.17487/RFC2119, March 1997, 538 . 540 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 541 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 542 2012, . 544 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 545 Encodings and Procedures for Multicast in MPLS/BGP IP 546 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 547 . 549 11.2. Informative References 551 [I-D.ietf-bess-evpn-bum-procedure-updates] 552 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 553 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 554 bess-evpn-bum-procedure-updates-08 (work in progress), 555 November 2019. 557 [I-D.ietf-bess-evpn-irb-mcast] 558 Lin, W., Zhang, Z., Drake, J., Rosen, E., Rabadan, J., and 559 A. Sajassi, "EVPN Optimized Inter-Subnet Multicast (OISM) 560 Forwarding", draft-ietf-bess-evpn-irb-mcast-05 (work in 561 progress), October 2020. 563 [I-D.ietf-bess-evpn-mvpn-seamless-interop] 564 Sajassi, A., Thiruvenkatasamy, K., Thoria, S., Gupta, A., 565 and L. Jalil, "Seamless Multicast Interoperability between 566 EVPN and MVPN PEs", draft-ietf-bess-evpn-mvpn-seamless- 567 interop-01 (work in progress), July 2020. 569 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 570 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 571 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 572 ietf-bess-mvpn-evpn-aggregation-label-04 (work in 573 progress), November 2020. 575 [I-D.ietf-spring-sr-replication-segment] 576 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 577 Zhang, "SR Replication Segment for Multi-point Service 578 Delivery", draft-ietf-spring-sr-replication-segment-03 579 (work in progress), October 2020. 581 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 582 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 583 RFC 6625, DOI 10.17487/RFC6625, May 2012, 584 . 586 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 587 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 588 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 589 2015, . 591 [RFC7899] Morin, T., Ed., Litkowski, S., Patel, K., Zhang, Z., 592 Kebler, R., and J. Haas, "Multicast VPN State Damping", 593 RFC 7899, DOI 10.17487/RFC7899, June 2016, 594 . 596 [RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R. 597 Krishnan, "A Framework for Multicast in Network 598 Virtualization over Layer 3", RFC 8293, 599 DOI 10.17487/RFC8293, January 2018, 600 . 602 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 603 Decraene, B., Litkowski, S., and R. Shakir, "Segment 604 Routing with the MPLS Data Plane", RFC 8660, 605 DOI 10.17487/RFC8660, December 2019, 606 . 608 11.3. URIs 610 [1] https://tools.ietf.org/html/draft-ietf-pim-sr-p2mp-policy- 611 00#section-4.1.1 613 [2] https://tools.ietf.org/html/rfc6514#section-9.1.1 615 [3] https://tools.ietf.org/html/rfc6514#section-9.1.2 617 [4] https://tools.ietf.org/html/rfc6514#section-12.1 619 [5] https://tools.ietf.org/html/rfc6514#section-12.3 621 [6] https://tools.ietf.org/html/rfc6514#section-12.3 623 [7] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 625 [8] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 627 [9] https://tools.ietf.org/html/rfc6514#section-9.2.3.4.1 629 [10] https://tools.ietf.org/html/rfc6514#section-9.2.3.5 631 [11] https://tools.ietf.org/html/rfc8293#section-3.4 633 Authors' Addresses 635 Rishabh Parekh 636 Cisco Systems, Inc. 637 170 W. Tasman Drive 638 San Jose, CA 95134 639 USA 641 Email: riparekh@cisco.com 643 Clarence Filsfils 644 Cisco Systems, Inc. 645 Brussels 646 BE 648 Email: cfilsfil@cisco.com 649 Arvind Venkateswaran 650 Cisco Systems, Inc. 651 170 W. Tasman Drive 652 San Jose, CA 95134 653 USA 655 Email: arvvenka@cisco.com 657 Hooman Bidgoli 658 Nokia 659 Ottawa 660 CA 662 Email: hooman.bidgoli@nokia.com 664 Daniel Voyer 665 Bell Canada 666 Montreal 667 CA 669 Email: daniel.voyer@bell.ca 671 Zhaohui Zhang 672 Juniper Networks 674 Email: zzhang@juniper.net