idnits 2.17.1 draft-xu-nvo3-lan-extension-path-optimization-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 date (July 9, 2012) is 4307 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2338 (Obsoleted by RFC 3768) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group X. Xu 2 Internet Draft Huawei Technologies 3 Category: Informational Kai Lee 4 China Telecom 6 Expires: January 2013 July 9, 2012 8 Path Optimization for LAN Extension 10 draft-xu-nvo3-lan-extension-path-optimization-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 9, 2013. 35 Copyright Notice 37 Copyright (c) 2009 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 45 respect to this document. 47 Abstract 49 This document describes path optimization issues caused by LAN 50 extension across geographically dispersed data centers. In addition, 51 this document also describes requirements for possible solutions to 52 these issues. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC-2119 [RFC2119]. 60 Table of Contents 62 1. Problem Statement ........................................... 3 63 1.1. Suboptimal Routing for Incoming Traffic ................ 4 64 1.2. Suboptimal Routing for Outgoing Traffic ................ 4 65 2. Terminology ................................................. 5 66 3. Solution Requirements ....................................... 5 67 3.1. Path Optimization for Incoming Traffic ................. 5 68 3.2. Path Optimization for Outgoing Traffic ................. 5 69 4. Security Considerations ..................................... 5 70 5. IANA Considerations ......................................... 6 71 6. Acknowledgements ............................................ 6 72 7. References .................................................. 6 73 7.1. Normative References ................................... 6 74 7.2. Informative References ................................. 6 75 Authors' Addresses ............................................. 6 77 1. Problem Statement 79 Virtual Machine (VM) migration and geo-clustering across data 80 centers usually require a LAN to be extended across these data 81 centers. Figure 1 depicts a generic data center interconnect 82 architecture where multiple data centers are interconnected with a 83 given LAN extension solution and remote VPN sites (e.g., cloud user 84 sites) are connected to these data centers with L3VPN solution 85 [RFC4364]. 87 --------------- 88 / \ 89 | Cloud User Site | 90 \ / 91 -------+------- 92 | 93 +---+---+ 94 | PE-3 | 95 +---+---+ 96 | 97 -------+------ 98 / \ 99 / \ 100 | MPLS/IP Backbone | 101 \ / 102 /\ /\ 103 / ---------------- \ 104 / \ 105 +-------/----+ +----\-------+ 106 | GW-1(PE-1) | | GW-2(PE-2) | 107 +-----+------+ +------+-----+ 108 | | 109 +---------+----------------------------+----------+ 110 | LAN Extension | 111 +---------+----------------------------+----------+ 112 | | 113 ----+----- ----+----- 114 / \ / \ 115 | DC West | | DC East | 116 \ / \ / 117 ---------- ---------- 119 Figure 1: A Generic Data Center Interconnect Architecture 121 Since the LAN has been extended across multiple data center 122 locations, the IP subnet associated with this LAN is also extended 123 across these locations. As such, the traffic to/from the extended 124 subnet (e.g., the traffic between cloud user sites and data centers) 125 would encounter suboptimal routing issues as described in the 126 following sub-sections. Such suboptimal routing not only 127 unnecessarily consumes the bandwidth intended for data center 128 interconnect, but also decreases the cloud users' experiences due to 129 increased path latency. Note that here the traffic to/from the 130 extended subnet refers to L3VPN traffic between a remote L3VPN site 131 (e.g., a cloud user site) and data centers, rather than Internet 132 traffic. How to optimize the path for Internet traffic to/from the 133 extended subnet would be explored in the future. 135 1.1. Suboptimal Routing for Incoming Traffic 137 Since an IP subnet has been extended across multiple locations, the 138 subnet no longer retains its location semantics. As a result, the 139 incoming traffic towards a given server within the extended subnet 140 could travel through suboptimal paths if the traffic is forwarded 141 based on the corresponding subnet route. For example, assume a 142 server is physically located at data center East of an extended 143 subnet, the incoming traffic towards that server would possibly 144 travel through the default gateway router at data center West when 145 entering that subnet. 147 1.2. Suboptimal Routing for Outgoing Traffic 149 Let's assume the existing VPLS solution [RFC4761, RFC4762] is used 150 to achieve LAN extension across multiple data center locations. In 151 this case, VRRP would usually be enabled on default gateway routers 152 of different locations and only one of them would be selected as the 153 VRRP Master for the subnet associated with the extended LAN, which 154 is available for forwarding outgoing traffic of the subnet. In 155 addition, although multiple default gateway routers of different 156 locations could be selected as VRRP masters by filtering VRRP 157 messages among them, since the existing VPLS solution however 158 perform MAC learning as a traditional bridge, the route (e.g., MAC 159 forwarding entry) for a given MAC address would be determined 160 without taking the network distance into account. As a result, if 161 the forwarding path to the VRRP virtual MAC is currently pointed to 162 a default gateway router at data center East, for those servers 163 located at data center West, their outgoing traffic would have to 164 traverse the data center interconnection path so as to reach that 165 default gateway router at data center East, which in turn forwards 166 the traffic out of that subnet. 168 2. Terminology 170 This memo makes use of the terms defined in [RFC4364] and [RFC2338]. 172 3. Solution Requirements 174 3.1. Path Optimization for Incoming Traffic 176 The basic idea is to allow each default gateway router acting as a 177 L3VPN PE router to propagate host routes for local servers within 178 the extended subnet to remote PE routers. More specifically, a 179 default gateway router at a given data center is allowed to 180 advertise hosts routes only for servers located in that data center, 181 rather than those ones located in other data centers. In this way, 182 remote PE routers would be able to forward traffic destined for a 183 given server within the extended subnet according to the 184 corresponding host route for that server, rather than the subnet 185 route for that extended subnet. 187 The challenge here is how to make default gateway routers be able to 188 tell which servers within the extended subnet are their local ones. 189 Hence the possible solution for this path optimization issue SHOULD 190 ensure default gateway routers to be able to obtain enough information 191 so as to distinguish local servers from remote ones. 193 3.2. Path Optimization for Outgoing Traffic 195 To realize the purposes of default gateway redundancy and VM live 196 mobility across data centers, default gateway routers of a given 197 extended subnet at different locations SHOULD be configured with an 198 identical virtual IP/MAC address pair (i.e., virtual router). As 199 such, servers within the extended subnet could use that virtual 200 router's IP address as their default gateway. To ensure the outgoing 201 traffic with destination MAC address being the virtual router's MAC 202 address to be forwarded to a local default gateway router, rather 203 than any remote default gateway router, just like the anycast manner 204 in IP networks, the LAN extension solution SHOULD be able to select 205 the best route for a given MAC address (e.g., the virtual router's 206 MAC address) among multiple possible routes, e.g., by taking network 207 distance as one factor in the decision-making process of best-route 208 selection. 210 4. Security Considerations 212 TBD. 214 5. IANA Considerations 216 There is no requirement for IANA. 218 6. Acknowledgements 220 TBD. 222 7. References 224 7.1. Normative References 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, March 1997. 229 7.2. Informative References 231 [RFC2338] Knight, S., et al., "Virtual Router Redundancy Protocol", 232 RFC 2338, April 1998. 234 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 235 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 236 4761, January 2007. 238 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 239 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 240 RFC 4762, January 2007. 242 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 243 Networks (VPNs)", RFC 4364, February 2006. 245 Authors' Addresses 247 Xiaohu Xu 248 Huawei Technologies, 249 Beijing, China. 251 Phone: +86 10 60610041 252 Email: xuxiaohu@huawei.com 254 Kai Lee 255 China Telecom, 256 Beijing, China. 258 Leekai@ctbri.com.cn