BESS Working Group                                          P. Brissette
Internet Draft                                              Cisco System
Intended Status: Proposed Standard                               H. Shah
Expires: June 4, 2016                                  Ciena Corporation
                                                                   Z. Li
                                                     Huawei Technologies
                                                                  A. liu
                                                                Ericsson
                                                         K. Tiruveedhula
                                                                T. Singh
                                                        Juniper Networks
                                                              I. Hussain
                                                    Infinera Corporation
                                                              J. Rabadan
                                                        December 2, 2015



                        Yang Data Model for EVPN
                   draft-brissette-bess-evpn-yang-01

Abstract

   This document describes a YANG data model for Ethernet VPN services.
   The model is agnostic of the underlay. It apply to MPLS as well as to
   VxLAN encapsulation. The model is also agnostic of the services
   including E-LAN, E-LINE and E-TREE services. The merging of this
   model with L2 services model is for future investigation. Any "add-
   on" features such as EVPN IRB, EVPN overlay, etc. are for future
   investigation. This document mainly focuses on EVPN instance
   framework.

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





Brissette, et. al         Expires June 4, 2016                  [Page 1]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

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


Copyright and License Notice

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

Convention

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2. Specification of Requirements . . . . . . . . . . . . . . . . .  5
   3. EVPN YANG Model . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2 Ethernet-Segment Model . . . . . . . . . . . . . . . . . . .  6
     3.3 EVPN Model . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1 Ethernet Segment Yang Module . . . . . . . . . . . . . . . .  7
     4.2 EVPN Yang Module . . . . . . . . . . . . . . . . . . . . . .  9
   5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
   6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
   7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1. Normative References  . . . . . . . . . . . . . . . . . . . 12
     8.2. Informative References  . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12




Brissette, et. al         Expires June 4, 2016                  [Page 2]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


1.  Introduction

   The Network Configuration Protocol (NETCONF) [RFC6241] is a network
   management protocol that defines mechanisms to manage network
   devices. YANG [RFC6020] is a modular language that represents data
   structures in an XML or JSON tree format, and is used as a data
   modeling language for the NETCONF.

   This document introduces a YANG data model for Ethernet VPN services
   (EVPN) [RFC7432], Provider Backbone Bridging Combined with Ethernet
   VPN (PBB-EVPN) [RFC7623] as well as other WG draft such as EVPN-VPWS,
   etc...  The EVPN services runs over MPLS and VxLAN underlay.

   The Yang data model in this document defines Ethernet VPN based
   services.  The model will leverage the definitions used in other IETF
   Yang draft such as L2VPN Yang.

   The goal is to propose a data object model consisting of building
   blocks that can be assembled in different order to realize different
   services. The definition work is undertaken initially by a smaller
   working group with members representing various vendors and service
   providers. The EVPN basic framework definition is covered first.
   Merging with L2 services model is left for future study. The EVPN
   basic framework consist of two modules: evpn and ethernet-segment.
   These models completely orthogonal. They usually work in pair but
   user can definitely use one or the other for its own need.

   The data model is defined for following constructs that are used for
   managing the services:

      o  Configuration

      o  Operational State

      o  Executables (Actions)

      o  Notifications

   The document is organized to first define the data model for the
   configuration, operational state, actions and notifications of EVPN
   and ethernet-segment.

   The EVPN data object model defined in this document uses the instance
   centric approach whereby EVPN service attributes are specified for a
   given EVPN instance.

   The ethernet-segment data object model defined in this document refer
   to specific an interface. The interface can be a physical interface,



Brissette, et. al         Expires June 4, 2016                  [Page 3]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


   a bundle interface or virtual interface. The latter includes
   pseudowires. The purpose of creating a separate module is due to the
   fact that it can be used without having the need to have evpn
   configured as layer 2 service. For example, an access node can be
   dual-homed to two service nodes servicing a VPLS core. The access
   connectivity can be represented by an ethernet-segment where EVPN BGP
   DF election is performed over both service nodes. The core remains
   VPLS. Therefore, there is no EVPN instance being used here.

2. Specification of Requirements

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

3. EVPN YANG Model

3.1.  Overview

      Two top level module, ethernet-segment and evpn, are defined. The
   ethernet-segment contains a list of interface to which any ethernet-
   segment attributes are configured/applied.

      The evpn module has 2 main containers: common and instance. The
   first one has common attributes to all VPNs where as the latter has
   attributes specific to an EVI.          This document state the scope of
   the EVPN object models definition.   The following documents are
   within the scope.  This is not an   exhaustive list but a
   representation of documents that are covered   for this work:


      o   Requirements for EVPN: RFC 7209
      o   EVPN: RFC 7432
      o   PBB-EVPN: RFC 7623

   The integration with L2VPN instance Yang model is left for future
   study. Following documents will be covered at that time:
      o   VPWS support in EVPN:  draft-ietf-bess-evpn-vpws-00
      o   E-TREE Support in EVPN & PBB-EVPN:
      draft-ietf-bess-evpn-etree-02
      o   (PBB-)EVPN Seamless Integration with (PBB-)VPLS:
      draft-ietf-bess-evpn-vpls-seamless-integ-00
      o   EVPN Virtual Ethernet Segment:
      draft-sajassi-bess-evpn-virtual-eth-segment-00

   The VxLAN aspect and the work related to Layer 3 is also for future
   definition. Following documents will be covered at that time:




