Internet DRAFT - draft-boutros-bess-evpn-auto-provisoning

draft-boutros-bess-evpn-auto-provisoning



 



INTERNET-DRAFT                                              Sami Boutros
Intended Status: Standard Track                                   VMware
                                                            Rex Fernando
                                                             Ali Sajassi
                                                           Cisco Systems

                                                              Kitty Pang
                                                                 Alibaba

                                                            Tapraj Singh
                                                                 Juniper

Expires: April 24, 2017                                 October 21, 2016


               EVPN auto provisioning using a controller 
              draft-boutros-bess-evpn-auto-provisoning-02


Abstract

   In some datacenter use cases, priori knowledge of what PE/NVE to be
   configured for a given L2 or L3 service may not be available. This
   document describes how EVPN can be extended to discover what L2 or L3
   services to be enabled on a given PE/NVE, based on first sign of life
   FSOL packets received on the PE/NVE ports. An EVPN route based on the
   FSOL packets will be sent to a controller to trigger a push of the
   related L2/L3 or subscriber service configuration to be provisioned
   on the PE/NVE and on the switch ports.

Status of this Memo

   This Internet-Draft is submitted to IETF 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/1id-abstracts.html

 


Boutros                  Expires April 24, 2017                 [Page 1]

INTERNET DRAFT           EVPN Auto provisioning         October 21, 2016


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License 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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Requirements  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1 Auto-Provisioning  . . . . . . . . . . . . . . . . . . . . .  3
     2.2 Scalability  . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.3 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.4 Multi-homing . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.5 Fast Convergence . . . . . . . . . . . . . . . . . . . . . .  4
   3. Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . .  4
   5 Ethernet Segment identifier encoding . . . . . . . . . . . . . .  6
   6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .  6
   7 Security Considerations  . . . . . . . . . . . . . . . . . . . .  6
   8  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     9.1  Normative References  . . . . . . . . . . . . . . . . . . .  7
     9.2  Informative References  . . . . . . . . . . . . . . . . . .  7
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7







 


Boutros                  Expires April 24, 2017                 [Page 2]

INTERNET DRAFT           EVPN Auto provisioning         October 21, 2016


1  Introduction

   This document describes how EVPN can be extended by access PE/NVE
   nodes and a controller in a data center to auto provision the L2 or
   L3 services needed to be enabled on the PE/NVE nodes.

   Initially, all the PE/NVE nodes are configured with a default EVPN
   service that includes all Ethernet access ports. Based on the FSOL
   packets received on any of the Ethernet trunk ports, an EVPN MAC/IP
   Advertisement route is sent to the controller containing the MAC and
   IP information associated with this FSOL packet. The ESI field of the
   route encodes both the Ethernet  port information as well as the
   Ethernet Tag associated with the FSOL packet.

   Once the controller receives the MAC/IP Advertisement route from the
   PE/NVE node, it consults a pre-configured policy for any L2 or L3
   services that need to be enabled on this PE/NVE node based on the
   information in the route. Any combination of fields encoded in the
   EVPN route may be used to that effect. If such service is required to
   be pushed to the PE/NVE node, the controller pushes the provisioning
   information to the access PE/NVE node and other PE/NVE nodes involved
   in this L2/L3 or subscriber service.

   The alternative is to configure every EVPN instance on all PE/NVEs
   and that poses a scale concern on the PE/NVEs deployed in the DC.


1.1  Terminology

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


2. Requirements

   This section describes the requirements specific to this draft. These
   requirements are in addition to the ones described in [EVPN-REQ],
   [EVPN], and [EVPN-VPWS].

2.1 Auto-Provisioning

   Auto provisioning of L2/L3 and subscriber services on PE/NVE nodes
   connected to a IP/MPLS fabric based on the FSOL packets received by
   the PE/NVE nodes.

2.2 Scalability

 


Boutros                  Expires April 24, 2017                 [Page 3]

INTERNET DRAFT           EVPN Auto provisioning         October 21, 2016


   A single controller node can provision many access PE/NVE nodes.

   A single controller node must be able to handle all EVPN routes
   received from all the access PE/NVE nodes that it is controlling.

2.3 Redundancy 

   TBD

2.4 Multi-homing

   TBD

2.5 Fast Convergence

   TBD


3. Benefits

   This section describes some of the major benefits of EVPN Auto-
   provisioning.

   Majors benefits are:

      - An easy and scalable mechanism for auto provisioning access 
        PE/NVE nodes connected to a DC fabric based on FSOL using
        EVPN control plane.

      - Auto-provision features such as QOS access lists (ACL), tunnel 
        preference, bandwidth, L3VPN, EVPN, etc.. based on the policy plane
        previously available to the controller.



