idnits 2.17.1 draft-parekh-bess-mvpn-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 11, 2019) is 1873 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 506 -- Looks like a reference, but probably isn't: '2' on line 508 -- Looks like a reference, but probably isn't: '3' on line 510 -- Looks like a reference, but probably isn't: '4' on line 512 -- Looks like a reference, but probably isn't: '5' on line 514 -- Looks like a reference, but probably isn't: '6' on line 516 -- Looks like a reference, but probably isn't: '7' on line 518 -- Looks like a reference, but probably isn't: '8' on line 520 -- Looks like a reference, but probably isn't: '9' on line 522 == Outdated reference: A later version (-03) exists of draft-voyer-spring-sr-p2mp-policy-01 Summary: 0 errors (**), 0 flaws (~~), 2 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 12, 2019 Cisco Systems, Inc. 6 H. Bidgoli 7 Nokia 8 D. Voyer 9 C. Hassen 10 Bell Canada 11 March 11, 2019 13 Multicast VPN with Segment Routing Point-to-Multipoint Segment 14 draft-parekh-bess-mvpn-sr-p2mp-00.txt 16 Abstract 18 A Point-to-Multipoint (P2MP) Segment in a Segment Routing domain 19 efficiently carries traffic from a Root to a set of Leaves. This 20 document describes extensions to BGP encodings and procedures for 21 P2MP segments used in BGP/MPLS IP VPNs. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 12, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. P2MP Segment P-Tunnels for MPVN . . . . . . . . . . . . . . . 3 65 3. PMSI Tunnel Attribute for P2MP Segment . . . . . . . . . . . 4 66 3.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1.1. SR MPLS . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Auto-Discovery and Binding Procedures . . . . . . . . . . . . 5 69 4.1. Intra-AS I-PMSI . . . . . . . . . . . . . . . . . . . . . 5 70 4.1.1. Originating Intra-AS I-PMSI routes . . . . . . . . . 5 71 4.1.2. Receiving Intra-AS I-PMSI A-D routes . . . . . . . . 6 72 4.2. Using S-PMSIs for binding customer flows to P2MP Segments 7 73 4.2.1. Originating S-PMSI A-D routes . . . . . . . . . . . . 7 74 4.2.2. Receiving S-PMSI A-D routes . . . . . . . . . . . . . 7 75 4.3. Inter-AS P-tunnels using P2MP Segments . . . . . . . . . 8 76 4.3.1. Advertising Inter-AS I-PMSI routes into iBGP . . . . 8 77 4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP . . . . 8 78 4.4. Leaf A-D routes for P2MP Segment Leaf Discovery . . . . . 8 79 4.4.1. Originating Leaf A-D routes . . . . . . . . . . . . . 9 80 4.4.2. Receiving Leaf A-D routes . . . . . . . . . . . . . . 9 81 5. Damping of MVPN routes . . . . . . . . . . . . . . . . . . . 9 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 9.2. Informative References . . . . . . . . . . . . . . . . . 11 88 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 RFC 6513 [RFC6513] and RFC 6514 [RFC6514] specify procedures that 94 allow a Service Provider to provide Multicast VPN (MVPN) service to 95 its customers. Multicast traffic from a customer is tunneled across 96 the service provider network over Provider Tunnels (P-Tunnels). 97 P-tunnels can be instantiated via different technologies. A service 98 provider network that uses Segment Routing can use a Point-to- 99 Multipoint Segment [I-D.voyer-spring-sr-p2mp-policy] (Tree-SID P2MP 100 segment) to instantiate P-Tunnels for MVPN. 102 In a Segment Routing network, a P2MP segment allows efficient 103 delivery of traffic from a Root to set of Leaf nodes. A P2MP segment 104 is defined by a P2MP segment Policy and instantiated via a P2MP 105 policy engine. A P2MP segment Policy consists of a Root, a Set of 106 Leaf Nodes and an optional set of constraints to be satisfied by the 107 P2MP segment. A unique P2MP segment Identifier (P2MP SID) is 108 associated with a P2MP segment. This P2MP SID can be an MPLS label 109 or an IPv6 address. 111 This document describes extensions to BGP Auto-Discovery procedures 112 specified in RFC 6514 [RFC6514] when P-Tunnels are realized by P2MP 113 segments (via P2MP segment Policy). Use of PIM for Auto-Discovery is 114 outside scope of this document. Support for customer BIDIR-PIM is 115 outside the scope of this document. 117 The reader is expected to be familiar with concepts and terminology 118 of RFC 6513, RFC 6514 and SR P2MP draft. 120 2. P2MP Segment P-Tunnels for MPVN 122 For MVPN, Provider Edge(PE) routers steer customer multicast traffic 123 into a P-Tunnel instantiated by P2MP segment. A Tree-SID P2MP 124 segment is defined by a P2MP segment policy 125 [I-D.voyer-spring-sr-p2mp-policy]. 127 A P2MP policy engine provides conceptual APIs, listed below, to 128 define and modify P2MP segment policies. These APIs can be invoked 129 by different methods (BGP, PCEP, etc.) which are outside the scope of 130 this document. 132 CreatePolicy: TBD 134 DeletePolicy: TBD 136 AddLeaf: TBD 138 DeleteLeaf: TBD 140 For a SR P2MP segment policy, the P2MP Policy Engine computes and 141 instantiates the Tree-SID P2MP segment on the nodes that are part of 142 the segment using an Identifier (TreeSID) and a SR Replication 143 [I-D.voyer-spring-sr-p2mp-policy]. A TreeSID segment can be 144 initiated by various methods (BGP, PCEP, others) which are outside 145 the scope of this document. 147 the Root of a P2MP segment imposes the P2MP SID to steer the customer 148 payload into the P2MP segment. Provider (P) routers replicate 149 customer payload, using the P2MP SID, towards the Leaf nodes of the 150 P2MP segment .Leaf nodes of the P2MP segment deliver the customer 151 payload after dispoing the P2MP SID. 153 3. PMSI Tunnel Attribute for P2MP Segment 155 A PMSI Tunnel Attribute (PTA) is defined in RFC 6514 [RFC6514] to 156 identify the P-Tunnel that is used to instantiate a Provider 157 Multicast Service Interface (PMSI). The PTA is carried in Intra-AS 158 I-PMSI, Inter-AS I-PMSI, Selective PMSI, and Leaf Auto-Discovery 159 routes. 161 A P2MP segment PTA is constructed as follows: 163 o Tunnel Type: The codepoint is set to [[CREF1: TBD]]for P2MP 164 segment from the "P-Multicast Service Interface Tunnel (PMSI 165 Tunnel) Tunnel Types" registry. 167 o Flags: See Section 4 for use of "Leaf Info Required bit". 169 o MPLS Label: See Section 3.1 171 o Tunnel Identifier: The P2MP segment P-Tunnel is identified by 172 where, 174 * Tree-ID is a 32-bit unsigned value that identifies a unique 175 P2MP segment at a Root.. 177 * Root is an IP address identifying the Root of a P2MP segment. 178 This can be either an IPv4 or IPv6 address and can be inferred 179 from the PTA length. 181 When a P-Tunnel is non-segmented the PTA is created by PE router at 182 the Root of a P2MP segment. For segmented P-tunnels, each segment 183 can be instantiated by a different technology. If a segment is 184 instantiated using P2MP segment, the router at the root of a P2MP 185 segment creates the PTA. 187 3.1. MPLS Label 189 [RFC6514] allows a PE to aggregate two or more MVPNs onto one 190 P-tunnel by advertising the same P-tunnel in PTA of Auto-Discovery 191 routes of different MVPNs. This section specifies how the "MPLS 192 Label" field of PTA is filled to provide a context bound to a 193 specific MPVN. 195 3.1.1. SR MPLS 197 When a P2MP segment P-tunnel, shared across different MVPNs, is 198 instantiated in a SR MPLS domain 199 [I-D.filsfils-spring-segment-routing-mpls], "MPLS Field" of a PTA 200 advertised in a Auto-Discovery route MUST contain an upstream- 201 assigned MPLS label that the advertising PE has bound to the MVPN. 203 When a customer payload is steered into a shared P2MP segment 204 P-tunnel, this MPLS label MUST be imposed before the MPLS label 205 reprsenting the P2MP SID. 207 4. Auto-Discovery and Binding Procedures 209 RFC 6514 [RFC6514] defines procedures for discovering PEs 210 participating in a given MVPN and binding customer multicast flows to 211 specific P-Tunnels. This section specifies modifications to these 212 procedures when P-Tunnels are instantiated by P2MP segments. 214 4.1. Intra-AS I-PMSI 216 Intra-AS I-PMSI A-D routes are exchanged to discover PEs 217 participating in a MVPN within an AS, or across different ASes when 218 non-segmented P-tunnels for inter-AS MVPNs. 220 4.1.1. Originating Intra-AS I-PMSI routes 222 RFC 6514 Section 9.1.1 [1] describes procedures for originating 223 Intra-AS I-PMSI A-D routes. For P2MP segment P-tunnels, these 224 procedures remain unchanged except as described in the following 225 paragraphs. 227 When a PE originates an Intra-AS I-PMSI A-D route with a PTA having 228 P2MP segment Tunnel Type, it MUST create a P2MP segment policy by 229 invoking CreatePolicy API of the P2MP Policy Engine. When the P2MP 230 Policy Engine instantiates the P2MP segment on the PE, the P2MP SID 231 MUST be imposed for customer flow(s) steered into the P2MP segment. 232 The Leaf nodes of P2MP segment are discovered using procedures 233 described in Section 4.1.2. 235 For a PE in "Receiver Sites set", condition (c) is modified to 236 include P2MP segment i.e. such a PE MUST originate an Intra-AS I-PMSI 237 A-D route when some PEs of the MVPN have VRFs that use P2MP segment 238 but MUST NOT create a P2MP segment policy as described above. 240 When a PE withdraws an Intra-AS I-PMSI A-D route, advertised with a 241 PTA having P2MP segment Tunnel Type, the P2MP SID imposition state at 242 the PE MUST be removed. 244 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 245 onto the same P2MP segment P-Tunnel. When a PE withdraws the last 246 Intra-AS I-PMSI A-D route, advertised with a PTA identifying a P2MP 247 segment P-Tunnel , it SHOULD remove the P2MP segment policy by 248 invoking DeletePolicy API of the P2MP policy engine. 250 4.1.2. Receiving Intra-AS I-PMSI A-D routes 252 Procedure for receiving Intra-AS I-PMSI A-D routes, as described in 253 RFC 6514 Section 9.1.2 [2], remain unchanged for P2MP segment 254 P-tunnels except as described in the following paragraph. 256 When a PE that advertises a P2MP segment in the PTA of its Intra-AS 257 I-PMSI A-D route, imports an Intra-AS I-PMSI A-D route from some PE, 258 it MUST add that PE as a Leaf node of the P2MP segment. The 259 Originating IP Address of the Intra-AS i-PMSI A-D route is used as 260 the Leaf Address when invoking AddLeaf API of the P2MP Policy Engine. 261 This procedure MUST also be followed for all Intra-AS I-PMSI routes 262 that are already imported when the PE advertises a P2MP segment in 263 PTA of its Intra-AS I-PMSI A-D route. 265 A PE that imports and processes an Intra-AS I-PMSI A-D route from 266 another PE with PTA having Tunnel Type as P2MP segment MUST program 267 the P2MP SID of the P2MP segment identified in the PTA of the route 268 for disposition. Note that an Intra-AS I-PMSI A-D route from another 269 PE can be imported before the P2MP segment identified in the PTA of 270 the route is instantiated by the P2MP policy engine at the importing 271 PE. In such case, the PE MUST correctly program P2MP SID for 272 disposition. A PE in "Sender Sites set" MAY avoid programming the 273 P2MP SID for disposition. 275 When an Intra-AS I-PMSI A-D route, advertised with a PTA having P2MP 276 segment Tunnel Type is withdrawn, a PE MUST remove the disposition 277 state of the P2MP SID associated with P2MP segment. 279 A PE MAY aggregate two or more Intra-AS I-PMSIs from different MVPNs 280 onto the same P2MP segment P-Tunnel. When a remote PE withdraws an 281 Intra-AS I-PMSI A-D route from a MVPN, and if this is the last MVPN 282 sharing a P2MP segment P-tunnel, a PE must remove the originating PE 283 as a Leaf from the P2MP segment, by invoking DeleteLeaf API. 285 4.2. Using S-PMSIs for binding customer flows to P2MP Segments 287 RFC 6514 [RFC6514] specifies procedures for binding (C-S,C-G) 288 customer flows to P-tunnels using S-PMSI A-D routes. RFC 6525 289 [RFC6625] specifies additional procedures to binding aggregate 290 customer flows to P-tunnels using "wildcard" S-PMSI A-D routes. This 291 section describes modification to these procedures when P2MP segment 292 P-tunnels. 294 4.2.1. Originating S-PMSI A-D routes 296 RFC 6514 Section 12.1 [3] describes procedures for originating S-PMSI 297 A-D routes. For P2MP segment P-tunnels, these procedures remain 298 unchanged except as described in the following paragraphs. 300 When a PE originates S-PMSI A-D route with a PTA having P2MP segment 301 Tunnel Type, it MUST set the "Leaf Info Required bit" in the PTA. 302 The PE MUST create a P2MP segment policy by invoking1 API of the P2MP 303 Policy Engine. When the P2MP Policy Engine instantiates the P2MP 304 segment on the PE, the P2MP SID MUST be imposed for customer flow(s) 305 steered into the P2MP segment P-Tunnel. 307 The Leaf nodes of P2MP segment are discovered by Leaf A-D routes 308 using procedures described in Section 4.4.2. When a PE originates 309 S-PMSI A-D route with a PTA having P2MP segment Tunnel Type, it is 310 possible the PE might have imported Leaf A-D routes whose route keys 311 match the S-PMSI A-D route. The PE MUST re-apply procedures of 312 Section 4.4.2 to these Leaf A-D routes. 314 When a PE withdraws a S-PMSI A-D route, advetised with PTA having 315 P2MP segment P-tunnle type, the P2MP SID imposition state MUST be 316 removed. 318 A PE MAY aggregate two or more S-PMSIs onto the same P2MP segment 319 P-Tunnel. When a PE withdraws the last S-PMSI A-D route, advertised 320 with a PTA identifying a specific P2MP segment P-Tunnel , it SHOULD 321 remove the P2MP segment policy by invoking DeletePolicy API of the 322 P2MP policy engine. 324 4.2.2. Receiving S-PMSI A-D routes 326 RFC 6514 Section 12.3 [4] describes procedures for receiving S-PMSI 327 A-D routes. For P2MP segment P-tunnels, these procedures remain 328 unchanged except as described in the following paragraphs. 330 The procedure to join P2MP segment P-Tunnel of S-PMSI A-D route by 331 using a Leaf A-D route is described in Section 4.4.1. If P2MP 332 segment identified in PTA of S-PMSI A-D route is already instantiated 333 by P2MP policy engine, the PE MUST program P2MP SID for disposition. 334 If the P2MP segment is instantiated later, the P2MP SID MUST be 335 programmed for disposition at that time. 337 When a S-PMSI A-D route, whose P2MP segment P-Tunnel is joined by a 338 PE, is withdrawn, or when conditions (see RFC 6514 Section 12.3 [5]) 339 required to join that P-Tunnel are no longer satisfied, the PE MUST 340 leave the P-Tunnel. The PE MUST withdraw the Leaf A-D route it had 341 originated and remove the P2MP SID disposition state. 343 4.3. Inter-AS P-tunnels using P2MP Segments 345 A segmented inter-AS P-tunnel consists of one or more intra-AS 346 segments, one in each AS, connected by inter-AS segments between 347 ASBRs of different ASes . These segments are constructed by PEs/ASBRs originating or re- 349 advertising Inter-AS I-PMSI A-D routes. This section describes 350 procedures for instantiating intra-AS segments using P2MP segments. 352 4.3.1. Advertising Inter-AS I-PMSI routes into iBGP 354 RFC 6514 Section 9.2.3.2 [6] specifies procedures for advertising an 355 Inter-AS I-PMSI A-D route to construct an intra-AS segment. The PTA 356 of the route identifies the type and identifier of the P-tunnel 357 instantiating the intra-AS segment. The procedure for creating P2MP 358 segment P-Tunnel for intra-AS segment are same as specified in 359 Section 4.2.1 except that instead of S-PMSI A-D routes, the 360 procedures apply to Inter-AS I-PMSI A-D routes. 362 4.3.2. Receiving Inter-AS I-PMSI A-D routes in iBGP 364 RFC 6514 Section 9.2.3.2 [7] specifies procedures for processing an 365 Inter-AS I-PMSI A-D route received via iBGP. If the PTA of the 366 Inter-AS I-PMSI A-D route has P2MP segment Tunnel Type, the 367 procedures are same as specified in Section 4.2.2 except that instead 368 of S-PMSI A-D routes, the procedures apply to Inter-AS I-PMSI A-D 369 routes. If the receiving router is an ASBR, the P2MP SID is stitched 370 to the inter-AS segments to ASBRs in other ASes. 372 4.4. Leaf A-D routes for P2MP Segment Leaf Discovery 374 This section describes procedures for originating and processing Leaf 375 A-D routes used for Leaf discovery of P2MP segment P-tunnels. 377 4.4.1. Originating Leaf A-D routes 379 The procedures for originating Leaf A-D route in response to 380 receiving a S-PMSI or Inter-AS I-PMSI A-D route with PTA having P2MP 381 segment Tunnel Type are same as specified in RFC 6514 382 Section 9.2.3.4.1 [8]. 384 4.4.2. Receiving Leaf A-D routes 386 Procedures for processing a received Leaf A-D route are specified in 387 RFC 6514 Section 9.2.3.5 [9]. These procedures remain unchanged for 388 discovering Leaf nodes of P2MP segments except for considerations 389 described in following paragraphs. These procedures apply to Leaf 390 A-D routes received in response to both S-PMSI and Inter-AS I-PMSI 391 A-D routes, shortened to "A-D routes" in this section 393 A Root PE/ASBR MAY aggregate two or more A-D routes on the same P2MP 394 segment P-Tunnel. For such aggregated P2MP segments, the PE/ASBR MAY 395 receive multiple Leaf A-D routes from a Leaf PEt. The P2MP segment 396 for which a Leaf A-D is received can be identified by examining the 397 P2MP tunnel Identifier in the PTA of A-D route that matches "Route 398 Key" field of the Leaf A-D route. When the PE receives the first 399 Leaf A-D route from a Leaf PE, identified by the Originating Router's 400 IP address field, it MUST add that PE as Leaf of the P2MP segment by 401 invoking the AddLeaf API of the P2MP policy engine. 403 When a Leaf PE withdraws the last Leaf A-D route for a given P2MP 404 segment, the Root PE MUST remove the Leaf PE from the P2MP segment by 405 invoking DeleteLeaf API of P2MP policy engine. Note that Root PE MAY 406 remove the P2MP segment, via the DeletePolicyAPI, before the last 407 Leaf A-D is withdrawn. In this case, the Root PE MAY decide to not 408 invoke the DeleteLeaf API. 410 5. Damping of MVPN routes 412 When P2MP segments are used as P-Tunnels for S-PMSI A-D routes, 413 change in group membership of receivers connected to PEs has direct 414 impact on the Leaf node set of a P2MP segment. If group membership 415 changes frequently for a large number of groups with a lot of 416 receivers across sites connected to different PEs, it can have an 417 impact on the interaction between PEs and the P2MP policy engine. 419 Since Leaf A-D routes are used to discover Leaf PE of a P2MP segment, 420 it is RECOMMENDED that PEs SHOULD damp Leaf A-D routes as described 421 in Section 6.1 of RFC 7899 [RFC7899]. PEs MAY also implement 422 procedures for damping other Auto-Discovery and BGP C-multicast 423 routes as described in [RFC7899]. 425 6. IANA Considerations 427 IANA to assign a codepoint [[CREF2: TBD]] for "P2MP segment" in the 428 "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" 429 registry. 431 7. Security Considerations 433 The procedures in this document do not introduce any additional 434 security considerations beyond those mentioned in [RFC6513] and 435 [RFC6514]. For general security considerations applicable to P2MP 436 segments, please refer to [I-D.voyer-spring-sr-p2mp-policy] . 438 8. Contributors 440 Zafar Ali 441 Cisco Systems, Inc. 442 US 444 Email: zali@cisco.com 446 Jayant Kotalwar 447 Nokia 448 Mountain View 449 US 451 Email: jayant.kotalwar@nokia.com 453 Tanmoy Kundu 454 Nokia 455 Mountain View 456 US 458 Email: tanmoy.kundu@nokia.com 460 9. References 462 9.1. Normative References 464 [I-D.voyer-spring-sr-p2mp-policy] 465 daniel.voyer@bell.ca, d., Hassen, C., Gillis, K., 466 Filsfils, C., Parekh, R., and H. Bidgoli, "SR Replication 467 Policy for P2MP Service Delivery", draft-voyer-spring-sr- 468 p2mp-policy-01 (work in progress), October 2018. 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 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 495 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 496 RFC 6625, DOI 10.17487/RFC6625, May 2012, 497 . 499 [RFC7899] Morin, T., Ed., Litkowski, S., Patel, K., Zhang, Z., 500 Kebler, R., and J. Haas, "Multicast VPN State Damping", 501 RFC 7899, DOI 10.17487/RFC7899, June 2016, 502 . 504 9.3. URIs 506 [1] https://tools.ietf.org/html/rfc6514#section-9.1.1 508 [2] https://tools.ietf.org/html/rfc6514#section-9.1.2 510 [3] https://tools.ietf.org/html/rfc6514#section-12.1 512 [4] https://tools.ietf.org/html/rfc6514#section-12.3 514 [5] https://tools.ietf.org/html/rfc6514#section-12.3 516 [6] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 518 [7] https://tools.ietf.org/html/rfc6514#section-9.2.3.2 520 [8] https://tools.ietf.org/html/rfc6514#section-9.2.3.4.1 522 [9] https://tools.ietf.org/html/rfc6514#section-9.2.3.5 524 Authors' Addresses 526 Rishabh Parekh 527 Cisco Systems, Inc. 528 170 W. Tasman Drive 529 San Jose, CA 95134 530 USA 532 Email: riparekh@cisco.com 534 Clarence Filsfils 535 Cisco Systems, Inc. 536 Brussels 537 BE 539 Email: cfilsfil@cisco.com 541 Arvind Venkateswaran 542 Cisco Systems, Inc. 543 170 W. Tasman Drive 544 San Jose, CA 95134 545 USA 547 Email: arvvenka@cisco.com 549 Hooman Bidgoli 550 Nokia 551 Ottawa 552 CA 554 Email: hooman.bidgoli@nokia.com 556 Daniel Voyer 557 Bell Canada 558 Montreal 559 CA 561 Email: daniel.voyer@bell.ca 562 Clayton Hassen 563 Bell Canada 564 Vancouver 565 CA 567 Email: clayton.hassen@bell.ca