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]