idnits 2.17.1 draft-rabadan-bess-vendor-evpn-route-05.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 date (April 9, 2018) is 2181 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 153, but not defined 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: October 11, 2018 April 9, 2018 12 EVPN Vendor-Specific Route Type 13 draft-rabadan-bess-vendor-evpn-route-05 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 October 11, 2018. 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", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC-2119 [RFC2119]. 154 In this document, these words will appear with that interpretation 155 only when in ALL CAPS. Lower case uses of these words are not to be 156 interpreted as carrying RFC-2119 significance. 158 In this document, the characters ">>" preceding an indented line(s) 159 indicates a compliance requirement statement using the key words 160 listed above. This convention aids reviewers in quickly identifying 161 or finding the explicit compliance requirements of this RFC. 163 4. Security Considerations 165 The relevant Security Considerations described in [RFC7432] apply to 166 the new Route Type defined in this document. 168 5. IANA Considerations 170 IANA is requested to allocate a new value in the "EVPN Route Types" 171 registry: 173 255 EVPN Vendor Specific [This document] 175 6. References 177 6.1 Normative References 179 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 180 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 181 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 182 . 184 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 185 Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, 186 DOI 10.17487/RFC7606, August 2015, . 189 [RFC7606] Chen E., Ed., Scudder J., Mohapatra P. and Patel K., 190 "Revised Error Handling for BGP UPDATE Messages", RFC 7606, August 191 2015, . 193 7. Acknowledgments 195 The authors want to thank Suresh Boddapati and Senthil Sathappan for 196 their ideas and contributions. 198 8. Authors' Addresses 200 Jorge Rabadan 201 Nokia 202 777 E. Middlefield Road 203 Mountain View, CA 94043 USA 204 Email: jorge.rabadan@nokia.com 206 Martin Vigoureux 207 Nokia 208 Email: martin.vigoureux@nokia.com 210 Siddhesh Dindorkar 211 Nuage Networks 212 Email: siddhesh.dindorkar@nuagenetworks.net 214 Mallika Gautam 215 Nokia 216 Email: mallika.gautam@nokia.com