idnits 2.17.00 (12 Aug 2021) /tmp/idnits15187/draft-zzhang-bier-evpn-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 (June 8, 2017) is 1801 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) == Missing Reference: 'RFC6625' is mentioned on line 126, but not defined == Missing Reference: 'RFC6514' is mentioned on line 154, but not defined == Unused Reference: 'RFC2119' is defined on line 495, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-01 == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-00 == Outdated reference: draft-ietf-bess-mvpn-expl-track has been published as RFC 8534 == Outdated reference: draft-ietf-bier-architecture has been published as RFC 8279 == Outdated reference: draft-ietf-bier-mpls-encapsulation has been published as RFC 8296 == Outdated reference: draft-ietf-bier-mvpn has been published as RFC 8556 == Outdated reference: A later version (-01) exists of draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-00 == Outdated reference: draft-ietf-bess-evpn-overlay has been published as RFC 8365 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Z. Zhang 3 Internet-Draft A. Przygienda 4 Intended status: Standards Track Juniper Networks 5 Expires: December 10, 2017 A. Sajassi 6 Cisco Systems 7 J. Rabadan 8 Nokia 9 June 8, 2017 11 EVPN BUM Using BIER 12 draft-zzhang-bier-evpn-00 14 Abstract 16 This document specifies protocols and procedures for forwarding 17 broadcast, unknown unicast and multicast (BUM) traffic of Ethernet 18 VPNs (EVPN) using Bit Index Explicit Replication (BIER). 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC2119. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 10, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4 63 2.1. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 5 64 2.1.1. Using IMET/SMET routes . . . . . . . . . . . . . . . 5 65 2.1.2. Using S-PMSI/Leaf A-D Routes . . . . . . . . . . . . 6 66 2.2. MPLS Label in PTA . . . . . . . . . . . . . . . . . . . . 6 67 3. Multihoming Split Horizon . . . . . . . . . . . . . . . . . . 7 68 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 8 70 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 9 72 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 10 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 8.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 [RFC7432] and [I-D.ietf-bess-evpn-overlay] specify the protocols and 84 procedures for Ethernet VPNs (EVPNs). For broadcast, unknown unicast 85 and multicast (BUM) traffic, provider/underlay tunnels (referred to 86 as P-tunnels) are used to carry the BUM traffic. Several kinds of 87 tunnel technologies can be used, as specified in [RFC7432]. 89 Bit Index Explicit Replication (BIER) ([I-D.ietf-bier-architecture]) 90 is an architecture that provides optimal multicast forwarding through 91 a "multicast domain", without requiring intermediate routers to 92 maintain any per-flow state or to engage in an explicit tree-building 93 protocol. The purpose of this document is to specify the protocols 94 and procedures to transport EVPN BUM traffic using BIER. 96 The EVPN BUM procedures specified in [RFC7432] and extended in 97 [I-D.ietf-bess-evpn-bum-procedure-updates], 98 [I-D.ietf-bess-evpn-igmp-mld-proxy], and 99 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] are much aligned with 100 MVPN procedures. As such, this document is also very much aligned 101 with [I-D.ietf-bier-mvpn]. For terseness, some background, terms and 102 concepts are not repeated here. Additionally, some text is borrowed 103 verbatim from [I-D.ietf-bier-mvpn]. 105 1.1. Terminologies 107 o BFR: Bit-Forwarding Router. 109 o BFIR: Bit-Forwarding Ingress Router. 111 o BFER: Bit-Forwarding Egress Router. 113 o BFR-Prefix: An IP address that uniquely identifies a BFR and is 114 routeable in a BIER domain. 116 o C-S: A multicast source address, identifying a multicast source 117 located at a VPN customer site. 119 o C-G: A multicast group address used by a VPN customer. 121 o C-flow: A customer multicast flow. Each C-flow is identified by 122 the ordered pair (source address, group address), where each 123 address is in the customer's address space. The identifier of a 124 particular C-flow is usually written as (C-S,C-G). Sets of 125 C-flows can be identified by the use of the "C-*" wildcard (see 126 [RFC6625]), e.g., (C-*,C-G). 128 o P-tunnel. A multicast tunnel through the network of one or more 129 SPs. P-tunnels are used to transport MVPN multicast data 131 o IMET Route: Inclusive Multicast Ethernet Tag Auto-Discovery route. 132 Carried in BGP Update messages, these routes are used to advertise 133 the "default" P-tunnel for a particular broadcast domain. 135 o SMET Route: Selective Multicast Ethernet Tag Auto-Discovery route. 136 Carried in BGP Update messages, these routes are used to advertise 137 the C-flows that the advertising PE is interested in. 139 o S-PMSI A-D route: Selective Provider Multicast Service Interface 140 Auto-Discovery route. Carried in BGP Update messages, these 141 routes are used to advertise the fact that particular C-flows are 142 bound to (i.e., are traveling through) particular P-tunnels. 144 o PMSI Tunnel attribute (PTA). This BGP attribute carried is used 145 to identify a particular P-tunnel. When C-flows of multiple VPNs 146 are carried in a single P-tunnel, this attribute also carries the 147 information needed to multiplex and demultiplex the C-flows. 149 2. Use of the PMSI Tunnel Attribute 151 [RFC7432] specifies that Inclusive Multicast Ethernet Tag (IMET) 152 routes carry a PMSI Tunnel Attribute (PTA) to identify the particular 153 P-tunnel to which one or more BUM flows are being assigned, the same 154 as specified in [RFC6514] for MVPN. [I-D.ietf-bier-mvpn] specifies 155 the encoding of PTA for use of BIER with MVPN. Much of that 156 specification is reused for use of BIER with EVPN and much of the 157 text below is borrowed verbatim from [I-D.ietf-bier-mvpn]. 159 The PMSI Tunnel Attribute (PTA) contains the following fields: 161 o "Tunnel Type". The same codepoint that [I-D.ietf-bier-mvpn] 162 requests IANA to assign for the new tunnel type "BIER" is used for 163 EVPN as well. 165 o "Tunnel Identifier". When the "tunnel type" field is "BIER", this 166 field contains two subfields. The text below is exactly as in 167 [I-D.ietf-bier-mvpn] 169 1 The first subfield is a single octet, containing the sub- 170 domain-id of the sub-domain to which the BFIR will assign the 171 packets that it transmits on the PMSI identified by the NLRI of 172 the IMET, S-PMSI A-D, or per-region I-PMSI A-D route that 173 contains this PTA. (How that sub-domain is chosen is outside 174 the scope of this document.) 176 2 The second subfield is the BFR-Prefix (see 177 [I-D.ietf-bier-architecture]) of the originator of the route 178 that is carrying this PTA. This will either be a /32 IPv4 179 address or a /128 IPv6 address. Whether the address is IPv4 or 180 IPv6 can be inferred from the total length of the PMSI Tunnel 181 attribute. 183 o "MPLS label". For EVPN-MPLS [RFC7432], this field contains an 184 upstream-assigned MPLS label. It is assigned by the BFIR. 185 Constraints on the way in which the originating router selects 186 this label are discussed in Section 2.2. For EVPN-VXLAN/NVGRE 187 [I-D.ietf-bess-evpn-overlay], this field is a 24-bit VNI/VSID of 188 global significance. 190 o "Flags". When the tunnel type is BIER, two of the flags in the 191 PTA Flags field are meaningful. Details about the use of these 192 flags can be found in Section 2.1. 194 * "Leaf Info Required per Flow (LIR-pF)" 195 [I-D.ietf-bess-mvpn-expl-track] 197 * "Leaf Info Required Bit (LIR)" 199 Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI 200 A-D, or per-region I-PMSI A-D route, the route MUST NOT be 201 distributed beyond the boundaries of a BIER domain. That is, any 202 routers that receive the route must be in the same BIER domain as the 203 originator of the route. If the originator is in more than one BIER 204 domain, the route must be distributed only within the BIER domain in 205 which the BFR-Prefix in the PTA uniquely identifies the originator. 206 As with all MVPN routes, distribution of these routes is controlled 207 by the provisioning of Route Targets. 209 2.1. Explicit Tracking 211 When using BIER to transport an EVPN BUM data packet through a BIER 212 domain, an ingress PE functions as a BFIR (see 213 [I-D.ietf-bier-architecture]). The BFIR must determine the set of 214 BFERs to which the packet needs to be delivered. This can be done in 215 either of two ways in the following two sections. 217 2.1.1. Using IMET/SMET routes 219 Both IMET and SMET (Selective Multicast Ethernet Tag 220 [I-D.ietf-bess-evpn-igmp-mld-proxy]) routes provide explicit tracking 221 functionality. 223 For an inclusive PMSI, the set of BFERs to deliver traffic to 224 includes the originators of all IMET routes for a broadcast domain. 225 For a selective PMSI, the set of BFERs to deliver traffic to includes 226 the originators of corresponding SMET routes. 228 The SMET routes do not carry a PTA. When an ingress PE sends traffic 229 on a selective tunnel using BIER, it uses the upstream assigned label 230 that is advertised in its IMET route. 232 Only when selectively forwarding is for all flows without tunnel 233 segmentation, SMET routes are used without S-PMSI A-D routes. 234 Otherwise, the procedures in the following section apply. 236 2.1.2. Using S-PMSI/Leaf A-D Routes 238 There are two cases where S-PMSI/Leaf A-D routes are used as 239 discussed in the following two sections. 241 2.1.2.1. Selective Forwarding Only for Some Flows 243 With the SMET procedure, a PE advertises an SMET route for each 244 (C-S,C-G) or (C-*,C-G) state that it learns on its ACs, and each SMET 245 route is tracked by every PE in the same broadcast domain. It may be 246 desired that SMET routes are not used to reduce the burden of 247 explicit tracking. 249 In this case, most multicast traffic will follow the I-PMSI 250 (advertised via IMET route) and only some flows follow S-PMSIs. To 251 achieve that, S-PMSI/Leaf A-D routes can be used, as specified in 252 [I-D.ietf-bess-evpn-bum-procedure-updates]. The LIR bit may be set 253 in the S-PMSI A-D routes, and the PEs that need to receive 254 corresponding traffic will respond with a Leaf A-D route. The 255 ingress PE identifies the set of BFERs to deliver traffic to 256 according to the set of corresponding Leaf A-D routes received. 258 The S-PMSI A-D route carries the same PTA as in the IMET route, 259 except that similar to MVPN, the LIR-pF flag may be set for an 260 ingress PE to request individual (C-S,C-G) or (C-*,C-G) Leaf A-D 261 routes. 263 2.1.2.2. Tunnel Segmentation 265 Another case where S-PMSI/Leaf A-D routes are necessary is tunnel 266 segmentation, which is also specified in 267 [I-D.ietf-bess-evpn-bum-procedure-updates], and further clarified in 268 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] for segmentation with 269 SMET routes. This is only applicable to EVPN-MPLS. 271 Similar to MVPN, the LIR-pF flag cannot be used with segmentation, 272 and the S-PMSI A-D routes' PTA MUST carry an upstream assigned label 273 to allow tunnel segmentation points to do label switching. The 274 S-PMSI A-D routes could be proactively (re-)advertised by the ingress 275 PEs or segmentation points, or could be triggered by the unsolicited 276 Leaf A-D routes received from downstream. 278 2.2. MPLS Label in PTA 280 Similar to the MVPN case in [I-D.ietf-bier-mvpn], the label 281 allocation for the upstream assigned label in the PTA MUST follow the 282 following rules (text borrowed verbatim from [I-D.ietf-bier-mvpn]). 284 Suppose an ingress PE originates two x-PMSI A-D routes, where we use 285 the term "x-PMSI" to mean "I-PMSI or S-PMSI". Suppose both routes 286 carry a PTA, and the PTA of each route specifies"BIER". 288 o If the two routes do not carry the same set of Route Targets 289 (RTs), then their respective PTAs MUST contain different MPLS 290 label values. 292 o If segmented P-tunnels are being used, then the respective PTAs of 293 the two routes MUST contain different MPLS label values, as long 294 as the NLRIs are not identical. In this case, the MPLS label can 295 be used by the BFER to identify the particular C-flow to which a 296 data packet belongs, and this greatly simplifies the process of 297 forwarding a received packet to its next P-tunnel segment. This 298 is explained further below. 300 When segmented P-tunnels are being used, an ABR or ASBR may receive, 301 from a BIER domain, an x-PMSI A-D route whose PTA specifies "BIER". 302 This means that BIER is being used for one segment of a segmented 303 P-tunnel. The ABR/ASBR may in turn need to originate an x-PMSI A-D 304 route whose PTA identifies the next segment of the P-tunnel. The 305 next segment may also be "BIER". Suppose an ABR/ASBR receives x-PMSI 306 A-D routes R1 and R2, and as a result originates x-PMSI A-D routes R3 307 and R4 respectively, where the PTAs of each of the four routes 308 specify BIER. Then the PTAs of R3 and R4 MUST NOT specify the same 309 MPLS label. 311 The ABR/ASBR MUST then program its dataplane such that a packet 312 arriving with the upstream-assigned label specified in route R1 is 313 transmitted with the upstream-assigned label specified in route R3, 314 and a packet arriving with the upstream-assigned label specified in 315 route R2 is transmitted with the label specified in route R4. Of 316 course, the data plane must also be programmed to encapsulate the 317 transmitted packets with an appropriate BIER header, whose BitString 318 is determined by the multicast flow overlay. 320 3. Multihoming Split Horizon 322 For EVPN-MPLS, [RFC7432] specifies the use of ESI labels to identify 323 the ES from which a BUM packet originates. A PE receiving that 324 packet from the core side will not forward it to the same ES. The 325 procedure works for both Ingress Replication (IR) and RSVP-TE/mLDP 326 P2MP tunnels, using downstream- and upstream-assigned ESI labels 327 respectively. For EVPN-VXLAN/NVGRE, [I-D.ietf-bess-evpn-overlay] 328 specifies local-bias procedures, where a PE receiving a BUM packet 329 from the core side knows from encapsulation the ingress PE so it does 330 not forward the packet to any multihoming ESes that the ingress PE is 331 on, because the ingress PE already forwarded the packet to those 332 ESes, regardless of whether the ingress PE is a DF for those ESes. 334 With BIER, the local-bias procedure still applies for EVPN-VXLAN/ 335 NVGRE as the BFIR-id in the BIER header identifies the ingress PE. 336 For EVPN-MPLS, ESI label procedures also still apply though two 337 upstream assigned labels will be used (one for identifying the 338 broadcast domain and one for identifying the ES) - the same as in the 339 case of using a single P2MP tunnel for multiple broadcast domains. 340 The BFIR-id in the BIER header identifies the ingress PE that 341 assigned those two labels. 343 Details for split-horizon in case of segmentation will be provided in 344 future revisions. 346 4. Data Plane 348 Similar to MVPN, the EVPN application plays the role of the 349 "multicast flow overlay" as described in 350 [I-D.ietf-bier-architecture]. 352 4.1. Encapsulation and Transmission 354 To transmit a BUM data packet, an ingress PE first pushes the ESI 355 label per [RFC7432] if the following conditions are all met: 357 o The packet is received on a multihomed ES. 359 o It's EVPN-MPLS. 361 o ESI label procedure is used for split-horizon. 363 It then finds the S-PMSI A-D route, or the SMET/IMET route that 364 matches that packet. Any S-PMSI A-D route with a PTA specifying "no 365 tunnel information" is ignored. If one ore more SMET routes are 366 matched, the IMET route originated by the ingress PE for the 367 broadcast domain is then located to obtain the PTA. 369 If the found S-PMSI A-D or the IMET route has a PTA specifying 370 "BIER", and the ingress PE determines that BIER should be used (e.g., 371 per procedures in [I-D.ietf-bess-evpn-igmp-mld-proxy] about 372 interworking with PEs that do not support certain tunnel types), the 373 (upstream-assigned) MPLS label from that PTA is pushed on the 374 packet's label stack in case of EVPN-MPLS. In case of EVPN-VXLAN/ 375 NVGRE, a VXLAN/NVGRE header is prepended to the packet with the VNI/ 376 VSID set to the value in the PTA's label field and no IP/UDP header 377 is used. 379 Then the packet is encapsulated in a BIER header and forwarded, 380 according to the procedures of [I-D.ietf-bier-architecture] and 381 [I-D.ietf-bier-mpls-encapsulation]. See especially Section 4, 382 "Imposing and Processing the BIER Encapsulation", of 383 [I-D.ietf-bier-mpls-encapsulation]. The "Proto" field in the BIER 384 header is set to 2 in case of EVPN-MPLS or a value to be assigned in 385 case of EVPN-VXLAN/NVGRE (Section 5). 387 In order to create the proper BIER header for a given packet, the 388 BFIR must know all the BFERs that need to receive that packet. If 389 SMET routes are matched, it determines all the BFERs from all the 390 matching SMET routes in the broadcast domain. 392 If an S-PMSI route is matched, it determines all the BFERs by finding 393 all the Leaf A-D routes that correspond to the S-PMSI A-D route that 394 is the packet's match for transmission. There are two different 395 cases to consider: 397 1 The S-PMSI A-D route that is the match for transmission carries a 398 PTA that has the LIR flag set but does not have the LIR-pF flag 399 set. In this case, the corresponding Leaf A-D routes are those 400 whose "route key" field is identical to the NLRI of the S-PMSI A-D 401 route. 403 2 The S-PMSI A-D route that is the match for transmission carries a 404 PTA that has the LIR-pF flag. In this case, the corresponding 405 Leaf A-D routes are those whose "route key" field is derived from 406 the NLRI of the S-PMSI A-D route according to the procedures 407 described in Section 5.2 of [EXPLICIT_TRACKING]. 409 4.2. Disposition 411 The same procedures in section 3.2 of [I-D.ietf-bier-mvpn] are 412 followed for EVPN-MPLS (text could be copied here). For EVPN-VXLAN/ 413 NVGRE, the only difference is that the payload is VXLAN/NVGRE and the 414 VNI/VSID field in the VXLAN/NVGRE header is used to determine the 415 corresponding mac VRF or broadcast domain. 417 4.2.1. At a BFER that is an Egress PE 419 Once the corresponding mac VRF or broadcast domain is determined from 420 the upstream assigned label or VNI/VSID, EVPN forwarding procedures 421 per [RFC7432] or [I-D.ietf-bess-evpn-overlay] are followed. In case 422 of EVPN-MPLS, if there is an inner label in the label stack following 423 the BIER header, that inner label is considered as the upstream 424 assigned ESI label for split horizon purpose. 426 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary 428 This is only applicable to EVPN-MPLS. The same procedures in 429 Section 3.2.2 of [I-D.ietf-bier-mvpn] are followed, subject to 430 multihoming considerations described in Section 3 of this document. 432 5. IANA Considerations 434 This document requests two assignments in "BIER Next Protocol 435 Identifiers" registry, with the following two recommended values: 437 o 7: Payload is VXLAN encapsulated (no IP/UDP header) 439 o 8: Payload is NVGRE encapsulated (no IP header) 441 6. Security Considerations 443 To be updated. 445 7. Acknowledgements 447 The authors thank Eric Rosen for his review and suggestions. 448 Additionally, much of the text is borrowed verbatim from 449 [I-D.ietf-bier-mvpn]. 451 8. References 453 8.1. Normative References 455 [I-D.ietf-bess-evpn-bum-procedure-updates] 456 Zhang, Z., Lin, W., Rabadan, J., and K. Patel, "Updates on 457 EVPN BUM Procedures", draft-ietf-bess-evpn-bum-procedure- 458 updates-01 (work in progress), December 2016. 460 [I-D.ietf-bess-evpn-igmp-mld-proxy] 461 Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., 462 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- 463 bess-evpn-igmp-mld-proxy-00 (work in progress), March 464 2017. 466 [I-D.ietf-bess-mvpn-expl-track] 467 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 468 "Explicit Tracking with Wild Card Routes in Multicast 469 VPN", draft-ietf-bess-mvpn-expl-track-02 (work in 470 progress), June 2017. 472 [I-D.ietf-bier-architecture] 473 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 474 S. Aldrin, "Multicast using Bit Index Explicit 475 Replication", draft-ietf-bier-architecture-06 (work in 476 progress), April 2017. 478 [I-D.ietf-bier-mpls-encapsulation] 479 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 480 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 481 Explicit Replication in MPLS and non-MPLS Networks", 482 draft-ietf-bier-mpls-encapsulation-07 (work in progress), 483 June 2017. 485 [I-D.ietf-bier-mvpn] 486 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 487 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 488 mvpn-05 (work in progress), January 2017. 490 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] 491 Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN 492 C-Multicast Routes Enhancements", draft-zzhang-bess-mvpn- 493 evpn-cmcast-enhancements-00 (work in progress), July 2016. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, 497 DOI 10.17487/RFC2119, March 1997, 498 . 500 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 501 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 502 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 503 2015, . 505 8.2. Informative References 507 [I-D.ietf-bess-evpn-overlay] 508 Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro, 509 J., and W. Henderickx, "A Network Virtualization Overlay 510 Solution using EVPN", draft-ietf-bess-evpn-overlay-08 511 (work in progress), March 2017. 513 Authors' Addresses 515 Zhaohui Zhang 516 Juniper Networks 518 EMail: zzhang@juniper.net 519 Antoni Przygienda 520 Juniper Networks 522 EMail: prz@juniper.net 524 Ali Sajassi 525 Cisco Systems 527 EMail: sajassi@cisco.com 529 Jorge Rabadan 530 Nokia 532 EMail: jorge.rabadan@nokia.com