Brissette, et. al         Expires June 4, 2016                  [Page 4]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


      o   IP Prefix Advertisement in EVPN:
      draft-ietf-bess-evpn-prefix-advertisement-02
      o   VXLAN DCI Using EVPN:
      draft-boutros-l2vpn-vxlan-evpn
      o   A Network Virtualization Overlay Solution using EVPN:
      draft-ietf-bess-evpn-overlay-00
      o   Interconnect Solution for EVPN Overlay networks:
      draft-ietf-bess-dci-evpn-overlay-00
      o   Integrated Routing and Bridging in EVPN:
      draft-ietf-bess-evpn-inter-subnet-forwarding-00

3.2 Ethernet-Segment Model

   The ethernet-segment data model has a list of ES where each refer to
   an interface. All attributes are optional due to auto-sensing default
   mode where all values are auto-derive from the network connectivity.

   module: ietf-ethernet-segment
      +--rw ethernet-segments
         +--rw ethernet-segment* [name]
            +--rw name                  string
            +--rw esi?                  empty
            +--rw (active-mode)
            |  +--:(single-active)
            |  |  +--rw single-active-mode?   empty
            |  +--:(all-active)
            |     +--rw all-active-mode?      empty
            +--rw bgp-parameters
            |  +--rw common
            |     +--rw route-distinguisher?   string
            |     +--rw vpn-targets* [rt-value]
            |        +--rw rt-value    string
            |        +--rw rt-type     bgp-rt-type
            +--rw df-election
               +--rw (df-election-method)?
               |  +--:(highest-random-weight)
               |     +--rw enable-hrw?           empty
               +--rw election-wait-time?   uint32

3.3 EVPN Model

      The evpn-instances container contains a list of evpn-instance.
   Each entry of the evpn-instance represents a different Ethernet VPN
   and it is represented by a EVI. Again, mainly all attributes are
   optional for the same reason as for the ethernet-segment module.

   module: ietf-evpn
      +--rw evpn



Brissette, et. al         Expires June 4, 2016                  [Page 5]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


         +--rw common
         |  +--rw (replication-type)?
         |     +--:(ingress-replication)
         |     |  +--rw ingress-replication?   boolean
         |     +--:(p2mp-replication)
         |        +--rw p2mp-replication?      boolean
         +--rw evpn-instances
            +--rw evpn-instance* [name]
               +--rw name              string
               +--rw evi?              uint32
               +--rw source-bmac?      yang:hex-string
               +--rw evpn-arp-proxy?   boolean
               +--rw nd-arp-proxy?     boolean
               +--rw bgp-parameters
                  +--rw common
                     +--rw route-distinguisher?   string
                     +--rw vpn-targets* [rt-value]
                        +--rw rt-value    string
                        +--rw rt-type     bgp-rt-type

4. YANG Module

      The EVPN configuration container is logically divided into
   following high level config areas:

4.1 Ethernet Segment Yang Module

   <CODE BEGINS> file "ietf-ethernet-segment@2015-12-02.yang"
   module ietf-ethernet-segment {
     namespace "urn:ietf:params:xml:ns:yang:ietf-ethernet-segment";
     prefix "es";

     import ietf-evpn {
       prefix "evpn";
     }

     organization  "ietf";
     contact       "ietf";
     description   "ethernet segment";

     revision "2015-10-15" {
       description "Initial revision";
       reference   "";
     }

     /* EVPN Ethernet Segment YANG Model */

     container ethernet-segments {



Brissette, et. al         Expires June 4, 2016                  [Page 6]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


       description "ethernet-segment";
       list ethernet-segment {
         key "name";
         leaf name {
           type string;
           description "Name of the ethernet segment";
         }
         leaf esi {
           type empty;
           description "esi";
         }
         choice active-mode {
           mandatory true;
           description "Choice of active mode";
           case single-active {
             leaf single-active-mode {
               type empty;
               description "single-active-mode";
             }
           }
           case all-active {
             leaf all-active-mode {
               type empty;
               description "all-active-mode";
             }
           }
         }
         uses evpn:bgp-parameters-grp;
         container df-election {
           description "df-election";
           choice df-election-method {
             description "Choice of df election method";
             case highest-random-weight {
               leaf enable-hrw {
                 type empty;
                 description "enable-hrw";
               }
             }
           }
           leaf election-wait-time {
             type uint32;
             description "election-wait-time";
           }
         }
         description "An ethernet segment";
       }
     }
   }



Brissette, et. al         Expires June 4, 2016                  [Page 7]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


   <CODE ENDS>


