idnits 2.17.1 draft-song-sfc-legacy-sf-mapping-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 36 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (April 14, 2014) is 3664 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: 'I-D.jiang-sfc-arch' is defined on line 446, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC working group H. Song 3 Internet-Draft L. Yong 4 Intended status: Standards Track Y. Jiang 5 Expires: October 16, 2014 Huawei 6 April 14, 2014 8 SFC Header Mapping for Legacy SF 9 draft-song-sfc-legacy-sf-mapping-01 11 Abstract 13 SFC (Service Function Chaining) is used to manipulate service 14 functions with easy creation, updating and deletion. A service 15 function chain goes through a list of ordered service function 16 instances. One assumption of this document is that legacy service 17 function instances can participate in the service chain. They are 18 not aware of the SFC header, nor interpret it. This document 19 provides a mechanism between a Service Forwarding Entity (SFE) and a 20 Service Function Instance (SFI), to identify the SFC header 21 associated with a packet that is returned from an SFI, without SFC 22 header being explicitly carried in the wired protocol between SFE and 23 SFI. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 16, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. For Transparent Service Functions . . . . . . . . . . . . 4 69 3.1.1. Layer 2 MAC Address . . . . . . . . . . . . . . . . . 4 70 3.1.2. VLAN . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1.3. QinQ . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1.4. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.2. For Non-transparent Service Functions . . . . . . . . . . 9 74 4. Operation Consideration . . . . . . . . . . . . . . . . . . . 9 75 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 76 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 77 7. Informative References . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 SFC is used to manipulate service functions with easy creation, 83 updating and deletion. A service function chain goes through a list 84 of ordered service functions. One assumption of this document is 85 that certain service functions can be kept as legacy. They do not 86 have to be aware of the SFC header, nor interprets it. This document 87 provides a mechanism between a Service Forwarding Entity and a 88 Service Function Instance, to identify the SFC header associated with 89 a packet that is returned from an SFI, without anything in the SFC 90 header being explicitly carried in the wired protocol between a SFE 91 and SFI. 93 +----------------+ 94 |Service Function| 95 |Instance | 96 +----+----+------+ 97 ^ | 98 | | 99 | | 100 (2)| |(3) 101 | | 102 | | 103 +----+----V--------+ 104 (1) |Service Forwarding| (4) 105 -------->|Entity +-------> 106 +------------------+ 107 Figure 1: Procedure of a packet processed by a legacy service function 109 The legacy service function (i.e. SFI in the Figure 1) only handles 110 packets without SFC header, because it does not understand the SFC 111 header. One advantage is that the existing service functions don't 112 need to be upgraded to support SFC. Otherwise it may be a hindrance 113 for the widely adoption of SFC. 115 Assuming that for most SFIs, the packet header is transparent to a 116 legacy SFI. SFI will not modify the layer 2 or layer 3 packet 117 headers. If the payload in the SFC encapsulation is layer 3 traffic, 118 it will be kept as it is, and a new layer 2 header will be added 119 before sending to the SFI. However if the payload in the SFC 120 encapsulation is layer 2 traffic, the SFE may modify the original 121 source MAC address and use the new source MAC address for mapping to 122 the stored SFC header. This will not impact the SFI processing. The 123 SFI will send the traffic back after processing. For the current 124 stage, we leave the legacy SFIs which modify the original packet 125 headers as an open issue for further study. 127 As shown in Figure 1, there are four steps. The SFE receives a 128 packet, and removes its SFC header, which may optionally contain 129 metadata, and stores the SFC header locally, and then sends the 130 original packet to the SFI. After SFI processing the packet, the 131 traffic will be sent back to the SFE. The SFE retrieves the pre- 132 stored SFC header accordingly, and encapsulates the packet with the 133 SFC header, and then sends the packet to next-hop service function. 134 The key problem here is how to map the packet to its original SFC 135 header. 137 If the SFC header is not changed per flow at a certain point, e.g., a 138 specific SFE, (i.e. each flow has a specific SFC header in a SFE, but 139 in another SFE, the SFC header is different), then the SFE needs to 140 find the original SFC header per flow. If the SFC header is changed 141 per packet for a specific flow at a certain point, then the SFE needs 142 to find the original SFC header per packet. The second case may be 143 happened if different packets in a flow carry different metadata 144 (e.g. the metadata can be injected to the packet by a DPI appliance). 145 It's also the reason why five-tuple cannot be used for the mapping to 146 retrieve the original SFC header. 148 An expiration time can be used for each mapping entry in the SFE. If 149 the SFC header in that entry has not been retrieved after the 150 expiration time, the entry will be deleted from the entry table. 152 2. Terminology 154 The terminology used in this document is defined below: 156 Legacy SF: A conventional service function that does not support 157 SFC header. 159 Transparent SF: A service function that does not change any bit of 160 the original service packet header (Layer 2, layer 3, and layer 4) 161 sent to it. 163 Non-transparent SF: A service function that changes some part of 164 the original service packet header sent to it. 166 Original Service Packet: The payload in a SFC encapsulation packet 167 or a packet constructed based on the original payload. 169 3. Mechanisms 171 The mechanisms used in this document require that each forwarding 172 entity and its connected service functions in a same layer 2 network. 173 The following are considerations mainly for transparent SFIs. If the 174 original payload packet is a layer 2 packet, and the mapping method 175 used is layer 2 MAC address, then the assumption is that the SFI does 176 not need to look into the layer 2 header. If it does, other 177 mechanisms should be used. 179 3.1. For Transparent Service Functions 181 If the service function is transparent to packet headers, the 182 following methods can be used for SFC header mapping. 184 3.1.1. Layer 2 MAC Address 186 The layer 2 MAC address is used to associate a SFC header between SFE 187 and SFI, i.e. each SFC header will be assigned a source MAC address 188 on the SFE. If SFC header can be changed per packet, then SFE 189 assigns a new source MAC address for each packet it received, 190 otherwise, it assigns a new MAC address for each flow it received. 192 When SFE received the returned packet from the SFI, it retrieves the 193 packet's original SFC header by using the MAC address as a key. And 194 then it encapsulates the packet with that SFC header and sends to the 195 next hop. 197 0 1 2 3 198 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 200 Outer Ethernet Header: 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | SFI Destination MAC Address | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |SFI Destination MAC Address | SFE Source MAC Address | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | SFE Source MAC Address | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Ethertype = 0x0800 | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Original IP Payload: 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Original Payload | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 3.1.2. VLAN 220 If the network between the SFE and SFI is a layer 2 network, and in 221 the case that a SFI need to look into the MAC address of the packet, 222 then VLAN can be used for the mapping between them. The SFE removes 223 the SFC header and sends the packet to the SFI, with encapsulating a 224 certain VLAN ID. It locally maintains the mapping between VLAN ID 225 and the SFC header. When it gets the returned packet from the SFI, 226 it removes the VLAN part from the packet and retrieves the 227 corresponding SFC header according to the VLAN ID, and then 228 encapsulates SFC header into that packet before sending to the next 229 service function. 231 The VLAN ID can be used for mapping per flow, i.e. each flow will be 232 assigned a new VLAN ID. If SFC header could be changed per packet, 233 the length of VLAN ID is not enough for mapping. 235 0 1 2 3 236 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 238 Outer Ethernet Header: 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | SFI Destination MAC Address | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |SFI Destination MAC Address | SFE Source MAC Address | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | SFE Source MAC Address | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |OptnlEthtype = C-Tag 802.1Q |Outer.VLAN Tag Information | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Ethertype = 0x0800 | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Original IP Payload: 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Original Payload | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 3.1.3. QinQ 260 If the network between the SFE and SFI is already a VLAN network, and 261 the SFI needs to look into the MAC address, then QinQ is used for the 262 communication between SFE and SFI. The SFE remove the SFC header and 263 send the original traffic to SFI with a certain outer VLAN ID. It 264 locally maintains the mapping between outer VLAN ID and the SFC 265 header. 267 If the network between SFE and SFI is not a VLAN network, then QinQ 268 can be used for either per flow mapping or per packet mapping, using 269 two layer VLAN fields. If the network between SFE and SFI is a VLAN 270 network, then QinQ can only be used for per flow mapping, using one 271 VLAN field. 273 0 1 2 3 274 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 276 Outer Ethernet Header: 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | SFI Destination MAC Address | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |SFI Destination MAC Address | SFE Source MAC Address | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | SFE Source MAC Address | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |OptnlEthtype = S-Tag 802.1Q |Outer.VLAN Tag Information | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |Ethertype = C-Tag 802.1Q |Inner.VLAN Tag Information | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Ethertype = 0x0800 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Original IP Payload: 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Original Payload | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 3.1.4. VXLAN 300 If the SFE and SFI are already deployed in a QinQ network, then VXLAN 301 [I-D.mahalingam-dutt-dcops-vxlan] can be used for the mapping, i.e. 302 VNI can be used for the mapping between them. This tunneling 303 technology is only used when the original packet type is at layer 2 304 and the SFI has to look into the layer 2 MAC header. 306 The drawback of this mechanism is that it requires both SFE and SFI 307 to support VXLAN. 309 0 1 2 3 310 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 312 Outer Ethernet Header: 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | SFI Destination MAC Address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |SFI Destination MAC Address | SFE Source MAC Address | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | SFE Source MAC Address | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |OptnlEthtype = C-Tag 802.1Q |Outer.VLAN Tag Information | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Ethertype = 0x0800 | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Outer IP Header: 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |Version| IHL |Type of Service| Total Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Identification |Flags| Fragment Offset | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |Time to Live |Protocol=17(UDP) | Header Checksum | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Outer Source IPv4 Address | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Outer Destination IPv4 Address | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Outer UDP Header: 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Source Port = xxxx | Dest Port = VXLAN Port | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | UDP Length | UDP Checksum | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 VXLAN Header: 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |R|R|R|R|I|R|R|R| Reserved | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | VXLAN Network Identifier (VNI) | Reserved | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 3.2. For Non-transparent Service Functions 358 Non transparent service functions including NAT (Network Address 359 Translation), WOC (WAN Optimization Controller) and etc, are more 360 complicated, as they may change any part of the original packet sent 361 to them. It is better to analyze case by case, to utilize a specific 362 filed that the SFI does not change for the mapping and retrieving the 363 SFC header. We would like to leave it for open discussion. 365 The use case below is just one example that SFE can learn the 366 behavior of the SFI changing the packet. In this example, the 367 following method is used for SFC header mapping. The SFI needs to 368 report its mapping rules (e.g. 5-tuple mapping rules) to the control 369 plane (step 1), and then the control plane can notify the SFE the 370 mapping information (step 2). According to the mapping information, 371 the SFE can establish a mapping table for the SFC header, the 372 original header, and the processed header of the packet. After 373 receiving the packet from the SFI (step 5), the SFE retrieves the SFC 374 header from the mapping table by using the processed header as a key. 376 +-------------+ 377 |Control Plane| 378 +--+-----+----+ 379 ^ ^ 380 | | 381 | |(1) +----------------+ 382 | +------->Service Function| 383 (2)| |Instance | 384 | +-----+---+------+ 385 | (4)^ |(5) 386 +---------------+ | | 387 | | | 388 +--V---+---V-------+ 389 (3) |Service Forwarding| (6) 390 --------->+Entity +-------> 391 +------------------+ 393 4. Operation Consideration 395 The following table shows all the methods and the conditions to use. 397 Table 1: Operation Consideration 398 +-----------+--------+-----------------+-------------+-------------------+ 399 | |Methods |Ingress Flow |Egress Flow |Application | 400 | | |Mapping |Mapping |Condition | 401 +-----------+--------+-----------------+-------------+-------------------+ 402 | |MAC |1.5-tuple->Source|Source MAC |L2 header won't | 403 |For Trans- |Address |MAC address |address->SFC |be modified by | 404 |parent SF | |2.Any SFC |header |the SFI. | 405 | | |packet->Source | | | 406 | | |MAC address | | | 407 | +--------+-----------------+-------------+-------------------+ 408 | |VLAN |5-tuple->VLAN ID |VLAN ID->SFC |L2 header won't | 409 | | | |header |be modified by | 410 | | | | |the SFI. | 411 | +--------+-----------------+-------------+-------------------+ 412 | |QinQ |5-tuple->Outer |Outer VLAN |The SFI is required| 413 | | |VLAN ID |ID->SFC |to support QinQ. | 414 | | | |header |L2 header won't | 415 | | | | |be modified by | 416 | | | | |the SFI. | 417 | +--------+-----------------+-------------+-------------------+ 418 | |VXLAN |5-tuple->VNI |VNI->SFC |The SFI is required| 419 | | | |header |to support VXLAN. | 420 | | | | |L2 header won't | 421 | | | | |be modified by | 422 | | | | |the SFI. | 423 +-----------+--------+-----------------+-------------+-------------------+ 424 | |TBD |e.g. 5-tuple |e.g. 5-tuple'|The SFE must be | 425 |For | |->5-tuple' |->SFC header |configured or be | 426 |Non-trans- | | | |able to obtain the | 427 |parent SF | | | |mapping rules of | 428 | | | | |the SFI. The SFI | 429 | | | | |only changes the | 430 | | | | |5-tuple mapping | 431 | | | | |rules of the | 432 | | | | |original packet. | 433 +-----------+--------+-----------------+---------------------------------+ 435 5. Security considerations 437 When the layer 2 header of the original packet is modified and sent 438 to the SFI, if the SFI needs to look into the layer 2 header, it may 439 cause security threats. It also provides diagrams of the main 440 entities that the information model is comprised of. 442 6. Acknowledgement 444 7. Informative References 446 [I-D.jiang-sfc-arch] 447 Jiang, Y. and L. Hongyu, "An Architecture of Service 448 Function Chaining", draft-jiang-sfc-arch-01 (work in 449 progress), February 2014. 451 [I-D.mahalingam-dutt-dcops-vxlan] 452 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 453 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 454 Framework for Overlaying Virtualized Layer 2 Networks over 455 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-09 456 (work in progress), April 2014. 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 Authors' Addresses 463 Haibin Song 464 Huawei 465 101 Software Avenue, Yuhua District 466 Nanjing, Jiangsu 210012 467 China 469 Email: haibin.song@huawei.com 471 Lucy Yong 472 Huawei 473 5340 Legacy Drive 474 Plano, TX 75025 475 U.S.A. 477 Email: lucy.yong@huawei.com 479 Yuanlong Jiang 480 Huawei 481 Bantian, Longgang district 482 Shenzhen 518129 483 China 485 Email: jiangyuanlong@huawei.com