idnits 2.17.1 draft-ietf-bier-mld-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 29, 2017) is 2493 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) == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-07 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pfister 3 Internet-Draft IJ. Wijnands 4 Intended status: Standards Track S. Venaas 5 Expires: December 31, 2017 Cisco Systems 6 C. Wang 8 Z. Zhang 9 ZTE Corporation 10 M. Stenberg 11 June 29, 2017 13 BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery 14 Protocols 15 draft-ietf-bier-mld-00 17 Abstract 19 This document specifies the ingress part of a multicast flow overlay 20 for BIER networks. Using existing multicast listener discovery 21 protocols, it enables multicast membership information sharing from 22 egress routers, acting as listeners, toward ingress routers, acting 23 as queriers. Ingress routers keep per-egress-router state, used to 24 construct the BIER bit mask associated with IP multicast packets 25 entering the BIER domain. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 31, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 65 5. Querier and Listener Specifications . . . . . . . . . . . . . 4 66 5.1. Configuration Parameters . . . . . . . . . . . . . . . . 5 67 5.2. MLDv2 instances. . . . . . . . . . . . . . . . . . . . . 5 68 5.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 6 69 5.2.2. Sending Reports . . . . . . . . . . . . . . . . . . . 6 70 5.2.3. Receiving Queries . . . . . . . . . . . . . . . . . . 6 71 5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 7 72 5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 7 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 9.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Appendix A. BIER Use Case in Data Centers . . . . . . . . . . . 9 80 A.1. Convention and Terminology . . . . . . . . . . . . . . . 11 81 A.2. BIER in data centers . . . . . . . . . . . . . . . . . . 11 82 A.3. A BIER MLD solution for Virtual Network information . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 The Bit Index Explicit Replication (BIER - 88 [I-D.ietf-bier-architecture]) forwarding technique enables IP 89 multicast transport across a BIER domain. When receiving or 90 originating a packet, ingress routers have to construct a bit mask 91 indicating which BIER egress routers located within the same BIER 92 domain will receive the packet. A stateless approach would consist 93 in forwarding all incoming packets toward all egress routers, which 94 would in turn make a forwarding decision based on local information. 95 But any more efficient approach would require ingress routers to keep 96 some state about egress routers multicast membership information, 97 hence requiring state sharing from egress routers toward ingress 98 routers. 100 This document specifies how to use the Multicast Listener Discovery 101 protocol version 2 [RFC3810] (resp. the Internet Group Management 102 protocol version 3 [RFC3376]) as the ingress part of a BIER multicast 103 flow overlay (BIER layering is described in 104 [I-D.ietf-bier-architecture]) for IPv6 (resp. IPv4). It enables 105 multicast membership information sharing from egress routers, acting 106 as listeners, toward ingress routers, acting as queriers. Ingress 107 routers keep per-egress-router state, used to construct the BIER bit 108 mask associated with IP multicast packets entering the BIER domain. 110 This specification is applicable to both IP version 4 and version 6. 111 It therefore specifies two separate mechanisms operating 112 independently. For the sake of simplicity, the rest of this document 113 uses IPv6 terminology. It can be applied to IPv4 by replacing 114 'MLDv2' with 'IGMPv3', and following specific requirements when 115 explicitly stated. 117 2. Terminology 119 In this document, the key words "MAY", "MUST", "MUST NOT", 120 "RECOMMENDED", and "SHOULD", are to be interpreted as described in 121 [RFC2119]. 123 The terms "Bit-Forwarding Router" (BFR), "Bit-Forwarding Egress 124 Router" (BFER), "Bit-Forwarding Ingress Router" (BFIR), "BFR-id" and 125 "BFR-Prefix" are to be interpreted as described in 126 [I-D.ietf-bier-architecture]. 128 Additionally, the following definitions are used: 130 BIER Multicast Listener Discovery (BMLD): The modified version of 131 MLD specified in this document. 133 BMLD Querier: A BFR implementing the Querier part of this 134 specification. A BMLD Node MAY be both a Querier and a Listener. 136 BMLD Listener: A BFR implementing the Listener part of this 137 specification. A BMLD Node MAY be both a Querier and a Listener. 139 3. Overview 141 This document proposes to use the mechanisms described in MLDv2 in 142 order to enable multicast membership information sharing from BFERs 143 toward BFIRs within a given BIER domain. BMLD queries (resp. 144 reports) are sent over BIER toward all BMLD Nodes (resp. BMLD 145 Queriers) using modified MLDv2 messages which IP destination is set 146 to a configured 'all BMLD Nodes' (resp. 'all BMLD Queriers') IP 147 multicast address. 149 By running MLDv2 instances with per-listener explicit tracking, BMLD 150 Queriers are able to map BMLD Listeners with MLDv2 membership states. 151 This state is then used to construct the set of BFERs associated with 152 each incoming IP multicast data packet. 154 4. Applicability Statement 156 BMLD runs on top of a BIER Layer and provides the ingress part of a 157 BIER multicast flow overlay, i.e, it specifies how BFIRs construct 158 the set of BFERs for each ingress IP multicast data packet. The BFER 159 part of the Multicast Flow Overlay is out of scope of this document. 161 The BIER Layer MUST be able to transport BMLD messages toward all 162 BMLD Queriers and Listeners. Such packets are IP multicast packets 163 with a BFR-Prefix as source address, a multicast destination address, 164 and containing a MLDv2 message. 166 BMLD only requires state to be kept by Queriers, and is therefore 167 more scalable than PIMv2 [RFC7761] in terms of overall state, but is 168 also likely to be less scalable than PIMv2 in terms of the amount of 169 control traffic and the size of the state that is kept by individual 170 routers. 172 This specification is applicable to both IP version 4 and version 6. 173 It therefore specifies two separate mechanisms operating 174 independently. For the sake of simplicity, this document uses IPv6 175 terminology. It can be applied to IPv4 by replacing 'MLDv2' with 176 'IGMPv3', and following specific requirements when explicitly stated. 178 5. Querier and Listener Specifications 180 Routers desiring to receive IP multicast traffic (e.g., for their own 181 use, or for forwarding) MUST behave as BMLD Listeners. Routers 182 receiving IP multicast traffic from outside the BIER domain, or 183 originating multicast traffic, MUST behave as BMLD Queriers. 185 BMLD Queriers (resp. BMLD Listeners) MUST act as MLDv2 Queriers 186 (resp. MLDv2 Listeners) as specified in [RFC3810] unless stated 187 otherwise in this section. 189 5.1. Configuration Parameters 191 Both Queriers and Listeners MUST operate as BFIRs and BFERs within 192 the BIER domain in order to send and receive BMLD messages. They 193 MUST therefore be configured accordingly, as specified in 194 [I-D.ietf-bier-architecture]. 196 All Listeners MUST be configured with a 'all BMLD Queriers' multicast 197 address and the BFR-ids of all the BMLD Queriers. This is used by 198 Listeners to send BMLD reports over BIER toward all Queriers. All 199 Queriers MUST be configured to accept BMLD reports sent to this 200 address. 202 All Queriers MUST be configured with a 'all BMLD Nodes' multicast 203 address and the BFR-ids of all the Queriers and Listeners. This 204 information is used by Queriers to send BMLD queries over BIER toward 205 all BMLD Nodes. All BMLD Nodes MUST be configured to accept BMLD 206 queries sent to this address. 208 Note that BMLD (unlike MLDv2) makes use of per-instance configured 209 multicast group addresses rather than well-known addresses so that 210 multiple instances of BMLD (using different group addresses) can be 211 run simultaneously within the same BIER domain. Configured group 212 addresses MAY be obtained from allocated IP prefixes using [RFC3306]. 213 One MAY choose to use the well-known MLDv2 addresses in one instance, 214 but different instances MUST use different addresses. 216 IP packets coming from outside of the BIER domain and having a 217 destination address set to the configured 'all BMLD Queriers' or the 218 'all BMLD Nodes' group address MUST be dropped. It is RECOMMENDED 219 that these configured addresses have a limited scope, enforcing this 220 behavior by scope-based filtering on BIER domain's egress interfaces. 222 5.2. MLDv2 instances. 224 BMLD Queriers MUST run a MLDv2 Querier instance with per-host 225 tracking, which means they keep track of the MLDv2 state associated 226 with each BMLD Listener. For that purpose, Listeners are identified 227 by their respective BFR-Prefix, used as IP source address in all BMLD 228 reports. 230 BMLD Listeners MUST run a MLDv2 Listener instance expressing their 231 interest in the multicast traffic they are supposed to receive for 232 local use or forwarding. 234 BMLD Listeners and Queriers MUST NOT run the MLDv1 (IGMPv2 and IGMPv1 235 for IPv4) backward compatibility procedures. 237 5.2.1. Sending Queries 239 BMLD Queries are IP packets sent over BIER by BMLD Queriers: 241 o Toward all BMLD Nodes (i.e., providing to the BIER Layer the BFR- 242 ids of all BMLD Nodes). 244 o Without the IPv6 router alert option [RFC2711] in the hop-by-hop 245 extension header [RFC2460] (or the IPv4 router alert option 246 [RFC2113] for IPv4). 248 o With the IP destination address set to the 'all BMLD Nodes' group 249 address. 251 o With the IP source address set to the BFR-Prefix of the sender. 253 o With a TTL value great enough such that the packet can be received 254 by all BMLD Nodes, depending on the underlying BIER layer (whether 255 it decrements the IP TTL or not) and the size of the network. The 256 default value is 64. 258 5.2.2. Sending Reports 260 BMLD Reports are IP packets sent over BIER by BMLD Listeners: 262 o Toward all BMLD Queriers (i.e., providing to the BIER layer the 263 BFR-ids of all BMLD Queriers). 265 o Without the IPv6 router alert option [RFC2711] in the hop-by-hop 266 extension header [RFC2460] (or the IPv4 router alert option 267 [RFC2113] for IPv4). 269 o With the IP destination address set to the 'all BMLD Queriers' 270 group address. 272 o With the IP source address set to the BFR-Prefix of the sender. 274 o With a TTL value great enough such that the packet can be received 275 by all BMLD Queriers, depending on the underlying BIER layer 276 (whether it decrements the IP TTL or not) and the size of the 277 network. The default value is 64. 279 5.2.3. Receiving Queries 281 BMLD Queriers and Listeners MUST check the destination address of all 282 the IP packets that are received or forwarded over BIER whenever 283 their own BIER bit is set in the packet. If the destination address 284 is equal to the 'all BMLD Nodes' group address the packet is 285 processed as specified in this section. 287 If the IPv6 (resp. IPv4) packet contains an ICMPv6 (resp. IGMP) 288 message of type 'Multicast Listener Query' (resp. of type 'Membership 289 Query'), it is processed by the MLDv2 (resp. IGMPv3) instance run by 290 the BMLD Querier. It MUST be dropped otherwise. 292 During the MLDv2 processing, the packet MUST NOT be checked against 293 the MLDv2 consistency conditions (i.e., the presence of the router 294 alert option, the TTL equaling 1 and, for IPv6 only, the source 295 address being link-local). 297 5.2.4. Receiving Reports 299 BMLD Queriers MUST check the destination address of all the IP 300 packets that are received or forwarded over BIER whenever their own 301 BIER bit is set. If the destination address is equal to the 'all 302 BMLD Queriers' the packet is processed as specified in this section. 304 If the IPv6 (resp. IPv4) packet contains an ICMPv6 (resp. IGMP) 305 message of type 'Multicast Listener Report Message v2' (resp. 306 'Version 3 Membership Report'), it is processed by the MLDv2 (resp. 307 IGMPv3) instance run by the BMLD Querier. It MUST be dropped 308 otherwise. 310 During the MLDv2 processing, the packet MUST NOT be checked against 311 the MLDv2 consistency conditions (i.e., the presence of the router 312 alert option, the TTL equaling 1 and, for IPv6 only, the source 313 address being link-local). 315 5.3. Packet Forwarding 317 BMLD Queriers configure the BIER Layer using the information obtained 318 using BMLD, which associates BMLD Listeners (identified by their BFR- 319 Prefixes) with their respective MLDv2 membership state. 321 More specifically, the MLDv2 state associated with each BMLD Listener 322 is provided to the BIER layer such that whenever a multicast packet 323 enters the BIER domain, if that packet matches the membership 324 information from a BMLD Listener, its BFR-id is added to the set of 325 BFR-ids the packet should be forwarded to by the BIER-Layer. 327 6. Security Considerations 329 BMLD makes use of IP MLDv2 messages transported over BIER in order to 330 configure the BIER Layer of BFIRs. BMLD messages MUST be secured, 331 either by relying on physical or link-layer security, by securing the 332 IP packets (e.g., using IPSec [RFC4301]), or by relying on security 333 features provided by the BIER Layer. 335 Whenever an attacker would be able to spoof the identity of a router, 336 it could: 338 o Redirect undesired traffic toward the spoofed router by 339 subscribing to undesired multicast traffic. 341 o Prevent desired multicast traffic from reaching the spoofed router 342 by unsubscribing to some desired multicast traffic. 344 7. IANA Considerations 346 This specification does not require any action from IANA. 348 8. Acknowledgements 350 Comments concerning this document are very welcome. 352 9. References 354 9.1. Normative References 356 [I-D.ietf-bier-architecture] 357 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 358 S. Aldrin, "Multicast using Bit Index Explicit 359 Replication", draft-ietf-bier-architecture-07 (work in 360 progress), June 2017. 362 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 363 DOI 10.17487/RFC2113, February 1997, 364 . 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, 368 DOI 10.17487/RFC2119, March 1997, 369 . 371 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 372 Thyagarajan, "Internet Group Management Protocol, Version 373 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 374 . 376 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 377 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 378 DOI 10.17487/RFC3810, June 2004, 379 . 381 9.2. Informative References 383 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 384 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 385 December 1998, . 387 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 388 RFC 2711, DOI 10.17487/RFC2711, October 1999, 389 . 391 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 392 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 393 August 2002, . 395 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 396 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 397 December 2005, . 399 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 400 "Bidirectional Protocol Independent Multicast (BIDIR- 401 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 402 . 404 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 405 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 406 eXtensible Local Area Network (VXLAN): A Framework for 407 Overlaying Virtualized Layer 2 Networks over Layer 3 408 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 409 . 411 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 412 Rekhter, "Framework for Data Center (DC) Network 413 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 414 2014, . 416 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 417 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 418 Multicast - Sparse Mode (PIM-SM): Protocol Specification 419 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 420 2016, . 422 Appendix A. BIER Use Case in Data Centers 424 In current data center virtualization, virtual eXtensible Local Area 425 Network (VXLAN) [RFC7348] is a kind of network virtualization overlay 426 technology which is overlaid between NVEs and is intended for multi- 427 tenancy data center networks, whose reference architecture is 428 illustrated as per Figure 1. 430 +--------+ +--------+ 431 | Tenant +--+ +----| Tenant | 432 | System | | (') | System | 433 +--------+ | ................ ( ) +--------+ 434 | +-+--+ . . +--+-+ (_) 435 | | NVE|--. .--| NVE| | 436 +--| | . . | |---+ 437 +-+--+ . . +--+-+ 438 / . . 439 / . L3 Overlay . +--+-++--------+ 440 +--------+ / . Network . | NVE|| Tenant | 441 | Tenant +--+ . .--| || System | 442 | System | . . +--+-++--------+ 443 +--------+ ................ 445 Figure 1: NVO3 Architecture 447 And there are two kinds of most common methods about how to forward 448 BUM packets in this virtualization overlay network. One is using PIM 449 as underlay multicast routing protocol to build explicit multicast 450 distribution tree, such as PIM-SM [RFC7761] or PIM-BIDIR [RFC5015] 451 multicast routing protocol. Then, when BUM packets arrive at NVE, it 452 requires NVE to have a mapping between the VXLAN Network Identifier 453 and the IP multicast group. According to the mapping, NVE can 454 encapsulate BUM packets in a multicast packet which group address is 455 the mapping IP multicast group address and steer them through 456 explicit multicast distribution tree to the destination NVEs. This 457 method has two serious drawbacks. It need the underlay network 458 supports complicated multicast routing protocol and maintains 459 multicast related per-flow state in every transit nodes. What is 460 more, how to configure the ratio of the mapping between VNI and IP 461 multicast group is also an issue. If the ratio is 1:1, there should 462 be 16M multicast groups in the underlay network at maximum to map to 463 the 16M VNIs, which is really a significant challenge for the data 464 center devices. If the ratio is n:1, it would result in inefficiency 465 bandwidth utilization which is not optimal in data center networks. 467 The other method is using ingress replication to require each NVE to 468 create a mapping between the VXLAN Network Identifier and the remote 469 addresses of NVEs which belong to the same virtual network. When NVE 470 receives BUM traffic from the attached tenant, NVE can encapsulate 471 these BUM packets in unicast packets and replicate them and tunnel 472 them to different remote NVEs respectively. Although this method can 473 eliminate the burden of running multicast protocol in the underlay 474 network, it has a significant disadvantage: large waste of bandwidth, 475 especially in big-sized data center where there are many receivers. 477 BIER [I-D.ietf-bier-architecture] is an architecture that provides 478 optimal multicast forwarding through a "BIER domain" without 479 requiring intermediate routers to maintain any multicast related per- 480 flow state. BIER also does not require any explicit tree-building 481 protocol for its operation. A multicast data packet enters a BIER 482 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 483 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 484 The BFIR router adds a BIER header to the packet. The BIER header 485 contains a bit-string in which each bit represents exactly one BFER 486 to forward the packet to. The set of BFERs to which the multicast 487 packet needs to be forwarded is expressed by setting the bits that 488 correspond to those routers in the BIER header. Specifically, for 489 BIER-TE, the BIER header may also contain a bit-string in which each 490 bit indicates the link the flow passes through. 492 The following sub-sections try to propose how to take full advantage 493 of overlay multicast protocol to carry virtual network information, 494 and create a mapping between the virtual network information and the 495 bit-string to implement BUM services in data centers. 497 A.1. Convention and Terminology 499 The terms about NVO3 are defined in [RFC7365]. The most common 500 terminology used in this appendix is listed below. 502 NVE: Network Virtualization Edge, which is the entity that 503 implements the overlay functionality. An NVE resides at the 504 boundary between a Tenant System and the overlay network. 506 VXLAN: Virtual eXtensible Local Area Network 508 VNI: VXLAN Network Identifier 510 Virtal Network Context Identifier: Field in an overlay encapsulation 511 header that identifies the specific VN the packet belongs to. 513 A.2. BIER in data centers 515 This section tries to describe how to use BIER as an optimal scheme 516 to forward the broadcast, unknown and multicast (BUM) packets when 517 they arrive at the ingress NVE in data centers. 519 The principle of using BIER to forward BUM traffic is that: firstly, 520 it requires each ingress NVE to have a mapping between the Virtual 521 Network Context Identifier and the bit-string in which each bit 522 represents exactly one egress NVE to forward the packet to. And 523 then, when receiving the BUM traffic, the BFIR/Ingree NVE maps the 524 receiving BUM traffic to the mapping bit-string, encapsulates the 525 BIER header, and forwards the encapsulated BUM traffic into the BIER 526 domain to the other BFERs/Egress NVEs indicated by the bit-string. 528 Furthermore, as for how each ingress NVE knows the other egress NVEs 529 that belong to the same virtual network and creates the mapping is 530 the main issue discussed below. Basically, BIER Multicast Listener 531 Discovery is an overlay solution to support ingress routers to keep 532 per-egress-router state to construct the BIER bit-string associated 533 with IP multicast packets entering the BIER domain. The following 534 section tries to extend BIER MLD to carry virtual network 535 information(such as Virtual Network Context identifier), and 536 advertise them between NVEs. When each NVE receive these 537 information, they create the mapping between the virtual network 538 information and the bit-string representing the other NVEs belonged 539 to the same virtual network. 541 A.3. A BIER MLD solution for Virtual Network information 543 The BIER MLD solution allows having multiple MLD instances by having 544 unique pairs of BMLD Nodes and BMLD Querier addresses for each 545 instance. Assume for now that we have a unique instance per VNI and 546 that all BMLD routers are using the same mapping between VNIs and 547 BMLD address pairs. Also for each VNI there is a multicast group 548 used for encapsulation of BUM traffic over BIER. This group may 549 potentially be shared by some or all of the VNIs. 551 Each NVE acquires the Virtual Network information, and advertises 552 this Virtual Network information to other NVEs through the MLD 553 messages. For a given VNI it sends BMLD reports to the BMLD nodes 554 address used for that VNI, for the group used for delivering BUM 555 traffic for that VNI. This allows all NVE routers to know which 556 other NVE routers have interest in BUM traffic for a particular VNI. 557 If one attached virtual network is migrated, the NVE will withdraw 558 the Virtual Network information by sending an unsolicited BMLD 559 report. Note that NVEs also respond to periodic queries to BMLD 560 Nodes addresses corresponding to VNIs for which they have interest. 562 When ingress NVE receives the Virtual Network information 563 advertisement message, it builds a mapping between the receiving 564 Virtual Network Context Identifier in this message and the bit-string 565 in which each bit represents one egress NVE who sends the same 566 Virtual Network information. Subsequently, once this ingress NVE 567 receives some other MLD advertisements which include the same Virtual 568 Network information from some other NVEs , it updates the bit-string 569 in the mapping and adds the corresponding sending NVE to the updated 570 bit-string. Once the ingress NVE removes one virtual network, it 571 will delete the mapping corresponding to this virtual network as well 572 as send withdraw message to other NVEs. 574 After finishing the above interaction of MLD messages, each ingress 575 NVE knows where the other egress NVEs are in the same virtual 576 network. When receiving BUM traffic from the attached virtual 577 network, each ingress NVE knows exactly how to encapsulate this 578 traffic and where to forward them to. 580 This can be used in both IPv4 network and IPv6 network. In IPv4, 581 IGMP protocol does the similar extension for carrying Virtual Network 582 information TLV in Version 2 membership report message. 584 Note that it is possible to have multiple VNIs map to the same pair 585 of BMLD addresses. Provided VNIs that map to the same BMLD address 586 uses different multicast groups for encapsulation, this is not a 587 problem, because each instance is tracking interest for each 588 multicast group separately. If multiple VNIs map to the same pair 589 and the multicast group used is not unique, some NVEs may receive BUM 590 traffic for which they are not interested. An NVE would drop packets 591 for an unknown VNI, but it means wasting some bandwidth and 592 processing. This is similar to the non-BIER case where there is not 593 a unique multicast group for encapsulation. The improvement offered 594 by using BMLD is by using multiple instance, hence reducing the 595 problems caused by using the same transport group for multiple VNIs. 597 Authors' Addresses 599 Pierre Pfister 600 Cisco Systems 601 Paris 602 France 604 Email: pierre.pfister@darou.fr 606 IJsbrand Wijnands 607 Cisco Systems 608 De Kleetlaan 6a 609 Diegem 1831 610 Belgium 612 Email: ice@cisco.com 613 Stig Venaas 614 Cisco Systems 615 Tasman Drive 616 San Jose, CA 95134 617 USA 619 Email: stig@cisco.com 621 Cui(Linda) Wang 623 Email: lindawangjoy@gmail.com 625 Zheng(Sandy) Zhang 626 ZTE Corporation 627 No.50 Software Avenue, Yuhuatai District 628 Nanjing, CA 629 China 631 Email: zhang.zheng@zte.com.cn 633 Markus Stenberg 634 Helsinki 00930 635 Finland 637 Email: markus.stenberg@iki.fi