idnits 2.17.1 draft-rfernando-ipse-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 46 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1883 has weird spacing: '... prefix ine...' == Line 1886 has weird spacing: '...ce-name ct:...' == Line 1889 has weird spacing: '...version uin...' == Line 1906 has weird spacing: '...ce-name ct:...' == Line 1907 has weird spacing: '...on-type tbl...' == (2 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 30, 2014) is 3680 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 122, but not defined == Missing Reference: 'VPE DRAFT' is mentioned on line 217, but not defined == Unused Reference: 'KEYWORDS' is defined on line 2104, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Rex Fernando 3 Intended Status: Standard Track Sami Boutros 4 Dhananjaya Rao 5 Cisco Systems 7 Expires: October 1, 2014 March 30, 2014 9 Interface to a Packet Switching Element (IPSE) 10 draft-rfernando-ipse-00.txt 12 Abstract 14 This document describes a set of mechanisms for decoupling the 15 control and data plane of a routing or a switching device and 16 describes an open API between the two that satisfies a set of 17 constraints that are desirable for such an interface. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Routing and Switching Systems Model . . . . . . . . . . . . . . 4 59 2.1 Control Plane (Route Controller) . . . . . . . . . . . . . . 4 60 2.2 Forwarding Plane (Packet Switching Element) . . . . . . . . 4 61 2.3 Motivation for separation of Route Controller and Packet 62 Switching Elements(s) . . . . . . . . . . . . . . . . . . . 5 63 2.4 Different constructions of RC and PSE(s) . . . . . . . . . . 6 64 3. Packet Switching Element Conceptual Model . . . . . . . . . . . 7 65 3.1 Typical PSE model . . . . . . . . . . . . . . . . . . . . . 7 66 3.1.1 I/P Block (Input Processing) . . . . . . . . . . . . . . 7 67 3.1.2 O/P Block (Output Processing) . . . . . . . . . . . . . 8 68 3.1.3 Forwarding Block . . . . . . . . . . . . . . . . . . . . 8 69 3.1.3.1 Forwarding block model . . . . . . . . . . . . . . . 8 70 3.1.3.2 Context Selection Block . . . . . . . . . . . . . . 9 71 4. Yang modules . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.1 YANG Module "pse" . . . . . . . . . . . . . . . . . . . . . 11 73 4.2 YANG Module "pse-common-types" . . . . . . . . . . . . . . . 15 74 4.3 Global sub-modules of "pse" . . . . . . . . . . . . . . . . 16 75 4.3.1 YANG sub module "pse-oam" . . . . . . . . . . . . . . . 16 76 4.3.2 YANG submodule "physical-interfaces" . . . . . . . . . . 19 77 4.3.3 YANG submodule "context-selector-table" . . . . . . . . 19 78 4.3.4 YANG submodule "label-table" . . . . . . . . . . . . . . 22 79 4.3.5 YANG submodule "l2tp-table" . . . . . . . . . . . . . . 25 80 4.4 PER Tenant submodules . . . . . . . . . . . . . . . . . . . 27 81 4.4.1 YANG submodule "ip-unicast-table" . . . . . . . . . . . 27 82 4.4.2 YANG submodule "flow-table" . . . . . . . . . . . . . . 29 83 4.4.3 YANG module "ip-next-hop" . . . . . . . . . . . . . . . 29 84 4.4.4 YANG submodule "l2-table" . . . . . . . . . . . . . . . 31 85 4.4.5 YANG submodule "l2-next-hop" . . . . . . . . . . . . . . 32 86 4.4.6 YANG submodule "interface-table" . . . . . . . . . . . . 35 87 4.4.7 YANG submodule "arp-table" . . . . . . . . . . . . . . . 38 88 4.4.8 Yang submodule "arp-proxy-table" . . . . . . . . . . . . 39 89 5. YANG data model tree . . . . . . . . . . . . . . . . . . . . . 40 90 6 Major Contributing Authors . . . . . . . . . . . . . . . . . . . 45 91 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 45 92 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 46 93 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 94 9.1 Normative References . . . . . . . . . . . . . . . . . . . 46 95 9.2 Informative References . . . . . . . . . . . . . . . . . . 46 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 98 1 Introduction 100 This document describes a data model driven API to program a routing 101 and switching system's forwarding plane. It describes the motivations 102 for creating an open API between a router's control and its 103 forwarding plane and lays out the exact mechanisms that can be used 104 by the control plane of a routing system to "program" the forwarding 105 tables and state contained in the forwarding plane and additionally 106 get notifications when that state changes in interesting ways. 108 The document proposes YANG as the modeling language for this purpose 109 and provides the exact models that represent the forwarding state of 110 a routers data plane. 112 Note that this document uses the word "router" to refer to any 113 network packet forwarding device. The mechanisms outlined here are 114 equally applicable to L3 devices (routers), L2 devices (switches), 115 MPLS label switches and any device that's a hybrid. 117 1.1 Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2. Routing and Switching Systems Model 125 Most modern routing and switching systems have two main components: 126 the control plane and the data plane. Traditionally these systems 127 implement proprietary closed communication between the control and 128 the data plane. 130 2.1 Control Plane (Route Controller) 132 The control plane typically implements different functions on a 133 routing and switching system, which include open interfaces for 134 external management and orchestration, an interface to retrieve 135 operational data, routing and switching control protocols to interact 136 with other network elements, route computation and database to store 137 computed results (RIB) and internal event handling infrastructure 138 that glues these control components together. 140 The rest of the document will refer to the control plane as the 141 "route controller" or just RC. 143 2.2 Forwarding Plane (Packet Switching Element) 144 The forwarding plane performs the forwarding functions on packets 145 received on physical interfaces as per the control directives and 146 state added by the control plane. It also informs the control plane 147 of local events and various operational state so that the control 148 plane can take the necessary actions. 150 The rest of this document will refer to the forwarding plane as the 151 "packet switching element" or just PSE. 153 The PSE has the following functional modules: 155 1. An PSE control agent that interfaces with the control plane. The 156 agent supports the protocol that is used to communicate with the 157 route controller. It processes the forwarding table and interface 158 updates sent by the controller and populates the forwarding tables 159 that the packet processing logic needs. 161 2. Packet processing module that performs the actual packet 162 forwarding and packet manipulation actions. It has a set of 163 forwarding and interface tables that it uses to lookup both runtime 164 and configuration state. The packet processing module also collects 165 various statistics and error counters, as well as generates events. 167 2.3 Motivation for separation of Route Controller and Packet Switching 168 Elements(s) 170 The advent of software defined networking (SDN) and virtualization 171 have opened up many well understood reasons for creating an open 172 interface between the route controller (RC) and forwarding element 173 (PSE). The reasons include but not limited to such factors as, (a) 174 being able to run the route controller on commodity x86 servers and 175 still be able to control the data plane of legacy devices, (b) being 176 able to create interesting routing and bridging topologies and 177 realizing policies at the forwarding plane, (c) modularizing the 178 interface allows best in class products to be assembled without a 179 vendor "lock-in" and the innovation that such a model provides and 180 (d) the cost savings provided by the de-coupled model where a central 181 control plane can provide better control and efficiency in directing 182 packet flows than the traditional distributed protocol based control 183 plane. 185 In short the benefits of software driven networking can be 186 effectively realized by decoupling the route controller and packet 187 switching elements and providing an open interface between the two. 189 An important consideration in providing this modularity is the 190 'reuse' of technology concepts instead of reinventing a brand new 191 mechanism at the data plane level just to provide an open interface. 192 There are many downsides to creating a new data plane model than the 193 well understood 'IP routing' or 'L2 switching' models - the foremost 194 of them being that existing equipment where the hardware behavior is 195 'baked' in have to be forklift upgraded and replaced with devices 196 that support the new forwarding model. Even if one were to ignore the 197 impracticality of such a solution, one cannot ignore the investment 198 loss in rendering all the legacy devices useless. 200 A more practical approach to solving the control and data plane 201 separation is to provide an interface to these devices that use 202 existing data plane concepts and objects such as IP prefixes, L2 mac 203 entries, next-hops (direct and recursive), vlans, MPLS labels, tunnel 204 encapsulations, interfaces/ports, ECMP forwarding and VRF containers. 206 Most devices understand these concepts and objects and use these 207 concepts and objects to classify and forward data traffic. The idea 208 behind IPSE is to create an abstraction layer to these forwarding 209 objects that allows an external control plane to communicate with a 210 forwarding plane to program these objects. The packet switching 211 element (PSE) itself could be both hardware or software based. 213 Software based PSE's are increasingly becoming popular especially in 214 data center and cloud use cases where multi-tenanted topologies can 215 be rapidly created by installing a software switch/router in the 216 server hosting the cloud and data center applications and using a 217 central controller to program their forwarding tables [VPE DRAFT]. 219 2.4 Different constructions of RC and PSE(s) 221 While the RC and PSEs can be separated from a communication 222 perspective as outlined in the previous section, there are two 223 distinct ways they can be packaged to work with each other. 225 The more traditional packaging involves both these functions co- 226 located in a single device (for instance within a router chassis). 227 The de-coupling of the controller and PSE enables them to be 228 separated out with the RC running in a different device than the PSE. 229 This might be desirable, because, the controller as an application 230 has different functional, performance and scale characteristics that 231 it would be inefficient and suboptimal for it to be coupled with the 232 forwarding elements. 234 One of the benefits of the model based approach to the separation of 235 RC and PSE is that, as long as the PSE(s) implements the models 236 described in this document and can have a back-end that can honor the 237 semantics of the models defined here, the PSE could be either 238 software based or hardware based. 240 This allows for integration of not just software based forwarding 241 elements but can also include hardware forwarding elements (legacy 242 router forwarding plane) as long as the forwarding plane implements 243 the YANG models defined in this document. 247 Lastly, when it comes to routing and reachability, the approach we 248 take to scale the system is to treat the RC and PSE(s) as have been 249 viewed traditionally. IOW, a set of PSE(s) can be programmed by a RC. 250 An RC could have a redundant RC to back it up in case of failure. Two 251 such complexes (with RCs and PSE(s)) would then talk to each other 252 using traditional routing protocols. From this standpoint, there 253 should be no impact to the scalability or the distributed nature of 254 existing routing systems due to the de-coupling of RC's and PSE(s). 255 This alignment to an existing routing model also allows one to keep 256 certain operational aspects intact with respect to the RC/PSE 257 construction. When properly built, the fact that RC and PSE(s) are 258 de-coupled need not be exposed to operational systems. 260 3. Packet Switching Element Conceptual Model 262 This section describes in brief the conceptual model for the packet 263 switching element (PSE). It describes the various functional blocks 264 and typical forwarding chains that a packet may pass through within 265 the PSE. The various tables specified in the data model in the 266 subsequent section contain the state needed to carry out the packet 267 processing described here. 269 3.1 Typical PSE model 271 In the packet forwarding path, an PSE consists of the following high- 272 level logical blocks. 274 +------------+ +-----------+ +------------+ 275 In-Phy --->| I/P Block |--+->|Forwarding |-+--> | O/P Block |--> Out-Phy 276 |(ACL,QoS,..)| | +-----------+ | |(ACL,QoS,..)| 277 +------------+ | | +------------+ 278 + ---<---<---<---v 280 In-Phy : A physical interface via which packets are received by the device. 281 Out-Phy : A physical interface via which packets are transmitted out of the 282 device. 284 3.1.1 I/P Block (Input Processing) 286 This is a logical packet processing block at the input to a routing 287 or switching device. This block acts upon the packet based on the 288 interface properties and packet attributes. It also generates the 289 necessary inputs to the forwarding block. 291 A device contains two broad categories of interfaces - those facing 292 the edge or providing access to an edge network or device, and those 293 facing the core network. The input (and output) processing logic 294 applies to both categories, though the rules and actions performed 295 might be different. 297 3.1.2 O/P Block (Output Processing) 299 This is a logical packet processing block at the output stage of 300 packet forwarding. This block typically applies the output features 301 such as output port policing, queuing and filtering before 302 transmitting the packet out on the physical port. 304 3.1.3 Forwarding Block 306 This is the block that contains the various forwarding and adjacency 307 tables, and the logic that does the forwarding table lookups and 308 packet rewrites. This document focusses on the models required to 309 describe the behavior and state required by the forwarding block. 311 Depending on the type of an incoming packet, it is possible to do 312 forwarding based on different attributes or combinations of 313 attributes in the packet header. Each of these attributes can be 314 considered as a forwarding class, and a given packet may be subject 315 to multiple of them, based on user requirements. 317 The forwarding-class selector logic identifies the fields in the 318 packet header that will be used to do the lookup for each forwarding- 319 class supported on the device. The lookup occurs in a specific table 320 for that class. 322 There is a logically separate FIB table for each class. Additionally, 323 a device may support multiple logical instances of each table, for 324 example, an IP FIB per VRF. 326 3.1.3.1 Forwarding block model 327 +------------------------------+ 328 | | 329 | Route Lookup, | 330 +-----------+ | Next-Hop Selection & | 331 ---+------->| Context |--->| Packet Rewrite |-------+---> 332 | (A) | Selection |(B) | +-------++-------++-------+ | (C) | 333 | +-----------+ | |Context||Context||Context| | | 334 | | |global ||'pepsi'||'coke' | | | 335 | | | || || | | | 336 ^ | |L2,L3, ||L2,L3 ||L2,L3 | | | 337 | | |Tables ||Tables ||Tables | | | 338 | | +-------++-------++-------+ | | 339 | +------------------------------+ | 340 | (Recirculation) | 341 +-----<---------<----------<----------<----------<----------<----+ 343 Forwarding Block 345 Conceptually, there are two components to the forwarding block. The 346 context selection logic and the actual route lookup, next-hop 347 selection and packet rewrite block. The idea is that an incoming 348 packet can be processed completely by these two blocks and then sent 349 out on an output port towards its next-hop. In some cases, however, 350 it might be easier to construct more complex scenarios by 351 recirculating the packet multiple times through these two blocks. 353 For instance, when an MPLS-VPN packet is received in the core facing 354 interface, the packet is encaped with the VPN label. The VPN label is 355 looked up in the global label table, the result of the lookup could 356 point to the final next-hop or to the context ip table in which the 357 ip packet destination should be looked up in to find the final next- 358 hop. It is easier to construct this 'chained' operation by simply 359 recirculating the packet through the 'context selector' and 'route 360 lookup' blocks than constructing a specific chain for this particular 361 scenario. 363 The idea then is to generalize the forwarding actions by decomposing 364 them into a series of 'context selection' followed by 'route lookup' 365 operations than creating static chain of such operations on a per 366 scenario basis. 368 3.1.3.2 Context Selection Block 370 The context-selector block determines the specific forwarding context 371 and the specific table within that context in which to perform the 372 forwarding lookup for an incoming packet. A device may have multiple 373 forwarding contexts to support multi-tenancy. Each forwarding context 374 could have multiple tables to support different types of lookups (L2, 375 IPv4, IPv6, flow, etc). 377 Inputs to the context selection is the received packet itself 378 together with information on the input interface (physical or 379 logical) on which the packet was received. 381 Currently the model supports determination of the context and table 382 based on the switching mode set on the interface or based on the 383 table pointed to by the MPLS VPN label on the packet. 385 The output of the context selection block is the {context, table} 386 pair to perform the lookup on. The output table could be L2, IPv4 or 387 IPv6 based on the packet type and the mode set on the input interface 388 or as implied by the VPN label on the packet. 390 4. Yang modules 392 In this section we describe the different YANG modules implementing 393 the data model for the Packet Switching Elements (PSEs). The 394 following sections will define a hierarchy of tables that are needed 395 to implement the L2, L3, MPLS and flow forwarding functions. 397 As is evident, there are cases where the forwarding lookup has to be 398 scoped by a given 'tenant'. In other cases the lookup has to be 399 performed at a global level. 401 At the top level we will define tables that have global scope i.e. 402 not per tenant. The following are the tables that have global scope, 404 a. The interface table that describe the interfaces attached to the 405 PSE's. 407 b. The Context Selector table that tells the PSE how to map traffic 408 arriving on a physical or logical interface to the tenant L2, L3 or 409 flow forwarding tables. The output of the context selector table is a 410 tenant context and a table name within that context to perform a 411 lookup on. 413 c. The MPLS label table that lists all the MPLS labels and the 414 associated tenant L2, L3 of flow forwarding tables 416 d. The L2 tunnel table that will list all the tenants L2 tunnels for 417 point2point cross-connects 419 e. The OAM table that lists the logical or physical interfaces as 420 well as the end-point prefixes that need to be monitored by the 421 forwarding element. The interface state is monitored through local 422 events such as 'link up' and 'link down'. Prefixes are monitored 423 through OAM protocols such as ICMP or BFD. A change in state of 424 interfaces or prefix reachability could trigger notification to the 425 route controller to ensure service assurance and continuity. 427 Then we will be defining the per tenant forwarding table hierarchy, 428 in which we will define both L2, L3 and flow forwarding tables and 429 the corresponding L2 and L3 next-hops. 431 4.1 YANG Module "pse" 433 The Packet Switching Element (PSE) module is the top level module 434 that allows for provisioning and managing a set of global tables and 435 tenant specific tables. The module defines read-only variables that 436 allows the route controller to query for PSE's forwarding 437 capabilities and features that are supported by the PSE that can be 438 turned on or utilized by the RC. 440 It allows for provisioning for IPv4, IPv6, L2, MPLS Label & Flow 441 forwarding tables based on device capabilities. 443 As the top level table, it includes other tables (such as interface 444 table, arp table, L3 and L2 tables) that are needed to perform packet 445 forwarding. 447 module pse { 448 namespace "http://www.cisco.com/yang-modules/ipse/pse"; 449 prefix "pset"; 450 import ietf-inet-types { 451 prefix "inet"; 452 } 454 import pse-common-types { 455 prefix "ct"; 456 } 458 include interface-table; 459 include context-selector-table; 460 include arp-table; 461 include arp-proxy-table; 462 include l2tp-table; 463 include pse-oam; 464 include ip-unicast-table; 465 include l2-table; 466 include flow-table; 467 include label-table; 468 description "PSE stands for Packet Switching Element. 469 The module allows for provisioning and managing multi-tenant 470 forwarding tables in a network device. Currently supports 471 IPv4, IPv6, L2 & Flow forwarding entries based on device 472 capabilities. This module extended to support multicast in 473 future"; 475 organization "Cisco Systems"; 476 contact "employee@cisco.com"; 478 revision 2013-12-05 { 479 description "Initial revision."; 480 } 482 container pse-global-features { 483 description "PSE capabilities and features (read only)"; 484 config false; 486 leaf ready { 487 description "Once the controller connects to the pse it 488 can be notified (or it can query) about the pse state to 489 check if pse is READY"; 491 type boolean; 492 } 494 leaf ip-unicast-forwarding { 495 description "This feature indicates that the device 496 implements IPv4 based unicast forwarding"; 498 type boolean; 499 } 501 leaf l2-forwarding { 503 description "This feature indicates that the device 504 implements forwarding based on L2 addresses"; 506 type boolean; 507 } 509 leaf flow-forwarding { 511 description "This feature indicates that the device 512 implements flow forwarding based on (src-ip, dst-ip, 513 src-port, dst-port, protocol)"; 515 type boolean; 517 } 519 uses ip-unicast-features; 520 uses l2-features; 521 uses flow-features; 522 } 524 container pse-oam { 526 description "This global table can be used to determine 527 the health status of objects - such as interface state 528 and reachability of a prefix" 529 uses pse-oam; 530 } 532 container sync { 533 leaf sync-state { 534 description "Used to Synchronize PSE tables. These 535 variables could be used by the route controller to 536 indicate the start and end of a route download operation"; 538 type enumeration { 539 enum sync-start; 540 enum sync-complete; 541 } 542 } 543 } 545 container context-selector-table { 546 uses context-selector-table; 547 } 549 uses label-table; 551 container interface-table { 552 uses if-table; 553 } 555 container protocol-addresses { 557 container ipv4 { 558 container table { 559 uses ct:table-name; 560 } 561 leaf source-address { 562 type inet:ipv4-address; 563 } 564 leaf dhcp-address { 565 type inet:ipv4-address; 566 } 567 leaf gateway-address { 568 type inet:ipv4-address; 569 } 570 } 572 container ipv6 { 573 container table { 574 uses ct:table-name; 575 } 576 leaf source-address { 577 type inet:ipv6-address; 578 } 579 leaf dhcp-address { 580 type inet:ipv6-address; 581 } 582 leaf gateway-address { 583 type inet:ipv6-address; 584 } 585 } 586 } 588 uses l2tp-table; 590 list pse-contexts { 592 description "This list represents a provisioned list of packet 593 forwarding contexts. Each context could represent a distinct 594 tenant and network address space. Forwarding tables and other 595 policy parameters related to routing, addressing, forwarding 596 are assumed to be defined within a pse context. Each pse 597 context is uniquely identified by a name"; 599 key pse-context-name; 601 leaf pse-context-name { 602 type string; 603 } 605 list tables { 606 description 607 "list of forwarding tables within the context, indexed 608 by unique table's name "; 610 key table-name; 612 leaf table-name { 613 type string; 614 description "Instance of a forwarding table identified 615 by name"; 616 } 618 leaf pse-vpn-id { 619 type string; 620 description "VPN-ID used by DHCP"; 621 } 623 choice pse-table-type { 624 case ip-unicast-table { 626 container arp-table { 627 uses arp-table; 628 } 630 container arp-proxy-table { 631 uses arp-proxy-table; 632 } 634 container ip-unicast-table { 635 uses ip-unicast-table; 636 } 637 } 639 case l2-table { 640 container l2-table { 641 uses l2-table; 642 } 643 } 645 case flow-table { 646 container flow-table { 647 uses flow-table; 648 } 649 } 650 } 651 } 652 } 653 } 655 4.2 YANG Module "pse-common-types" 657 This module defines some common types used by all the modules and sub 658 modules defined in this document. 660 module pse-common-types { 661 namespace "http://www.cisco.com/yang-modules/ipse/pse-common-types"; 662 prefix "psect"; 664 revision "2013-12-05" { 665 description "Initial revision."; 666 } 668 grouping table-name { 669 description "The unique table's name is specified by PSE 670 context-name, and the table's name within the context"; 672 leaf pse-ctx-name { 673 description "The name of PSE context"; 674 type string; 675 } 677 leaf ctx-tbl-name { 678 description "The name of table within PSE context"; 679 type string; 680 } 681 } 683 typedef interfaceName { 684 type string; 685 } 687 typedef interfaceLogicalUnit { 688 type int32 { 689 range "0..9999"; 690 } 691 } 693 typedef prefixLengthIPv4 { 694 type int32 { 695 range "0..32"; 696 } 697 } 699 typedef prefixLengthIPv6 { 700 type int32 { 701 range "0..128"; 702 } 703 } 704 } 706 4.3 Global sub-modules of "pse" 708 4.3.1 YANG sub module "pse-oam" 709 This sub module defines the provisioned and operational list of 710 interfaces and prefixes to be monitored by the devices implementing 711 the PSE. 713 submodule pse-oam { 715 belongs-to pse { 716 prefix "pset"; 717 } 719 import pse-common-types { 720 prefix "ct"; 721 } 723 import ietf-inet-types { 724 prefix "inet"; 725 } 727 organization "Cisco Systems"; 728 contact "joe@acme.example.com"; 729 description 730 "OAM Status for PSE "; 731 revision 2013-12-05 { 732 description "Initial revision."; 733 } 735 grouping pse-oam { 737 container prefix-table { 738 list unicast-prefix { 739 description 740 "This list defines the prefixes to be monitored by OAM."; 741 key "prefix"; 743 leaf prefix { 744 type inet:ip-prefix; 745 } 746 } 747 } 749 container interface-table { 750 list interfaces { 751 description 752 "This list defines the interfaces to be monitored by OAM"; 754 key "interface-name"; 756 leaf interface-name { 757 type ct:interfaceName; 758 } 759 } 760 } 762 container oper-prefix-down-table { 763 config false; 765 list oper-prefix-down-list { 766 description 767 "This list defines the prefixes oper down state monitored 768 by OAM"; 770 key "version"; 772 leaf version { 773 description "Version "; 774 type uint32; 775 } 777 leaf prefix { 778 type inet:ip-prefix; 779 } 780 } 781 } 783 container oper-interface-down-table { 785 config false; 787 list oper-interfaces-down-list { 788 description 789 "This list defines the interfaces oper down state 790 monitored by OAM"; 792 key "version"; 794 leaf version { 795 description "Version "; 796 type uint32; 797 } 799 leaf interface-name { 800 type ct:interfaceName; 801 } 802 } 803 } 804 } 806 } 808 4.3.2 YANG submodule "physical-interfaces" 810 This submodule defines the list of physical interfaces discovered on 811 the devices implementing the PSE. 813 submodule physical-interfaces { 815 belongs-to pse-tables { 816 prefix "pset"; 817 } 819 import pse-common-types { 820 prefix "ct"; 821 } 823 organization "Cisco Systems"; 824 contact "employee@cisco.com"; 826 description 827 "The module list the operational physical interfaces"; 829 revision 2013-12-05 { 830 description "Initial revision."; 831 } 833 grouping physical-interfaces { 834 container physical-interfaces { 835 config false; 836 list interfaces { 837 description 838 " This list define the physical interfaces discovered 839 on end server"; 840 key "interface-name"; 842 leaf interface-name { 843 type ct:interfaceName; 844 } 845 } 846 } 847 } 848 } 850 4.3.3 YANG submodule "context-selector-table" 852 This submodule defines the list of per tenant selector types. 854 submodule context-selector-table { 856 belongs-to pse-tables { 857 prefix "pset"; 858 } 860 import pse-common-types { 861 prefix "ct"; 862 } 864 organization "Cisco Systems"; 865 contact "joe@acme.example.com"; 867 description 868 "The module maps incoming traffic to the forwarding table"; 870 revision 2013-12-05 { 871 description "Initial revision."; 872 } 874 typedef tbl-selection-type { 875 type enumeration { 876 enum ipv4 { 877 description "The table for IPv4 traffic is derived 878 from interface configuration"; 879 } 880 enum ipv6 { 881 description "The table for IPv6 traffic is derived 882 from interface configuration"; 883 } 884 enum l2-table { 885 description "The table for L2 lookup is derived 886 from interface configuration"; 887 } 888 enum flow-table { 889 description "The table for flow based forwarding is 890 derived from interface configuration"; 891 } 892 } 893 } 895 grouping context-selector-table { 896 container label-ctx-selection-table { 897 list label-entry { 898 key label; 899 leaf label { 900 type uint32; 901 } 902 container disposition-table { 903 uses ct:table-name; 904 } 905 } 906 } 908 container interface-ctx-selector-table { 909 list interfaces { 910 description 911 " This list define the table selection mechanism 912 on interface"; 914 key "interface-name selection-type"; 915 leaf interface-name { 916 type ct:interfaceName; 917 } 919 leaf selection-type { 920 type tbl-selection-type; 921 } 923 choice tbl-selection-type { 924 case ipv4 { 925 container ipv4-table { 926 uses ct:table-name; 927 } 928 } 929 case ipv6 { 930 container ipv6-table { 931 uses ct:table-name; 932 } 933 } 934 case l2-table { 935 container ipv6-table { 936 uses ct:table-name; 937 } 938 } 939 case flow-table { 940 container ipv6-table { 941 uses ct:table-name; 942 } 943 } 944 } 945 } 946 } 947 } 948 } 950 4.3.4 YANG submodule "label-table" 952 This submodule defines the list of MPLS labels pointing to the 953 different per tenant L2 and L3 tables. 955 submodule label-table { 957 belongs-to pse-tables { 958 prefix "pset"; 959 } 961 import ietf-inet-types { 962 prefix "inet"; 963 } 965 import ietf-yang-types { 966 prefix "yang"; 967 } 969 import pse-common-types { 970 prefix "ct"; 971 } 973 organization "Cisco Systems"; 974 contact "joe@acme.example.com"; 976 description 977 "The module defines a forwarding tables based on IpV4/V6 addresses"; 979 revision 2013-12-05 { 980 description "Initial revision."; 981 } 983 grouping out-label-stats { 984 leaf packets { 985 type yang:counter64; 986 } 988 leaf bytes { 989 type yang:counter64; 990 } 991 } 993 grouping mpls-next-hop { 994 choice ip-next-hop-type { 995 case ip-nh-type { 996 description 997 "Specifies the content of unicast IP next-hop"; 998 leaf ip-next-hop { 999 type inet:ip-address; 1000 } 1002 leaf interface { 1003 type ct:interfaceName; 1004 } 1006 container nh-tbl-name { 1007 uses ct:table-name; 1008 } 1009 } 1011 case ip-nh-type-mpls-gre { 1012 leaf local-gre-addr { 1013 type inet:ip-address; 1014 } 1015 leaf remote-gre-addr { 1016 type inet:ip-address; 1017 } 1018 container nh-gre-tbl-name { 1019 uses ct:table-name; 1020 } 1022 leaf mpls-label { 1023 type uint32; 1024 } 1026 leaf gre-key { 1027 type uint32; 1028 } 1029 } 1031 case ip-nh-type-vxlan { 1032 leaf local-vxlan-addr { 1033 type inet:ip-address; 1034 } 1036 leaf remote-vxlan-addr { 1037 type inet:ip-address; 1038 } 1040 leaf vxlan-id { 1041 type uint32; 1042 } 1043 } 1044 } 1045 leaf label { 1046 description "output label"; 1047 type uint32; 1048 } 1050 leaf label-type { 1051 type enumeration { 1052 enum valid { 1053 description "valid output label"; 1054 } 1055 enum pop { 1056 description "pop-and-forward"; 1057 } 1058 } 1059 } 1061 container next-hop-stats { 1062 config false; 1063 uses out-label-stats; 1064 } 1065 } 1067 grouping mpls-nh-array { 1068 list mpls-nh-array { 1069 key next-hop-index; 1070 leaf next-hop-index { 1071 type uint8; 1072 description "The numerical index of next-hop in 1073 next-hop array"; 1074 } 1076 leaf nh-weight { 1077 type uint32; 1078 } 1080 uses mpls-next-hop; 1081 } 1082 } 1084 typedef LocalLabelType { 1085 type enumeration { 1086 enum head-prefix { 1087 description "LSP head per-prefix label"; 1088 } 1089 enum label-xconnect { 1090 description "Midpoint label"; 1091 } 1092 } 1094 } 1096 grouping local-label-attributes { 1097 leaf local-label-type { 1098 type LocalLabelType; 1099 description "label type"; 1100 } 1102 choice local-label-type-choice { 1103 case head-prefix { 1104 leaf prefix { 1105 type inet:ip-prefix; 1106 } 1107 container pref-table { 1108 uses ct:table-name; 1109 } 1110 } 1111 } 1112 } 1114 grouping label-table { 1115 list label-table { 1116 key "local-label"; 1118 leaf local-label { 1119 description "input label"; 1120 type uint32; 1121 } 1123 container label-attributes { 1124 uses local-label-attributes; 1125 } 1127 uses mpls-nh-array; 1128 } 1129 } 1130 } 1132 4.3.5 YANG submodule "l2tp-table" 1134 This submodule defines the list of per tenant layer 2 tunnel protocol 1135 (l2tp) point2point cross connects. 1137 submodule l2tp-table { 1139 belongs-to pse-tables { 1140 prefix "pset"; 1141 } 1142 import ietf-inet-types { 1143 prefix "inet"; 1144 } 1146 import pse-common-types { 1147 prefix "ct"; 1148 } 1150 organization "Cisco Systems"; 1151 contact "joe@acme.example.com"; 1153 description 1154 "L2TP v3/v6 tables"; 1156 revision 2013-12-05 { 1157 description "Initial revision."; 1158 } 1160 grouping l2tp-table { 1161 list l2tp { 1162 key "src-addr dst-addr session-id"; 1164 leaf src-addr { 1165 type inet:ip-address; 1166 } 1168 leaf dst-addr { 1169 type inet:ip-address; 1170 } 1172 leaf session-id { 1173 type uint32; 1174 } 1176 leaf src-cookie { 1177 type uint32; 1178 } 1180 leaf dst-cookie { 1181 type uint32; 1182 } 1184 leaf interface-name { 1185 type ct:interfaceName; 1186 } 1187 } 1188 } 1189 } 1191 4.4 PER Tenant submodules 1193 4.4.1 YANG submodule "ip-unicast-table" 1195 This submodule defines the per tenant ipv4/v6 forwarding tables. 1197 submodule ip-unicast-table { 1199 belongs-to pse-tables { 1200 prefix "pset"; 1201 } 1203 import ietf-yang-types { 1204 prefix "yang"; 1205 } 1207 import iana-afn-safi { 1208 prefix "ianaaf"; 1209 } 1211 import ietf-inet-types { 1212 prefix "inet"; 1213 } 1215 import ip-next-hop { 1216 prefix "ipnh"; 1217 } 1218 organization "Cisco Systems"; 1219 contact "joe@acme.example.com"; 1221 description 1222 "The module defines a forwarding tables based on IpV4/V6 addresses"; 1224 revision 2013-12-05 { 1225 description "Initial revision."; 1226 } 1228 grouping ip-unicast-features { 1230 container ipv4-unicast-features { 1231 description "This feature indicates that the device 1232 implements IPv4 based unicast forwarding"; 1234 container ipv4-features { 1235 uses ipnh:ip-next-hop-features; 1236 } 1237 } 1238 container ipv6-unicast-features { 1240 description "This feature indicates that the device 1241 implements IPv6 based unicast forwarding"; 1243 container ipv6-features { 1244 uses ipnh:ip-next-hop-features; 1245 } 1246 } 1247 } 1249 grouping ip-tbl-attribute { 1250 leaf afi { 1251 description "Type of IP table: ipv4/ipv6"; 1252 type ianaaf:address-family; 1253 } 1254 } 1256 grouping prefix-stats { 1257 leaf packets { 1258 type yang:counter64; 1259 } 1261 leaf bytes { 1262 type yang:counter64; 1263 } 1264 } 1266 grouping ip-unicast-table { 1268 container ip-tbl-attrs { 1269 uses ip-tbl-attribute; 1270 } 1272 list unicast-prefix { 1273 key "prefix"; 1275 leaf prefix { 1276 type inet:ip-prefix; 1277 } 1279 uses ipnh:ip-nh-array; 1281 container per-prefix-stats { 1282 config false; 1283 uses prefix-stats; 1285 } 1287 } 1288 } 1289 } 1291 4.4.2 YANG submodule "flow-table" 1293 This submodule defines the per tenant flow tables to allow for per 1294 flow forwarding across devices implementing the PSE. 1296 TBD. 1298 4.4.3 YANG module "ip-next-hop" 1300 This submodule defines per tenant the list of different L3 next hops 1301 that can be pointed at by L2 and L3 prefixes in the L2 or L3 tables. 1303 module ip-next-hop { 1305 namespace "http://www.cisco.com/something/something-else/context1"; 1306 prefix "ipnh"; 1308 import ietf-inet-types { 1309 prefix "inet"; 1310 } 1312 import pse-common-types { 1313 prefix "ct"; 1314 } 1316 description 1317 "The module defines a set of next-hop tables 1318 specific forwarding tables can be derived"; 1320 revision 2013-12-05 { 1321 description "Initial revision."; 1322 } 1324 grouping ip-next-hop-features { 1325 leaf ecmp-supported { 1326 type boolean; 1327 } 1329 leaf ucmp-supported { 1330 type boolean; 1331 } 1332 leaf max-mp-next-hops { 1333 type uint32; 1334 } 1336 container nh-type-supported { 1337 leaf nh-type-regular { 1338 type boolean; 1339 } 1341 leaf nh-type-mpls-over-gre { 1342 type boolean; 1343 } 1345 leaf nh-type-vxlan { 1346 type boolean; 1347 } 1348 } 1349 } 1351 grouping ip-next-hop { 1352 choice ip-next-hop-type { 1354 case ip-nh-type { 1355 description 1356 "Specifies the content of unicast IP next-hop"; 1357 leaf ip-next-hop { 1358 type inet:ip-address; 1359 } 1361 leaf interface { 1362 type ct:interfaceName; 1363 } 1365 container nh-tbl-name { 1366 uses ct:table-name; 1367 } 1368 } 1370 case ip-nh-type-mpls-gre { 1371 leaf local-gre-addr { 1372 type inet:ip-address; 1373 } 1375 leaf remote-gre-addr { 1376 type inet:ip-address; 1377 } 1379 container nh-gre-tbl-name { 1380 uses ct:table-name; 1381 } 1383 leaf mpls-label { 1384 type uint32; 1385 } 1387 leaf gre-key { 1388 type uint32; 1389 } 1390 } 1392 case ip-nh-type-vxlan { 1393 leaf local-vxlan-addr { 1394 type inet:ip-address; 1395 } 1397 leaf remote-vxlan-addr { 1398 type inet:ip-address; 1399 } 1401 leaf vxlan-id { 1402 type uint32; 1403 } 1404 } 1405 } 1406 } 1408 grouping ip-nh-array { 1409 list ip-nh-array { 1410 key next-hop-index; 1411 leaf next-hop-index { 1412 type uint8; 1413 description "The numerical index of next-hop in 1414 next-hop array"; 1415 } 1417 leaf nh-weight { 1418 type uint32; 1419 } 1421 uses ip-next-hop; 1422 } 1423 } 1424 } 1426 4.4.4 YANG submodule "l2-table" 1427 This submodule defines the per tenant L2 tables keyed by L2 MAC 1428 addresses. 1430 submodule l2-table { 1432 belongs-to pse-tables { 1433 prefix "pset"; 1434 } 1436 import ietf-yang-types { 1437 prefix "yang"; 1438 } 1440 import l2-next-hop { 1441 prefix "l2nh"; 1442 } 1444 organization "Cisco Systems"; 1445 contact "joe@acme.example.com"; 1447 description 1448 "The module defines a forwarding tables based on L2 MAC addresses"; 1450 revision 2013-12-05 { 1451 description "Initial revision."; 1452 } 1453 grouping l2-features { 1454 uses l2nh:l2-next-hop-features; 1455 } 1457 grouping l2-table { 1458 list L2-table { 1459 key "dst-mac"; 1461 leaf dst-mac { 1462 type yang:mac-address; 1463 } 1465 uses l2nh:l2-nh-array; 1466 } 1467 } 1468 } 1470 4.4.5 YANG submodule "l2-next-hop" 1472 This submodule defines per tenant the list of different L2 next hops 1473 that can be pointed at by L2 and L3 prefixes in the L2 or L3 tables. 1475 module l2-next-hop { 1477 namespace "http://www.cisco.com/something/something-else/context3"; 1478 prefix "l2nh"; 1480 import ietf-inet-types { 1481 prefix "inet"; 1482 } 1484 import pse-common-types { 1485 prefix "ct"; 1486 } 1488 description 1489 "The module defines a set of next-hop tables 1490 specific forwarding tables can be derived"; 1492 revision 2013-12-05 { 1493 description "Initial revision."; 1494 } 1496 grouping l2-next-hop-features { 1497 leaf l2-ecmp-supported { 1498 type boolean; 1499 } 1501 leaf l2-ucmp-supported { 1502 type boolean; 1503 } 1505 leaf l2-max-mp-next-hops { 1506 type uint32; 1507 } 1509 container l2-nh-type-supported { 1510 leaf nh-type-if { 1511 type boolean; 1512 } 1514 leaf nh-type-mpls-over-gre { 1515 type boolean; 1516 } 1518 leaf nh-type-vxlan { 1519 type boolean; 1520 } 1521 } 1522 } 1523 grouping l2-next-hop { 1525 choice l2-next-hop-type { 1527 case l2-nh-type-if { 1528 leaf l2-nh-if { 1529 type ct:interfaceName; 1530 } 1531 } 1533 case l2-nh-type-mpls-over-gre { 1534 leaf local-gre-addr { 1535 type inet:ip-address; 1536 } 1538 leaf remote-gre-addr { 1539 type inet:ip-address; 1540 } 1542 leaf gre-key { 1543 type uint32; 1544 } 1546 leaf mpls-label { 1547 type uint32; 1548 } 1549 } 1551 case l2-nh-type-vxlan { 1552 leaf local-vxlan-addr { 1553 type inet:ip-address; 1554 } 1556 leaf remote-vxlan-addr { 1557 type inet:ip-address; 1558 } 1560 leaf vxlan-id { 1561 type uint32; 1562 } 1563 } 1564 } 1565 } 1567 grouping l2-nh-array { 1568 list l2-nh-array { 1569 key next-hop-index; 1570 leaf next-hop-index { 1571 type uint8; 1572 description "This is an opaque index generated by the 1573 device to uniquely identify a list of 1574 multi-path next-hops"; 1575 } 1577 leaf nh-weight { 1578 type uint32; 1579 } 1581 uses l2-next-hop; 1582 } 1583 } 1584 } 1586 4.4.6 YANG submodule "interface-table" 1588 This submodule defines per tenant table the list of interfaces will 1589 be hosted on a device implementing PSE. 1591 submodule interface-table { 1592 belongs-to pse-tables { 1593 prefix "pse-if"; 1594 } 1595 import ietf-interfaces { 1596 prefix if; 1597 } 1598 import ietf-inet-types { 1599 prefix "inet"; 1600 } 1601 import pse-common-types { 1602 prefix "ct"; 1603 } 1604 description 1605 "Interface table"; 1607 organization "Cisco Systems"; 1608 contact "employee@cisco.com"; 1610 revision 2013-12-05 { 1611 description "Initial revision."; 1612 } 1613 augment "/if:interfaces/if:interface" { 1614 when "if:type = 'ethernetCsmacd' or 1615 if:type = 'ieee8023adLag'"; 1616 leaf vlan-tagging { 1617 type boolean; 1618 default false; 1619 } 1620 } 1621 augment "/if:interfaces/if:interface" { 1622 when "if:type = 'l2vlan'"; 1623 leaf base-interface { 1624 type if:interface-ref; 1625 must "/if:interfaces/if:interface[if:name = current()]" 1626 + "/if:vlan-tagging = 'true'" { 1627 description 1628 "The base interface must have vlan tagging enabled."; 1629 } 1630 } 1631 leaf outer-vlan-id { 1632 type uint16 { 1633 range "1..4094"; 1634 } 1635 must "../base-interface" { 1636 description 1637 "If a vlan-id is defined, a base-interface must 1638 be specified."; 1639 } 1640 } 1641 leaf inner-vlan-id { 1642 type uint16 { 1643 range "1..4094"; 1644 } 1645 must "../base-interface" { 1646 description 1647 "If a vlan-id is defined, a base-interface must 1648 be specified."; 1649 } 1650 } 1651 } 1652 augment "/if:interfaces/if:interface" { 1653 when "if:type = 'ethernetCsmacd'"; 1655 container ethernet { 1656 must "../if:location" { 1657 description 1658 "An ethernet interface must specify the physical 1659 location of the ethernet hardware."; 1660 } 1661 choice transmission-params { 1662 case auto { 1663 leaf auto-negotiate { 1664 type empty; 1666 } 1667 } 1668 case manual { 1669 leaf duplex { 1670 type enumeration { 1671 enum "half"; 1672 enum "full"; 1673 } 1674 } 1675 leaf speed { 1676 type enumeration { 1677 enum "10Mb"; 1678 enum "100Mb"; 1679 enum "1Gb"; 1680 enum "10Gb"; 1681 } 1682 } 1683 } 1684 } 1685 } 1686 } 1687 augment "/if:interfaces/if:interface" { 1688 leaf ip-enabled { 1689 type boolean; 1690 default false; 1691 } 1692 } 1693 augment "/if:interfaces/if:interface" { 1694 leaf base-ip { 1695 type if:interface-ref; 1696 must "/if:interfaces/if:interface[if:name = current()]" 1697 + "/if:ip-enabled = 'true'" { 1698 description 1699 "The base interface must have vlan tagging enabled."; 1700 } 1701 } 1702 leaf ipv4-addr { 1703 type inet:ipv4-address; 1704 must "../base-interface" { 1705 description 1706 "If an ip address is defined, a base-interface must 1707 be specified."; 1708 } 1709 } 1710 leaf ipv4-prefix-length { 1711 type ct:prefixLengthIPv4; 1712 must "../base-interface" { 1713 description 1714 "IPv4 address prefix length"; 1715 } 1716 } 1717 leaf ipv6-addr { 1718 type inet:ipv6-address; 1719 must "../base-interface" { 1720 description 1721 "If an ip address is defined, a base-interface must 1722 be specified."; 1723 } 1724 } 1725 leaf ipv6-prefix-length { 1726 type ct:prefixLengthIPv6; 1727 must "../base-interface" { 1728 description 1729 "IPv6 address prefix length"; 1730 } 1731 } 1732 leaf mtu { 1733 type uint32; 1734 description 1735 "The size, in octets, of the largest packet that the 1736 interface can send and receive. This node might not be 1737 valid for all interface types. 1739 Media-specific modules must specify any restrictions on 1740 the mtu for their interface type."; 1741 } 1742 leaf unnumbered-to-intf { 1743 type if:interface-ref; 1744 } 1745 } 1746 grouping if-table { 1747 leaf table-int { 1748 type if:interface-ref; 1749 } 1750 } 1751 } 1753 4.4.7 YANG submodule "arp-table" 1755 This submodule defines per tenant the list of ARP entries that will 1756 be hosted on a device implementing PSE. 1758 submodule arp-table { 1759 belongs-to pse-tables { 1760 prefix "arp"; 1761 } 1762 import ietf-inet-types { 1763 prefix "inet"; 1764 } 1766 import ietf-yang-types { 1767 prefix "yang"; 1768 } 1770 import pse-common-types { 1771 prefix "ct"; 1772 } 1774 organization "Cisco Systems"; 1775 contact "joe@acme.example.com"; 1777 description 1778 "The module defines a forwarding tables based on IpV4/V6 addresses"; 1780 revision 2013-12-05 { 1781 description "Initial revision."; 1782 } 1784 grouping arp-table { 1785 list arptable { 1786 key "ip-address"; 1787 leaf ip-address { 1788 type inet:ip-address; 1789 } 1791 leaf mac-address { 1792 type yang:mac-address; 1793 description "Destination MAC Address"; 1794 } 1796 leaf interface-name { 1797 type ct:interfaceName; 1798 } 1799 } 1800 } 1801 } 1803 4.4.8 Yang submodule "arp-proxy-table" 1805 This submodule defines per tenant proxy-arp entries that will be 1806 hosted on a device implementing PSE. 1808 submodule arp-proxy-table { 1809 belongs-to pse-tables { 1810 prefix "arp-proxy"; 1811 } 1813 import ietf-inet-types { 1814 prefix "inet"; 1815 } 1817 organization "Cisco Systems"; 1818 contact "joe@acme.example.com"; 1820 description 1821 "The module defines ARP Proxy tables based on IpV4/V6 addresses"; 1823 revision 2013-12-05 { 1824 description "Initial revision."; 1825 } 1827 grouping arp-proxy-table { 1828 list arpproxytable { 1829 key "ip-prefix"; 1830 leaf ip-prefix { 1831 type inet:ip-prefix; 1832 } 1833 leaf gateway-ip-address { 1834 type inet:ip-address; 1835 } 1836 } 1837 } 1838 } 1840 5. YANG data model tree 1842 module: pse-tables 1843 +--ro pse-global-features 1844 | +--ro ready? boolean 1845 | +--ro ip-unicast-forwarding? boolean 1846 | +--ro l2-forwarding? boolean 1847 | +--ro flow-forwarding? boolean 1848 | +--ro ipv4-unicast-features 1849 | | +--ro ipv4-features 1850 | | +--ro ecmp-supported? boolean 1851 | | +--ro ucmp-supported? boolean 1852 | | +--ro max-mp-next-hops? uint32 1853 | | +--ro nh-type-supported 1854 | | +--ro nh-type-regular? boolean 1855 | | +--ro nh-type-mpls-over-gre? boolean 1856 | | +--ro nh-type-vxlan? boolean 1857 | +--ro ipv6-unicast-features 1858 | | +--ro ipv6-features 1859 | | +--ro ecmp-supported? boolean 1860 | | +--ro ucmp-supported? boolean 1861 | | +--ro max-mp-next-hops? uint32 1862 | | +--ro nh-type-supported 1863 | | +--ro nh-type-regular? boolean 1864 | | +--ro nh-type-mpls-over-gre? boolean 1865 | | +--ro nh-type-vxlan? boolean 1866 | +--ro l2-ecmp-supported? boolean 1867 | +--ro l2-ucmp-supported? boolean 1868 | +--ro l2-max-mp-next-hops? uint32 1869 | +--ro l2-nh-type-supported 1870 | | +--ro nh-type-if? boolean 1871 | | +--ro nh-type-mpls-over-gre? boolean 1872 | | +--ro nh-type-vxlan? boolean 1873 | +--ro ecmp-supported? boolean 1874 | +--ro ucmp-supported? boolean 1875 | +--ro max-mp-next-hops? uint32 1876 | +--ro nh-type-supported 1877 | +--ro nh-type-regular? boolean 1878 | +--ro nh-type-mpls-over-gre? boolean 1879 | +--ro nh-type-vxlan? boolean 1880 +--rw pse-oam 1881 | +--rw prefix-table 1882 | | +--rw unicast-prefix [prefix] 1883 | | +--rw prefix inet:ip-prefix 1884 | +--rw interface-table 1885 | | +--rw interfaces [interface-name] 1886 | | +--rw interface-name ct:interfaceName 1887 | +--ro oper-prefix-down-table 1888 | | +--ro oper-prefix-down-list [version] 1889 | | +--ro version uint32 1890 | | +--ro prefix? inet:ip-prefix 1891 | +--ro oper-interface-down-table 1892 | +--ro oper-interfaces-down-list [version] 1893 | +--ro version uint32 1894 | +--ro interface-name? ct:interfaceName 1895 +--rw sync 1896 | +--rw sync-state? enumeration 1897 +--rw context-selector-table 1898 | +--rw label-ctx-selection-table 1899 | | +--rw label-entry [label] 1900 | | +--rw label uint32 1901 | | +--rw disposition-table 1902 | | +--rw pse-ctx-name? string 1903 | | +--rw ctx-tbl-name? string 1904 | +--rw interface-ctx-selector-table 1905 | +--rw interfaces [interface-name selection-type] 1906 | +--rw interface-name ct:interfaceName 1907 | +--rw selection-type tbl-selection-type 1908 | +--rw (tbl-selection-type)? 1909 | +--:(ipv4) 1910 | | +--rw ipv4-table 1911 | | +--rw pse-ctx-name? string 1912 | | +--rw ctx-tbl-name? string 1913 | +--:(ipv6) 1914 | +--rw ipv6-table 1915 | +--rw pse-ctx-name? string 1916 | +--rw ctx-tbl-name? string 1917 +--rw label-table [local-label] 1918 | +--rw local-label uint32 1919 | +--rw label-attributes 1920 | | +--rw local-label-type? LocalLabelType 1921 | | +--rw (local-label-type-choice)? 1922 | | +--:(head-prefix) 1923 | | +--rw prefix? inet:ip-prefix 1924 | | +--rw pref-table 1925 | | +--rw pse-ctx-name? string 1926 | | +--rw ctx-tbl-name? string 1927 | +--rw mpls-nh-array [next-hop-index] 1928 | +--rw next-hop-index uint8 1929 | +--rw nh-weight? uint32 1930 | +--rw (ip-next-hop-type)? 1931 | | +--:(ip-nh-type) 1932 | | | +--rw ip-next-hop? inet:ip-address 1933 | | | +--rw interface? ct:interfaceName 1934 | | | +--rw nh-tbl-name 1935 | | | +--rw pse-ctx-name? string 1936 | | | +--rw ctx-tbl-name? string 1937 | | +--:(ip-nh-type-mpls-gre) 1938 | | | +--rw local-gre-addr? inet:ip-address 1939 | | | +--rw remote-gre-addr? inet:ip-address 1940 | | | +--rw nh-gre-tbl-name 1941 | | | | +--rw pse-ctx-name? string 1942 | | | | +--rw ctx-tbl-name? string 1943 | | | +--rw mpls-label? uint32 1944 | | | +--rw gre-key? uint32 1945 | | +--:(ip-nh-type-vxlan) 1946 | | +--rw local-vxlan-addr? inet:ip-address 1947 | | +--rw remote-vxlan-addr? inet:ip-address 1948 | | +--rw vxlan-id? uint32 1949 | +--rw label? uint32 1950 | +--rw label-type? enumeration 1951 | +--ro next-hop-stats 1952 | +--ro packets? yang:counter64 1953 | +--ro bytes? yang:counter64 1954 +--rw interface-table 1955 | +--rw table-int? if:interface-ref 1956 +--rw protocol-addresses 1957 | +--rw ipv4 1958 | | +--rw table 1959 | | | +--rw pse-ctx-name? string 1960 | | | +--rw ctx-tbl-name? string 1961 | | +--rw source-address? inet:ipv4-address 1962 | | +--rw dhcp-address? inet:ipv4-address 1963 | | +--rw gateway-address? inet:ipv4-address 1964 | +--rw ipv6 1965 | +--rw table 1966 | | +--rw pse-ctx-name? string 1967 | | +--rw ctx-tbl-name? string 1968 | +--rw source-address? inet:ipv6-address 1969 | +--rw dhcp-address? inet:ipv6-address 1970 | +--rw gateway-address? inet:ipv6-address 1971 +--rw l2tp [src-addr dst-addr session-id] 1972 | +--rw src-addr inet:ip-address 1973 | +--rw dst-addr inet:ip-address 1974 | +--rw session-id uint32 1975 | +--rw src-cookie? uint32 1976 | +--rw dst-cookie? uint32 1977 | +--rw interface-name? ct:interfaceName 1978 +--rw pse-contexts [pse-context-name] 1979 +--rw pse-context-name string 1980 +--rw tables [table-name] 1981 +--rw table-name string 1982 +--rw pse-vpn-id? string 1983 +--rw (pse-table-type)? 1984 +--:(ip-unicast-table) 1985 | +--rw arp-table 1986 | | +--rw arptable [ip-address] 1987 | | +--rw ip-address inet:ip-address 1988 | | +--rw mac-address? yang:mac-address 1989 | | +--rw interface-name? ct:interfaceName 1990 | +--rw arp-proxy-table 1991 | | +--rw arpproxytable [ip-prefix] 1992 | | +--rw ip-prefix inet:ip-prefix 1993 | | +--rw gateway-ip-address? inet:ip-address 1994 | +--rw ip-unicast-table 1995 | +--rw ip-tbl-attrs 1996 | | +--rw afi? ianaaf:address-family 1997 | +--rw unicast-prefix [prefix] 1998 | +--rw prefix inet:ip-prefix 1999 | +--rw ip-nh-array [next-hop-index] 2000 | | +--rw next-hop-index uint8 2001 | | +--rw nh-weight? uint32 2002 | | +--rw (ip-next-hop-type)? 2003 | | +--:(ip-nh-type) 2004 | | | +--rw ip-next-hop? inet:ip-address 2005 | | | +--rw interface? ct:interfaceName 2006 | | | +--rw nh-tbl-name 2007 | | | +--rw pse-ctx-name? string 2008 | | | +--rw ctx-tbl-name? string 2009 | | +--:(ip-nh-type-mpls-gre) 2010 | | | +--rw local-gre-addr? inet:ip-address 2011 | | | +--rw remote-gre-addr? inet:ip-address 2012 | | | +--rw nh-gre-tbl-name 2013 | | | | +--rw pse-ctx-name? string 2014 | | | | +--rw ctx-tbl-name? string 2015 | | | +--rw mpls-label? uint32 2016 | | | +--rw gre-key? uint32 2017 | | +--:(ip-nh-type-vxlan) 2018 | | +--rw local-vxlan-addr? inet:ip-address 2019 | | +--rw remote-vxlan-addr? inet:ip-address 2020 | | +--rw vxlan-id? uint32 2021 | +--ro per-prefix-stats 2022 | +--ro packets? yang:counter64 2023 | +--ro bytes? yang:counter64 2024 +--:(l2-table) 2025 | +--rw l2-table 2026 | +--rw L2-table [dst-mac] 2027 | +--rw dst-mac yang:mac-address 2028 | +--rw l2-nh-array [next-hop-index] 2029 | +--rw next-hop-index uint8 2030 | +--rw nh-weight? uint32 2031 | +--rw (l2-next-hop-type)? 2032 | +--:(l2-nh-type-if) 2033 | | +--rw l2-nh-if? ct:interfaceName 2034 | +--:(l2-nh-type-mpls-over-gre) 2035 | | +--rw local-gre-addr? inet:ip-address 2036 | | +--rw remote-gre-addr? inet:ip-address 2037 | | +--rw gre-key? uint32 2038 | | +--rw mpls-label? uint32 2039 | +--:(l2-nh-type-vxlan) 2040 | +--rw local-vxlan-addr? inet:ip-address 2041 | +--rw remote-vxlan-addr? inet:ip-address 2042 | +--rw vxlan-id? uint32 2043 +--:(flow-table) 2044 +--rw flow-table 2045 +--rw afi? ianaaf:address-family 2046 +--rw flow-table 2047 +--rw src-address inet:ip-address 2048 +--rw dst-address inet:ip-address 2049 +--rw src-port uint32 2050 +--rw dst-port uint32 2051 +--rw protocol-type string 2052 +--rw nh-array 2053 +--rw ip-nh-array [next-hop-index] 2054 +--rw next-hop-index uint8 2055 +--rw nh-weight? uint32 2056 +--rw (ip-next-hop-type)? 2057 +--:(ip-nh-type) 2058 | +--rw ip-next-hop? inet:ip-address 2059 | +--rw interface? ct:interfaceName 2060 | +--rw nh-tbl-name 2061 | +--rw pse-ctx-name? string 2062 | +--rw ctx-tbl-name? string 2063 +--:(ip-nh-type-mpls-gre) 2064 | +--rw local-gre-addr? inet:ip-address 2065 | +--rw remote-gre-addr? inet:ip-address 2066 | +--rw nh-gre-tbl-name 2067 | | +--rw pse-ctx-name? string 2068 | | +--rw ctx-tbl-name? string 2069 | +--rw mpls-label? uint32 2070 | +--rw gre-key? uint32 2071 +--:(ip-nh-type-vxlan) 2072 +--rw local-vxlan-addr? inet:ip-address 2073 +--rw remote-vxlan-addr? inet:ip-address 2074 +--rw vxlan-id? uint32 2076 6 Major Contributing Authors 2078 The editors would like to thank Reshad Rahman, Yuri Tsier, and Kausik 2079 Majumdar who made a major contribution to the development of this 2080 document. 2082 Reshad Rahman 2083 Cisco 2084 Email: rrahman@cisco.com 2086 Yuri Tsier 2087 Cisco 2088 Email: ytsier@cisco.com 2090 Kausik Majumdar 2091 Cisco 2092 Email: kmajumda@cisco.com 2094 7 Security Considerations 2095 This document does not introduce any additional security constraints. 2097 8 IANA Considerations 2099 TBD 2101 9 References 2102 9.1 Normative References 2104 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 2105 Requirement Levels", BCP 14, RFC 2119, March 1997. 2106 9.2 Informative References 2108 Authors' Addresses 2110 Rex Fernando 2111 Cisco 2112 Email: rex@cisco.com 2114 Sami Boutros 2115 Cisco 2116 Email: sboutros@cisco.com 2118 Dhananjaya Rao 2119 Cisco 2120 Email: dhrao@cisco.com