idnits 2.17.1 draft-ietf-armd-call-for-investigation-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 (May 28, 2011) is 4717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ARMD B. Schliesser 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational L. Dunbar 5 Expires: November 29, 2011 Huawei Technologies 6 May 28, 2011 8 ARMD Call for Investigation 9 draft-ietf-armd-call-for-investigation-00 11 Abstract 13 This document is a call for investigation into the topic of address 14 resolution in massive datacenters. It describes the intended work of 15 the ARMD working group, providing both context and direction for 16 investigating the issues outlined in the working group's charter. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 29, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Call for Investigation . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Call for Investigation 62 1.1. Context 64 Modern datacenters are increasingly used to support advanced 65 services, such as multi-tenant hosting, cloud, and Internet-scale 66 websites. Many of these datacenter facilities are being built to a 67 much larger scale than previous generations. As a result, datacenter 68 network infrastructure is being stressed in a number of dimensions 69 and traditional limits to scale are being tested. One such aspect, 70 being investigated by the ARMD working group, is the scaling of 71 address resolution between the network (L3) and link (L2) layers of 72 modern datacenter networks. 74 In many cases, datacenter operators are responsible for provisioning 75 and running everything from routers, switches, load balancers, 76 firewalls, servers, and storage infrastructure. Further, with the 77 introduction of virtualization technology the capacity of these 78 elements is increasing. Each physical device attached to the network 79 may now represent multiple logical instances, and may expose those 80 instances through unique MAC and/or IP addresses. For instance, with 81 the introduction of Virtual Machine technology the operator can 82 reduce wasted resources and achieve greater flexibility by 83 instantiating multiple hosts on each physical server resource. 84 Likewise virtual storage volumes, virtual routers, etc, may all exist 85 in larger numbers. 87 This virtualization trend contributes to both the increased scale and 88 management complexity of these datacenter environments. The 89 flexibility of VM placement, including migration between different 90 physical resources, has increased datacenter administrators' ability 91 to instantiate VMs where the resources are, i.e. being able to 92 relocate hosts from over-utilized servers to underutilized servers. 93 There is a growing trend towards using resource-aware algorithms 94 (e.g. evaluating energy, bandwidth, memory, CPU, etc) to determine 95 placement that satisfies the processing and redundancy requirements 96 of each VM while using the minimal number of physical resources. 97 Fundamentally, such datacenter management tools are responsible for 98 making trade-offs between different dimensions of scale, which can be 99 difficult in very large and dynamic environments, and in all cases 100 requires a significantly stronger understanding of platform 101 capabilities. 103 In this environment, IP subnets can extend throughout multiple racks 104 and/or rows in a data center, sometimes throughout multiple sites. 105 There are cases, such as HPC and cloud datacenters, where the number 106 of hosts in a single subnet (on a single segment) is growing. In 107 addition to the more recent VM environment, traditional organic 108 growth of physical hosts can also cause L2 segments to be extended 109 throughout massive datacenters. Availability / redundancy 110 requirements, subnet size requirements (versus port density), and 111 cost issues can all contribute to the growth and/or extension of 112 segments. 114 The business demands and workloads for data centers have changed 115 greatly over last 10 years, however some fundamental networking 116 limitations remain unexplored. Even though deployed networks 117 generally do work, this often is because they're designed around 118 known limitations (and redesigned around newly discovered limitations 119 as time goes on). There are datacenter networks that work fine until 120 something changes, such as scale, at which time they're "fixed". 121 Often the "fix" also introduces undesired limitations. An example of 122 this is a datacenter that moves from a flat L2 topology to a L3 core 123 with multiple segregated L2 domains due to scale limitations, and 124 subsequently is unable to distribute clustered servers beyond the 125 boundaries of the "pod" in which a VLAN scope can be configured. 127 1.2. Questions 129 The initial goal of the ARMD working group is to document the 130 limiting factors in address resolution scale and the problems 131 associated with exceeding those limits. Subsequently, the working 132 group will identify operational solutions to these problems (to be 133 promoted as Best Current Practice) or will identify gaps in existing 134 solutions (for exploration in subsequent work). Thus the ARMD 135 working group is asked to consider the following questions: 137 1. What are the scaling characteristics of modern datacenter 138 networks (e.g. "dimensions" of scale and their normal ranges) 139 that are relevant to address resolution? 141 2. What are the operational problems related to address resolution 142 in the modern datacenter environment? 144 3. What is the relationship between scaling characteristics of 145 datacenter networks (question #1) and operational problems 146 related to address resolution (question #2)? 148 4. What, if any, are alternative solutions to the operational 149 problems of address resolution at massive scale? 151 5. What, if any, are the "gaps" in existing solutions? 153 2. Acknowledgements 155 The authors would like to thank Ron Bonica for his significant 156 contributions to this text. 158 3. IANA Considerations 160 This memo includes no request to IANA. 162 4. Security Considerations 164 This document does not, by itself, introduce any specific security 165 considerations. However, this document calls for further 166 investigation into subject matter that may require significant 167 consideration of security issues. It is anticipated that documents 168 submitted in response to this call for investigation will include 169 appropriate Security Considerations text. 171 Authors' Addresses 173 Benson Schliesser 174 Cisco Systems, Inc. 176 Email: bschlies@cisco.com 178 Linda Dunbar 179 Huawei Technologies 181 Email: ldunbar@huawei.com