4.2 EVPN Yang Module

   <CODE BEGINS> file "ietf-evpn@2015-12-02.yang"
   module ietf-evpn {
     namespace "urn:ietf:params:xml:ns:yang:ietf-evpn";
     prefix "evpn";

     import ietf-yang-types {
       prefix "yang";
     }

     organization  "ietf";
     contact       "ietf";
     description   "evpn";

     revision "2015-10-15" {
       description "Initial revision";
       reference   "";
     }

     /* Typedefs */

     typedef bgp-rt-type {
       type enumeration {
         enum import {
           description "For import";
         }
         enum export {
           description "For export";
         }
         enum both {
           description "For both import and export";
         }
       }
       description "BGP route-target type. Import from BGP YANG";
     }

     /* Groupings */

     grouping bgp-parameters-grp {
       description "BGP parameters grouping";
       container bgp-parameters {
         description "BGP parameters";
         container common {
           description "Common BGP parameters";



Brissette, et. al         Expires June 4, 2016                  [Page 8]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


           leaf route-distinguisher {
             type string;
             description "BGP RD";
           }
           list vpn-targets {
             key rt-value;
             description "Route Targets";
             leaf rt-value {
               type string;
               description "Route-Target value";
             }
             leaf rt-type {
               type bgp-rt-type;
               mandatory true;
               description "Type of RT";
             }
           }
         }
       }
     }

     /* EVPN YANG Model */

     container evpn {
       description "evpn";
       container common {
         description "common epn attributes";
         choice replication-type {
           description "A choice of replication type";
           case ingress-replication {
             leaf ingress-replication {
               type boolean;
               description "ingress-replication";
             }
           }
           case p2mp-replication {
             leaf p2mp-replication {
               type boolean;
               description "p2mp-replication";
             }
           }
         }
       }
       container evpn-instances {
         description "evpn-instances";
         list evpn-instance {
           key "name";
           description "An EVPN instance";



Brissette, et. al         Expires June 4, 2016                  [Page 9]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


           leaf name {
             type string;
             description "Name of EVPN instance";
           }
           leaf evi {
             type uint32;
             description "evi";
           }
           leaf source-bmac {
             type yang:hex-string;
             description "source-bmac";
           }
           leaf evpn-arp-proxy {
             type boolean;
             description "evpn-arp-proxy";
           }
           leaf nd-arp-proxy {
             type boolean;
             description "nd-arp-proxy";
           }
           uses bgp-parameters-grp;
         }
       }
     }
   }
   <CODE ENDS>

5. Security Considerations

      The configuration, state, action and notification data defined in
   this document are designed to be accessed via the NETCONF protocol
   [RFC6241].  The lowest NETCONF layer is the secure transport layer
   and the mandatory-to-implement secure transport is SSH [RFC6242]. The
   NETCONF access control model [RFC6536] provides means to restrict
   access for particular NETCONF users to a pre-configured subset of all
   available NETCONF protocol operations and content.

      The security concerns listed above are, however, no different than
   faced by other routing protocols. Hence, this draft does not change
   any underlying security issues inherent in [I-D.ietf-netmod-routing-
   cfg]

6. IANA Considerations

      None.

7. Acknowledgments




Brissette, et. al         Expires June 4, 2016                 [Page 10]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


      The authors would like to acknowledge TBD for their useful
   comments.

8. References

8.1. Normative References

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


8.2. Informative References
      [RFC6241]  R.Enns et al., "Network Configuration
                 Protocol (NETCONF)",
                 RFC 6241, June 2011

      [RFC6020]  M. Bjorklund, "YANG - A Data Modeling Language for
                 the Network Configuration Protocol (NETCONF)",
                 RFC 6020, October 2010.

      [RFC6242]  M. Wasserman, "Using the NETCONF Protocol over
                 Secure Shell (SSH)",
                 RFC 6242, June 2011.

      [RFC6536]  A. Bierman et al., "Network Configuration Protocol
                 (NETCONF) Access Control Model"
                 RFC 6536, March 2012.


      [RFC7432]  Sajassi et al., "BGP MPLS-Based Ethernet VPN",
                 RFC 7432, February 2015.


      [RFC7623]  Sajassi et al., "Provider Backbone Bridging
                 Combined with Ethernet VPN (PBB-EVPN)",
                 RFC 7623, September 2015

Authors' Addresses


   Patrice Brissette
   Cisco Systems, Inc.
   EMail: pbrisset@cisco.com

   Himanshu Shah
   Ciena Corporation
   EMail: hshah@ciena.com




Brissette, et. al         Expires June 4, 2016                 [Page 11]


Internet-Draft            draft-bess-evpn-yang          December 2, 2015


   Zhenbin Li
   Huawei Technologies
   EMail: lizhenbin@huawei.com

   Autumn Liu
   Ericsson
   EMail: autumn.liu@ericsson.com

   Kishore Tiruveedhula
   Juniper Networks
   EMail: kishoret@juniper.net

   Tapraj Singh
   Juniper Networks
   EMail: tsingh@juniper.net

   Iftekar Hussain
   Infinera Corporation
   EMail: ihussain@infinera.com
































Brissette, et. al         Expires June 4, 2016                 [Page 12]