Skip to main content

EVPN Venfor-Specific Route Type
draft-rabadan-bess-vendor-evpn-route-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Jorge Rabadan , Martin Vigoureux , Mallika Gautam , Siddhesh Dindorkar
Last updated 2016-09-19
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-rabadan-bess-vendor-evpn-route-01
BESS Workgroup                                           J. Rabadan, Ed.
Internet Draft                                              M. Vigoureux
Intended status: Standards Track                               M. Gautam
                                                                   Nokia

                                                            S. Dindorkar
                                                          Nuage Networks

Expires: March 23, 2017                               September 19, 2016

                    EVPN Venfor-Specific Route Type
                draft-rabadan-bess-vendor-evpn-route-01

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 March 23, 2017                 [Page 1]
Internet-Draft      EVPN Vendor Specific Route Type   September 19, 2016

   This Internet-Draft will expire on March 23, 2017.

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 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 March 23, 2017                 [Page 2]
Internet-Draft      EVPN Vendor Specific Route Type   September 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 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 March 23, 2017                 [Page 3]
Internet-Draft      EVPN Vendor Specific Route Type   September 19, 2016

   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", "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

 

Rabadan et al.           Expires March 23, 2017                 [Page 4]
Internet-Draft      EVPN Vendor Specific Route Type   September 19, 2016

   [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, <http://www.rfc-
   editor.org/info/rfc7432>.

   [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>.

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 March 23, 2017                 [Page 5]