A Control Plane for Network Virtualized Overlays
draft-drake-nvo3-evpn-control-plane-00

Versions: 00                                                            
Network Working Group
Internet-Draft                                                 T. Nadeau
Intended status: Standards Track                                J. Drake
Expires: March 16, 2013                                          Editors
                                                        Juniper Networks

                                                            B. Schlisser
James Uttaro                                                  Y. Rekhter
ATT                                                         Ravi Shekhar
                                                        Juniper Networks

Wim Hendrix                                                  Nabil Bitar
Alcatel-Lucent                                                   Verizon

                                                            Aldrin Isaac
                                                               Bloomberg

                                                      September 16, 2012


            A Control Plane for Network Virtualized Overlays
                  draft-drake-nvo3-evpn-control-plane-00

Abstract

        The purpose of this document is to describe how Ethernet Virtual
        Private Network (E-VPN) can be used as the control plane for
        Network Virtual Overlays.  Currently this protocol is defined to
        act as the control plane for Virtual Extensible Local Area
        Network (VXLAN), Network Virtualization using Generic Routing
        Encapsulation (NVGRE), MPLS or VLANs while maintaining their
        existing data plane encapsulations. The intent is that this
        protocol will be capable of extensions in the future to handle
        additinal data plane encapsulations and functions as needed.


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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on November March 16, 2012.



Nadeau & Drake, Editors        Expires March 14, 2013        [Page 1]


                 EVPN Control Plane                September 14, 2012












Copyright Notice

   Copyright (c) 2012 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.

Requirements Language

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


Table of Contents
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
   1.2.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . .
   2.  E-VPN Attributes . . . . . . . . . . . . . . . . . . . . . . .
   3.  Constructing E-VPN routes  . . . . . . . . . . . . . . . . . .
   4.  Interworking Capabilities  . . . . . . . . . . . . . . . . . .
   5. Active/Active Multihoming   . . . . . . . . . . . . . . . . . .
   6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . .
   6.1. P-Tunnel Identification . . . . . . . . . . . . . . . . . . .
   6.2. Ingress Replication . . . . . . . . . . . . . . . . . . . . .
   6.3. PIM-SSM/SM Tree . . . . . . . . . . . . . . . . . . . . . . .
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .
   8. Security Considerations   . . . . . . . . . . . . . . . . . . .
   9. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .
   10. References   . . . . . . . . . . . . . . . . . . . . . . . . .
    10.1. Normative References  . . . . . . . . . . . . . . . . . . .
    10.2. Informative References  . . . . . . . . . . . . . . . . . .



Nadeau & Drake, Editors        Expires March 14, 2013        [Page 2]


                 EVPN Control Plane                September 14, 2012






1.  Introduction

        The purpose of this document is to describe a single control
        plane protocol control protocol that can be used for all
        types of data planes used in network virtualization overlays
        (NVOs).  In particular, we describe how The Ethernet Virtual
        Private Network (E-VPN) protocol, as described in
        [I-D.draft-ietf-l2vpn-evpn-01], can be
        used as the control plane for Virtual Extensible Local
        Area Network (VXLAN) [I-D.draft-mahalingam-dutt-dcops-vxlan],
        Network Virtualization using Generic Routing Encapsulation
        (NVGRE) [I-D.draft-sridharan-virtualization-nvgre-00], MPLS or
        Ethernet VLANs. In all cases, the existing data plane
        encapsulations are maintained.

        Network Virtualization Overlays (NVOs), as described in
        [I-D.draft-ietf-nvo3-overlay-problem-statement], are intended
        to provide separate logical tenant networks over a common
        physical infrastructure in a data center environment.

        Both VXLAN and NVGRE are examples of technologies provide
        a data plane encapsulation which is used to transport a
        packet over the common physical infrastructure between
        NVO endpoints.


1.2.  Acronyms


   CE      Customer Edge.

   OAM     Operation and Maintenance.

   PE      Provider Edge.

   NVE     Network Virtualization Endpoint

   NVGRE   Network Virtualization Using Generic Routing Encapsulation

   NVO     Network Virtual Overlay

   VNE     Virtual Network Identifier

   VTEP    VXLAN Tunnel End Point




