idnits 2.17.00 (12 Aug 2021) /tmp/idnits17680/draft-singh-nvo3-vxlan-router-alert-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 == 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 [I-D.draft-mahalingam-dutt-dcops-vxlan], 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 (May 24, 2013) is 3283 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 185, 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') == Outdated reference: draft-mahalingam-dutt-dcops-vxlan has been published as RFC 7348 ** Downref: Normative reference to an Informational draft: draft-mahalingam-dutt-dcops-vxlan (ref. 'I-D.draft-mahalingam-dutt-dcops-vxlan') Summary: 2 errors (**), 0 flaws (~~), 4 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 F. Balus 5 Expires: November 25, 2013 Nuage Networks. 6 W. Henderickx 7 Alcatel-Lucent, Inc. 8 May 24, 2013 10 VxLAN Router Alert Option 11 draft-singh-nvo3-vxlan-router-alert-00 13 Abstract 15 This proposal describes a new option to achieve a mechanism which 16 alerts VxLAN terminating VTEP to more closely examine the contents of 17 the packet encapsulated under VxLAN header. This option is useful 18 for case(s) where a given frame encapsulated within a given VXLAN 19 segment responsible for carrying data between two different End 20 Systems contains some control information (e.g OAM information) that 21 may require special handling/processing by terminating VTEP. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 25, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Originating VTEP Procedure . . . . . . . . . . . . . . . . 6 63 3.2. Terminating VTEP Procedure . . . . . . . . . . . . . . . . 6 65 4. Management Considerations . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC2119 [RFC2119]. 82 When used in lower case, these words convey their typical use in 83 common language, and are not to be interpreted as described in 84 RFC2119 [RFC2119]. 86 1. Introduction 88 VXLAN [I-D.draft-mahalingam-dutt-dcops-vxlan]is a tunneling mechanism 89 to overlay Layer 2 networks on top of Layer 3 networks. In most 90 cases the end point of the tunnel (VTEP) is intended to be at the 91 edge of the network, typically connecting an access switch to an IP 92 transport network. The access switch could be a physical or a 93 virtual switch located within the hypervisor on the server which is 94 connected to End System which is a VM. 96 VXLAN segment encapsulates End System data at Originating VTEP and 97 carries it over L3 network to the Terminating VTEP, where VXLAN 98 header is interpreted, removed and data is passed on to the End 99 System. 101 There could be some scenarios like for case of OAM, where the network 102 element at originating VTEP needs to encapsulate some control 103 information for a given VXLAN segment, and this control information 104 needs to be analyzed and processed at the terminating VTEP for that 105 VXLAN segment. 107 This document defines a mechanism whereby Originating VTEP can add 108 additional information to the VXLAN header, based upon which the 109 Terminating VTEP can decide to analyze the payload under VXLAN 110 packet, rather then forwarding it to the destination End System. 112 2. Terminology 114 Terminology used in this document: 116 VXLAN: Virtual eXtensible Local Area Network. 118 VTEP: VXLAN Tunnel End Point. 120 VM: Virtual Machine. 122 End System: Could be VM etc. - System whose data is expected to go 123 over VXLAN Segment. 125 OAM: Operations, Administration, and Maintenance 127 Other terminologies are as defined in 128 [I-D.draft-mahalingam-dutt-dcops-vxlan]. 130 3. Approach 132 If the Originating VTEP decides to generate control informtaion, 133 which needs to go over a given VXLAN segment and if the Terminating 134 VTEP needs to analyze and process it, then following procedures have 135 to be followed at Originating and Terminating VTEP(s):- 137 3.1. Originating VTEP Procedure 139 When creating the VXLAN header for a given VXLAN segment, the 140 Originating VTEP MUST set Router Alert Bit in the Flag bits in VXLAN 141 header. The VNI for this frame MUST be the same as for the given 142 VXLAN segment which carries the data traffic of the End System. 144 VXLAN Header: 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 |R|R|R|R|I|R|R|RA| Reserved | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | VXLAN Network Identifier (VNI) | Reserved | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 RA: Router Alter Bit (Proposed) 153 3.2. Terminating VTEP Procedure 155 On receiving VXLAN frame, the Terminating VTEP would do the usual 156 VXLAN processing as defined in 157 [I-D.draft-mahalingam-dutt-dcops-vxlan], but if the RA Bit in Flags 158 is Set it MUST send the rest of the inner frame for further 159 processing to the above application. The details of the applications 160 and how it would process the inner frame is outside the scope of this 161 document. This frame MUST not be sent to the target End System. 163 4. Management Considerations 165 None 167 5. Security Considerations 169 TBD 171 6. Acknowledgements 173 The authors want to thank Diego Garcia Del Rio and Suresh Boddapati 174 of Nuage Networksfor significant contribution and feedback. 176 7. IANA Considerations 178 Router Alter Bit (RA): IANA is request to assing 1 Bit in Flags field 179 of VXLAN Header to communicate VXLAN Router Alert information. 181 8. References 183 8.1. Normative References 185 [I-D.draft-lasserre-nvo3-framework] 186 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 187 Rekhter, "Framework for DC Network Virtualization", 188 September 2011. 190 [I-D.draft-mahalingam-dutt-dcops-vxlan] 191 Mahalingam, M., Dutt, D., Agarwal, P., Kreeger, L., 192 Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 193 Framework for Overlaying Virtualized Layer 2 Networks 194 over Layer 3 Networks", May 2013. 196 8.2. Informative References 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, March 1997. 201 Authors' Addresses 203 Kanwar Singh 204 Nuage Networks. 205 755 Ravendale Drive 206 Mountain View, CA 94043 207 USA 209 Email: kanwar@nuagenetworks.net 211 Pradeep Jain 212 Nuage Networks. 213 755 Ravendale Drive 214 Mountain View, CA 94043 215 USA 217 Email: pradeep@nuagenetworks.net 219 Florin Balus 220 Nuage Networks. 221 755 Ravendale Drive 222 Mountain View, CA 94043 223 USA 225 Email: florin@nuagenetworks.net 227 Wim Henderickx 228 Alcatel-Lucent, Inc. 229 Copernicuslaan 50, 2018 230 ANTWERP 2018 231 BELGIUM 233 Email: Wim.Henderickx@alcatel-lucent.com