4. Solution Overview 












 


Boutros                  Expires April 24, 2017                 [Page 4]

INTERNET DRAFT           EVPN Auto provisioning         October 21, 2016


      +----------+
      |Controller|
      +----------+

                             +---------+         
                             |         |          
      +-------+   +--------+ | IP/MPLS | +--------+   +-------+
      |Server1|---|access  |-| Access  |-|access  |---|Server2| 
      +-------+   |PE-1    | | Network | |PE-2    |   +-------+
                  +--------+ |         | +--------+        
                             +---------+         


   Figure 1: 

   EVPN-Auto provisioning Operation

   Initially all the access PE/NVE nodes trunk ports will be associated
   with a default bridge and will be associated with a default EVPN
   instance that all PE/NVE node(s) and the controller are part of.

   Based on FSOL packet received from Server1, an EVPN MAC/IP
   Advertisement route will be sent by PE-1 to the controller, the ESI
   value will be encoded to contain the access port number and the
   Ethernet Tag(s) associated with the FSOL packet, the IP and MAC
   fields will be set based on the source IP and MAC information on the
   FSOL packet.

   Assuming for example, an operator previously provisioned a policy to
   associate a VLAN identifier on a given PE or set of PE(s) with a L2
   or L3 service.

   An operator may as well have previously provisioned an IPoE, MAC
   session or an unclassified VLAN or MAC service associated on with a
   given port on the access PE/NVE.

   When the BGP EVPN advertisement is received by the controller, the
   controller checks the policy, and pushes down to the PE/NVE node or
   set of PE/NVE nodes(s) the L2/L3 or subscriber service to be
   provisioned on those access routers/switches.

   A controller may as well based on the type of service, do
   authentication and authorization of service first before pushing the
   configuration associated with the service to the access PE/NVE.

   When the service configured by the controller is an EVPN service, the
   provisioned access PE/NVE will advertise to other BGP Peers Inclusive
   Multicast route, the receiving PE/NVE(s) will check if an EVPN
 


Boutros                  Expires April 24, 2017                 [Page 5]

INTERNET DRAFT           EVPN Auto provisioning         October 21, 2016


   service/EVI is configured with same RT or not. If the service is not
   configured with received RT the receiving PE may send the received
   Inclusive Mcast route to the controller. The Inclusive Mcast route
   may have the Ethernet Tag field set. Upon receiving the Inclusive
   Mcast route a controller may do authentication and authorization
   service and may push service configuration associated with the
   service to the PE/NVE. 

   Please note that controller's capability is outside of the scope of
   this draft.

5 Ethernet Segment identifier encoding

   This document proposes a new ESI type to encode the Ethernet port on
   which the FSOL packet was received, and the Ethernet Tag(s) that are
   encoded on the FSOL packet.


                  +---+---+---+---+---+---+---+---+---+---+
                  | T |          ESI Value                |
                  +---+---+---+---+---+---+---+---+---+---+

   The ESI 9 octets value will be as follow:


                  +---+---+---+---+---+---+---+---+---+---+
                  | T |Ethernet Port #|Vlan-1 |Vlan-2 |0's|
                  +---+---+---+---+---+---+---+---+---+---+


   Ethernet Port number encoded on the 1st 4 bytes, this Ethernet port
   number will be used on the controller to infer the actual physical
   port on the access node/router.

   The Vlan-1 and Vlan-2 values are used to encode the Ethernet Tag
   identifiers found on the FSOL packet received on the Ethernet port.

6 Acknowledgements

   The authors would like to thank Samer Salam for his valuable
   comments.

7 Security Considerations

   This document does not introduce any additional security constraints.

8  IANA Considerations

 


Boutros                  Expires April 24, 2017                 [Page 6]

INTERNET DRAFT           EVPN Auto provisioning         October 21, 2016


   New ESI type need to be allocated to specify the encoding in section
   5.

9  References

9.1  Normative References

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

9.2  Informative References

   [RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet
   VPN".

   [EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet
   VPN", draft-ietf-l2vpn-evpn-11.txt.

   [EVPN-VPWS] S. Boutros et. al., "EVPN-VPWS", draft-ietf-bess-evpn-
   vpws-00.txt.


Authors' Addresses


   Sami Boutros
   VMware 
   Email: sboutros@vmware.com

   Rex Fernando
   Cisco
   Email: rex@cisco.com

   Ali Sajassi
   Cisco
   Email: sajassi@cisco.com

   Kitty Pang
   Alibaba
   Email: kittypang@alibaba-inc.com

   Tapraj Singh
   Juniper
   Email: tsingh@juniper.net







Boutros                  Expires April 24, 2017                 [Page 7]