Nadeau & Drake, Editors        Expires March 14, 2013        [Page 3]


                 EVPN Control Plane                September 14, 2012



   VXLAN   Virtual Extensible Local Area Network


2. E-VPN Attributes

      Both VXLAN and NVGRE are examples of technologies provide
      a data plane encapsulation which is used to transport a
      packet over the common physical infrastructure between
      NVO endpoints, VXLAN Tunnel End Point (VTEP) in VXLAN and
      Network Virtualization Endpoint (NVE) in NVGRE. Both of
      these technologies include the identifier of the specific
      NVO instance, Virtual Network Identifier (VNI) in VXLAN
      and Tenant ID in NVGRE, in each packet.

      E-VPN was originally designed to support the requirements
      detailed in [I-D.draft-ietf-l2vpn-evpn-req] and therefore has
      the following attributes which directly address control plane
      scaling and ease of deployment issues.

      1)  Control plane traffic is distributed with BGP and Broadcast
          and Multicast traffic is sent using a shared multicast tree
          or with ingress replication.

      2)  Control plane learning is used instead flooding unknown
          unicast and ARP packets.

      3)  Auto-discovery via BGP Route Reflectors is used.

      4)  Active-active multihoming is used.  This allows a given
          customer device to have multiple attachment links to an
          E-VPN instance (EVI), via a Link Aggregation Group (LAG).
          This allows traffic to/from that customer to fully utilize
          all of these links.  The set of attachment links to a given
          customer device is termed an Ethernet Segment and is
          typically identified with that customer device's MAC address.

      5)  Block withdraw is used.  When a link between a customer
          device and an EVI fails, the other nodes in the EVI are
          notified via the withdrawal of a single E-VPN route
          regardless of how many MAC addresses are located at the
          customer device.

      6)  Route filtering and constrained route distribution are
          used to ensure that the control plane traffic for a given
          EVI is only distributed to those nodes in that EVI.

      7)  The internal identifier of a broadcast domain, the Ethernet
          Tag, is a 32 bit number, which is mapped into whatever



Nadeau & Drake, Editors        Expires March 14, 2013        [Page 4]


                 EVPN Control Plane                September 14, 2012



          broadcast domain identifier, e.g., VLAN ID, is understood
          by the attaching CE device.  This means that there are up
          to 4096 distinct VLAN IDs for each attaching Customer Edge
          (CE) device in a given EVI.

          Note that an EVI is equivalent to an NVO instance and that a
          Provider Edge (PE) is equivalent to a VTEP/NVE.

      8)  Because the design goal for NVO is millions of instances
          per common physical infrastructure, the scaling properties
          of the control plane for NVO are extremely important. The
          E-VPN and the extensions described herein, are designed
          with this level of scalability in mind.

3.   Constructing E-VPN routes

     In E-VPN an MPLS label distributed by the egress PE via the E-VPN
     control plane and placed in the MPLS header of a given packet by
     the ingress PE is used upon receipt of that packet by the egress
     PE to determine to which EVI that packet is to be sent.  This is
     very similar to the use of the VNI or Tenant ID by the egress
     VTEP or NVE, respectively, with the difference being that an
     MPLS label has local significance and is distributed by the
     E-VPN control plane, while a VNI or Tenant ID currently has
     global significance.

     In E-VPN, an MPLS label is carried in a three octet MPLS Label
     field, and consists of the twenty bit label.  Both the VNI and
     Tenant ID are also three octets in length and so could be
     transparently carried in the MPLS label field of the E-VPN MAC
     Advertisement or Per EVI Ethernet AD route.

     This memo specifies that when E-VPN is to be used with a VXLAN or
     NVGRE data plane that a VNI or Tenant ID is twenty bits in
     length and may have either global or local significance, that
     the remaining four bits are reserved, and that the value
     advertised in the MPLS label field is to be treated as a three
     octet quantity to be placed directly in the VNI or tenant ID
     field of a packet.

     Note that because in this context an advertised VNI or Tenant
     ID may have local significance, the advertising PE may
     transparently use it to represent the VN or Tenant, a set of
     addresses within the VN or Tenant, or an individual address
     within the VN or Tenant.

     In order to indicate that a VXLAN or NVGRE data plane
     encapsulation rather than MPLS label stack encapsulation is to



