INTERNET-DRAFT Rex Fernando Intended Status: Standard Track Sami Boutros Dhananjaya Rao Cisco Systems Expires: October 1, 2014 March 30, 2014 Interface to a Packet Switching Element (IPSE) draft-rfernando-ipse-00.txt Abstract This document describes a set of mechanisms for decoupling the control and data plane of a routing or a switching device and describes an open API between the two that satisfies a set of constraints that are desirable for such an interface. 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Fernando Expires October 1, 2014 [Page 1] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Routing and Switching Systems Model . . . . . . . . . . . . . . 4 2.1 Control Plane (Route Controller) . . . . . . . . . . . . . . 4 2.2 Forwarding Plane (Packet Switching Element) . . . . . . . . 4 2.3 Motivation for separation of Route Controller and Packet Switching Elements(s) . . . . . . . . . . . . . . . . . . . 5 2.4 Different constructions of RC and PSE(s) . . . . . . . . . . 6 3. Packet Switching Element Conceptual Model . . . . . . . . . . . 7 3.1 Typical PSE model . . . . . . . . . . . . . . . . . . . . . 7 3.1.1 I/P Block (Input Processing) . . . . . . . . . . . . . . 7 3.1.2 O/P Block (Output Processing) . . . . . . . . . . . . . 8 3.1.3 Forwarding Block . . . . . . . . . . . . . . . . . . . . 8 3.1.3.1 Forwarding block model . . . . . . . . . . . . . . . 8 3.1.3.2 Context Selection Block . . . . . . . . . . . . . . 9 4. Yang modules . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 YANG Module "pse" . . . . . . . . . . . . . . . . . . . . . 11 4.2 YANG Module "pse-common-types" . . . . . . . . . . . . . . . 15 4.3 Global sub-modules of "pse" . . . . . . . . . . . . . . . . 16 4.3.1 YANG sub module "pse-oam" . . . . . . . . . . . . . . . 16 4.3.2 YANG submodule "physical-interfaces" . . . . . . . . . . 19 4.3.3 YANG submodule "context-selector-table" . . . . . . . . 19 4.3.4 YANG submodule "label-table" . . . . . . . . . . . . . . 22 4.3.5 YANG submodule "l2tp-table" . . . . . . . . . . . . . . 25 4.4 PER Tenant submodules . . . . . . . . . . . . . . . . . . . 27 4.4.1 YANG submodule "ip-unicast-table" . . . . . . . . . . . 27 4.4.2 YANG submodule "flow-table" . . . . . . . . . . . . . . 29 4.4.3 YANG module "ip-next-hop" . . . . . . . . . . . . . . . 29 4.4.4 YANG submodule "l2-table" . . . . . . . . . . . . . . . 31 4.4.5 YANG submodule "l2-next-hop" . . . . . . . . . . . . . . 32 4.4.6 YANG submodule "interface-table" . . . . . . . . . . . . 35 Fernando Expires October 1, 2014 [Page 2] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 4.4.7 YANG submodule "arp-table" . . . . . . . . . . . . . . . 38 4.4.8 Yang submodule "arp-proxy-table" . . . . . . . . . . . . 39 5. YANG data model tree . . . . . . . . . . . . . . . . . . . . . 40 6 Major Contributing Authors . . . . . . . . . . . . . . . . . . . 45 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 45 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 46 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 9.1 Normative References . . . . . . . . . . . . . . . . . . . 46 9.2 Informative References . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Fernando Expires October 1, 2014 [Page 3] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 1 Introduction This document describes a data model driven API to program a routing and switching system's forwarding plane. It describes the motivations for creating an open API between a router's control and its forwarding plane and lays out the exact mechanisms that can be used by the control plane of a routing system to "program" the forwarding tables and state contained in the forwarding plane and additionally get notifications when that state changes in interesting ways. The document proposes YANG as the modeling language for this purpose and provides the exact models that represent the forwarding state of a routers data plane. Note that this document uses the word "router" to refer to any network packet forwarding device. The mechanisms outlined here are equally applicable to L3 devices (routers), L2 devices (switches), MPLS label switches and any device that's a hybrid. 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. Routing and Switching Systems Model Most modern routing and switching systems have two main components: the control plane and the data plane. Traditionally these systems implement proprietary closed communication between the control and the data plane. 2.1 Control Plane (Route Controller) The control plane typically implements different functions on a routing and switching system, which include open interfaces for external management and orchestration, an interface to retrieve operational data, routing and switching control protocols to interact with other network elements, route computation and database to store computed results (RIB) and internal event handling infrastructure that glues these control components together. The rest of the document will refer to the control plane as the "route controller" or just RC. 2.2 Forwarding Plane (Packet Switching Element) Fernando Expires October 1, 2014 [Page 4] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 The forwarding plane performs the forwarding functions on packets received on physical interfaces as per the control directives and state added by the control plane. It also informs the control plane of local events and various operational state so that the control plane can take the necessary actions. The rest of this document will refer to the forwarding plane as the "packet switching element" or just PSE. The PSE has the following functional modules: 1. An PSE control agent that interfaces with the control plane. The agent supports the protocol that is used to communicate with the route controller. It processes the forwarding table and interface updates sent by the controller and populates the forwarding tables that the packet processing logic needs. 2. Packet processing module that performs the actual packet forwarding and packet manipulation actions. It has a set of forwarding and interface tables that it uses to lookup both runtime and configuration state. The packet processing module also collects various statistics and error counters, as well as generates events. 2.3 Motivation for separation of Route Controller and Packet Switching Elements(s) The advent of software defined networking (SDN) and virtualization have opened up many well understood reasons for creating an open interface between the route controller (RC) and forwarding element (PSE). The reasons include but not limited to such factors as, (a) being able to run the route controller on commodity x86 servers and still be able to control the data plane of legacy devices, (b) being able to create interesting routing and bridging topologies and realizing policies at the forwarding plane, (c) modularizing the interface allows best in class products to be assembled without a vendor "lock-in" and the innovation that such a model provides and (d) the cost savings provided by the de-coupled model where a central control plane can provide better control and efficiency in directing packet flows than the traditional distributed protocol based control plane. In short the benefits of software driven networking can be effectively realized by decoupling the route controller and packet switching elements and providing an open interface between the two. An important consideration in providing this modularity is the 'reuse' of technology concepts instead of reinventing a brand new Fernando Expires October 1, 2014 [Page 5] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 mechanism at the data plane level just to provide an open interface. There are many downsides to creating a new data plane model than the well understood 'IP routing' or 'L2 switching' models - the foremost of them being that existing equipment where the hardware behavior is 'baked' in have to be forklift upgraded and replaced with devices that support the new forwarding model. Even if one were to ignore the impracticality of such a solution, one cannot ignore the investment loss in rendering all the legacy devices useless. A more practical approach to solving the control and data plane separation is to provide an interface to these devices that use existing data plane concepts and objects such as IP prefixes, L2 mac entries, next-hops (direct and recursive), vlans, MPLS labels, tunnel encapsulations, interfaces/ports, ECMP forwarding and VRF containers. Most devices understand these concepts and objects and use these concepts and objects to classify and forward data traffic. The idea behind IPSE is to create an abstraction layer to these forwarding objects that allows an external control plane to communicate with a forwarding plane to program these objects. The packet switching element (PSE) itself could be both hardware or software based. Software based PSE's are increasingly becoming popular especially in data center and cloud use cases where multi-tenanted topologies can be rapidly created by installing a software switch/router in the server hosting the cloud and data center applications and using a central controller to program their forwarding tables [VPE DRAFT]. 2.4 Different constructions of RC and PSE(s) While the RC and PSEs can be separated from a communication perspective as outlined in the previous section, there are two distinct ways they can be packaged to work with each other. The more traditional packaging involves both these functions co- located in a single device (for instance within a router chassis). The de-coupling of the controller and PSE enables them to be separated out with the RC running in a different device than the PSE. This might be desirable, because, the controller as an application has different functional, performance and scale characteristics that it would be inefficient and suboptimal for it to be coupled with the forwarding elements. One of the benefits of the model based approach to the separation of RC and PSE is that, as long as the PSE(s) implements the models described in this document and can have a back-end that can honor the semantics of the models defined here, the PSE could be either software based or hardware based. Fernando Expires October 1, 2014 [Page 6] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 This allows for integration of not just software based forwarding elements but can also include hardware forwarding elements (legacy router forwarding plane) as long as the forwarding plane implements the YANG models defined in this document. Lastly, when it comes to routing and reachability, the approach we take to scale the system is to treat the RC and PSE(s) as have been viewed traditionally. IOW, a set of PSE(s) can be programmed by a RC. An RC could have a redundant RC to back it up in case of failure. Two such complexes (with RCs and PSE(s)) would then talk to each other using traditional routing protocols. From this standpoint, there should be no impact to the scalability or the distributed nature of existing routing systems due to the de-coupling of RC's and PSE(s). This alignment to an existing routing model also allows one to keep certain operational aspects intact with respect to the RC/PSE construction. When properly built, the fact that RC and PSE(s) are de-coupled need not be exposed to operational systems. 3. Packet Switching Element Conceptual Model This section describes in brief the conceptual model for the packet switching element (PSE). It describes the various functional blocks and typical forwarding chains that a packet may pass through within the PSE. The various tables specified in the data model in the subsequent section contain the state needed to carry out the packet processing described here. 3.1 Typical PSE model In the packet forwarding path, an PSE consists of the following high- level logical blocks. +------------+ +-----------+ +------------+ In-Phy --->| I/P Block |--+->|Forwarding |-+--> | O/P Block |--> Out-Phy |(ACL,QoS,..)| | +-----------+ | |(ACL,QoS,..)| +------------+ | | +------------+ + ---<---<---<---v In-Phy : A physical interface via which packets are received by the device. Out-Phy : A physical interface via which packets are transmitted out of the device. 3.1.1 I/P Block (Input Processing) This is a logical packet processing block at the input to a routing Fernando Expires October 1, 2014 [Page 7] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 or switching device. This block acts upon the packet based on the interface properties and packet attributes. It also generates the necessary inputs to the forwarding block. A device contains two broad categories of interfaces - those facing the edge or providing access to an edge network or device, and those facing the core network. The input (and output) processing logic applies to both categories, though the rules and actions performed might be different. 3.1.2 O/P Block (Output Processing) This is a logical packet processing block at the output stage of packet forwarding. This block typically applies the output features such as output port policing, queuing and filtering before transmitting the packet out on the physical port. 3.1.3 Forwarding Block This is the block that contains the various forwarding and adjacency tables, and the logic that does the forwarding table lookups and packet rewrites. This document focusses on the models required to describe the behavior and state required by the forwarding block. Depending on the type of an incoming packet, it is possible to do forwarding based on different attributes or combinations of attributes in the packet header. Each of these attributes can be considered as a forwarding class, and a given packet may be subject to multiple of them, based on user requirements. The forwarding-class selector logic identifies the fields in the packet header that will be used to do the lookup for each forwarding- class supported on the device. The lookup occurs in a specific table for that class. There is a logically separate FIB table for each class. Additionally, a device may support multiple logical instances of each table, for example, an IP FIB per VRF. 3.1.3.1 Forwarding block model Fernando Expires October 1, 2014 [Page 8] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 +------------------------------+ | | | Route Lookup, | +-----------+ | Next-Hop Selection & | ---+------->| Context |--->| Packet Rewrite |-------+---> | (A) | Selection |(B) | +-------++-------++-------+ | (C) | | +-----------+ | |Context||Context||Context| | | | | |global ||'pepsi'||'coke' | | | | | | || || | | | ^ | |L2,L3, ||L2,L3 ||L2,L3 | | | | | |Tables ||Tables ||Tables | | | | | +-------++-------++-------+ | | | +------------------------------+ | | (Recirculation) | +-----<---------<----------<----------<----------<----------<----+ Forwarding Block Conceptually, there are two components to the forwarding block. The context selection logic and the actual route lookup, next-hop selection and packet rewrite block. The idea is that an incoming packet can be processed completely by these two blocks and then sent out on an output port towards its next-hop. In some cases, however, it might be easier to construct more complex scenarios by recirculating the packet multiple times through these two blocks. For instance, when an MPLS-VPN packet is received in the core facing interface, the packet is encaped with the VPN label. The VPN label is looked up in the global label table, the result of the lookup could point to the final next-hop or to the context ip table in which the ip packet destination should be looked up in to find the final next- hop. It is easier to construct this 'chained' operation by simply recirculating the packet through the 'context selector' and 'route lookup' blocks than constructing a specific chain for this particular scenario. The idea then is to generalize the forwarding actions by decomposing them into a series of 'context selection' followed by 'route lookup' operations than creating static chain of such operations on a per scenario basis. 3.1.3.2 Context Selection Block The context-selector block determines the specific forwarding context and the specific table within that context in which to perform the forwarding lookup for an incoming packet. A device may have multiple Fernando Expires October 1, 2014 [Page 9] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 forwarding contexts to support multi-tenancy. Each forwarding context could have multiple tables to support different types of lookups (L2, IPv4, IPv6, flow, etc). Inputs to the context selection is the received packet itself together with information on the input interface (physical or logical) on which the packet was received. Currently the model supports determination of the context and table based on the switching mode set on the interface or based on the table pointed to by the MPLS VPN label on the packet. The output of the context selection block is the {context, table} pair to perform the lookup on. The output table could be L2, IPv4 or IPv6 based on the packet type and the mode set on the input interface or as implied by the VPN label on the packet. 4. Yang modules In this section we describe the different YANG modules implementing the data model for the Packet Switching Elements (PSEs). The following sections will define a hierarchy of tables that are needed to implement the L2, L3, MPLS and flow forwarding functions. As is evident, there are cases where the forwarding lookup has to be scoped by a given 'tenant'. In other cases the lookup has to be performed at a global level. At the top level we will define tables that have global scope i.e. not per tenant. The following are the tables that have global scope, a. The interface table that describe the interfaces attached to the PSE's. b. The Context Selector table that tells the PSE how to map traffic arriving on a physical or logical interface to the tenant L2, L3 or flow forwarding tables. The output of the context selector table is a tenant context and a table name within that context to perform a lookup on. c. The MPLS label table that lists all the MPLS labels and the associated tenant L2, L3 of flow forwarding tables d. The L2 tunnel table that will list all the tenants L2 tunnels for point2point cross-connects e. The OAM table that lists the logical or physical interfaces as well as the end-point prefixes that need to be monitored by the Fernando Expires October 1, 2014 [Page 10] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 forwarding element. The interface state is monitored through local events such as 'link up' and 'link down'. Prefixes are monitored through OAM protocols such as ICMP or BFD. A change in state of interfaces or prefix reachability could trigger notification to the route controller to ensure service assurance and continuity. Then we will be defining the per tenant forwarding table hierarchy, in which we will define both L2, L3 and flow forwarding tables and the corresponding L2 and L3 next-hops. 4.1 YANG Module "pse" The Packet Switching Element (PSE) module is the top level module that allows for provisioning and managing a set of global tables and tenant specific tables. The module defines read-only variables that allows the route controller to query for PSE's forwarding capabilities and features that are supported by the PSE that can be turned on or utilized by the RC. It allows for provisioning for IPv4, IPv6, L2, MPLS Label & Flow forwarding tables based on device capabilities. As the top level table, it includes other tables (such as interface table, arp table, L3 and L2 tables) that are needed to perform packet forwarding. module pse { namespace "http://www.cisco.com/yang-modules/ipse/pse"; prefix "pset"; import ietf-inet-types { prefix "inet"; } import pse-common-types { prefix "ct"; } include interface-table; include context-selector-table; include arp-table; include arp-proxy-table; include l2tp-table; include pse-oam; include ip-unicast-table; include l2-table; include flow-table; include label-table; Fernando Expires October 1, 2014 [Page 11] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 description "PSE stands for Packet Switching Element. The module allows for provisioning and managing multi-tenant forwarding tables in a network device. Currently supports IPv4, IPv6, L2 & Flow forwarding entries based on device capabilities. This module extended to support multicast in future"; organization "Cisco Systems"; contact "employee@cisco.com"; revision 2013-12-05 { description "Initial revision."; } container pse-global-features { description "PSE capabilities and features (read only)"; config false; leaf ready { description "Once the controller connects to the pse it can be notified (or it can query) about the pse state to check if pse is READY"; type boolean; } leaf ip-unicast-forwarding { description "This feature indicates that the device implements IPv4 based unicast forwarding"; type boolean; } leaf l2-forwarding { description "This feature indicates that the device implements forwarding based on L2 addresses"; type boolean; } leaf flow-forwarding { description "This feature indicates that the device implements flow forwarding based on (src-ip, dst-ip, src-port, dst-port, protocol)"; type boolean; Fernando Expires October 1, 2014 [Page 12] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 } uses ip-unicast-features; uses l2-features; uses flow-features; } container pse-oam { description "This global table can be used to determine the health status of objects - such as interface state and reachability of a prefix" uses pse-oam; } container sync { leaf sync-state { description "Used to Synchronize PSE tables. These variables could be used by the route controller to indicate the start and end of a route download operation"; type enumeration { enum sync-start; enum sync-complete; } } } container context-selector-table { uses context-selector-table; } uses label-table; container interface-table { uses if-table; } container protocol-addresses { container ipv4 { container table { uses ct:table-name; } leaf source-address { type inet:ipv4-address; } leaf dhcp-address { Fernando Expires October 1, 2014 [Page 13] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 type inet:ipv4-address; } leaf gateway-address { type inet:ipv4-address; } } container ipv6 { container table { uses ct:table-name; } leaf source-address { type inet:ipv6-address; } leaf dhcp-address { type inet:ipv6-address; } leaf gateway-address { type inet:ipv6-address; } } } uses l2tp-table; list pse-contexts { description "This list represents a provisioned list of packet forwarding contexts. Each context could represent a distinct tenant and network address space. Forwarding tables and other policy parameters related to routing, addressing, forwarding are assumed to be defined within a pse context. Each pse context is uniquely identified by a name"; key pse-context-name; leaf pse-context-name { type string; } list tables { description "list of forwarding tables within the context, indexed by unique table's name "; key table-name; leaf table-name { Fernando Expires October 1, 2014 [Page 14] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 type string; description "Instance of a forwarding table identified by name"; } leaf pse-vpn-id { type string; description "VPN-ID used by DHCP"; } choice pse-table-type { case ip-unicast-table { container arp-table { uses arp-table; } container arp-proxy-table { uses arp-proxy-table; } container ip-unicast-table { uses ip-unicast-table; } } case l2-table { container l2-table { uses l2-table; } } case flow-table { container flow-table { uses flow-table; } } } } } } 4.2 YANG Module "pse-common-types" This module defines some common types used by all the modules and sub modules defined in this document. module pse-common-types { Fernando Expires October 1, 2014 [Page 15] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 namespace "http://www.cisco.com/yang-modules/ipse/pse-common-types"; prefix "psect"; revision "2013-12-05" { description "Initial revision."; } grouping table-name { description "The unique table's name is specified by PSE context-name, and the table's name within the context"; leaf pse-ctx-name { description "The name of PSE context"; type string; } leaf ctx-tbl-name { description "The name of table within PSE context"; type string; } } typedef interfaceName { type string; } typedef interfaceLogicalUnit { type int32 { range "0..9999"; } } typedef prefixLengthIPv4 { type int32 { range "0..32"; } } typedef prefixLengthIPv6 { type int32 { range "0..128"; } } } 4.3 Global sub-modules of "pse" 4.3.1 YANG sub module "pse-oam" Fernando Expires October 1, 2014 [Page 16] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 This sub module defines the provisioned and operational list of interfaces and prefixes to be monitored by the devices implementing the PSE. submodule pse-oam { belongs-to pse { prefix "pset"; } import pse-common-types { prefix "ct"; } import ietf-inet-types { prefix "inet"; } organization "Cisco Systems"; contact "joe@acme.example.com"; description "OAM Status for PSE "; revision 2013-12-05 { description "Initial revision."; } grouping pse-oam { container prefix-table { list unicast-prefix { description "This list defines the prefixes to be monitored by OAM."; key "prefix"; leaf prefix { type inet:ip-prefix; } } } container interface-table { list interfaces { description "This list defines the interfaces to be monitored by OAM"; key "interface-name"; leaf interface-name { Fernando Expires October 1, 2014 [Page 17] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 type ct:interfaceName; } } } container oper-prefix-down-table { config false; list oper-prefix-down-list { description "This list defines the prefixes oper down state monitored by OAM"; key "version"; leaf version { description "Version "; type uint32; } leaf prefix { type inet:ip-prefix; } } } container oper-interface-down-table { config false; list oper-interfaces-down-list { description "This list defines the interfaces oper down state monitored by OAM"; key "version"; leaf version { description "Version "; type uint32; } leaf interface-name { type ct:interfaceName; } } } } Fernando Expires October 1, 2014 [Page 18] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 } 4.3.2 YANG submodule "physical-interfaces" This submodule defines the list of physical interfaces discovered on the devices implementing the PSE. submodule physical-interfaces { belongs-to pse-tables { prefix "pset"; } import pse-common-types { prefix "ct"; } organization "Cisco Systems"; contact "employee@cisco.com"; description "The module list the operational physical interfaces"; revision 2013-12-05 { description "Initial revision."; } grouping physical-interfaces { container physical-interfaces { config false; list interfaces { description " This list define the physical interfaces discovered on end server"; key "interface-name"; leaf interface-name { type ct:interfaceName; } } } } } 4.3.3 YANG submodule "context-selector-table" This submodule defines the list of per tenant selector types. Fernando Expires October 1, 2014 [Page 19] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 submodule context-selector-table { belongs-to pse-tables { prefix "pset"; } import pse-common-types { prefix "ct"; } organization "Cisco Systems"; contact "joe@acme.example.com"; description "The module maps incoming traffic to the forwarding table"; revision 2013-12-05 { description "Initial revision."; } typedef tbl-selection-type { type enumeration { enum ipv4 { description "The table for IPv4 traffic is derived from interface configuration"; } enum ipv6 { description "The table for IPv6 traffic is derived from interface configuration"; } enum l2-table { description "The table for L2 lookup is derived from interface configuration"; } enum flow-table { description "The table for flow based forwarding is derived from interface configuration"; } } } grouping context-selector-table { container label-ctx-selection-table { list label-entry { key label; leaf label { type uint32; } Fernando Expires October 1, 2014 [Page 20] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 container disposition-table { uses ct:table-name; } } } container interface-ctx-selector-table { list interfaces { description " This list define the table selection mechanism on interface"; key "interface-name selection-type"; leaf interface-name { type ct:interfaceName; } leaf selection-type { type tbl-selection-type; } choice tbl-selection-type { case ipv4 { container ipv4-table { uses ct:table-name; } } case ipv6 { container ipv6-table { uses ct:table-name; } } case l2-table { container ipv6-table { uses ct:table-name; } } case flow-table { container ipv6-table { uses ct:table-name; } } } } } } } Fernando Expires October 1, 2014 [Page 21] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 4.3.4 YANG submodule "label-table" This submodule defines the list of MPLS labels pointing to the different per tenant L2 and L3 tables. submodule label-table { belongs-to pse-tables { prefix "pset"; } import ietf-inet-types { prefix "inet"; } import ietf-yang-types { prefix "yang"; } import pse-common-types { prefix "ct"; } organization "Cisco Systems"; contact "joe@acme.example.com"; description "The module defines a forwarding tables based on IpV4/V6 addresses"; revision 2013-12-05 { description "Initial revision."; } grouping out-label-stats { leaf packets { type yang:counter64; } leaf bytes { type yang:counter64; } } grouping mpls-next-hop { choice ip-next-hop-type { case ip-nh-type { description Fernando Expires October 1, 2014 [Page 22] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 "Specifies the content of unicast IP next-hop"; leaf ip-next-hop { type inet:ip-address; } leaf interface { type ct:interfaceName; } container nh-tbl-name { uses ct:table-name; } } case ip-nh-type-mpls-gre { leaf local-gre-addr { type inet:ip-address; } leaf remote-gre-addr { type inet:ip-address; } container nh-gre-tbl-name { uses ct:table-name; } leaf mpls-label { type uint32; } leaf gre-key { type uint32; } } case ip-nh-type-vxlan { leaf local-vxlan-addr { type inet:ip-address; } leaf remote-vxlan-addr { type inet:ip-address; } leaf vxlan-id { type uint32; } } } Fernando Expires October 1, 2014 [Page 23] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 leaf label { description "output label"; type uint32; } leaf label-type { type enumeration { enum valid { description "valid output label"; } enum pop { description "pop-and-forward"; } } } container next-hop-stats { config false; uses out-label-stats; } } grouping mpls-nh-array { list mpls-nh-array { key next-hop-index; leaf next-hop-index { type uint8; description "The numerical index of next-hop in next-hop array"; } leaf nh-weight { type uint32; } uses mpls-next-hop; } } typedef LocalLabelType { type enumeration { enum head-prefix { description "LSP head per-prefix label"; } enum label-xconnect { description "Midpoint label"; } } Fernando Expires October 1, 2014 [Page 24] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 } grouping local-label-attributes { leaf local-label-type { type LocalLabelType; description "label type"; } choice local-label-type-choice { case head-prefix { leaf prefix { type inet:ip-prefix; } container pref-table { uses ct:table-name; } } } } grouping label-table { list label-table { key "local-label"; leaf local-label { description "input label"; type uint32; } container label-attributes { uses local-label-attributes; } uses mpls-nh-array; } } } 4.3.5 YANG submodule "l2tp-table" This submodule defines the list of per tenant layer 2 tunnel protocol (l2tp) point2point cross connects. submodule l2tp-table { belongs-to pse-tables { prefix "pset"; } Fernando Expires October 1, 2014 [Page 25] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 import ietf-inet-types { prefix "inet"; } import pse-common-types { prefix "ct"; } organization "Cisco Systems"; contact "joe@acme.example.com"; description "L2TP v3/v6 tables"; revision 2013-12-05 { description "Initial revision."; } grouping l2tp-table { list l2tp { key "src-addr dst-addr session-id"; leaf src-addr { type inet:ip-address; } leaf dst-addr { type inet:ip-address; } leaf session-id { type uint32; } leaf src-cookie { type uint32; } leaf dst-cookie { type uint32; } leaf interface-name { type ct:interfaceName; } } } } Fernando Expires October 1, 2014 [Page 26] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 4.4 PER Tenant submodules 4.4.1 YANG submodule "ip-unicast-table" This submodule defines the per tenant ipv4/v6 forwarding tables. submodule ip-unicast-table { belongs-to pse-tables { prefix "pset"; } import ietf-yang-types { prefix "yang"; } import iana-afn-safi { prefix "ianaaf"; } import ietf-inet-types { prefix "inet"; } import ip-next-hop { prefix "ipnh"; } organization "Cisco Systems"; contact "joe@acme.example.com"; description "The module defines a forwarding tables based on IpV4/V6 addresses"; revision 2013-12-05 { description "Initial revision."; } grouping ip-unicast-features { container ipv4-unicast-features { description "This feature indicates that the device implements IPv4 based unicast forwarding"; container ipv4-features { uses ipnh:ip-next-hop-features; } } Fernando Expires October 1, 2014 [Page 27] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 container ipv6-unicast-features { description "This feature indicates that the device implements IPv6 based unicast forwarding"; container ipv6-features { uses ipnh:ip-next-hop-features; } } } grouping ip-tbl-attribute { leaf afi { description "Type of IP table: ipv4/ipv6"; type ianaaf:address-family; } } grouping prefix-stats { leaf packets { type yang:counter64; } leaf bytes { type yang:counter64; } } grouping ip-unicast-table { container ip-tbl-attrs { uses ip-tbl-attribute; } list unicast-prefix { key "prefix"; leaf prefix { type inet:ip-prefix; } uses ipnh:ip-nh-array; container per-prefix-stats { config false; uses prefix-stats; Fernando Expires October 1, 2014 [Page 28] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 } } } } 4.4.2 YANG submodule "flow-table" This submodule defines the per tenant flow tables to allow for per flow forwarding across devices implementing the PSE. TBD. 4.4.3 YANG module "ip-next-hop" This submodule defines per tenant the list of different L3 next hops that can be pointed at by L2 and L3 prefixes in the L2 or L3 tables. module ip-next-hop { namespace "http://www.cisco.com/something/something-else/context1"; prefix "ipnh"; import ietf-inet-types { prefix "inet"; } import pse-common-types { prefix "ct"; } description "The module defines a set of next-hop tables specific forwarding tables can be derived"; revision 2013-12-05 { description "Initial revision."; } grouping ip-next-hop-features { leaf ecmp-supported { type boolean; } leaf ucmp-supported { type boolean; } Fernando Expires October 1, 2014 [Page 29] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 leaf max-mp-next-hops { type uint32; } container nh-type-supported { leaf nh-type-regular { type boolean; } leaf nh-type-mpls-over-gre { type boolean; } leaf nh-type-vxlan { type boolean; } } } grouping ip-next-hop { choice ip-next-hop-type { case ip-nh-type { description "Specifies the content of unicast IP next-hop"; leaf ip-next-hop { type inet:ip-address; } leaf interface { type ct:interfaceName; } container nh-tbl-name { uses ct:table-name; } } case ip-nh-type-mpls-gre { leaf local-gre-addr { type inet:ip-address; } leaf remote-gre-addr { type inet:ip-address; } container nh-gre-tbl-name { Fernando Expires October 1, 2014 [Page 30] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 uses ct:table-name; } leaf mpls-label { type uint32; } leaf gre-key { type uint32; } } case ip-nh-type-vxlan { leaf local-vxlan-addr { type inet:ip-address; } leaf remote-vxlan-addr { type inet:ip-address; } leaf vxlan-id { type uint32; } } } } grouping ip-nh-array { list ip-nh-array { key next-hop-index; leaf next-hop-index { type uint8; description "The numerical index of next-hop in next-hop array"; } leaf nh-weight { type uint32; } uses ip-next-hop; } } } 4.4.4 YANG submodule "l2-table" Fernando Expires October 1, 2014 [Page 31] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 This submodule defines the per tenant L2 tables keyed by L2 MAC addresses. submodule l2-table { belongs-to pse-tables { prefix "pset"; } import ietf-yang-types { prefix "yang"; } import l2-next-hop { prefix "l2nh"; } organization "Cisco Systems"; contact "joe@acme.example.com"; description "The module defines a forwarding tables based on L2 MAC addresses"; revision 2013-12-05 { description "Initial revision."; } grouping l2-features { uses l2nh:l2-next-hop-features; } grouping l2-table { list L2-table { key "dst-mac"; leaf dst-mac { type yang:mac-address; } uses l2nh:l2-nh-array; } } } 4.4.5 YANG submodule "l2-next-hop" This submodule defines per tenant the list of different L2 next hops that can be pointed at by L2 and L3 prefixes in the L2 or L3 tables. Fernando Expires October 1, 2014 [Page 32] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 module l2-next-hop { namespace "http://www.cisco.com/something/something-else/context3"; prefix "l2nh"; import ietf-inet-types { prefix "inet"; } import pse-common-types { prefix "ct"; } description "The module defines a set of next-hop tables specific forwarding tables can be derived"; revision 2013-12-05 { description "Initial revision."; } grouping l2-next-hop-features { leaf l2-ecmp-supported { type boolean; } leaf l2-ucmp-supported { type boolean; } leaf l2-max-mp-next-hops { type uint32; } container l2-nh-type-supported { leaf nh-type-if { type boolean; } leaf nh-type-mpls-over-gre { type boolean; } leaf nh-type-vxlan { type boolean; } } } Fernando Expires October 1, 2014 [Page 33] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 grouping l2-next-hop { choice l2-next-hop-type { case l2-nh-type-if { leaf l2-nh-if { type ct:interfaceName; } } case l2-nh-type-mpls-over-gre { leaf local-gre-addr { type inet:ip-address; } leaf remote-gre-addr { type inet:ip-address; } leaf gre-key { type uint32; } leaf mpls-label { type uint32; } } case l2-nh-type-vxlan { leaf local-vxlan-addr { type inet:ip-address; } leaf remote-vxlan-addr { type inet:ip-address; } leaf vxlan-id { type uint32; } } } } grouping l2-nh-array { list l2-nh-array { key next-hop-index; Fernando Expires October 1, 2014 [Page 34] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 leaf next-hop-index { type uint8; description "This is an opaque index generated by the device to uniquely identify a list of multi-path next-hops"; } leaf nh-weight { type uint32; } uses l2-next-hop; } } } 4.4.6 YANG submodule "interface-table" This submodule defines per tenant table the list of interfaces will be hosted on a device implementing PSE. submodule interface-table { belongs-to pse-tables { prefix "pse-if"; } import ietf-interfaces { prefix if; } import ietf-inet-types { prefix "inet"; } import pse-common-types { prefix "ct"; } description "Interface table"; organization "Cisco Systems"; contact "employee@cisco.com"; revision 2013-12-05 { description "Initial revision."; } augment "/if:interfaces/if:interface" { when "if:type = 'ethernetCsmacd' or if:type = 'ieee8023adLag'"; leaf vlan-tagging { Fernando Expires October 1, 2014 [Page 35] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 type boolean; default false; } } augment "/if:interfaces/if:interface" { when "if:type = 'l2vlan'"; leaf base-interface { type if:interface-ref; must "/if:interfaces/if:interface[if:name = current()]" + "/if:vlan-tagging = 'true'" { description "The base interface must have vlan tagging enabled."; } } leaf outer-vlan-id { type uint16 { range "1..4094"; } must "../base-interface" { description "If a vlan-id is defined, a base-interface must be specified."; } } leaf inner-vlan-id { type uint16 { range "1..4094"; } must "../base-interface" { description "If a vlan-id is defined, a base-interface must be specified."; } } } augment "/if:interfaces/if:interface" { when "if:type = 'ethernetCsmacd'"; container ethernet { must "../if:location" { description "An ethernet interface must specify the physical location of the ethernet hardware."; } choice transmission-params { case auto { leaf auto-negotiate { type empty; Fernando Expires October 1, 2014 [Page 36] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 } } case manual { leaf duplex { type enumeration { enum "half"; enum "full"; } } leaf speed { type enumeration { enum "10Mb"; enum "100Mb"; enum "1Gb"; enum "10Gb"; } } } } } } augment "/if:interfaces/if:interface" { leaf ip-enabled { type boolean; default false; } } augment "/if:interfaces/if:interface" { leaf base-ip { type if:interface-ref; must "/if:interfaces/if:interface[if:name = current()]" + "/if:ip-enabled = 'true'" { description "The base interface must have vlan tagging enabled."; } } leaf ipv4-addr { type inet:ipv4-address; must "../base-interface" { description "If an ip address is defined, a base-interface must be specified."; } } leaf ipv4-prefix-length { type ct:prefixLengthIPv4; must "../base-interface" { description Fernando Expires October 1, 2014 [Page 37] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 "IPv4 address prefix length"; } } leaf ipv6-addr { type inet:ipv6-address; must "../base-interface" { description "If an ip address is defined, a base-interface must be specified."; } } leaf ipv6-prefix-length { type ct:prefixLengthIPv6; must "../base-interface" { description "IPv6 address prefix length"; } } leaf mtu { type uint32; description "The size, in octets, of the largest packet that the interface can send and receive. This node might not be valid for all interface types. Media-specific modules must specify any restrictions on the mtu for their interface type."; } leaf unnumbered-to-intf { type if:interface-ref; } } grouping if-table { leaf table-int { type if:interface-ref; } } } 4.4.7 YANG submodule "arp-table" This submodule defines per tenant the list of ARP entries that will be hosted on a device implementing PSE. submodule arp-table { belongs-to pse-tables { prefix "arp"; } Fernando Expires October 1, 2014 [Page 38] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 import ietf-inet-types { prefix "inet"; } import ietf-yang-types { prefix "yang"; } import pse-common-types { prefix "ct"; } organization "Cisco Systems"; contact "joe@acme.example.com"; description "The module defines a forwarding tables based on IpV4/V6 addresses"; revision 2013-12-05 { description "Initial revision."; } grouping arp-table { list arptable { key "ip-address"; leaf ip-address { type inet:ip-address; } leaf mac-address { type yang:mac-address; description "Destination MAC Address"; } leaf interface-name { type ct:interfaceName; } } } } 4.4.8 Yang submodule "arp-proxy-table" This submodule defines per tenant proxy-arp entries that will be hosted on a device implementing PSE. submodule arp-proxy-table { belongs-to pse-tables { Fernando Expires October 1, 2014 [Page 39] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 prefix "arp-proxy"; } import ietf-inet-types { prefix "inet"; } organization "Cisco Systems"; contact "joe@acme.example.com"; description "The module defines ARP Proxy tables based on IpV4/V6 addresses"; revision 2013-12-05 { description "Initial revision."; } grouping arp-proxy-table { list arpproxytable { key "ip-prefix"; leaf ip-prefix { type inet:ip-prefix; } leaf gateway-ip-address { type inet:ip-address; } } } } 5. YANG data model tree module: pse-tables +--ro pse-global-features | +--ro ready? boolean | +--ro ip-unicast-forwarding? boolean | +--ro l2-forwarding? boolean | +--ro flow-forwarding? boolean | +--ro ipv4-unicast-features | | +--ro ipv4-features | | +--ro ecmp-supported? boolean | | +--ro ucmp-supported? boolean | | +--ro max-mp-next-hops? uint32 | | +--ro nh-type-supported | | +--ro nh-type-regular? boolean | | +--ro nh-type-mpls-over-gre? boolean | | +--ro nh-type-vxlan? boolean | +--ro ipv6-unicast-features Fernando Expires October 1, 2014 [Page 40] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 | | +--ro ipv6-features | | +--ro ecmp-supported? boolean | | +--ro ucmp-supported? boolean | | +--ro max-mp-next-hops? uint32 | | +--ro nh-type-supported | | +--ro nh-type-regular? boolean | | +--ro nh-type-mpls-over-gre? boolean | | +--ro nh-type-vxlan? boolean | +--ro l2-ecmp-supported? boolean | +--ro l2-ucmp-supported? boolean | +--ro l2-max-mp-next-hops? uint32 | +--ro l2-nh-type-supported | | +--ro nh-type-if? boolean | | +--ro nh-type-mpls-over-gre? boolean | | +--ro nh-type-vxlan? boolean | +--ro ecmp-supported? boolean | +--ro ucmp-supported? boolean | +--ro max-mp-next-hops? uint32 | +--ro nh-type-supported | +--ro nh-type-regular? boolean | +--ro nh-type-mpls-over-gre? boolean | +--ro nh-type-vxlan? boolean +--rw pse-oam | +--rw prefix-table | | +--rw unicast-prefix [prefix] | | +--rw prefix inet:ip-prefix | +--rw interface-table | | +--rw interfaces [interface-name] | | +--rw interface-name ct:interfaceName | +--ro oper-prefix-down-table | | +--ro oper-prefix-down-list [version] | | +--ro version uint32 | | +--ro prefix? inet:ip-prefix | +--ro oper-interface-down-table | +--ro oper-interfaces-down-list [version] | +--ro version uint32 | +--ro interface-name? ct:interfaceName +--rw sync | +--rw sync-state? enumeration +--rw context-selector-table | +--rw label-ctx-selection-table | | +--rw label-entry [label] | | +--rw label uint32 | | +--rw disposition-table | | +--rw pse-ctx-name? string | | +--rw ctx-tbl-name? string | +--rw interface-ctx-selector-table | +--rw interfaces [interface-name selection-type] Fernando Expires October 1, 2014 [Page 41] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 | +--rw interface-name ct:interfaceName | +--rw selection-type tbl-selection-type | +--rw (tbl-selection-type)? | +--:(ipv4) | | +--rw ipv4-table | | +--rw pse-ctx-name? string | | +--rw ctx-tbl-name? string | +--:(ipv6) | +--rw ipv6-table | +--rw pse-ctx-name? string | +--rw ctx-tbl-name? string +--rw label-table [local-label] | +--rw local-label uint32 | +--rw label-attributes | | +--rw local-label-type? LocalLabelType | | +--rw (local-label-type-choice)? | | +--:(head-prefix) | | +--rw prefix? inet:ip-prefix | | +--rw pref-table | | +--rw pse-ctx-name? string | | +--rw ctx-tbl-name? string | +--rw mpls-nh-array [next-hop-index] | +--rw next-hop-index uint8 | +--rw nh-weight? uint32 | +--rw (ip-next-hop-type)? | | +--:(ip-nh-type) | | | +--rw ip-next-hop? inet:ip-address | | | +--rw interface? ct:interfaceName | | | +--rw nh-tbl-name | | | +--rw pse-ctx-name? string | | | +--rw ctx-tbl-name? string | | +--:(ip-nh-type-mpls-gre) | | | +--rw local-gre-addr? inet:ip-address | | | +--rw remote-gre-addr? inet:ip-address | | | +--rw nh-gre-tbl-name | | | | +--rw pse-ctx-name? string | | | | +--rw ctx-tbl-name? string | | | +--rw mpls-label? uint32 | | | +--rw gre-key? uint32 | | +--:(ip-nh-type-vxlan) | | +--rw local-vxlan-addr? inet:ip-address | | +--rw remote-vxlan-addr? inet:ip-address | | +--rw vxlan-id? uint32 | +--rw label? uint32 | +--rw label-type? enumeration | +--ro next-hop-stats | +--ro packets? yang:counter64 | +--ro bytes? yang:counter64 Fernando Expires October 1, 2014 [Page 42] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 +--rw interface-table | +--rw table-int? if:interface-ref +--rw protocol-addresses | +--rw ipv4 | | +--rw table | | | +--rw pse-ctx-name? string | | | +--rw ctx-tbl-name? string | | +--rw source-address? inet:ipv4-address | | +--rw dhcp-address? inet:ipv4-address | | +--rw gateway-address? inet:ipv4-address | +--rw ipv6 | +--rw table | | +--rw pse-ctx-name? string | | +--rw ctx-tbl-name? string | +--rw source-address? inet:ipv6-address | +--rw dhcp-address? inet:ipv6-address | +--rw gateway-address? inet:ipv6-address +--rw l2tp [src-addr dst-addr session-id] | +--rw src-addr inet:ip-address | +--rw dst-addr inet:ip-address | +--rw session-id uint32 | +--rw src-cookie? uint32 | +--rw dst-cookie? uint32 | +--rw interface-name? ct:interfaceName +--rw pse-contexts [pse-context-name] +--rw pse-context-name string +--rw tables [table-name] +--rw table-name string +--rw pse-vpn-id? string +--rw (pse-table-type)? +--:(ip-unicast-table) | +--rw arp-table | | +--rw arptable [ip-address] | | +--rw ip-address inet:ip-address | | +--rw mac-address? yang:mac-address | | +--rw interface-name? ct:interfaceName | +--rw arp-proxy-table | | +--rw arpproxytable [ip-prefix] | | +--rw ip-prefix inet:ip-prefix | | +--rw gateway-ip-address? inet:ip-address | +--rw ip-unicast-table | +--rw ip-tbl-attrs | | +--rw afi? ianaaf:address-family | +--rw unicast-prefix [prefix] | +--rw prefix inet:ip-prefix | +--rw ip-nh-array [next-hop-index] | | +--rw next-hop-index uint8 | | +--rw nh-weight? uint32 Fernando Expires October 1, 2014 [Page 43] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 | | +--rw (ip-next-hop-type)? | | +--:(ip-nh-type) | | | +--rw ip-next-hop? inet:ip-address | | | +--rw interface? ct:interfaceName | | | +--rw nh-tbl-name | | | +--rw pse-ctx-name? string | | | +--rw ctx-tbl-name? string | | +--:(ip-nh-type-mpls-gre) | | | +--rw local-gre-addr? inet:ip-address | | | +--rw remote-gre-addr? inet:ip-address | | | +--rw nh-gre-tbl-name | | | | +--rw pse-ctx-name? string | | | | +--rw ctx-tbl-name? string | | | +--rw mpls-label? uint32 | | | +--rw gre-key? uint32 | | +--:(ip-nh-type-vxlan) | | +--rw local-vxlan-addr? inet:ip-address | | +--rw remote-vxlan-addr? inet:ip-address | | +--rw vxlan-id? uint32 | +--ro per-prefix-stats | +--ro packets? yang:counter64 | +--ro bytes? yang:counter64 +--:(l2-table) | +--rw l2-table | +--rw L2-table [dst-mac] | +--rw dst-mac yang:mac-address | +--rw l2-nh-array [next-hop-index] | +--rw next-hop-index uint8 | +--rw nh-weight? uint32 | +--rw (l2-next-hop-type)? | +--:(l2-nh-type-if) | | +--rw l2-nh-if? ct:interfaceName | +--:(l2-nh-type-mpls-over-gre) | | +--rw local-gre-addr? inet:ip-address | | +--rw remote-gre-addr? inet:ip-address | | +--rw gre-key? uint32 | | +--rw mpls-label? uint32 | +--:(l2-nh-type-vxlan) | +--rw local-vxlan-addr? inet:ip-address | +--rw remote-vxlan-addr? inet:ip-address | +--rw vxlan-id? uint32 +--:(flow-table) +--rw flow-table +--rw afi? ianaaf:address-family +--rw flow-table +--rw src-address inet:ip-address +--rw dst-address inet:ip-address +--rw src-port uint32 Fernando Expires October 1, 2014 [Page 44] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 +--rw dst-port uint32 +--rw protocol-type string +--rw nh-array +--rw ip-nh-array [next-hop-index] +--rw next-hop-index uint8 +--rw nh-weight? uint32 +--rw (ip-next-hop-type)? +--:(ip-nh-type) | +--rw ip-next-hop? inet:ip-address | +--rw interface? ct:interfaceName | +--rw nh-tbl-name | +--rw pse-ctx-name? string | +--rw ctx-tbl-name? string +--:(ip-nh-type-mpls-gre) | +--rw local-gre-addr? inet:ip-address | +--rw remote-gre-addr? inet:ip-address | +--rw nh-gre-tbl-name | | +--rw pse-ctx-name? string | | +--rw ctx-tbl-name? string | +--rw mpls-label? uint32 | +--rw gre-key? uint32 +--:(ip-nh-type-vxlan) +--rw local-vxlan-addr? inet:ip-address +--rw remote-vxlan-addr? inet:ip-address +--rw vxlan-id? uint32 6 Major Contributing Authors The editors would like to thank Reshad Rahman, Yuri Tsier, and Kausik Majumdar who made a major contribution to the development of this document. Reshad Rahman Cisco Email: rrahman@cisco.com Yuri Tsier Cisco Email: ytsier@cisco.com Kausik Majumdar Cisco Email: kmajumda@cisco.com 7 Security Considerations Fernando Expires October 1, 2014 [Page 45] INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014 This document does not introduce any additional security constraints. 8 IANA Considerations TBD 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 Authors' Addresses Rex Fernando Cisco Email: rex@cisco.com Sami Boutros Cisco Email: sboutros@cisco.com Dhananjaya Rao Cisco Email: dhrao@cisco.com Fernando Expires October 1, 2014 [Page 46]