idnits 2.17.1 draft-rosen-l3vpn-mvpn-bier-02.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 4, 2014) is 3430 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Rosen, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track M. Sivakumar 5 Expires: June 7, 2015 IJ. Wijnands 6 Cisco Systems, Inc. 7 S. Aldrin 8 Huawei Technologies 9 A. Dolganow 10 Alcatel-Lucent 11 T. Przygienda 12 Ericsson 13 December 4, 2014 15 Multicast VPN Using BIER 16 draft-rosen-l3vpn-mvpn-bier-02 18 Abstract 20 The Multicast Virtual Private Network (MVPN) specifications require 21 the use of multicast tunnels ("P-tunnels") that traverse a Service 22 Provider's backbone network. The P-tunnels are used for carrying 23 multicast traffic across the backbone. A variety of P-tunnel types 24 are supported. Bit Index Explicit Replication (BIER) is a new 25 architecture that provides optimal multicast forwarding through a 26 "multicast domain", without requiring intermediate routers to 27 maintain any per-flow state or to engage in an explicit tree-building 28 protocol. This document specifies the protocol and procedures that 29 allow MVPN to use BIER as the method of carrying multicast traffic 30 over an SP backbone network. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on June 7, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4 68 3. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 8.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 [RFC6513] and [RFC6514] specify the protocols and procedures that a 81 Service Provider (SP) can use to provide Multicast Virtual Private 82 Network (MVPN) service to its customers. Multicast tunnels are 83 created through an SP's backbone network; these are known as 84 "P-tunnels". The P-tunnels are used for carrying multicast traffic 85 across the backbone. The MVPN specifications allow the use of 86 several different kinds of P-tunnel technology. 88 Bit Index Explicit Replication (BIER) ([BIER_ARCH]) is an 89 architecture that provides optimal multicast forwarding through a 90 "multicast domain", without requiring intermediate routers to 91 maintain any per-flow state or to engage in an explicit tree-building 92 protocol. The purpose of the current document is to specify the 93 protocols and procedures needed in order to provide MVPN service 94 using BIER to transport the multicast traffic over the backbone. 96 Although BIER does not explicitly build and maintain multicast 97 tunnels, one can think of BIER as using a number of implicitly 98 created tunnels through a "BIER domain". In particular, one can 99 think of there as being one Point-to-Multipoint (P2MP) tunnel from 100 each "Bit Forwarding Ingress Router" (BFIR) to all the "Bit 101 Forwarding Egress Routers" (BFERs) in the BIER domain, where a BIER 102 domain is generally co-extensive with an IGP network. These 103 "tunnels" are not specific to any particular VPN. However, the MVPN 104 architecture provides protocols and procedures that allow the traffic 105 of multiple MVPNs to be aggregated on a single P-tunnel. In this 106 document, we specify how to use these multi-VPN aggregation 107 procedures to enable BIER to transport traffic from multiple MVPNs. 109 MVPN traffic must sometimes traverse more than one IGP domain, 110 whereas BIER only carries multicast traffic within a single IGP 111 domain. However, the MVPN specifications allow P-tunnels to be 112 "segmented", where the segmentation points may either be Autonomous 113 System Border Routers (ASBRs), as described in [RFC6514], or Area 114 Border Routers (ABRs), as described in [SEAMLESS_MCAST]. As long as 115 the segmentation points are capable of acting as BFIRs and BFERs, 116 BIER can be used to provide some or all of the segments of a 117 P-tunnel. 119 This revision of the document does not specify the procedures 120 necessary to support MVPN customers that are using BIDIR-PIM. Those 121 procedures will be added in a future revision. 123 This document uses the following terminology from [BIER_ARCH]: 125 o BFR: Bit-Forwarding Router. 127 o BFIR: Bit-Forwarding Ingress Router. 129 o BFER: Bit-Forwarding Egress Router. 131 This document uses the following terminology from [RFC6513]: 133 o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in 134 which multicast service is offered. 136 o P-tunnel. A multicast tunnel through the network of one or more 137 SPs. P-tunnels are used to transport MVPN multicast data 139 o C-S: A multicast source address, identifying a multicast source 140 located at a VPN customer site. 142 o C-G: A multicast group address used by a VPN customer. 144 o C-flow: A customer multicast flow. Each C-flow is identified by 145 the ordered pair (source address, group address), where each 146 address is in the customer's address space. The identifier of a 147 particular C-flow is usually written as (C-S,C-G). 148 Sets of C-flows can be identified by the use of the "C-*" wildcard 149 (see [RFC6625]), e.g., (C-*,C-G). 151 o I-PMSI A-D Route: Inclusive Provider Multicast Service Interface 152 Auto-Discovery route. Carried in BGP Update messages, these 153 routes are used to advertise the "default" P-tunnel for a 154 particular MVPN. 156 o S-PMSI A-D route: Selective Provider Multicast Service Interface 157 Auto-Discovery route. Carried in BGP Update messages, these 158 routes are used to advertise the fact that particular C-flows are 159 bound to (i.e., are traveling through) particular P-tunnels. 161 o PMSI Tunnel attribute (PTA). This BGP attribute carried is used 162 to identify a particular P-tunnel. When C-flows of multiple VPNs 163 is carried in a single P-tunnel, this attribute also carries the 164 information needed to multiplex and demultiplex the C-flows. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 2. Use of the PMSI Tunnel Attribute 172 As defined in [RFC6514], the PMSI Tunnel attribute is used to 173 identify the particular P-tunnel to which one or more multicast flows 174 are being assigned. 176 The PMSI Tunnel attribute (PTA)contains the following fields: 178 o "Tunnel Type". IANA is requested to assign a new tunnel type 179 codepoint for "BIER". This codepoint will be used to indicate 180 that the PMSI is instantiated by BIER. 182 o "Tunnel Identifier". When the "tunnel type" field is "BIER", this 183 field contains two subfields: 185 1. The first subfield is a single octet, containing the sub- 186 domain-id of the sub-domain to which the BFIR will assign the 187 packets that it transmits on the PMSI identified by the NLRI 188 of the BGP I-PMSI or S-PMSI A-D route that contains this PTA. 189 (How that sub-domain is chosen is outside the scope of this 190 document.) 192 2. The second subfield is the BFR-Prefix (see [BIER_ARCH]) of the 193 originator of the route that is carrying this PTA. This will 194 either be a /32 IPv4 address or a /128 IPv6 address. Whether 195 the address is IPv4 or IPv6 can be inferred from the total 196 length of the PMSI Tunnel attribute. 198 o "MPLS label". This field contains an upstream-assigned MPLS 199 label. It is assigned by the router that originates the BGP route 200 to which the PTA is attached. Constraints on the way in which the 201 originating router selects this label are discussed below. 203 o "Leaf Info Required Bit". The setting of this bit depends upon 204 the type of route and the NLRI of the route that carries the PTA. 206 * In an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D route, the bit 207 SHOULD be clear. 209 * In other S-PMSI A-D routes, the bit SHOULD be set. 211 Note that if a PTA specifying "BIER" is attached to an I-PMSI or 212 S-PMSI A-D route, the route MUST NOT be distributed beyond the 213 boundaries of a BIER domain. That is, any routers that receive the 214 route must be in the same BIER domain as the originator of the route. 215 If the originator is in more than one BIER domain, the route must be 216 distributed only within the BIER domain in which the BFR-Prefix in 217 the PTA uniquely identifies the originator. As with all MVPN routes, 218 distribution of these routes is controlled by the provisioning of 219 Route Targets. 221 Suppose an ingress PE originates two x-PMSI A-D routes, where we use 222 the term "x-PMSI" to mean "I-PMSI or S-PMSI". Suppose both routes 223 carry a PTA, and the PTA of each route specifies"BIER". 225 o If the two routes do not carry the same set of Route Targets 226 (RTs), then their respective PTAs MUST contain different MPLS 227 label values. 229 o If the ingress PE is supporting MVPN extranet ([EXTRANET]) 230 functionality, and if the two routes originate from different 231 VRFs, then the respective PTAs of the two routes MUST contain 232 different MPLS label values. 234 o If the ingress PE is supporting the "Extranet Separation" feature 235 of MVPN extranet (see Section 7.3 of [EXTRANET], section ), and if 236 one of the routes carries the "Extranet Separation" extended 237 community and the other does not, then the respective PTAs of the 238 two routes MUST contain different MPLS label values. 240 When segmented P-tunnels are being used, an ABR or ASBR may receive, 241 from a BIER domain, an x-PMSI A-D route whose PTA specifies "BIER". 242 This means that BIER is being used for one segment of a segmented 243 P-tunnel. The ABR/ASBR may in turn need to originate an x-PMSI A-D 244 route whose PTA identifies the next segment of the P-tunnel. The 245 next segment may also be "BIER". Suppose an ASBR receives x-PMSI A-D 246 routes R1 and R2, and as a result originates x-PMSI A-D routes R3 and 247 R4 respectively, where the PTAs of each of the four routes specify a 248 BIER.. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS 249 label, UNLESS both of the following conditions hold: 251 o R1 and R2 have the same "originating router" in their respective 252 NLRIs. 254 o R1 and R2 specify the same MPLS label in their respective PTAs. 256 3. Explicit Tracking 258 [Editor's note: The procedures of this section are still under 259 discussion, and significant changes may be expected in the next 260 revision.] 262 When using BIER to transport an MVPN data packet through a BIER 263 domain, an ingress PE functions as a BFIR (see [BIER_ARCH]). The 264 BFIR must determine the set of BFERs to which the packet needs to be 265 delivered. This is done by using the explicit tracking mechanism 266 specified in [RFC6513] and [RFC6514]. 268 To determine the set of BFERs to which a given MVPN data packet needs 269 to be delivered, the BFIR originating an S-PMSI A-D route sets the 270 LIR bit in the route's PTA. Per [RFC6514], the BFERs will respond 271 with Leaf A-D routes. By matching the received Leaf A-D routes to 272 the originated S-PMSI A-D routes, the originator of the S-PMSI A-D 273 route determines the set of BFERs that need to receive the multicast 274 data flow (or flows) that is (are) identified in the NLRI of the of 275 the S-PMSI A-D route. 277 This requires that each BFIR originate an S-PMSI A-D route for each 278 C-flow for which it serves as BFIR. The BFIR MAY include, in each 279 such route, a PTA as described in Section 2. However, if the BFIR 280 has originated an I-PMSI A-D route or a wildcard S-PMSI A-D route 281 that "matches" (according to the rules of [RFC6625]) a particular 282 C-flow, then it may do explicit tracking for that C-flow by 283 originating an S-PMSI A-D route for that C-flow, but including a PTA 284 that specifies "no tunnel type". 286 4. Data Plane 288 The MVPN application plays the role of the "multicast flow layer" as 289 described in [BIER_ARCH]. 291 To transmit an MVPN data packet, an ingress PE follows the rules of 292 [RFC6625] to find the S-PMSI A-D route or I-PMSI A-D route that is a 293 "match for transmission" for that packet. (In applying the rules of 294 [RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel 295 information" is ignored.) If the matching route has a PTA specifying 296 a "BIER", the (upstream-assigned) MPLS label from that PTA is pushed 297 on the packet's label stack. Then the packet is forwarded according 298 to the procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially 299 Section 4, "Imposing and Processing the BIER Encapsulation", of 300 [BIER_ENCAPS].) 302 When a BFER receives an MVPN multicast data packet that has been 303 BIER-encapsulated, the BIER layer passes the following information to 304 the multicast flow layer: 306 o The BFR-prefix corresponding to the sub-domain-id and BFIR-id in 307 the BIER header. 309 o The "payload", which is an MPLS packet whose top label is an 310 upstream-assigned label. The BFR-prefix provides the "context" in 311 which the upstream-assigned label is interpreted. 313 Note that per [RFC5331], the context for an upstream-assigned 314 label is the IP address of the label assigner, which in this case 315 is the BFR-prefix of the BFIR. 317 5. Acknowledgments 319 The authors wish to thank Jeffrey Zhang for his ideas and 320 contributions to this work. 322 6. IANA Considerations 324 IANA is requested to assign a value for "BIER" from the "P-Multicast 325 Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The 326 reference should be this document. 328 7. Security Considerations 330 The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513] 331 and [RFC6514] are applicable. 333 8. References 335 8.1. Normative References 337 [BIER_ARCH] 338 Wijnands, IJ., "Multicast using Bit Index Explicit 339 Replication Architecture", internet-draft draft-wijnands- 340 bier-architecture-02, December 2014. 342 [BIER_ENCAPS] 343 Wijnands, IJ., "Multicast using Bit Index Explicit 344 Replication Architecture", internet-draft draft-wijnands- 345 mpls-bier-encapsulation-02, December 2014. 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 351 Networks (VPNs)", RFC 4364, February 2006. 353 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 354 Label Assignment and Context-Specific Label Space", RFC 355 5331, August 2008. 357 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 358 VPNs", RFC 6513, February 2012. 360 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 361 Encodings and Procedures for Multicast in MPLS/BGP IP 362 VPNs", RFC 6514, February 2012. 364 [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, 365 "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 366 6625, May 2012. 368 8.2. Informative References 370 [EXTRANET] 371 Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP 372 MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet- 373 05, July 2014. 375 [SEAMLESS_MCAST] 376 Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I., 377 Leymann, N., and S. Saad, "Inter-Area P2MP Segmented 378 LSPs", internet-draft draft-ietf-mpls-seamless-mcast-14, 379 June 2014. 381 Authors' Addresses 383 Eric C. Rosen (editor) 384 Juniper Networks, Inc. 385 10 Technology Park Drive 386 Westford, Massachusetts 01886 387 US 389 Email: erosen@juniper.net 391 Mahesh Sivakumar 392 Cisco Systems, Inc. 393 510 McCarthy Blvd 394 Milpitas, California 95035 395 US 397 Email: masivaku@cisco.com 399 IJsbrand Wijnands 400 Cisco Systems, Inc. 401 De Kleetlaan 6a 402 Diegem 1831 403 BE 405 Email: ice@cisco.com 407 Sam K Aldrin 408 Huawei Technologies 409 2330 Central Express Way 410 Santa Clara, California 411 US 413 Email: aldrin.ietf@gmail.com 415 Andrew Dolganow 416 Alcatel-Lucent 417 600 March Rd. 418 Ottawa, Ontario K2K 2E6 419 CA 421 Email: andrew.dolganow@alcatel-lucent.com 422 Tony Przygienda 423 Ericsson 424 300 Holger Way 425 San Jose, California 95134 426 US 428 Email: antoni.przygienda@ericsson.com