idnits 2.17.1 draft-rodrigueznatal-lisp-vendor-lcaf-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 'SHOULD not' in this paragraph: The Vendor Specific LCAF type SHOULD not be used in deployments where different organizations interoperate. If a LISP device receives a LISP message containing an Vendor Specific LCAF with and OUI it does not understand, it SHOULD drop the message and a log action MUST be taken. -- The document date (July 3, 2017) is 2483 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 143, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group A. Rodriguez-Natal 3 Internet-Draft V. Ermagan 4 Intended status: Experimental A. Smirnov 5 Expires: January 4, 2018 V. Ashtaputre 6 Cisco Systems 7 D. Farinacci 8 lispers.net 9 July 3, 2017 11 Vendor Specific LCAF 12 draft-rodrigueznatal-lisp-vendor-lcaf-00 14 Abstract 16 This document describes a new LCAF for LISP, the Vendor Specific 17 LCAF. This LCAF enables organizations to have internal encodings for 18 LCAF addresses. 20 Status of This Memo 22 This Internet-Draft is submitted 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 4, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Vendor Specific LCAF . . . . . . . . . . . . . . . . . . . . 2 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 6. Normative References . . . . . . . . . . . . . . . . . . . . 3 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 62 1. Introduction 64 The LISP Canonical Address Format [RFC8060] defines the format and 65 encoding for different address types that can be used on LISP 66 [RFC6830] deployments. However, certain deployments require specific 67 format encodings that may not be applicable outside of the use-case 68 for which they are defined. The Vendor Specific LCAF allows 69 organizations to create LCAF addresses to be internally-only used on 70 particular LISP deployments. 72 2. Vendor Specific LCAF 74 The Vendor Specific LCAF relies on using the IEEE Organizationally 75 Unique Identifier (OUI) [IEEE.802_2001] to prevent collisions across 76 vendors or organizations using the LCAF. The format of the Vendor 77 Specific LCAF is provided below. 79 0 1 2 3 80 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | AFI = 16387 | Rsvd1 | Flags | 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 | Type = 255 | Rsvd2 | Length | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | Rsvd3 | Organizationally Unique Identifier (OUI) | 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | Internal format... | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 Vendor Specific LCAF 93 The Vendor Specific LCAF has the following fields. 95 Rsvd3: This 8-bit field is reserved for future use. It MUST be 96 set to 0 on transmit and MUST be ignored on receipt. 98 Organizationally Unique Identifier (OUI): This is a 24-bit field 99 that carries the IEEE OUI [IEEE.802_2001] of the organization. 101 Internal format: This is a variable length field that is left 102 undefined on purpose. Each vendor or organization can define its 103 own internal format(s) to use with the Vendor Specific LCAF. 105 The definition for the rest of the fields can be found in [RFC8060]. 107 The Vendor Specific LCAF type SHOULD not be used in deployments where 108 different organizations interoperate. If a LISP device receives a 109 LISP message containing an Vendor Specific LCAF with and OUI it does 110 not understand, it SHOULD drop the message and a log action MUST be 111 taken. 113 3. Security Considerations 115 TBD. 117 4. Acknowledgments 119 TBD. 121 5. IANA Considerations 123 Following the guidelines of [RFC5226], this document requests IANA to 124 update the "LISP Canonical Address Format (LCAF) Types" Registry 125 defined in [RFC8060] to allocate the following assignment: 127 +---------+---------------------+-----------+ 128 | Value # | LISP LCAF Type Name | Reference | 129 +---------+---------------------+-----------+ 130 | 255 | Vendor Specific | Section 2 | 131 +---------+---------------------+-----------+ 133 Table 1: Vendor Specific LCAF assignment 135 6. Normative References 137 [IEEE.802_2001] 138 IEEE, "IEEE Standard for Local and Metropolitan Area 139 Networks: Overview and Architecture", IEEE 802-2001, 140 DOI 10.1109/ieeestd.2002.93395, July 2002, 141 . 143 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 144 Requirement Levels", BCP 14, RFC 2119, 145 DOI 10.17487/RFC2119, March 1997, 146 . 148 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 149 IANA Considerations Section in RFCs", RFC 5226, 150 DOI 10.17487/RFC5226, May 2008, 151 . 153 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 154 Locator/ID Separation Protocol (LISP)", RFC 6830, 155 DOI 10.17487/RFC6830, January 2013, 156 . 158 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 159 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 160 February 2017, . 162 Authors' Addresses 164 Alberto Rodriguez-Natal 165 Cisco Systems 166 170 Tasman Drive 167 San Jose, CA 168 USA 170 Email: natal@cisco.com 172 Vina Ermagan 173 Cisco Systems 174 170 Tasman Drive 175 San Jose, CA 176 USA 178 Email: vermagan@cisco.com 180 Anton Smirnov 181 Cisco Systems 182 170 Tasman Drive 183 San Jose, CA 184 USA 186 Email: asmirnov@cisco.com 187 Vrushali Ashtaputre 188 Cisco Systems 189 170 Tasman Drive 190 San Jose, CA 191 USA 193 Email: vrushali@cisco.com 195 Dino Farinacci 196 lispers.net 197 San Jose, CA 198 USA 200 Email: farinacci@gmail.com