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]