idnits 2.17.1 draft-parekh-bess-mvpn-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 (October 29, 2019) is 1633 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 512 -- Looks like a reference, but probably isn't: '2' on line 514 -- Looks like a reference, but probably isn't: '3' on line 516 -- Looks like a reference, but probably isn't: '4' on line 518 -- Looks like a reference, but probably isn't: '5' on line 520 -- Looks like a reference, but probably isn't: '6' on line 522 -- Looks like a reference, but probably isn't: '7' on line 524 -- Looks like a reference, but probably isn't: '8' on line 526 -- Looks like a reference, but probably isn't: '9' on line 528 == Outdated reference: A later version (-02) exists of draft-voyer-pim-sr-p2mp-policy-00 == Outdated reference: A later version (-04) exists of draft-voyer-spring-sr-replication-segment-00 Summary: 0 errors (**), 0 flaws (~~), 3 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: May 1, 2020 Cisco Systems, Inc. 6 H. Bidgoli 7 Nokia 8 D. Voyer 9 Bell Canada 10 Z. Zhang 11 Juniper Networks 12 October 29, 2019 14 Multicast VPN with Segment Routing Point-to-Multipoint Trees 15 draft-parekh-bess-mvpn-sr-p2mp-01.txt 17 Abstract 19 A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain 20 efficiently carries traffic from a Root to a set of Leaves. This 21 document describes extensions to BGP encodings and procedures for 22 P2MP trees used in BGP/MPLS IP VPNs. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 1, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. SR P2MP P-Tunnels for MPVN . . . . . . . . . . . . . . . . . 3 66 3. PMSI Tunnel Attribute for SR P2MP . . . . . . . . . . . . . . 4 67 3.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1.1. SR MPLS . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Auto-Discovery and Binding Procedures . . . . . . . . . . . . 5 70 4.1. Intra-AS I-PMSI . . . . . . . . . . . . . . . . . . . . . 5 71 4.1.1. Originating Intra-AS I-PMSI routes . . . . . . . . . 5 72 4.1.2. Receiving Intra-AS I-PMSI A-D routes . . . . . . . . 6 73 4.2. Using S-PMSIs for binding customer flows to P2MP Segments 7 74 4.2.1. Originating S-PMSI A-D routes . . . . . . . . . . . . 7 75 4.2.2. Receiving S-PMSI A-D routes . . . . . . . . . . . . . 7 76 4.3. Inter-AS P-tunnels using P2MP Segments . . . . . . . . . 8 77 4.3.1. Advertising Inter-AS I-PMSI routes into iBGP . . . . 8 78 4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP . . . . 8 79 4.4. Leaf A-D routes for P2MP Segment Leaf Discovery . . . . . 8 80 4.4.1. Originating Leaf A-D routes . . . . . . . . . . . . . 8 81 4.4.2. Receiving Leaf A-D routes . . . . . . . . . . . . . . 9 82 5. Damping of MVPN routes . . . . . . . . . . . . . . . . . . . 9 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 9.2. Informative References . . . . . . . . . . . . . . . . . 11 89 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 RFC 6513 [RFC6513] and RFC 6514 [RFC6514] specify procedures that 95 allow a Service Provider to provide Multicast VPN (MVPN) service to 96 its customers. Multicast traffic from a customer is tunneled across 97 the service provider network over Provider Tunnels (P-Tunnels). 98 P-tunnels can be instantiated via different technologies. A service 99 provider network that uses Segment Routing can use a Point-to- 100 Multipoint (SR P2MP) tree [I-D.voyer-pim-sr-p2mp-policy] to 101 instantiate P-Tunnels for MVPN. 103 In a Segment Routing network, a P2MP tree allows efficient delivery 104 of traffic from a Root to set of Leaf nodes. A SR P2MP tree is 105 defined by a SR P2MP Policy and instantiated via a PCE. A P2MP 106 Policy consists of a Root, a Set of Leaf Nodes and a set of candidate 107 paths with optional set of constraints and/or optimization objectives 108 to be satisfied by the P2MP tree. A unique Identifier, called Tree- 109 SID, is associated with a P2MP tree. This Tree-SID can be an MPLS 110 label or an IPv6 address. 112 This document describes extensions to BGP Auto-Discovery procedures 113 specified in RFC 6514 [RFC6514] when P-Tunnels are realized by SR 114 P2MP trees. Use of PIM for Auto-Discovery is outside scope of this 115 document. Support for customer BIDIR-PIM is outside the scope of 116 this document. 118 The reader is expected to be familiar with concepts and terminology 119 of RFC 6513, RFC 6514 and SR P2MP draft. 121 2. SR P2MP P-Tunnels for MPVN 123 For MVPN, Provider Edge(PE) routers steer customer multicast traffic 124 into a P-Tunnel instantiated by SR P2MP tree. A SR P2MP tree is 125 defined by a SR P2MP policy [I-D.voyer-pim-sr-p2mp-policy]. 127 Given a SR P2MP policy, a PCE computes and instantiates the SR P2MP 128 tree on the nodes that are part of the tree using Replication 129 segments and Tree-SID which a unique identifier for the tree 130 [I-D.voyer-spring-sr-replication-segment]. A Replication segment can 131 be initiated by various methods (BGP, PCEP, others) which are outside 132 the scope of this document. 134 A PCE provides conceptual APIs, listed below, to define and modify SR 135 P2MP policies. These APIs are invoked by a PCC, which is the root of 136 P2MP tree, using various methods (BGP, PCEP, etc.) which are outside 137 the scope of this document. 139 CreatePolicy: TBD 140 DeletePolicy: TBD 142 AddLeaf: TBD 144 DeleteLeaf: TBD 146 The Root of a P2MP tree imposes the Tree-SID to steer the customer 147 payload into the P2MP tree. Provider (P) routers replicate customer 148 payload, using Replication segments, towards the Leaf nodes of the 149 P2MP tree. Leaf nodes of the P2MP tree deliver the customer payload 150 after dispoing the Tree-SID. 152 3. PMSI Tunnel Attribute for SR P2MP 154 A PMSI Tunnel Attribute (PTA) is defined in RFC 6514 [RFC6514] to 155 identify the P-Tunnel that is used to instantiate a Provider 156 Multicast Service Interface (PMSI). The PTA is carried in Intra-AS 157 I-PMSI, Inter-AS I-PMSI, Selective PMSI, and Leaf Auto-Discovery 158 routes. 160 A P2MP tree PTA is constructed as follows: 162 o Tunnel Type: The codepoint is set to [[CREF1: TBD]]for SR P2MP 163 tree from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) 164 Tunnel Types" registry. 166 o Flags: See Section 4 for use of "Leaf Info Required bit". 168 o MPLS Label: See Section 3.1 170 o Tunnel Identifier: The SR P2MP P-tunnel is identified by where, 173 * Tree-ID is a 32-bit unsigned value that identifies a unique 174 P2MP tree at a Root.. 176 * Root is an IP address identifying the Root of a P2MP tree. 177 This can be either an IPv4 or IPv6 address and can be inferred 178 from the PTA length. 180 When a P-Tunnel is non-segmented, the PTA is created by PE router at 181 the Root of a SR P2MP tree. For segmented P-tunnels, each segment 182 can be instantiated by a different technology. If a segment is 183 instantiated using P2MP tree, the router at the root of a P2MP tree 184 creates the PTA. 186 3.1. MPLS Label 188 [RFC6514] allows a PE to aggregate two or more MVPNs onto one 189 P-tunnel by advertising the same P-tunnel in PTA of Auto-Discovery 190 routes of different MVPNs. This section specifies how the "MPLS 191 Label" field of PTA is filled to provide a context bound to a 192 specific MPVN. 194 3.1.1. SR MPLS 196 When a SR P2MP P-tunnel, shared across different MVPNs, is 197 instantiated in a SR MPLS domain 198 [I-D.filsfils-spring-segment-routing-mpls], "MPLS Field" of a PTA 199 advertised in a Auto-Discovery route MUST contain an upstream- 200 assigned MPLS label that the advertising PE has bound to the MVPN. 202 When a customer payload is steered into a shared SR P2MP P-tunnel, 203 this MPLS label MUST be imposed before the MPLS label reprsenting the 204 Tree-SID. 206 4. Auto-Discovery and Binding Procedures 208 RFC 6514 [RFC6514] defines procedures for discovering PEs 209 participating in a given MVPN and binding customer multicast flows to 210 specific P-Tunnels. This section specifies modifications to these 211 procedures for SR P2MP P-Tunnels. 213 4.1. Intra-AS I-PMSI 215 Intra-AS I-PMSI A-D routes are exchanged to discover PEs 216 participating in a MVPN within an AS, or across different ASes when 217 non-segmented P-tunnels for inter-AS MVPNs. 219 4.1.1. Originating Intra-AS I-PMSI routes 221 RFC 6514 Section 9.1.1 [1] describes procedures for originating 222 Intra-AS I-PMSI A-D routes. For SR P2MP P-tunnels, these procedures 223 remain unchanged except as described in the following paragraphs. 225 When a PE originates an Intra-AS I-PMSI A-D route with a PTA having 226 SR P2MP P-tunnel Type, it MUST create a P2MP policy by invoking 227 CreatePolicy API of the PCE. When the PCE instantiates the P2MP tree 228 on the PE, the Tree-SID MUST be imposed for customer flow(s) steered 229 into the P2MP tree. The Leaf nodes of P2MP tree are discovered using 230 procedures described in Section 4.1.2. 232 For a PE in "Receiver Sites set", condition (c) is modified to 233 include P2MP tree i.e. such a PE MUST originate an Intra-AS I-PMSI 234 A-D route when some PEs of the MVPN have VRFs that use SR P2MP tree 235 but MUST NOT create a SR P2MP policy as described above. 237 When a PE withdraws an Intra-AS I-PMSI A-D route, advertised with a 238 PTA having SR P2MP P-tunnel Type, the Tree-SID imposition state at 239 the PE MUST be removed. 241 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 242 onto the same SR P2MP P-tunnel. When a PE withdraws the last Intra- 243 AS I-PMSI A-D route, advertised with a PTA identifying a SR P2MP 244 P-tunnel , it SHOULD remove the SR P2MP policy by invoking 245 DeletePolicy API of the PCE. 247 4.1.2. Receiving Intra-AS I-PMSI A-D routes 249 Procedure for receiving Intra-AS I-PMSI A-D routes, as described in 250 RFC 6514 Section 9.1.2 [2], remain unchanged for SR P2MP P-tunnels 251 except as described in the following paragraphs. 253 When a PE that advertises a SR P2MP P-tunnel in the PTA of its Intra- 254 AS I-PMSI A-D route, imports an Intra-AS I-PMSI A-D route from some 255 PE, it MUST add that PE as a Leaf node of the P2MP tree. The 256 Originating IP Address of the Intra-AS i-PMSI A-D route is used as 257 the Leaf Address when invoking AddLeaf API of the PCE. This 258 procedure MUST also be followed for all Intra-AS I-PMSI routes that 259 are already imported when the PE advertises a SR P2MP P-tunnel in PTA 260 of its Intra-AS I-PMSI A-D route. 262 A PE that imports and processes an Intra-AS I-PMSI A-D route from 263 another PE with PTA having SR P2MP P-Tunnel MUST program the Tree-SID 264 of the P2MP tree identified in the PTA of the route for disposition. 265 Note that an Intra-AS I-PMSI A-D route from another PE can be 266 imported before the P2MP tree identified in the PTA of the route is 267 instantiated by the PCEat the importing PE. In such case, the PE 268 MUST correctly program Tree-SID for disposition. A PE in "Sender 269 Sites set" MAY avoid programming the Tree-SID for disposition. 271 When an Intra-AS I-PMSI A-D route, advertised with a PTA having SR 272 P2MP P-tunnel Type is withdrawn, a PE MUST remove the disposition 273 state of the Tree-SID associated with P2MP tree. 275 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 276 onto the same SR P2MP P-tunnel. When a remote PE withdraws an Intra- 277 AS I-PMSI A-D route from a MVPN, and if this is the last MVPN sharing 278 a SR P2MP P-tunnel, a PE must remove the originating PE as a Leaf 279 from the P2MP tree, by invoking DeleteLeaf API. 281 4.2. Using S-PMSIs for binding customer flows to P2MP Segments 283 RFC 6514 [RFC6514] specifies procedures for binding (C-S,C-G) 284 customer flows to P-tunnels using S-PMSI A-D routes. RFC 6525 285 [RFC6625] specifies additional procedures to binding aggregate 286 customer flows to P-tunnels using "wildcard" S-PMSI A-D routes. This 287 section describes modification to these procedures for SR P2MP 288 P-tunnels. 290 4.2.1. Originating S-PMSI A-D routes 292 RFC 6514 Section 12.1 [3] describes procedures for originating S-PMSI 293 A-D routes. For SR P2MP P-tunnels, these procedures remain unchanged 294 except as described in the following paragraphs. 296 When a PE originates S-PMSI A-D route with a PTA having SR P2MP 297 P-tunnel Type, it MUST set the "Leaf Info Required bit" in the PTA. 298 The PE MUST create a SR P2MP policy by invoking1 API of the PCE. 299 When the PCEinstantiates the P2MP tree on the PE, the Tree-SID MUST 300 be imposed for customer flows steered into the SR P2MP P-tunnel. 302 The Leaf nodes of P2MP tree are discovered by Leaf A-D routes using 303 procedures described in Section 4.4.2. When a PE originates S-PMSI 304 A-D route with a PTA having SR P2MP P-tunnel Type, it is possible the 305 PE might have imported Leaf A-D routes whose route keys match the 306 S-PMSI A-D route. The PE MUST re-apply procedures of Section 4.4.2 307 to these Leaf A-D routes. 309 When a PE withdraws a S-PMSI A-D route, advetised with PTA having 310 P2MP tree P-tunnle type, the Tree-SID imposition state MUST be 311 removed. 313 A PE MAY aggregate two or more S-PMSIs onto the same SR P2MP 314 P-tunnel. When a PE withdraws the last S-PMSI A-D route, advertised 315 with a PTA identifying a specific SR P2MP P-tunnel , it SHOULD remove 316 the SR P2MP policy by invoking DeletePolicy API of the PCE. 318 4.2.2. Receiving S-PMSI A-D routes 320 RFC 6514 Section 12.3 [4] describes procedures for receiving S-PMSI 321 A-D routes. For SR P2MP P-tunnels, these procedures remain unchanged 322 except as described in the following paragraphs. 324 The procedure to join SR P2MP P-tunnel of S-PMSI A-D route by using a 325 Leaf A-D route is described in Section 4.4.1. If P2MP tree 326 identified in PTA of S-PMSI A-D route is already instantiated by PCE, 327 the PE MUST program Tree-SID for disposition. If the P2MP tree is 328 instantiated later, the Tree-SID MUST be programmed for disposition 329 at that time. 331 When a S-PMSI A-D route, whose SR P2MP P-tunnel is joined by a PE, is 332 withdrawn, or when conditions (see RFC 6514 Section 12.3 [5]) 333 required to join that P-Tunnel are no longer satisfied, the PE MUST 334 leave the P-Tunnel. The PE MUST withdraw the Leaf A-D route it had 335 originated and remove the Tree-SID disposition state. 337 4.3. Inter-AS P-tunnels using P2MP Segments 339 A segmented inter-AS P-tunnel consists of one or more intra-AS 340 segments, one in each AS, connected by inter-AS segments between 341 ASBRs of different ASes . These segments are constructed by PEs/ASBRs originating or re- 343 advertising Inter-AS I-PMSI A-D routes. This section describes 344 procedures for instantiating intra-AS segments using SR P2MP trees. 346 4.3.1. Advertising Inter-AS I-PMSI routes into iBGP 348 RFC 6514 Section 9.2.3.2 [6] specifies procedures for advertising an 349 Inter-AS I-PMSI A-D route to construct an intra-AS segment. The PTA 350 of the route identifies the type and identifier of the P-tunnel 351 instantiating the intra-AS segment. The procedure for creating SR 352 P2MP P-tunnel for intra-AS segment are same as specified in 353 Section 4.2.1 except that instead of S-PMSI A-D routes, the 354 procedures apply to Inter-AS I-PMSI A-D routes. 356 4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP 358 RFC 6514 Section 9.2.3.2 [7] specifies procedures for processing an 359 Inter-AS I-PMSI A-D route received via iBGP. If the PTA of the 360 Inter-AS I-PMSI A-D route has SR P2MP P-tunnel Type, the procedures 361 are same as specified in Section 4.2.2 except that instead of S-PMSI 362 A-D routes, the procedures apply to Inter-AS I-PMSI A-D routes. If 363 the receiving router is an ASBR, the Tree-SID is stitched to the 364 inter-AS segments to ASBRs in other ASes. 366 4.4. Leaf A-D routes for P2MP Segment Leaf Discovery 368 This section describes procedures for originating and processing Leaf 369 A-D routes used for Leaf discovery of SR P2MP trees. 371 4.4.1. Originating Leaf A-D routes 373 The procedures for originating Leaf A-D route in response to 374 receiving a S-PMSI or Inter-AS I-PMSI A-D route with PTA having SR 375 P2MP P-tunnel Type are same as specified in RFC 6514 376 Section 9.2.3.4.1 [8]. 378 4.4.2. Receiving Leaf A-D routes 380 Procedures for processing a received Leaf A-D route are specified in 381 RFC 6514 Section 9.2.3.5 [9]. These procedures remain unchanged for 382 discovering Leaf nodes of P2MP trees except for considerations 383 described in following paragraphs. These procedures apply to Leaf 384 A-D routes received in response to both S-PMSI and Inter-AS I-PMSI 385 A-D routes, shortened to "A-D routes" in this section 387 A Root PE/ASBR MAY use the same SR P2MP P-tunnel in PTA of two or 388 more A-D routes. For such aggregated P2MP trees, the PE/ASBR MAY 389 receive multiple Leaf A-D routes from a Leaf PE. The P2MP tree for 390 which a Leaf A-D is received can be identified by examining the P2MP 391 tunnel Identifier in the PTA of A-D route that matches "Route Key" 392 field of the Leaf A-D route. When the PE receives the first Leaf A-D 393 route from a Leaf PE, identified by the Originating Router's IP 394 address field, it MUST add that PE as Leaf of the P2MP tree by 395 invoking the AddLeaf API of the PCE. 397 When a Leaf PE withdraws the last Leaf A-D route for a given SR P2MP 398 P-tunnel, the Root PE MUST remove the Leaf PE from the P2MP tree by 399 invoking DeleteLeaf API of PCE. Note that Root PE MAY remove the 400 P2MP tree, via the DeletePolicyAPI, before the last Leaf A-D is 401 withdrawn. In this case, the Root PE MAY decide to not invoke the 402 DeleteLeaf API. 404 5. Damping of MVPN routes 406 When P2MP trees are used as P-Tunnels for S-PMSI A-D routes, change 407 in group membership of receivers connected to PEs has direct impact 408 on the Leaf node set of a P2MP tree. If group membership changes 409 frequently for a large number of groups with a lot of receivers 410 across sites connected to different PEs, it can have an impact on the 411 interaction between PEs and the PCE. 413 Since Leaf A-D routes are used to discover Leaf PE of a P2MP tree, it 414 is RECOMMENDED that PEs SHOULD damp Leaf A-D routes as described in 415 Section 6.1 of RFC 7899 [RFC7899]. PEs MAY also implement procedures 416 for damping other Auto-Discovery and BGP C-multicast routes as 417 described in [RFC7899]. 419 6. IANA Considerations 421 IANA to assign a codepoint [[CREF2: TBD]] for "P2MP tree" in the 422 "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" 423 registry. 425 7. Security Considerations 427 The procedures in this document do not introduce any additional 428 security considerations beyond those mentioned in [RFC6513] and 429 [RFC6514]. For general security considerations applicable to P2MP 430 trees, please refer to [I-D.voyer-pim-sr-p2mp-policy] . 432 8. Contributors 434 Zafar Ali 435 Cisco Systems, Inc. 436 US 438 Email: zali@cisco.com 440 Jayant Kotalwar 441 Nokia 442 Mountain View 443 US 445 Email: jayant.kotalwar@nokia.com 447 Tanmoy Kundu 448 Nokia 449 Mountain View 450 US 452 Email: tanmoy.kundu@nokia.com 454 Clayton Hassen 455 Bell Canada 456 Vancouver 457 CA 459 Email: clayton.hassen@bell.ca 461 9. References 462 9.1. Normative References 464 [I-D.voyer-pim-sr-p2mp-policy] 465 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 466 Zhang, "Segment Routing Point-to-Multipoint Policy", 467 draft-voyer-pim-sr-p2mp-policy-00 (work in progress), 468 October 2019. 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, 472 DOI 10.17487/RFC2119, March 1997, 473 . 475 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 476 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 477 2012, . 479 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 480 Encodings and Procedures for Multicast in MPLS/BGP IP 481 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 482 . 484 9.2. Informative References 486 [I-D.filsfils-spring-segment-routing-mpls] 487 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 488 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 489 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 490 "Segment Routing with MPLS data plane", draft-filsfils- 491 spring-segment-routing-mpls-03 (work in progress), August 492 2014. 494 [I-D.voyer-spring-sr-replication-segment] 495 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 496 Zhang, "SR Replication Segment for Multi-point Service 497 Delivery", draft-voyer-spring-sr-replication-segment-00 498 (work in progress), October 2019. 500 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 501 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 502 RFC 6625, DOI 10.17487/RFC6625, May 2012, 503 . 505 [RFC7899] Morin, T., Ed., Litkowski, S., Patel, K., Zhang, Z., 506 Kebler, R., and J. Haas, "Multicast VPN State Damping", 507 RFC 7899, DOI 10.17487/RFC7899, June 2016, 508 . 510 9.3. URIs 512 [1] https://tools.ietf.org/html/rfc6514#section-9.1.1 514 [2] https://tools.ietf.org/html/rfc6514#section-9.1.2 516 [3] https://tools.ietf.org/html/rfc6514#section-12.1 518 [4] https://tools.ietf.org/html/rfc6514#section-12.3 520 [5] https://tools.ietf.org/html/rfc6514#section-12.3 522 [6] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 524 [7] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 526 [8] https://tools.ietf.org/html/rfc6514#section-9.2.3.4.1 528 [9] https://tools.ietf.org/html/rfc6514#section-9.2.3.5 530 Authors' Addresses 532 Rishabh Parekh 533 Cisco Systems, Inc. 534 170 W. Tasman Drive 535 San Jose, CA 95134 536 USA 538 Email: riparekh@cisco.com 540 Clarence Filsfils 541 Cisco Systems, Inc. 542 Brussels 543 BE 545 Email: cfilsfil@cisco.com 547 Arvind Venkateswaran 548 Cisco Systems, Inc. 549 170 W. Tasman Drive 550 San Jose, CA 95134 551 USA 553 Email: arvvenka@cisco.com 554 Hooman Bidgoli 555 Nokia 556 Ottawa 557 CA 559 Email: hooman.bidgoli@nokia.com 561 Daniel Voyer 562 Bell Canada 563 Montreal 564 CA 566 Email: daniel.voyer@bell.ca 568 Zhaohui Zhang 569 Juniper Networks 571 Email: zzhang@juniper.net