idnits 2.17.00 (12 Aug 2021) /tmp/idnits39198/draft-singh-nvo3-vxlan-router-alert-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: On receiving VXLAN frame, the Terminating VTEP would do the usual VXLAN processing as defined in [RFC7348], but if the RA Bit in Flags is Set it MUST send the rest of the inner frame for further processing to the above application. The details of the applications and how it would process the inner frame is outside the scope of this document. This frame MUST not be sent to the target End System. -- The document date (September 21, 2015) is 2427 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.draft-lasserre-nvo3-framework' is defined on line 204, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-lasserre-nvo3-framework (ref. 'I-D.draft-lasserre-nvo3-framework') ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 K. Singh 3 Internet-Draft P. Jain 4 Intended status: Standards Track D. Garcia del Rio 5 Expires: March 24, 2016 Nuage Networks. 6 W. Henderickx 7 Alcatel-Lucent, Inc. 8 R. Shekhar 9 Juniper Networks 10 R. Rahman 11 Cisco Systems 12 September 21, 2015 14 VxLAN Router Alert Option 15 draft-singh-nvo3-vxlan-router-alert-02 17 Abstract 19 This proposal describes a new option to achieve a mechanism which 20 alerts VxLAN terminating VTEP to more closely examine the contents of 21 the packet encapsulated under VxLAN header. This option is useful 22 for case(s) where a given frame encapsulated within a given VXLAN 23 segment responsible for carrying data between two different End 24 Systems contains some control information (e.g OAM information, any 25 control plane protocol packet etc.) that may require special 26 handling/processing by terminating VTEP. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 24, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Conventions Used in This Document . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Originating VTEP Procedure . . . . . . . . . . . . . . . . 6 70 4.2. Terminating VTEP Procedure . . . . . . . . . . . . . . . . 6 72 5. Management Considerations . . . . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Conventions Used in This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC2119 [RFC2119]. 92 When used in lower case, these words convey their typical use in 93 common language, and are not to be interpreted as described in 94 RFC2119 [RFC2119]. 96 2. Introduction 98 VXLAN [RFC7348]is a tunneling mechanism to overlay Layer 2 networks 99 on top of Layer 3 networks. In most cases the end point of the 100 tunnel (VTEP) is intended to be at the edge of the network, typically 101 connecting an access switch to an IP transport network. The access 102 switch could be a physical or a virtual switch located within the 103 hypervisor on the server which is connected to End System which is a 104 VM. 106 VXLAN segment encapsulates End System data at Originating VTEP and 107 carries it over L3 network to the Terminating VTEP, where VXLAN 108 header is interpreted, removed and data is passed on to the End 109 System. 111 There could be some scenarios, where the network element at 112 originating VTEP needs to encapsulate some control information in a 113 given VXLAN segment, and this control information needs to be 114 analysed and processed at the terminating VTEP for that VXLAN 115 segment. There could be various examples of such control information 116 e.g OAM, and protocol control packets encapsulated in VxLAN segment. 118 This document defines a mechanism whereby Originating VTEP can add 119 additional information to the VXLAN header, based upon which the 120 Terminating VTEP can decide to analyse the payload under VXLAN packet 121 and handle it to slow-path, rather then forwarding it to the 122 destination End System. 124 3. Terminology 126 Terminology used in this document: 128 VXLAN: Virtual eXtensible Local Area Network. 130 VTEP: VXLAN Tunnel End Point. 132 VM: Virtual Machine. 134 End System: Could be VM etc. - System whose data is expected to go 135 over VXLAN Segment. 137 OAM: Operations, Administration, and Maintenance 139 Other terminologies are as defined in [RFC7348]. 141 4. Approach 143 If the Originating VTEP decides to generate control information, 144 which needs to go over a given VXLAN segment and if the Terminating 145 VTEP needs to analyse and process it, then following procedures have 146 to be followed at Originating and Terminating VTEP(s):- 148 4.1. Originating VTEP Procedure 150 When creating the VXLAN header for a given VXLAN segment, the 151 Originating VTEP MUST set Router Alert Bit in the Flag bits in VXLAN 152 header. The VNI for this frame MUST be the same as for the given 153 VXLAN segment which carries the data traffic of the End System. 155 VXLAN Header: 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 |R|R|R|R|I|R|R|RA| Reserved | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | VXLAN Network Identifier (VNI) | Reserved | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 RA: Router Alert Bit (Proposed) 164 4.2. Terminating VTEP Procedure 166 On receiving VXLAN frame, the Terminating VTEP would do the usual 167 VXLAN processing as defined in [RFC7348], but if the RA Bit in Flags 168 is Set it MUST send the rest of the inner frame for further 169 processing to the above application. The details of the applications 170 and how it would process the inner frame is outside the scope of this 171 document. This frame MUST not be sent to the target End System. 173 5. Management Considerations 175 None 177 6. Security Considerations 179 For wide range, security requirements for VxLAN Packets with Route 180 Alert (RA) bit set is no different from how IP Router Alert Option is 181 handled in Network End Points. 183 The most common potential attack could be Denial-of-Service attacks 184 by sending VxLAN Packets with Router Alert Bit Set at aggressive 185 rate, causing potential high resource utilization. For such 186 scenarios its recommended that implementations regulate sending of 187 such packets to control plane via rate limiting. 189 7. Acknowledgements 191 The authors want to thank Krishna Ram Kuttuva Jeyaram, and Suresh 192 Boddapati of Nuage Networks for significant contribution and 193 feedback. 195 8. IANA Considerations 197 Router Alert Bit (RA): IANA is request to asigh 1 Bit in Flags field 198 of VXLAN Header to communicate VXLAN Router Alert information. 200 9. References 202 9.1. Normative References 204 [I-D.draft-lasserre-nvo3-framework] 205 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 206 Rekhter, "Framework for DC Network Virtualization", 207 September 2011. 209 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 210 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 211 eXtensible Local Area Network (VXLAN): A Framework for 212 Overlaying Virtualized Layer 2 Networks over Layer 3 213 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 214 . 216 9.2. Informative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 220 RFC2119, March 1997, 221 . 223 Authors' Addresses 225 Kanwar Singh 226 Nuage Networks. 227 755 Ravendale Drive 228 Mountain View, CA 94043 229 USA 231 Email: kanwar@nuagenetworks.net 233 Pradeep Jain 234 Nuage Networks. 235 755 Ravendale Drive 236 Mountain View, CA 94043 237 USA 239 Email: pradeep@nuagenetworks.net 241 Diego 242 Nuage Networks. 243 755 Ravendale Drive 244 Mountain View, CA 94043 245 USA 247 Email: diego@nuagenetworks.net 249 Wim Henderickx 250 Alcatel-Lucent, Inc. 251 Copernicuslaan 50, 2018 252 ANTWERP 2018 253 BELGIUM 255 Email: Wim.Henderickx@alcatel-lucent.com 257 Ravi Shekhar 258 Juniper Networks 259 1194 North Mathilda Ave. 260 Sunnyvale, CA 94089 261 USA 263 Email: rshekhar@juniper.net 264 Reshad Rahman 265 Cisco Systems 266 2000 Innovation Drive 267 Kanata, ON K2K 3E8 268 USA 270 Email: rrahman@cisco.com