BESS Workgroup J. Rabadan, Ed. Internet Draft M. Vigoureux Intended status: Standards Track M. Gautam Nokia S. Dindorkar Nuage Networks Expires: September 20, 2016 March 19, 2016 EVPN Generic Route Type draft-rabadan-bess-vendor-evpn-route-00 Abstract RFC7432 defines Ethernet VPN as a BGP address family that makes use of Typed NLRIs. IANA has a registry called "EVPN Route Types" that allocates values to Route Types. The purpose of this document is to solicit IANA the registration of a route type value for a vendor specific usage, as well as the definition of the EVPN NLRI for that route. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Rabadan et al. Expires September 20, 2016 [Page 1] Internet-Draft EVPN Vendor Specific Route Type March 19, 2016 This Internet-Draft will expire on September 20, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The EVPN Generic Route Type . . . . . . . . . . . . . . . . . . 3 3. Conventions used in this document . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction RFC7432 creates an IANA managed registry called "EVPN Route Types" and makes the initial registrations for different NLRIs. The ability to define Typed NLRIs makes EVPN a flexible and extensible technology that can be used for multiple purposes. This document solicits the value 255 for a new Route Type that will be called "EVPN Vendor Specific" Route Type. The intend of this new Type is to allow operators and vendors to design rapidly new EVPN applications/prototypes and experiment with them in deployed networks before standardizing the specific application. Software Defined Networks (SDN) are evolving fast and the flexibility allowed by this new Route Type will contribute to the SDN control plane evolution. Rabadan et al. Expires September 20, 2016 [Page 2] Internet-Draft EVPN Vendor Specific Route Type March 19, 2016 Another motivation for this new Route Type is the exchange of vendor specific information that may be relevant only for the vendor using it. Other vendors may convey the information in a different way, or they simply don't need to exchange it. In order to allow multiple applications, the new NLRI contains a Organizational Unique Identifier (OUI) field for which the IEEE registers and maintains values. 2. The EVPN Generic Route Type [RFC7432] defines the EVPN NLRI with the following format: +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+ Where Route Type can be a value between 0 and 255. IANA maintains a registry called "EVPN Route Types" where the different values are assigned. This document solicits a new Route Type with value 255. When the Route Type field includes the value 255, the Route Type specific field will include the following information: +--------------------------------------------+ | Route Distinguisher (RD) (8 octets) | +--------------------------------------------+ | Organizational Unique Id (OUI) (3 octets) | +--------------------------------------------+ | Vendor Key Length (1 octet) | +--------------------------------------------+ | Vendor Specific Key | | (variable) | +--------------------------------------------+ | Vendor Specific | | Information (variable) | +--------------------------------------------+ Where Route Distinguisher, OUI, Vendor Key Length and Vendor Specific Key are considered part of the route key for BGP processing. The Vendor Key Length field indicates the length in octets of the Vendor Rabadan et al. Expires September 20, 2016 [Page 3] Internet-Draft EVPN Vendor Specific Route Type March 19, 2016 Specific Key field of the NLRI. The OUI values are owned and assigned by the IEEE Registration Authority. As per [RFC7606] section 5.4, a BGP speaker advertising support for EVPN address family MUST handle routes with unrecognized NLRI types within that address family by discarding them unless the relevant specification for that address family specifies otherwise. However, a BGP speaker supporting this new Route Type MUST accept the route even if the OUI and Vendor fields are unrecognized. 3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. 4. Security Considerations The relevant Security Considerations described in [RFC7432] apply to the new Route Type defined in this document. 5. IANA Considerations IANA is requested to allocate a new value in the "EVPN Route Types" registry: 255 EVPN Vendor Specific [This document] 6. References 6.1 Normative References [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Rabadan et al. Expires September 20, 2016 [Page 4] Internet-Draft EVPN Vendor Specific Route Type March 19, 2016 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC7606] Chen E., Ed., Scudder J., Mohapatra P. and Patel K., "Revised Error Handling for BGP UPDATE Messages", RFC 7606, August 2015, . 7. Acknowledgments The authors want to thank Suresh Boddapati and Senthil Sathappan for their ideas and contributions. 8. Authors' Addresses Jorge Rabadan Nokia 777 E. Middlefield Road Mountain View, CA 94043 USA Email: jorge.rabadan@nokia.com Martin Vigoureux Nokia Email: martin.vigoureux@nokia.com Siddhesh Dindorkar Nuage Networks Email: siddhesh.dindorkar@nuagenetworks.net Mallika Gautam Nokia Email: mallika.gautam@nokia.com Rabadan et al. Expires September 20, 2016 [Page 5]