idnits 2.17.1 draft-balaji-opsawg-vxlan-vm-topo-discovery-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 : ---------------------------------------------------------------------------- ** There are 22 instances of lines with control characters in the document. 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 (March 26, 2012) is 4414 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) == Missing Reference: 'RFC2119' is mentioned on line 87, but not defined -- Looks like a reference, but probably isn't: '2011' on line 250 == Unused Reference: 'KEYWORDS' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 267, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'RFC2011' is defined on line 275, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 279, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 285, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1776 ** Downref: Normative reference to an Informational RFC: RFC 1925 (ref. 'TRUTHS') -- Obsolete informational reference (is this intentional?): RFC 2011 (Obsoleted by RFC 4293) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG Working Group Balaji Venkat Venkataswami 3 INTERNET-DRAFT Bhargav Bhikkaji 4 Intended Status: Proposed Standard DELL-Force10 5 Expires: September 2012 March 26, 2012 7 VM to VTEP maps topology discovery in VXLAN based data centers 8 draft-balaji-opsawg-vxlan-vm-topo-discovery-01 10 Abstract 12 This document proposes a method by which in a VXLAN environment the 13 ARP tables of each VTEP having an active VM belonging to a particular 14 tenant where such active VMs are distributed amongst several VTEPs in 15 a data center or across data centers are walked through and the 16 collation of the location of such active VMs and the VTEPs they are 17 located in is found for management and network resource planning 18 purposes. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2.1 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 6 62 2. Applicability to NMS Applications . . . . . . . . . . . . . . . 7 63 2.1 VTEP support . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 65 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1 Normative References . . . . . . . . . . . . . . . . . . . 8 68 5.2 Informative References . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1 Introduction 73 It will be necessary in a VXLAN data center environment to locate the 74 several active VMs belonging to one or more tenants or all tenants 75 which are hosted by the VTEPs in the data center and list the active 76 VMs such that management and network resource planning can be done 77 for that tenant. This information may be useful to the network 78 administrators of the data center deploying VXLAN and to the tenants 79 that have their active VMs hosted in the data center running VXLAN 80 for the mentioned purposes. 82 1.1 Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 1.2 Methodology 90 The following IP Address Translation table also called the ARP table 91 as outlined in RFC 2011 will be useful in this method. It is possible 92 that several IP sub-nets are deployed for a given tenant. For each 93 such IP sub-net there may be a VLAN allocated. For routing between 94 such IP sub-nets the default gateway for a VLAN that has its VNICs in 95 several such VLANs may be deployed. In such a case the ARP tables of 96 each of the interfaces of then active VM default gateway for the 97 several VLANs involved is inspected to collate the different VLAN's 98 active VMs that are hosted on the VTEPs in the VXLAN based data 99 center. The algorithm that does this specific job of collation is 100 explained in section 1.2.1. 102 -- the IP Address Translation table 104 -- The Address Translation tables contain the IpAddress to 105 -- "physical" address equivalences. Some interfaces do not 106 -- use translation tables for determining address 107 -- equivalences (e.g., DDN-X.25 has an algorithmic method); 108 -- if all interfaces are of this type, then the Address 109 -- Translation table is empty, i.e., has zero entries. 111 ipNetToMediaTable OBJECT-TYPE 112 SYNTAX SEQUENCE OF IpNetToMediaEntry 113 MAX-ACCESS not-accessible 114 STATUS current 115 DESCRIPTION 116 "The IP Address Translation table used for mapping from 117 IP addresses to physical addresses." 118 ::= { ip 22 } 120 ipNetToMediaEntry OBJECT-TYPE 121 SYNTAX IpNetToMediaEntry 122 MAX-ACCESS not-accessible 123 STATUS current 124 DESCRIPTION 125 "Each entry contains one IpAddress to `physical' address 126 equivalence." 127 INDEX { ipNetToMediaIfIndex, 128 ipNetToMediaNetAddress } 129 ::= { ipNetToMediaTable 1 } 131 IpNetToMediaEntry ::= SEQUENCE { 132 ipNetToMediaIfIndex INTEGER, 133 ipNetToMediaPhysAddress PhysAddress, 134 ipNetToMediaNetAddress IpAddress, 135 ipNetToMediaType INTEGER 136 } 138 ipNetToMediaIfIndex OBJECT-TYPE 139 SYNTAX INTEGER (1..2147483647) 140 MAX-ACCESS read-create 141 STATUS current 142 DESCRIPTION 143 "The interface on which this entry's equivalence is 144 effective.The interface identified by a particular value 145 of this index is the same interface as identified by the 146 same value of RFC 1573's ifIndex." 147 ::= { ipNetToMediaEntry 1 } 149 ipNetToMediaPhysAddress OBJECT-TYPE 150 SYNTAX PhysAddress 151 MAX-ACCESS read-create 152 STATUS current 153 DESCRIPTION 154 "The media-dependent `physical' address." 155 ::= { ipNetToMediaEntry 2 } 157 ipNetToMediaNetAddress OBJECT-TYPE 158 SYNTAX IpAddress 159 MAX-ACCESS read-create 160 STATUS current 161 DESCRIPTION 162 "The IpAddress corresponding to the media-dependent 163 `physical' address." 164 ::= { ipNetToMediaEntry 3 } 166 ipNetToMediaType OBJECT-TYPE 167 SYNTAX INTEGER { 168 other(1), -- none of the following 169 invalid(2), -- an invalidated mapping 170 dynamic(3), 171 static(4) 172 } 173 MAX-ACCESS read-create 174 STATUS current 175 DESCRIPTION 176 "The type of mapping. 177 Setting this object to the value invalid(2) has the 178 effect 179 of invalidating the corresponding entry in the 180 ipNetToMediaTable. That is, it effectively disassociates 181 the interface identified with said entry from the mapping 182 identified with said entry. It is an implementation- 183 specific matter as to whether the agent removes an 184 invalidated entry from the table.Accordingly, management 185 stations must be prepared to receive tabular information 186 from agents that corresponds to entries not currently in 187 use. Proper interpretation of such entries requires 188 examination of the relevant ipNetToMediaType object." 189 ::= { ipNetToMediaEntry 4 } 191 1.2.1 Algorithm 193 Input : Seed VTEP IP address of a particular tenant Y 195 Output: Collated output of all active VMs in the respective VTEPs in 196 the VXLAN data center. 198 AlgorithmBegin 200 While more VTEPs to be scanned 202 START_LABEL: 204 While ( there exists more entries in 205 current_vlan ARP TABLE Where the TABLE = RFC 2011 206 ipNetToMediaEntryTable of Seed VTEP ) 208 Get Next of the entry in the ARP table of the VTEP; 209 If (active VM listed in ARP table is 210 tenant of Y ) 211 then 212 Add to list the unique ARP table entry; 213 Add VTEP in the ARP table entry 214 to unique VTEP list; 215 endif 217 EndWhile 219 If (any other VLAN's ARP table is available 220 in case the VM is a gateway VM) then 222 Set current_vlan = VLAN located; 223 goto START_LABEL; 224 else 225 // do nothing; 226 endif 228 Set Seed VTEP = Next VTEP address in the unique VTEP list; 230 Advance one entry in the unique VTEP list; 232 Set NextVTEP = Seed VTEP; 234 EndWhile; 236 AlgorithmEnd; 238 2. Applicability to NMS Applications 240 Network Management Applications can provide a friendly user interface 241 where the topology of the Layer 3 transport network with the TORs and 242 respective VTEPs under them can be discovered using regular Layer 3 243 topology discovery. The algorithm in 1.2.1 can then be executed and 244 the active VMs of various tenants displayed. This will help in 245 management and in network resource planning. 247 2.1 VTEP support 249 VTEPs in the VXLAN environment in data centers are expected to have 250 SNMP support in the form of MIBs as per [2011]. 252 3 Security Considerations 254 The usual SNMP related security concerns apply. 256 4 IANA Considerations 258 None. 260 5 References 262 5.1 Normative References 264 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 268 1 1995. 270 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 271 April 1 1996. 273 5.2 Informative References 275 [RFC2011] McCloghrie, K., Ed., "SNMPv2 Management Information Base 276 for the Internet Protocol using SMIv2", RFC 2011, November 277 1996. 279 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 280 RFC 3514, April 1 2003. 282 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 283 Acronyms", RFC 5513, April 1 2009. 285 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 286 2009. 288 Authors' Addresses 290 Balaji Venkat Venkataswami, 291 Dell-Force10, 292 Olympia Technology Park, 293 Fortius block, 7th & 8th Floor, 294 Plot No. 1, SIDCO Industrial Estate, 295 Guindy, Chennai - 600032. 296 TamilNadu, India. 297 Tel: +91 (0) 44 4220 8400 298 Fax: +91 (0) 44 2836 2446 300 EMail: BALAJI_VENKAT_VENKAT@dell.com 302 Bhargav Bhikkaji, 303 Dell-Force10, 304 350 Holger Way, 305 San Jose, CA 306 U.S.A 308 Email: Bhargav_Bhikkaji@dell.com