Internet DRAFT - draft-rabadan-bess-vendor-evpn-route
draft-rabadan-bess-vendor-evpn-route
BESS Workgroup J. Rabadan, Ed.
Internet Draft M. Vigoureux
Intended status: Standards Track M. Gautam
Nokia
S. Dindorkar
Nuage Networks
Expires: October 23, 2019 April 21, 2019
EVPN Vendor-Specific Route Type
draft-rabadan-bess-vendor-evpn-route-07
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 October 23, 2019 [Page 1]
Internet-Draft EVPN Vendor Specific Route Type April 21, 2019
This Internet-Draft will expire on October 23, 2019.
Copyright Notice
Copyright (c) 2019 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 Vendor-Specific 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 October 23, 2019 [Page 2]
Internet-Draft EVPN Vendor Specific Route Type April 21, 2019
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 Vendor-Specific 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 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 Specific Key field of
Rabadan et al. Expires October 23, 2019 [Page 3]
Internet-Draft EVPN Vendor Specific Route Type April 21, 2019
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. Specifically, a Route
Reflector MUST forward this new route type to its BGP peers, even if
the receiver does not understand or cannot process the route.
3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015,
<https://www.rfc-editor.org/info/rfc7432>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Rabadan et al. Expires October 23, 2019 [Page 4]
Internet-Draft EVPN Vendor Specific Route Type April 21, 2019
Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606,
DOI 10.17487/RFC7606, August 2015, <https://www.rfc-
editor.org/info/rfc7606>.
[RFC7606] Chen E., Ed., Scudder J., Mohapatra P. and Patel K.,
"Revised Error Handling for BGP UPDATE Messages", RFC 7606, August
2015, <http://www.rfc-editor.org/info/rfc7606>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
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 October 23, 2019 [Page 5]