Nadeau & Drake, Editors        Expires March 14, 2013        [Page 5]


                 EVPN Control Plane                September 14, 2012



     be used, the Tunnel Encapsulation attribute defined in [RFC5512]
     is included with E-VPN MAC Advertisement or Per EVI Ethernet AD
     routes advertised by an egress PE.  Two new values, one for
     VXLAN and one for NVGRE, will be defined.  This same mechanism
     should be used to advertise MPLS or VLAN encapsulations when
     they are used.

4.  Interworking Capabilities

    Through the presence of the Tunnel Encapsulation attribute, each
    PE within a given EVI will know whether the other PEs in that EVI
    support MPLS label stack, VXLAN, or NVGRE data plane encapsulation.

    This means that a given EVI can support multiple data plane
    encapsulations. This has the advantage of allowing
    interoperability between VXLAN, NVGRE, and E-VPN (and by
    extension L3VPNs).

    Note that an ingress PE must use the data plane encapsulation
    specified by a given egress PE in the subject MAC Advertisement
    or Per EVI Ethernet AD route when sending a packet to that PE.
    Further, an ingress node that uses shared multicast trees for
    sending Broadcast and Multicast traffic must maintain distinct
    trees for each different encapsulation type.


5. Active/Active Multihoming

   The base E-VPN protocol supports active/active multihoming.  In
   order to prevent loops of Broadcast and Multicast packets, these
   packets need to carry two labels, one to identify the EVI to which
   the packet should be sent and one to identify the Ethernet Segment
   from which it was received.  The latter label is termed the 'split
   horizon label' and when a Broadcast or Multicast packet is received
   by an egress PE, it uses that label to stop it from sending the
   packet back to the Ethernet Segment from which the packet was
   received.

   When using the VXLAN or NVGRE encapsulation, there is no field in
   the packet in which to carry the split horizon label.

   This memo specifies that an egress PE must use the sender MAC
   address to determine whether to send a received Broadcast or
   Multicast packet to a given Ethernet Segment.  I.e., if the sender
   MAC address is associated with a given Ethernet Segment, the egress
   PE must not send the packet to that Ethernet Segment.





Nadeau & Drake, Editors        Expires March 14, 2013        [Page 6]


                 EVPN Control Plane                September 14, 2012



6. Multicast

   The base E-VPN protocol allows to use MPLS ingress replication or
   P2MP LSPs to send BUM traffic to other PEs. When VXLAN/NVGRE
   encapsulations are used with E-VPN, IP based ingress replication
   and IP multicast trees must be supported.

6.1. P-Tunnel Identification

   In order to identify the P-Tunnel used for sending broadcast,
   unknown unicast or multicast traffic, the Inclusive Multicast
   Ethernet Tag route MUST carry a "PMSI Tunnel Attribute" as
   specified in [RFC6513]. The following changes are required for
   VXLAN/NVGRE

        + When a PE that uses a P-Multicast tree for the P-tunnel
          wants to aggregate two or more Ethernet Tags in the same or
          different EVIs present on the PE onto the same tree. In this
          case, in addition to carrying the identity of the tree, the
          PMSI Tunnel attribute MUST carry a upstream assigned VNI or
          tenant ID in the MPLS Label field of the PMSI attribute
          which the PE has bound uniquely to the Ethernet Tag for the
          EVI associated with this update (as determined by its RTs).

        + If the PE that originates the advertisement uses ingress
          replication for the P-tunnel for E-VPN, the route MUST
          include the PMSI Tunnel attribute with the Tunnel Type set to
          Ingress Replication and Tunnel Identifier set to a routable
          address of the PE. The PMSI Tunnel attribute MUST carry a
          downstream assigned VNI or tenant ID in the MPLS Label
          field of the PMSI attribute. This identifier is used to
          demultiplex the broadcast, multicast or unknown unicast E-VPN
          traffic received over a MP2P tunnel by the PE.

        + If the PE that originates the advertisement uses IP
          multicast replication for the P-tunnel for E-VPN, the
          route MUST include the PMSI Tunnel attribute with the
          Tunnel Type set to PIM-SSM or PIM ASM Tree.

          When the Tunnel Type is set to Protocol
          Independent Multicast - Sparse Mode (PIM-SM) tree, the
          Tunnel Identifier is <Sender Address, P-Multicast Group>.
          The node that originated the attribute MUST use the address
          carried in the Sender Address as the source IP address for
          the IP/GRE (NVGRE) or IP/UDP (VXLAN) encapsulation of the
          BUM data.

          When the Tunnel Type is set to PIM-SSM tree, the Tunnel



