[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-brissette-bess-evpn-yang) 00 01 02 03 04 05 06 07

BESS Working Group                                          P. Brissette
Internet Draft                                              Cisco System
Intended Status: Proposed Standard                               H. Shah
Expires: December 25, 2016                             Ciena Corporation
                                                                   Z. Li
                                                     Huawei Technologies
                                                                 I. Chen
                                                                Ericsson
                                                         K. Tiruveedhula
                                                        Juniper Networks
                                                              I. Hussain
                                                    Infinera Corporation
                                                              J. Rabadan
                                                                   Nokia

                                                           June 23, 2016



                        Yang Data Model for EVPN
                      draft-ietf-bess-evpn-yang-00

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. Any "add-on" features
   such as EVPN IRB, EVPN overlay, etc. are for future investigation.
   This document mainly focuses on EVPN and Ethernet-Segment 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 December 25, 2016                [Page 1]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


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

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 December 25, 2016                [Page 2]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


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 consist of two modules: EVPN and
   Ethernet-Segment. These models are 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 a specific  interface. That interface can be a physical interface,
   a bundle interface or virtual interface. The latter includes



Brissette, et. al      Expires December 25, 2016                [Page 3]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


   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 in 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. and no EVPN instance is 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 December 25, 2016                [Page 4]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


      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 December 25, 2016                [Page 5]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


         +--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@2016-06-23.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 "2016-06-23" {
       description "WG document adoption";
       reference   "";
     }

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



Brissette, et. al      Expires December 25, 2016                [Page 6]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


     }

     /* EVPN Ethernet Segment YANG Model */

     container ethernet-segments {

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



Brissette, et. al      Expires December 25, 2016                [Page 7]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


           }
         }
         description "An ethernet segment";
       }
     }
   }

   <CODE ENDS>


4.2 EVPN Yang Module

   <CODE BEGINS> file "ietf-evpn@2016-06-23.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 "2016-06-23" {
       description "WG document adoption";
       reference   "";
     }

     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";
         }



Brissette, et. al      Expires December 25, 2016                [Page 8]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


       }
       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";

           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";
             }
           }



Brissette, et. al      Expires December 25, 2016                [Page 9]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


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

           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



Brissette, et. al      Expires December 25, 2016               [Page 10]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


   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


      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.





Brissette, et. al      Expires December 25, 2016               [Page 11]


Internet-Draft            draft-bess-evpn-yang             June 23, 2016


      [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

   Zhenbin Li
   Huawei Technologies
   EMail: lizhenbin@huawei.com

   Helen Chen
   Ericsson
   EMail: ichen@kuatrotech.com

   Kishore Tiruveedhula
   Juniper Networks
   EMail: kishoret@juniper.net

   Iftekar Hussain
   Infinera Corporation
   EMail: ihussain@infinera.com

   Jorge Rabadan
   Nokia
   EMail: jorge.rabadan@nokia.com

















Brissette, et. al      Expires December 25, 2016               [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/