idnits 2.17.1 draft-wang-bier-vxlan-use-case-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 5, 2016) is 2782 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) == Unused Reference: 'RFC5015' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-idr-extensions' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-isis-extensions' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-ospf-bier-extensions' is defined on line 367, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Downref: Normative reference to an Informational RFC: RFC 7348 ** Downref: Normative reference to an Informational RFC: RFC 7365 == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-04 == Outdated reference: A later version (-10) exists of draft-ietf-bier-idr-extensions-01 == Outdated reference: A later version (-11) exists of draft-ietf-bier-isis-extensions-02 == Outdated reference: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-02 == Outdated reference: A later version (-12) exists of draft-ietf-bier-use-cases-03 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER WG C. Wang 3 Internet-Draft Z. Zhang 4 Intended status: Standards Track ZTE Corporation 5 Expires: March 9, 2017 September 5, 2016 7 BIER Use Case in Data Centers 8 draft-wang-bier-vxlan-use-case-02 10 Abstract 12 Bit Index Explicit Replication (BIER) is an architecture that 13 provides optimal multicast forwarding through a "BIER domain" without 14 requiring intermediate routers to maintain any multicast related per- 15 flow state. BIER also does not require any explicit tree-building 16 protocol for its operation. A multicast data packet enters a BIER 17 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 18 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 19 The BFIR router adds a BIER header to the packet. The BIER header 20 contains a bit-string in which each bit represents exactly one BFER 21 to forward the packet to. The set of BFERs to which the multicast 22 packet needs to be forwarded is expressed by setting the bits that 23 correspond to those routers in the BIER header. 25 This document tries to describe the drawbacks of how BUM services are 26 deployed in current data centers, and proposes how to take full 27 advantage of BIER to implement BUM services in data centers. 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 http://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 March 9, 2017. 46 Copyright Notice 48 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Convention and Terminology . . . . . . . . . . . . . . . . . 4 65 3. BIER in data centers . . . . . . . . . . . . . . . . . . . . 5 66 4. BIER MLD extension for Virtual Network information . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 7.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 This document is motivated by [I-D.ietf-bier-use-cases]. 78 In current data center virtualization, virtual eXtensible Local Area 79 Network (VXLAN) [RFC7348] is a kind of network virtualization overlay 80 technology which is overlaid between NVEs and is intended for multi- 81 tenancy data center networks, whose reference architecture is 82 illustrated as per Figure 1. 84 +--------+ +--------+ 85 | Tenant +--+ +----| Tenant | 86 | System | | (') | System | 87 +--------+ | ................ ( ) +--------+ 88 | +-+--+ . . +--+-+ (_) 89 | | NVE|--. .--| NVE| | 90 +--| | . . | |---+ 91 +-+--+ . . +--+-+ 92 / . . 93 / . L3 Overlay . +--+-++--------+ 94 +--------+ / . Network . | NVE|| Tenant | 95 | Tenant +--+ . .--| || System | 96 | System | . . +--+-++--------+ 97 +--------+ ................ 99 Figure 1: NVO3 Architecture 101 And there are two kinds of most common methods about how to forward 102 BUM packets in this virtualization overlay network. One is using PIM 103 as underlay multicast routing protocol to build explicit multicast 104 distribution tree, such as PIM-SM[RFC4601] or PIM-BIDIR 105 [RFC5015]multicast routing protocol. Then, when BUM packets arrive 106 at NVE, it requires NVE to have a mapping between the VXLAN Network 107 Identifier and the IP multicast group. According to the mapping, NVE 108 can encapsulate BUM packets in a multicast packet which group address 109 is the mapping IP multicast group address and steer them through 110 explicit multicast distribution tree to the destination NVEs. This 111 method has two serious drawbacks. It need the underlay network 112 supports complicated multicast routing protocol and maintains 113 multicast related per-flow state in every transit nodes. What is 114 more, how to configure the ratio of the mapping between VNI and IP 115 multicast group is also an issue. If the ratio is 1:1, there should 116 be 16M multicast groups in the underlay network at maximum to map to 117 the 16M VNIs, which is really a significant challenge for the data 118 center devices. If the ratio is n:1, it would result in inefficiency 119 bandwidth utilization which is not optimal in data center networks. 121 The other method is using ingress replication to require each NVE to 122 create a mapping between the VXLAN Network Identifier and the remote 123 addresses of NVEs which belong to the same virtual network. When NVE 124 receives BUM traffic from the attached tenant, NVE can encapsulate 125 these BUM packets in unicast packets and replicate them and tunnel 126 them to different remote NVEs respectively. Although this method can 127 eliminate the burden of running multicast protocol in the underlay 128 network, it has a significant disadvantage: large waste of bandwidth, 129 especially in big-sized data center where there are many receivers. 131 Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] is 132 an architecture that provides optimal multicast forwarding through a 133 "BIER domain" without requiring intermediate routers to maintain any 134 multicast related per-flow state. BIER also does not require any 135 explicit tree-building protocol for its operation. A multicast data 136 packet enters a BIER domain at a "Bit-Forwarding Ingress Router" 137 (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding 138 Egress Routers" (BFERs). The BFIR router adds a BIER header to the 139 packet. The BIER header contains a bit-string in which each bit 140 represents exactly one BFER to forward the packet to. The set of 141 BFERs to which the multicast packet needs to be forwarded is 142 expressed by setting the bits that correspond to those routers in the 143 BIER header. Specifically, for BIER-TE, the BIER header may also 144 contain a bit-string in which each bit indicates the link the flow 145 passes through. 147 The following sections try to propose how to take full advantage of 148 overlay multicast protocol to carry virtual network information, and 149 create a mapping between the virtual network information and the bit- 150 string to implement BUM services in data centers. 152 2. Convention and Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 The terms about BIER are defined in [I-D.ietf-bier-architecture]. 160 The terms about NVO3 are defined in [RFC7365]. 162 Here tries to list the most common terminology mentioned in this 163 draft. 165 BIER: Bit Index Explicit Replication(Bit Index Explicit Replication 166 (The overall architecture of forwarding multicast using a Bit 167 Position). 169 NVE: Network Virtualization Edge, which is the entity that implements 170 the overlay functionality. An NVE resides at the boundary between a 171 Tenant System and the overlay network. 173 VXLAN: Virtual eXtensible Local Area Network 175 VNI: VXLAN Network Identifier 177 Virtal Network Context Identifier: Field in an overlay encapsulation 178 header that identifies the specific VN the packet belongs to. 180 3. BIER in data centers 182 This section tries to describe how to use BIER as an optimal scheme 183 to forward the broadcast, unknown and multicast (BUM) packets when 184 they arrive at the ingress NVE in data centers. 186 The principle of using BIER to forward BUM traffic is that: firstly, 187 it requires each ingress NVE to have a mapping between the Virtual 188 Network Context Identifier and the bit-string in which each bit 189 represents exactly one egress NVE to forward the packet to. And 190 then, when receiving the BUM traffic, the BFIR/Ingree NVE maps the 191 receiving BUM traffic to the mapping bit-string, encapsulates the 192 BIER header, and forwards the encapsulated BUM traffic into the BIER 193 domain to the other BFERs/Egress NVEs indicated by the bit-string. 195 Furthermore, as for how each ingress NVE knows the other egress NVEs 196 that belong to the same virtual network and creates the mapping is 197 the main issue discussed below. Basically, BIER Multicast Listener 198 Discovery is an overlay solution to support ingress routers to keep 199 per-egress-router state to construct the BIER bit-string associated 200 with IP multicast packets entering the BIER domain. The following 201 section tries to extend BIER MLD to carry virtual network 202 information(such as Virtual Network Context identifier), and 203 advertise them between NVEs. When each NVE receive these 204 information, they create the mapping between the virtual network 205 information and the bit-string representing the other NVEs belonged 206 to the same virtual network. 208 4. BIER MLD extension for Virtual Network information 210 Figure 2 draws the extension of the MLD report message format. In 211 order to support Virtual Network information advertisement, one bit 212 of the reserved field need be defined to indicate that there is a 213 extended MLD Virtual Network information TLV immediately following in 214 this message. 216 0 1 2 3 217 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type | Code | Checksum | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Maximum Response Delay | Reserved |1| 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 + + 225 | | 226 + Multicast Address + 227 | | 228 + + 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | VN Info type | length | Value | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | ...... | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 2: MLD message format 238 Specifically, Figure 3 illustrates the detailed Virtual Network 239 information TLV format in MLD report message to carry Virtual Network 240 information. 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | type | length | Encap Type | Reserved | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Virtual Network Context Identifier | Reserved | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Virtual Network Context Identifier | Reserved | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | ...... | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 3: MLD Virtual Network information TLV 254 Type: 256 indicates Virtual Network information TLV. Value 1 indicates Virtual 257 Network information advertisement. Value 2 indicates Virtual Network 258 information withdraw. 260 Length: 1 cotet. 262 Encap Type: 264 indicates the encapsulation type the virtual netowrk using, such as 265 VxLAN,NVGRE,Geneve and so on. 267 Virtual Network Context Idenfifier: 269 indicates the identifier of the virtual network. Different 270 encapsulation type has different meaning for this field. In VxLAN 271 encasulation type, this field indicates VxLAN Network Identifier. In 272 NVGRE encapsulation type, this field indicates Virtual Subnet 273 ID(VSID).In Geneve encapsulation type, this field indicates Virtual 274 Network Identifier. 276 Each NVE acquires the Virtual Network information, and advertises 277 this Virtual Network information to other NVEs through the MLD 278 messages. If the NVE attaches to several virtual networks, it will 279 carry several Virtual Network Context Identifiers in the Virtual 280 Network advertisement message. if the NVE supports several 281 encapsulation types, it will carry the Virtual Network Context 282 Identifiers belonging to one encapsulation type in one Virtual 283 Network information TLV. if one attached virtual network is 284 migrated, the NVE will withdraw the Virtual Network information. 286 When ingress NVE receives the Virtual Network information 287 advertisement message, it builds a mapping between the receiving 288 Virtual Network Context Identifier in this message and the bit-string 289 in which each bit represents one egress NVE who sends the same 290 Virtual Network information. Subsequently, once this ingress NVE 291 receives some other MLD advertisements which include the same Virtual 292 Network information from some other NVEs , it updates the bit-string 293 in the mapping and adds the corresponding sending NVE to the updated 294 bit-string. Once the ingress NVE removes one virtual network, it 295 will delete the mapping corresponding to this virtual network as well 296 as send withdraw message to other NVEs. 298 After finishing the above interaction of MLD messages, each ingress 299 NVE knows where the other egress NVEs are in the same virtual 300 network. When receiving BUM traffic from the attached virtual 301 network, each ingress NVE knows exactly how to encapsulate this 302 traffic and where to forward them to. 304 This can be used in both IPv4 network and IPv6 network. In IPv4, 305 IGMP protocol does the similar extension for carrying Virtual Network 306 information TLV in Version 2 membership report message. 308 5. Security Considerations 310 It will be considered in a future revision. 312 6. IANA Considerations 314 There need one new Type for Virtual Network information TLV in MLD 315 protocol and one in IGMP protocol. 317 7. References 319 7.1. Normative References 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, 323 DOI 10.17487/RFC2119, March 1997, 324 . 326 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 327 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 328 Protocol Specification (Revised)", RFC 4601, 329 DOI 10.17487/RFC4601, August 2006, 330 . 332 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 333 "Bidirectional Protocol Independent Multicast (BIDIR- 334 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 335 . 337 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 338 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 339 eXtensible Local Area Network (VXLAN): A Framework for 340 Overlaying Virtualized Layer 2 Networks over Layer 3 341 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 342 . 344 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 345 Rekhter, "Framework for Data Center (DC) Network 346 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 347 2014, . 349 7.2. Informative References 351 [I-D.ietf-bier-architecture] 352 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 353 S. Aldrin, "Multicast using Bit Index Explicit 354 Replication", draft-ietf-bier-architecture-04 (work in 355 progress), July 2016. 357 [I-D.ietf-bier-idr-extensions] 358 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 359 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 360 idr-extensions-01 (work in progress), June 2016. 362 [I-D.ietf-bier-isis-extensions] 363 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 364 "BIER support via ISIS", draft-ietf-bier-isis- 365 extensions-02 (work in progress), March 2016. 367 [I-D.ietf-bier-ospf-bier-extensions] 368 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 369 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 370 for BIER", draft-ietf-bier-ospf-bier-extensions-02 (work 371 in progress), March 2016. 373 [I-D.ietf-bier-use-cases] 374 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 375 Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., 376 Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases 377 draft-ietf-bier-use-cases-03 .txt", draft-ietf-bier-use- 378 cases-03 (work in progress), July 2016. 380 Authors' Addresses 382 Cui(Linda) Wang 383 ZTE Corporation 384 No.50 Software Avenue, Yuhuatai District 385 Nanjing 386 China 388 Email: wang.cui1@zte.com.cn 390 Zheng(Sandy) Zhang 391 ZTE Corporation 392 No.50 Software Avenue, Yuhuatai District 393 Nanjing 394 China 396 Email: zhang.zheng@zte.com.cn