Nadeau & Drake, Editors        Expires March 14, 2013        [Page 7]


                 EVPN Control Plane                September 14, 2012



          Identifier is <P-Root Node Address, P-Multicast Group>.  The
          node that originates the attribute MUST use the address
          carried in the P-Root Node Address as the source IP address
          for the IP/GRE (NVGRE) or IP/UDP (VXLAN) encapsulation of
          the BUM data.

          According to [RFC4607], the group address can be locally
          allocated by the originating PE without any consideration
          for the group address used by other PE on the same MVPN.

6.2. Ingress Replication

   The PEs may use ingress replication for flooding unknown unicast,
   multicast or broadcast traffic. The VXLAN or NVGRE encapsulations
   are used with the VNI or tenant ID exchanged in the I-PMSI PMSI
   attribute.

6.3. PIM-SSM/SM Tree

   An PE may use an IP multicast "Inclusive" tree for sending an
   unknown unicast, broadcast or multicast packet or a "Selective"
   tree. For VXLAN or NVGRE the destination address of the UDP/GRE
   encapsulations use the multicast address of the PMSI attribute in
   the Inclusive Multicast Ethernet Tag route. When no aggregated
   trees are used the VNI or tenant ID is set to 0.


7.  IANA Considerations

   4.1  E-VPN Encapsulation Types

       IANA is requested to assign two values from the "BGP Tunnel
       Encapsulation Attribute Tunnel Types" registry [RFC5512] as
       follows.

       - VxLan: Tunnel Type = TBD

       - NVGRE: Tunnel Type = TBD +1


8.  Security Considerations

   This document uses IP-based tunnel technologies to support data
   plane transport.  Consequently, the security considerations of
   those tunnel technologies apply.  This document defines support
   for VxLan [I-D.draft-mahalingam-dutt-dcops-vxlan] and
   NVGRE [I-D.draft-sridharan-virtualization-nvgre-00].
   The security considerations from those documents as well as



Nadeau & Drake, Editors        Expires March 14, 2013        [Page 8]


                 EVPN Control Plane                September 14, 2012



   [RFC4301] apply to the data plane aspects of this document.

   As with [RFC5512], any modification of the information that is used
   to form encapsulation headers, to choose a tunnel type, or to choose
   a particular tunnel for a particular payload type may lead to user
   data packets getting misrouted, misdelivered, and/or dropped.

   More broadly, the security considerations for the transport of IP
   reachability information using BGP are discussed in [RFC4271] and
   [RFC4272], and are equally applicable for the extensions described
   in this document.

   If the integrity of the BGP session is not itself protected, then an
   imposter could mount a denial-of-service attack by establishing
   numerous BGP sessions and forcing an IPsec SA to be created for each
   one.  However, as such an imposter could wreak havoc on the entire
   routing system, this particular sort of attack is probably not of
   any special importance.

   It should be noted that a BGP session may itself be transported over
   an IPsec tunnel.  Such IPsec tunnels can provide additional security
   to a BGP session.  The management of such IPsec tunnels is outside
   the scope of this document.



