idnits 2.17.1 draft-parekh-bess-mvpn-evpn-sr-p2mp-00.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 (March 04, 2020) is 1514 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 589 -- Looks like a reference, but probably isn't: '2' on line 591 -- Looks like a reference, but probably isn't: '3' on line 593 -- Looks like a reference, but probably isn't: '4' on line 595 -- Looks like a reference, but probably isn't: '5' on line 597 -- Looks like a reference, but probably isn't: '6' on line 599 -- Looks like a reference, but probably isn't: '7' on line 601 -- Looks like a reference, but probably isn't: '8' on line 603 -- Looks like a reference, but probably isn't: '9' on line 605 == Outdated reference: A later version (-02) exists of draft-voyer-pim-sr-p2mp-policy-00 == 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-04 == Outdated reference: A later version (-06) exists of draft-ietf-bess-evpn-mvpn-seamless-interop-00 == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-03 == Outdated reference: A later version (-04) exists of draft-voyer-spring-sr-replication-segment-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 10 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: September 5, 2020 Cisco Systems, Inc. 6 H. Bidgoli 7 Nokia 8 D. Voyer 9 Bell Canada 10 Z. Zhang 11 Juniper Networks 12 March 04, 2020 14 Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint 15 Trees 16 draft-parekh-bess-mvpn-evpn-sr-p2mp-00.txt 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 September 5, 2020. 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 . . . . . . . . . . . . . 7 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 . . . . . 8 81 4.4.1. Originating Leaf A-D routes . . . . . . . . . . . . . 9 82 4.4.2. Receiving Leaf A-D routes . . . . . . . . . . . . . . 9 83 5. Damping of MVPN routes . . . . . . . . . . . . . . . . . . . 9 84 6. SR P2MP Trees for EVPN . . . . . . . . . . . . . . . . . . . 10 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 10.2. Informative References . . . . . . . . . . . . . . . . . 12 91 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 94 1. Introduction 96 RFC 6513 [RFC6513] and RFC 6514 [RFC6514] specify procedures that 97 allow a Service Provider to provide Multicast VPN (MVPN) service to 98 its customers. Multicast traffic from a customer is tunneled across 99 the service provider network over Provider Tunnels (P-Tunnels). 100 P-tunnels can be instantiated via different technologies. A service 101 provider network that uses Segment Routing can use a Point-to- 102 Multipoint (SR P2MP) tree [I-D.voyer-pim-sr-p2mp-policy] to 103 instantiate P-Tunnels for MVPN. 105 In a Segment Routing network, a P2MP tree allows efficient delivery 106 of traffic from a Root to set of Leaf nodes. A SR P2MP tree is 107 defined by a SR P2MP Policy and instantiated via a PCE. A P2MP 108 Policy consists of a Root, a Set of Leaf Nodes and a set of candidate 109 paths with optional set of constraints and/or optimization objectives 110 to be satisfied by the P2MP tree. A unique Identifier, called Tree- 111 SID, is associated with a P2MP tree. This Tree-SID can be an MPLS 112 label or an IPv6 address. 114 This document describes extensions to BGP Auto-Discovery procedures 115 specified in RFC 6514 [RFC6514] when P-Tunnels are realized by SR 116 P2MP trees. Use of PIM for Auto-Discovery is outside scope of this 117 document. Support for customer BIDIR-PIM is outside the scope of 118 this document. 120 For BGP MPLS Ethernet VPN specified in RFC 7432 [RFC7432] and 121 extensions to this document, P-Tunnels are advertised for handling 122 multi-destination traffic. These P-tunnels can be realized by SR 123 P2MP trees. 125 The reader is expected to be familiar with concepts and terminology 126 of RFC 6513, RFC 6514 and SR P2MP draft. 128 2. SR P2MP P-Tunnels 130 For MVPN or EVPN, Provider Edge(PE) routers steer customer traffic 131 into a P-Tunnel that can be instantiated by SR P2MP tree. A SR P2MP 132 tree is defined by a SR P2MP policy [I-D.voyer-pim-sr-p2mp-policy]. 134 Given a SR P2MP policy, a PCE computes and instantiates the SR P2MP 135 tree on the nodes that are part of the tree using Replication 136 segments and Tree-SID which a unique identifier for the tree 137 [I-D.voyer-spring-sr-replication-segment]. A Replication segment can 138 be initiated by various methods (BGP, PCEP, others) which are outside 139 the scope of this document. 141 A PCE provides conceptual APIs, listed below, to define and modify SR 142 P2MP policies. These APIs are invoked by a PCC, which is the root of 143 P2MP tree, using various methods (BGP, PCEP, etc.) which are outside 144 the scope of this document. 146 CreatePolicy: TBD 148 DeletePolicy: TBD 150 AddLeaf: TBD 152 DeleteLeaf: TBD 154 The Root of a P2MP tree imposes the Tree-SID to steer the customer 155 payload into the P2MP tree. Provider (P) routers replicate customer 156 payload, using Replication segments, towards the Leaf nodes of the 157 P2MP tree. Leaf nodes of the P2MP tree deliver the customer payload 158 after dispoing the Tree-SID. 160 3. PMSI Tunnel Attribute for SR P2MP 162 A PMSI Tunnel Attribute (PTA) is defined in RFC 6514 [RFC6514] to 163 identify the P-Tunnel that is used to instantiate a Provider 164 Multicast Service Interface (PMSI). The PTA is carried in Intra-AS 165 I-PMSI, Inter-AS I-PMSI, Selective PMSI, and Leaf Auto-Discovery 166 routes. 168 A P2MP tree PTA is constructed as follows: 170 o Tunnel Type: The codepoint is set to [[CREF1: TBD]]for SR P2MP 171 tree from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) 172 Tunnel Types" registry. 174 o Flags: See Section 4 for use of "Leaf Info Required bit". 176 o MPLS Label: See Section 3.1 178 o Tunnel Identifier: The SR P2MP P-tunnel is identified by where, 181 * Tree-ID is a 32-bit unsigned value that identifies a unique 182 P2MP tree at a Root.. 184 * Root is an IP address identifying the Root of a P2MP tree. 185 This can be either an IPv4 or IPv6 address and can be inferred 186 from the PTA length. 188 When a P-Tunnel is non-segmented, the PTA is created by PE router at 189 the Root of a SR P2MP tree. For segmented P-tunnels, each segment 190 can be instantiated by a different technology. If a segment is 191 instantiated using P2MP tree, the router at the root of a P2MP tree 192 creates the PTA. 194 3.1. MPLS Label 196 [RFC6514] allows a PE to aggregate two or more MVPNs onto one 197 P-tunnel by advertising the same P-tunnel in PTA of Auto-Discovery 198 routes of different MVPNs. This section specifies how the "MPLS 199 Label" field of PTA is filled to provide a context bound to a 200 specific MPVN. For EVPN considerations, see SR P2MP Trees for EVPN 201 section. 203 3.1.1. SR MPLS 205 When a SR P2MP P-tunnel, shared across different MVPNs, is 206 instantiated in a SR MPLS domain 207 [I-D.filsfils-spring-segment-routing-mpls], "MPLS Field" of a PTA 208 advertised in a Auto-Discovery route MUST contain an upstream- 209 assigned MPLS label that the advertising PE has bound to the MVPN. 211 When a customer payload is steered into a shared SR P2MP P-tunnel, 212 this MPLS label MUST be imposed before the MPLS label representing 213 the Tree-SID. 215 4. MVPN Auto-Discovery and Binding Procedures 217 RFC 6514 [RFC6514] defines procedures for discovering PEs 218 participating in a given MVPN and binding customer multicast flows to 219 specific P-Tunnels. This section specifies modifications to these 220 procedures for SR P2MP P-Tunnels. 222 4.1. Intra-AS I-PMSI 224 Intra-AS I-PMSI A-D routes are exchanged to discover PEs 225 participating in a MVPN within an AS, or across different ASes when 226 non-segmented P-tunnels for inter-AS MVPNs. 228 4.1.1. Originating Intra-AS I-PMSI routes 230 RFC 6514 Section 9.1.1 [1] describes procedures for originating 231 Intra-AS I-PMSI A-D routes. For SR P2MP P-tunnels, these procedures 232 remain unchanged except as described in the following paragraphs. 234 When a PE originates an Intra-AS I-PMSI A-D route with a PTA having 235 SR P2MP P-tunnel Type, it MUST create a P2MP policy by invoking 236 CreatePolicy API of the PCE. When the PCE instantiates the P2MP tree 237 on the PE, the Tree-SID MUST be imposed for customer flow(s) steered 238 into the P2MP tree. The Leaf nodes of P2MP tree are discovered using 239 procedures described in Section 4.1.2. 241 For a PE in "Receiver Sites set", condition (c) is modified to 242 include P2MP tree i.e. such a PE MUST originate an Intra-AS I-PMSI 243 A-D route when some PEs of the MVPN have VRFs that use SR P2MP tree 244 but MUST NOT create a SR P2MP policy as described above. 246 When a PE withdraws an Intra-AS I-PMSI A-D route, advertised with a 247 PTA having SR P2MP P-tunnel Type, the Tree-SID imposition state at 248 the PE MUST be removed. 250 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 251 onto the same SR P2MP P-tunnel. When a PE withdraws the last Intra- 252 AS I-PMSI A-D route, advertised with a PTA identifying a SR P2MP 253 P-tunnel , it SHOULD remove the SR P2MP policy by invoking 254 DeletePolicy API of the PCE. 256 4.1.2. Receiving Intra-AS I-PMSI A-D routes 258 Procedure for receiving Intra-AS I-PMSI A-D routes, as described in 259 RFC 6514 Section 9.1.2 [2], remain unchanged for SR P2MP P-tunnels 260 except as described in the following paragraphs. 262 When a PE that advertises a SR P2MP P-tunnel in the PTA of its Intra- 263 AS I-PMSI A-D route, imports an Intra-AS I-PMSI A-D route from some 264 PE, it MUST add that PE as a Leaf node of the P2MP tree. The 265 Originating IP Address of the Intra-AS i-PMSI A-D route is used as 266 the Leaf Address when invoking AddLeaf API of the PCE. This 267 procedure MUST also be followed for all Intra-AS I-PMSI routes that 268 are already imported when the PE advertises a SR P2MP P-tunnel in PTA 269 of its Intra-AS I-PMSI A-D route. 271 A PE that imports and processes an Intra-AS I-PMSI A-D route from 272 another PE with PTA having SR P2MP P-Tunnel MUST program the Tree-SID 273 of the P2MP tree identified in the PTA of the route for disposition. 274 Note that an Intra-AS I-PMSI A-D route from another PE can be 275 imported before the P2MP tree identified in the PTA of the route is 276 instantiated by the PCEat the importing PE. In such case, the PE 277 MUST correctly program Tree-SID for disposition. A PE in "Sender 278 Sites set" MAY avoid programming the Tree-SID for disposition. 280 When an Intra-AS I-PMSI A-D route, advertised with a PTA having SR 281 P2MP P-tunnel Type is withdrawn, a PE MUST remove the disposition 282 state of the Tree-SID associated with P2MP tree. 284 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 285 onto the same SR P2MP P-tunnel. When a remote PE withdraws an Intra- 286 AS I-PMSI A-D route from a MVPN, and if this is the last MVPN sharing 287 a SR P2MP P-tunnel, a PE must remove the originating PE as a Leaf 288 from the P2MP tree, by invoking DeleteLeaf API. 290 4.2. Using S-PMSIs for binding customer flows to P2MP Segments 292 RFC 6514 [RFC6514] specifies procedures for binding (C-S,C-G) 293 customer flows to P-tunnels using S-PMSI A-D routes. RFC 6525 294 [RFC6625] specifies additional procedures to binding aggregate 295 customer flows to P-tunnels using "wildcard" S-PMSI A-D routes. This 296 section describes modification to these procedures for SR P2MP 297 P-tunnels. 299 4.2.1. Originating S-PMSI A-D routes 301 RFC 6514 Section 12.1 [3] describes procedures for originating S-PMSI 302 A-D routes. For SR P2MP P-tunnels, these procedures remain unchanged 303 except as described in the following paragraphs. 305 When a PE originates S-PMSI A-D route with a PTA having SR P2MP 306 P-tunnel Type, it MUST set the "Leaf Info Required bit" in the PTA. 307 The PE MUST create a SR P2MP policy by invoking1 API of the PCE. 308 When the PCEinstantiates the P2MP tree on the PE, the Tree-SID MUST 309 be imposed for customer flows steered into the SR P2MP P-tunnel. 311 The Leaf nodes of P2MP tree are discovered by Leaf A-D routes using 312 procedures described in Section 4.4.2. When a PE originates S-PMSI 313 A-D route with a PTA having SR P2MP P-tunnel Type, it is possible the 314 PE might have imported Leaf A-D routes whose route keys match the 315 S-PMSI A-D route. The PE MUST re-apply procedures of Section 4.4.2 316 to these Leaf A-D routes. 318 When a PE withdraws a S-PMSI A-D route, advetised with PTA having 319 P2MP tree P-tunnle type, the Tree-SID imposition state MUST be 320 removed. 322 A PE MAY aggregate two or more S-PMSIs onto the same SR P2MP 323 P-tunnel. When a PE withdraws the last S-PMSI A-D route, advertised 324 with a PTA identifying a specific SR P2MP P-tunnel , it SHOULD remove 325 the SR P2MP policy by invoking DeletePolicy API of the PCE. 327 4.2.2. Receiving S-PMSI A-D routes 329 RFC 6514 Section 12.3 [4] describes procedures for receiving S-PMSI 330 A-D routes. For SR P2MP P-tunnels, these procedures remain unchanged 331 except as described in the following paragraphs. 333 The procedure to join SR P2MP P-tunnel of S-PMSI A-D route by using a 334 Leaf A-D route is described in Section 4.4.1. If P2MP tree 335 identified in PTA of S-PMSI A-D route is already instantiated by PCE, 336 the PE MUST program Tree-SID for disposition. If the P2MP tree is 337 instantiated later, the Tree-SID MUST be programmed for disposition 338 at that time. 340 When a S-PMSI A-D route, whose SR P2MP P-tunnel is joined by a PE, is 341 withdrawn, or when conditions (see RFC 6514 Section 12.3 [5]) 342 required to join that P-Tunnel are no longer satisfied, the PE MUST 343 leave the P-Tunnel. The PE MUST withdraw the Leaf A-D route it had 344 originated and remove the Tree-SID disposition state. 346 4.3. Inter-AS P-tunnels using P2MP Segments 348 A segmented inter-AS P-tunnel consists of one or more intra-AS 349 segments, one in each AS, connected by inter-AS segments between 350 ASBRs of different ASes . These segments are constructed by PEs/ASBRs originating or re- 352 advertising Inter-AS I-PMSI A-D routes. This section describes 353 procedures for instantiating intra-AS segments using SR P2MP trees. 355 4.3.1. Advertising Inter-AS I-PMSI routes into iBGP 357 RFC 6514 Section 9.2.3.2 [6] specifies procedures for advertising an 358 Inter-AS I-PMSI A-D route to construct an intra-AS segment. The PTA 359 of the route identifies the type and identifier of the P-tunnel 360 instantiating the intra-AS segment. The procedure for creating SR 361 P2MP P-tunnel for intra-AS segment are same as specified in 362 Section 4.2.1 except that instead of S-PMSI A-D routes, the 363 procedures apply to Inter-AS I-PMSI A-D routes. 365 4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP 367 RFC 6514 Section 9.2.3.2 [7] specifies procedures for processing an 368 Inter-AS I-PMSI A-D route received via iBGP. If the PTA of the 369 Inter-AS I-PMSI A-D route has SR P2MP P-tunnel Type, the procedures 370 are same as specified in Section 4.2.2 except that instead of S-PMSI 371 A-D routes, the procedures apply to Inter-AS I-PMSI A-D routes. If 372 the receiving router is an ASBR, the Tree-SID is stitched to the 373 inter-AS segments to ASBRs in other ASes. 375 4.4. Leaf A-D routes for P2MP Segment Leaf Discovery 377 This section describes procedures for originating and processing Leaf 378 A-D routes used for Leaf discovery of SR P2MP trees. 380 4.4.1. Originating Leaf A-D routes 382 The procedures for originating Leaf A-D route in response to 383 receiving a S-PMSI or Inter-AS I-PMSI A-D route with PTA having SR 384 P2MP P-tunnel Type are same as specified in RFC 6514 385 Section 9.2.3.4.1 [8]. 387 4.4.2. Receiving Leaf A-D routes 389 Procedures for processing a received Leaf A-D route are specified in 390 RFC 6514 Section 9.2.3.5 [9]. These procedures remain unchanged for 391 discovering Leaf nodes of P2MP trees except for considerations 392 described in following paragraphs. These procedures apply to Leaf 393 A-D routes received in response to both S-PMSI and Inter-AS I-PMSI 394 A-D routes, shortened to "A-D routes" in this section 396 A Root PE/ASBR MAY use the same SR P2MP P-tunnel in PTA of two or 397 more A-D routes. For such aggregated P2MP trees, the PE/ASBR MAY 398 receive multiple Leaf A-D routes from a Leaf PE. The P2MP tree for 399 which a Leaf A-D is received can be identified by examining the P2MP 400 tunnel Identifier in the PTA of A-D route that matches "Route Key" 401 field of the Leaf A-D route. When the PE receives the first Leaf A-D 402 route from a Leaf PE, identified by the Originating Router's IP 403 address field, it MUST add that PE as Leaf of the P2MP tree by 404 invoking the AddLeaf API of the PCE. 406 When a Leaf PE withdraws the last Leaf A-D route for a given SR P2MP 407 P-tunnel, the Root PE MUST remove the Leaf PE from the P2MP tree by 408 invoking DeleteLeaf API of PCE. Note that Root PE MAY remove the 409 P2MP tree, via the DeletePolicyAPI, before the last Leaf A-D is 410 withdrawn. In this case, the Root PE MAY decide to not invoke the 411 DeleteLeaf API. 413 5. Damping of MVPN routes 415 When P2MP trees are used as P-Tunnels for S-PMSI A-D routes, change 416 in group membership of receivers connected to PEs has direct impact 417 on the Leaf node set of a P2MP tree. If group membership changes 418 frequently for a large number of groups with a lot of receivers 419 across sites connected to different PEs, it can have an impact on the 420 interaction between PEs and the PCE. 422 Since Leaf A-D routes are used to discover Leaf PE of a P2MP tree, it 423 is RECOMMENDED that PEs SHOULD damp Leaf A-D routes as described in 424 Section 6.1 of RFC 7899 [RFC7899]. PEs MAY also implement procedures 425 for damping other Auto-Discovery and BGP C-multicast routes as 426 described in [RFC7899]. 428 6. SR P2MP Trees for EVPN 430 BGP MPLS Ethernet VPN specified in RFC 7432 [RFC7432] specifies 431 Inclusive Multicast Ethernet Tag route to support Broadcast, Unknown 432 Unicast and Multicast (BUM) traffic. This IMET route is the 433 equivalent of MVPN Intra-AS I-PMSI route and is advertised with a 434 PMSI Tunnel Attribute (PTA) as specified in RFC 6514 [RFC6514]. 435 P-tunnels advertised in the PTA can be realized by SR P2MP trees. 436 For SR P2MP trees, the ESI label used for split horizon MUST be 437 either upstream assigned by PE advertising Inclusive Multicast 438 Ethernet Tag route or assigned from a global context such as "Domain- 439 wide Common Block" (DCB) as specified in 440 [I-D.ietf-bess-mvpn-evpn-aggregation-label]. 442 [I-D.ietf-bess-evpn-bum-procedure-updates] updates BUM procedures to 443 support slective multicast and P-tunnel segmentation in EVPN. This 444 documents specifies new route types that are advertised with PTA. 445 These P-tunnels can be realized by SR P2MP trees. 447 [I-D.ietf-bess-evpn-irb-mcast] specifies procedures to support Inter- 448 Subnet Multicast. [I-D.ietf-bess-evpn-mvpn-seamless-interop] 449 specifies how MVPN SAFI routes can be used to support Inter-Subnet 450 Multicast. The P-tunnels advertised in PTA of either EVPN and MVPN 451 routes as specified in these documents respectively can be realized 452 by SR P2MP trees. 454 The same procedures specified for MVPN are used to collect the leaf 455 information of corresponding SR P2MP tree (either based on IMET route 456 or Leaf A-D routes in response to x-PMSI routes), to pass the tree 457 information to the PCE controller, and to get back tree forwarding 458 state used for customer multicast traffic forwarding. 460 7. IANA Considerations 462 IANA to assign a codepoint [[CREF2: TBD]] for "P2MP tree" in the 463 "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" 464 registry. 466 8. Security Considerations 468 The procedures in this document do not introduce any additional 469 security considerations beyond those mentioned in [RFC6513] and 470 [RFC6514]. For general security considerations applicable to P2MP 471 trees, please refer to [I-D.voyer-pim-sr-p2mp-policy] . 473 9. Contributors 475 Zafar Ali 476 Cisco Systems, Inc. 477 US 479 Email: zali@cisco.com 481 Ehsan Hemmati 482 Cisco Systems, Inc. 483 US 485 Email: ehemmati@cisco.com 487 Jayant Kotalwar 488 Nokia 489 Mountain View 490 US 492 Email: jayant.kotalwar@nokia.com 494 Tanmoy Kundu 495 Nokia 496 Mountain View 497 US 499 Email: tanmoy.kundu@nokia.com 501 Clayton Hassen 502 Bell Canada 503 Vancouver 504 CA 506 Email: clayton.hassen@bell.ca 508 10. References 510 10.1. Normative References 512 [I-D.voyer-pim-sr-p2mp-policy] 513 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 514 Zhang, "Segment Routing Point-to-Multipoint Policy", 515 draft-voyer-pim-sr-p2mp-policy-00 (work in progress), 516 October 2019. 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, 520 DOI 10.17487/RFC2119, March 1997, 521 . 523 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 524 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 525 2012, . 527 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 528 Encodings and Procedures for Multicast in MPLS/BGP IP 529 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 530 . 532 10.2. Informative References 534 [I-D.filsfils-spring-segment-routing-mpls] 535 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 536 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 537 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 538 "Segment Routing with MPLS data plane", draft-filsfils- 539 spring-segment-routing-mpls-03 (work in progress), August 540 2014. 542 [I-D.ietf-bess-evpn-bum-procedure-updates] 543 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 544 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 545 bess-evpn-bum-procedure-updates-08 (work in progress), 546 November 2019. 548 [I-D.ietf-bess-evpn-irb-mcast] 549 Lin, W., Zhang, Z., Drake, J., Rosen, E., Rabadan, J., and 550 A. Sajassi, "EVPN Optimized Inter-Subnet Multicast (OISM) 551 Forwarding", draft-ietf-bess-evpn-irb-mcast-04 (work in 552 progress), October 2019. 554 [I-D.ietf-bess-evpn-mvpn-seamless-interop] 555 Sajassi, A., Thiruvenkatasamy, K., Thoria, S., Gupta, A., 556 and L. Jalil, "Seamless Multicast Interoperability between 557 EVPN and MVPN PEs", draft-ietf-bess-evpn-mvpn-seamless- 558 interop-00 (work in progress), November 2019. 560 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 561 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 562 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 563 ietf-bess-mvpn-evpn-aggregation-label-03 (work in 564 progress), October 2019. 566 [I-D.voyer-spring-sr-replication-segment] 567 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 568 Zhang, "SR Replication Segment for Multi-point Service 569 Delivery", draft-voyer-spring-sr-replication-segment-02 570 (work in progress), November 2019. 572 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 573 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 574 RFC 6625, DOI 10.17487/RFC6625, May 2012, 575 . 577 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 578 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 579 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 580 2015, . 582 [RFC7899] Morin, T., Ed., Litkowski, S., Patel, K., Zhang, Z., 583 Kebler, R., and J. Haas, "Multicast VPN State Damping", 584 RFC 7899, DOI 10.17487/RFC7899, June 2016, 585 . 587 10.3. URIs 589 [1] https://tools.ietf.org/html/rfc6514#section-9.1.1 591 [2] https://tools.ietf.org/html/rfc6514#section-9.1.2 593 [3] https://tools.ietf.org/html/rfc6514#section-12.1 595 [4] https://tools.ietf.org/html/rfc6514#section-12.3 597 [5] https://tools.ietf.org/html/rfc6514#section-12.3 599 [6] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 601 [7] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 603 [8] https://tools.ietf.org/html/rfc6514#section-9.2.3.4.1 605 [9] https://tools.ietf.org/html/rfc6514#section-9.2.3.5 607 Authors' Addresses 608 Rishabh Parekh 609 Cisco Systems, Inc. 610 170 W. Tasman Drive 611 San Jose, CA 95134 612 USA 614 Email: riparekh@cisco.com 616 Clarence Filsfils 617 Cisco Systems, Inc. 618 Brussels 619 BE 621 Email: cfilsfil@cisco.com 623 Arvind Venkateswaran 624 Cisco Systems, Inc. 625 170 W. Tasman Drive 626 San Jose, CA 95134 627 USA 629 Email: arvvenka@cisco.com 631 Hooman Bidgoli 632 Nokia 633 Ottawa 634 CA 636 Email: hooman.bidgoli@nokia.com 638 Daniel Voyer 639 Bell Canada 640 Montreal 641 CA 643 Email: daniel.voyer@bell.ca 645 Zhaohui Zhang 646 Juniper Networks 648 Email: zzhang@juniper.net