idnits 2.17.1 draft-rabadan-bess-vendor-evpn-route-06.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 is 1 instance 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 19, 2018) is 2015 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet Draft M. Vigoureux 4 Intended status: Standards Track M. Gautam 5 Nokia 7 S. Dindorkar 8 Nuage Networks 10 Expires: April 22, 2019 October 19, 2018 12 EVPN Vendor-Specific Route Type 13 draft-rabadan-bess-vendor-evpn-route-06 15 Abstract 17 RFC7432 defines Ethernet VPN as a BGP address family that makes use 18 of Typed NLRIs. IANA has a registry called "EVPN Route Types" that 19 allocates values to Route Types. The purpose of this document is to 20 solicit IANA the registration of a route type value for a vendor 21 specific usage, as well as the definition of the EVPN NLRI for that 22 route. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on April 22, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. The EVPN Vendor-Specific Route Type . . . . . . . . . . . . . . 3 65 3. Conventions used in this document . . . . . . . . . . . . . . . 4 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 4 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 71 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5 73 1. Introduction 75 RFC7432 creates an IANA managed registry called "EVPN Route Types" 76 and makes the initial registrations for different NLRIs. The ability 77 to define Typed NLRIs makes EVPN a flexible and extensible technology 78 that can be used for multiple purposes. This document solicits the 79 value 255 for a new Route Type that will be called "EVPN Vendor 80 Specific" Route Type. 82 The intend of this new Type is to allow operators and vendors to 83 design rapidly new EVPN applications/prototypes and experiment with 84 them in deployed networks before standardizing the specific 85 application. Software Defined Networks (SDN) are evolving fast and 86 the flexibility allowed by this new Route Type will contribute to the 87 SDN control plane evolution. 89 Another motivation for this new Route Type is the exchange of vendor 90 specific information that may be relevant only for the vendor using 91 it. Other vendors may convey the information in a different way, or 92 they simply don't need to exchange it. 94 In order to allow multiple applications, the new NLRI contains a 95 Organizational Unique Identifier (OUI) field for which the IEEE 96 registers and maintains values. 98 2. The EVPN Vendor-Specific Route Type 100 [RFC7432] defines the EVPN NLRI with the following format: 102 +-----------------------------------+ 103 | Route Type (1 octet) | 104 +-----------------------------------+ 105 | Length (1 octet) | 106 +-----------------------------------+ 107 | Route Type specific (variable) | 108 +-----------------------------------+ 110 Where Route Type can be a value between 0 and 255. IANA maintains a 111 registry called "EVPN Route Types" where the different values are 112 assigned. This document solicits a new Route Type with value 255. 114 When the Route Type field includes the value 255, the Route Type 115 specific field will include the following information: 117 +--------------------------------------------+ 118 | Route Distinguisher (RD) (8 octets) | 119 +--------------------------------------------+ 120 | Organizational Unique Id (OUI) (3 octets) | 121 +--------------------------------------------+ 122 | Vendor Key Length (1 octet) | 123 +--------------------------------------------+ 124 | Vendor Specific Key | 125 | (variable) | 126 +--------------------------------------------+ 127 | Vendor Specific | 128 | Information (variable) | 129 +--------------------------------------------+ 131 Where OUI, Vendor Key Length and Vendor Specific Key are considered 132 part of the route key for BGP processing. The Vendor Key Length field 133 indicates the length in octets of the Vendor Specific Key field of 134 the NLRI. 136 The OUI values are owned and assigned by the IEEE Registration 137 Authority. 139 As per [RFC7606] section 5.4, a BGP speaker advertising support for 140 EVPN address family MUST handle routes with unrecognized NLRI types 141 within that address family by discarding them unless the relevant 142 specification for that address family specifies otherwise. However, a 143 BGP speaker supporting this new Route Type MUST accept the route even 144 if the OUI and Vendor fields are unrecognized. Specifically, a Route 145 Reflector MUST forward this new route type to its BGP peers, even if 146 the receiver does not understand or cannot process the route. 148 3. Conventions used in this document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in 153 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 4. Security Considerations 158 The relevant Security Considerations described in [RFC7432] apply to 159 the new Route Type defined in this document. 161 5. IANA Considerations 163 IANA is requested to allocate a new value in the "EVPN Route Types" 164 registry: 166 255 EVPN Vendor Specific [This document] 168 6. References 170 6.1 Normative References 172 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 173 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 174 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 175 . 177 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 179 Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, 180 DOI 10.17487/RFC7606, August 2015, . 183 [RFC7606] Chen E., Ed., Scudder J., Mohapatra P. and Patel K., 184 "Revised Error Handling for BGP UPDATE Messages", RFC 7606, August 185 2015, . 187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 189 1997, . 191 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 192 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 193 . 195 7. Acknowledgments 197 The authors want to thank Suresh Boddapati and Senthil Sathappan for 198 their ideas and contributions. 200 8. Authors' Addresses 202 Jorge Rabadan 203 Nokia 204 777 E. Middlefield Road 205 Mountain View, CA 94043 USA 206 Email: jorge.rabadan@nokia.com 208 Martin Vigoureux 209 Nokia 210 Email: martin.vigoureux@nokia.com 212 Siddhesh Dindorkar 213 Nuage Networks 214 Email: siddhesh.dindorkar@nuagenetworks.net 216 Mallika Gautam 217 Nokia 218 Email: mallika.gautam@nokia.com