9.  Acknowledgements

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March

   [RFC4271]  Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.,
              "A Border Gateway Protocol 4 (BGP-4)", January 2006.

   [RFC4272]  S. Murphy, "BGP Security Vulnerabilities Analysis.",
              January 2006.

   [RFC4301]   S. Kent, K. Seo., "Security Architecture for the
               Internet Protocol.", December 2005.

   [RFC4607]  H. Holbrook, B. Cain., "Source-Specific Multicast for
              IP.", RFC4607, August 2006.

   [RFC5512]  Mohapatra, P. and E. Rosen, "The BGP Encapsulation



Nadeau & Drake, Editors        Expires March 14, 2013        [Page 9]


                 EVPN Control Plane                September 14, 2012



              Subsequent Address Family Identifier (SAFI) and the BGP
              Tunnel Encapsulation Attribute", RFC 5512, April 2009.


   [RFC6513]  Rosen, E., et al., "Multicast in MPLS/BGP IP VPNs.",
              RFC6513, February 2012.

   [I-D.draft-ietf-l2vpn-evpn] Aggarwal et al., "BGP MPLS Based
               Ethernet VPN",
               draft-raggarwa-sajassi-l2vpn-evpn-02.txt, work in
               progress, March, 2011.

   [I-D.draft-sridharan-virtualization-nvgre-00]   Sridhavan, M., et
               al., "NVGRE: Network Virtualization using Generic
               Routing Encapsulation",
               draft-sridharan-virtualization-nvgre-01.txt, July 8,
               2012.

   [I-D.draft-mahalingam-dutt-dcops-vxlan] Dutt, D., et al,
               "VXLAN: A Framework for Overlaying Virtualized Layer 2
                Networks over Layer 3 Networks",
                draft-mahalingam-dutt-dcops-vxlan-02.txt,
                August 22, 2012.

   [I-D.draft-ietf-nvo3-overlay-problem-statement] Narten, et al,
               "Problem Statement: Overlays for Network
                Virtualization",
                draft-ietf-nvo3-overlay-problem-statement-00.txt,
                5-Sep-12.

   [I-D.draft-ietf-l2vpn-evpn-req] Sajassi et al., "Requirements for
               Ethernet VPN (E-VPN)", draft-ietf-l2vpn-l2vpn-evpn-
               req-00.txt, work in progress,
               March 27, 2012.



10.2.  Informative References


   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing
              an IANA Considerations Section in RFCs", BCP 26,
              RFC 5226, May 2008.

   [I-D.lasserre-nvo3-framework]
              Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
              Rekhter, "Framework for DC Network Virtualization",
              draft-lasserre-nvo3-framework-03 (work in progress),



Nadeau & Drake, Editors        Expires March 14, 2013       [Page 10]


                 EVPN Control Plane                September 14, 2012



              July 2012.



Editors' Addresses

   Thomas D. Nadeau
   Juniper Networks
   Email: tnadeau@juniper.net

   John E. Drake
   Juniper Networks
   Email: jnadeau@juniper.net

 Authors' Addresses

   Benson Schliser
   Juniper Networks
   Email: bensons@juniper.net

   Yakov Reckhter
   Juniper Networks
   Email: yakov@juniper.net

   Nabil Bitar
   Verizon Communications
   Email : nabil.n.bitar@verizon.com

   Ravi Shekhar
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089 US
   Email: rshekhar@juniper.net

   Aldrin Isaac
   Bloomberg
   aldrin.isaac@gmail.com

   Wim Henderickx
   Alcatel-Lucent
   e-mail: wim.henderickx@alcatel-lucent.com

   James Uttaro
   AT&T
   200 S. Laurel Avenue
   Middletown, NJ  07748
   USA
   Email: uttaro@att.com



Nadeau & Drake, Editors        Expires March 14, 2013       [Page 11]


                 EVPN Control Plane                September 14, 2012






















































Nadeau & Drake, Editors        Expires March 14, 2013       [Page 12]