--- 1/draft-ietf-i2rs-rib-data-model-05.txt 2016-07-04 00:15:55.888807572 -0700 +++ 2/draft-ietf-i2rs-rib-data-model-06.txt 2016-07-04 00:15:55.996810293 -0700 @@ -1,26 +1,26 @@ Network Working Group L. Wang Internet-Draft Individual Intended status: Standards Track H. Ananthakrishnan -Expires: September 18, 2016 Packet Design +Expires: January 4, 2017 Packet Design M. Chen Huawei A. Dass S. Kini Ericsson N. Bahadur Bracket Computing - March 17, 2016 + July 3, 2016 A YANG Data Model for Routing Information Base (RIB) - draft-ietf-i2rs-rib-data-model-05 + draft-ietf-i2rs-rib-data-model-06 Abstract This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on September 18, 2016. + This Internet-Draft will expire on January 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,136 +64,140 @@ 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 2. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 7 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 8 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 14 2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 18 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 64 - 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 64 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 64 + 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 65 8.2. Informative References . . . . . . . . . . . . . . . . . 65 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 1. Introduction The Interface to the Routing System (I2RS) [I-D.ietf-i2rs-architecture] provides read and write access to the information and state within the routing process that exists inside - the routing elements, this is achieved via the protocol message - exchange between I2RS clients and I2RS agents associated with the - routing system. One of the functions of I2RS is to read and write - data of Routing Information Base (RIB). - [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use - cases. The RIB information model is defined in - [I-D.ietf-i2rs-rib-info-model]. + the routing elements, this is achieved via protocol message exchange + between I2RS clients and I2RS agents associated with the routing + system. One of the functions of I2RS is to read and write data of + Routing Information Base (RIB). [I-D.ietf-i2rs-usecase-reqs-summary] + introduces a set of RIB use cases. The RIB information model is + defined in [I-D.ietf-i2rs-rib-info-model]. This document defines a YANG [RFC6020][RFC6991] data model for the RIB that satisfies the RIB use cases and aligns with the RIB information model. 1.1. Definitions and Acronyms RIB: Routing Information Base Information Model (IM): An abstract model of a conceptual domain, independent of a specific implementation or data representation. 1.2. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. + o Curly braces "{" and "}" contain names of optional features that + make the corresponding node conditional. + o Abbreviations before data node names: "rw" means configuration (read-write) and "ro" state data (read-only). o Symbols after data node names: "?" means an optional node and "*" denotes a "list" and "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 2. Model Structure The following figure shows an overview of structure tree of the ietf- i2rs-rib module. To give a whole view of the structure tree, some details of the tree are omitted. The relevant details are introduced - in the following sub-sections. + in the subsequent sub-sections. module: ietf-i2rs-rib +--rw routing-instance +--rw name string +--rw interface-list* [name] | +--rw name if:interface-ref +--rw router-id? yang:dotted-quad +--rw lookup-limit? uint8 +--rw rib-list* [name] +--rw name string - +--rw rib-family rib-family-def + +--rw address-family rib-family-def +--rw ip-rpf-check? boolean +--rw route-list* [route-index] - +--rw route-index uint64 - +--rw match - | +--rw (route-type)? - | +--:(ipv4) - | | ... - | +--:(ipv6) - | | ... - | +--:(mpls-route) - | | ... - | +--:(mac-route) - | | ... - | +--:(interface-route) - | ... - +--rw nexthop - | +--rw nexthop-id? uint32 - | +--rw sharing-flag? boolean - | +--rw (nexthop-type)? - | +--:(nexthop-base) + | +--rw route-index uint64 + | +--rw match + | | +--rw (route-type)? + | | +--:(ipv4) + | | | ... + | | +--:(ipv6) + | | | ... + | | +--:(mpls-route) + | | | ... + | | +--:(mac-route) + | | | ... + | | +--:(interface-route) | | ... - | +--:(nexthop-chain) {nexthop-chain}? + | +--rw nexthop + | | +--rw nexthop-id? uint32 + | | +--rw sharing-flag? boolean + | | +--rw (nexthop-type)? + | | +--:(nexthop-base) + | | | ... + | | +--:(nexthop-chain) {nexthop-chain}? + | | | ... + | | +--:(nexthop-replicates) {nexthop-replicates}? + | | | ... + | | +--:(nexthop-protection) {nexthop-protection}? + | | | ... + | | +--:(nexthop-load-balance) {nexthop-load-balance}? | | ... - | +--:(nexthop-replicates) {nexthop-replicates}? + | +--rw route-status | | ... - | +--:(nexthop-protection) {nexthop-protection}? + | +--rw route-attributes | | ... - | +--:(nexthop-load-balance) {nexthop-load-balance}? - | ... - +--rw route-statistic - | ... - +--rw route-attributes - | ... - +--rw route-vendor-attributes + | +--rw route-vendor-attributes + +--rw nexthop-list* [nexthop-member-id] + +--rw nexthop-member-id uint32 rpcs: +---x rib-add | +---w input - | | +---w rib-name string - | | +---w rib-family rib-family-def + | | +---w name string + | | +---w address-family rib-family-def | | +---w ip-rpf-check? boolean | +--ro output | +--ro result uint32 | +--ro reason? string +---x rib-delete | +---w input - | | +---w rib-name string + | | +---w name string | +--ro output | +--ro result uint32 | +--ro reason? string +---x route-add | +---w input | | +---w return-failure-detail? boolean | | +---w rib-name string | | +---w routes | | +---w route-list* [route-index] | | ... @@ -289,83 +293,83 @@ | | | ... | | +--:(nexthop-replicates) {nexthop-replicates}? | | | ... | | +--:(nexthop-protection) {nexthop-protection}? | | | ... | | +--:(nexthop-load-balance) {nexthop-load-balance}? | | ... | +--ro nexthop-state nexthop-state-def +---n route-change +--ro rib-name string - +--ro rib-family rib-family-def + +--ro address-family rib-family-def +--ro route-index uint64 +--ro match | +--ro (route-type)? | +--:(ipv4) | | ... | +--:(ipv6) | | ... | +--:(mpls-route) | | ... | +--:(mac-route) | | ... | +--:(interface-route) | ... +--ro route-installed-state route-installed-state-def +--ro route-state route-state-def +--ro route-change-reason route-reason-def - Figure 1: Overview of I2RS Rib Module Structure + Figure 1: Overview of I2RS RIB Module Structure 2.1. RIB Capability RIB capability negotiation is very important because not all of the hardware will be able to support all kinds of nexthops and there - should be a limitation on how many levels of lookup can be - practically performed. Therefore, a RIB data model MUST specify a - way for an external entity to learn about the functional capabilities - of a network device. + might be a limitation on how many levels of lookup can be practically + performed. Therefore, a RIB data model MUST specify a way for an + external entity to learn about the functional capabilities of a + network device. At the same time, nexthop chains can be used to specify multiple headers over a packet, before that particular packet is forwarded. Not every network device will be able to support all kinds of nexthop chains along with the arbitrary number of headers which are chained together. The RIB data model MUST provide a way to expose the nexthop chaining capability supported by a given network device. This module uses the feature and if-feature statements to achieve - above capability negotiation. + above capability advertisement. 2.2. Routing Instance and Rib A routing instance, in the context of the RIB information model, is a collection of RIBs, interfaces, and routing protocol parameters. A routing instance creates a logical slice of the router and can allow - multiple different logical slices; across a set of routers; to - communicate with each other. And the routing protocol parameters - control the information available in the RIBs. More detail about - routing instance can be found in Section 2.2 of + multiple different logical slices, across a set of routers, to + communicate with each other. The routing protocol parameters control + the information available in the RIBs. More detail about routing + instance can be found in Section 2.2 of [I-D.ietf-i2rs-rib-info-model]. - For a routing instance, there will be multiple RIBs. Therefore, this + For a routing instance, there can be multiple RIBs. Therefore, this model uses "list" to express the RIBs. The structure tree is shown - as following figure. + below: +--rw routing-instance +--rw name string +--rw interface-list* [name] | +--rw name if:interface-ref +--rw router-id? yang:dotted-quad +--rw lookup-limit? uint8 +--rw rib-list* [name] +--rw name string - +--rw rib-family rib-family-def + +--rw address-family rib-family-def +--rw ip-rpf-check? boolean +--rw route-list* [route-index] ... (refer to Section 2.3) Figure 2: Routing Instance Structure 2.3. Route A route is essentially a match condition and an action following that match. The match condition specifies the kind of route (e.g., IPv4, @@ -375,26 +379,25 @@ route MUST associate with the following attributes: o ROUTE_PREFERENCE: See Section 2.3 of [I-D.ietf-i2rs-rib-info-model]. o ACTIVE: Indicates whether a route has at least one fully resolved nexthop and is therefore eligible for installation in the FIB. o INSTALLED: Indicates whether the route got installed in the FIB. - In addition, a route can associate with one or more optional route - attributes(e.g., route-vendor-attributes). + In addition, a route can be associated with one or more optional + route attributes (e.g., route-vendor-attributes). - For a RIB, there will have a number of routes, so the routes are - expressed as a list under a specific rib. Each rib has its own route - list. + A RIB will have a number of routes, so the routes are expressed as a + list under a specific rib. Each RIB has its own route list. +--rw route-list* [route-index] +--rw route-index uint64 +--rw match | +--rw (route-type)? | +--:(ipv4) | | +--rw ipv4 | | +--rw (ip-route-match-type)? | | +--:(dest-ipv4-address) | | | ... @@ -419,24 +422,24 @@ | +--rw interface-identifier if:interface-ref +--rw nexthop | ...(refer to Section 2.4) Figure 3: Routes Structure 2.4. Nexthop A nexthop represents an object resulting from a route lookup. As illustrated in Section 2.4 of [I-D.ietf-i2rs-rib-info-model], to - support various of use cases (e.g., load balance, protection, - multicast or the combination of them), the nexthop is modelled as a - multi-level structure and supports recursion. The first level of the - nexthop includes the following four types: + support various use cases (e.g., load balance, protection, multicast + or a combination of them), the nexthop is modeled as a multi-level + structure and supports recursion. The first level of the nexthop + includes the following four types: o Base: The "base" nexthop is the foundation of all other nexthop types. It includes the follow basic nexthops: * nexthop-id * IPv4 address * IPv6 address @@ -482,21 +485,21 @@ | +--:(nexthop-replicates) {nexthop-replicates}? | | +--rw nexthop-replicates | | +--rw nexthop-list* [nexthop-member-id] | | +--rw nexthop-member-id uint32 | +--:(nexthop-protection) {nexthop-protection}? | | +--rw nexthop-protection | | +--rw nexthop-list* [nexthop-member-id] | | +--rw nexthop-member-id uint32 | | +--rw nexthop-preference nexthop-preference-def | +--:(nexthop-load-balance) {nexthop-load-balance}? - | +--rw nexthop-lbs + | +--rw nexthop-lb | +--rw nexthop-list* [nexthop-member-id] | +--rw nexthop-member-id uint32 | +--rw nexthop-lb-weight nexthop-lb-weight-def Figure 4: Nexthop Structure Figure 5 (as shown blow) is a sub-tree of nexthop, it's under the nexthop base node and shows that structure of the "base" nexthop. +--:(nexthop-base) @@ -623,117 +626,115 @@ | | +--rw rib-name? string | +--:(nexthop-identifier) | +--rw nexthop-ref nexthop-ref Figure 5: Nexthop Base Structure 2.5. RPC Operations This module defines the following RPC operations: - o rib-add: It is defined to add a rib to a routing instance. A name - of the rib, address family of the rib and whether the RPF check is - enabled are passed as the input parameters. The output is the + o rib-add: Add a RIB to a routing instance. A name of the rib, + address family of the RIB and (optionally) whether the RPF check + is enabled are passed as the input parameters. The output is the result of the add operation: * true - success; * false - failed; when failed, the i2rs agent may return the specific reason that causes the failure. - o rib-delete: It is defined to delete a rib from a routing instance. - When a rib is deleted, all routes installed in the rib will be - deleted. A name of the rib is passed as the input parameter. The - output is the result of the delete operation: + o rib-delete: Delete a RIB from a routing instance. When a RIB is + deleted, all routes installed in the RIB will be deleted. A name + of the RIB is passed as the input parameter. The output is the + result of the delete operation: * true - success; * false - failed; when failed, the i2rs agent may return the specific reason that causes the failure. - o route-add: It is defined to add a route or a set of routes to a - rib. A rib name, the route prefix(es), route attributes, route - vendor attributes, nexthop and whether return failure detail are - passed as the input parameters. Before calling the route-add rpc, - it is required to call the nh-add rpc to create and/or return the - nexthop identifier. The output is a combination of the route - operation states that include: + o route-add: Add a route or a set of routes to a rib. A RIB name, + the route prefix(es), route attributes, route vendor attributes, + nexthop and whether return failure detail are passed as the input + parameters. Before calling the route-add rpc, it is required to + call the nh-add rpc to create and/or return the nexthop + identifier. The output is a combination of the route operation + states that include: - * success-count: the numbers of routes that are successfully + * success-count: the number of routes that were successfully added; - * failed-count: the numbers of the routes that are failed to be - added; + * failed-count: the number of the routes that failed to be added; - * failure-detail: shows the specific failed routes that failure - reason. + * failure-detail: shows the specific routes that failed to be + added. - o route-delete: It is defined to delete a route or a set of routes - from a rib. A name of the rib, the route prefix(es) and whether - return failure detail are passed as the input parameters. The - output is combination of the route operation states that include: + o route-delete: Delete a route or a set of routes from a rib. A + name of the rib, the route prefix(es) and whether to return + failure detail are passed as the input parameters. The output is + a combination of route operation states that include: - * success-count: the numbers of routes that are successfully + * success-count: the number of routes that were successfully deleted; - * failed-count: the numbers of the routes that are failed to be + * failed-count: the number of the routes that failed to be deleted; - * failure-detail: shows the specific failed routes that failure - reason. + * failure-detail: shows the specific routes that failed to be + deleted. - o route-update: It is defined to update a route or a set of routes. - A rib name, the route prefix(es), or route attributes, or route - vendor attributes, or nexthop are passed as the input parameters. - The match conditions can be either route prefix(es), or route - attributes, or route vendor attributes, or nexthop. The update - actions include: update the nexthop, update the route attributes, - update the route vendor attributes. The output is combination of - the route operation states that include: + o route-update: Update a route or a set of routes. A RIB name, the + route prefix(es), or route attributes, or route vendor attributes, + or nexthop are passed as the input parameters. The match + conditions can be either route prefix(es), or route attributes, or + route vendor attributes, or nexthop. The update actions include: + update the nexthop, update the route attributes, update the route + vendor attributes. The output is combination of the route + operation states that include: - * success-count: the numbers of routes that are successfully + * success-count: the number of routes that were successfully updated; - * failed-count: the numbers of the routes that are failed to be + * failed-count: the number of the routes that failed to be updated; - * failure-detail: shows the specific failed routes that failure - reason. + * failure-detail: shows the specific routes that failed to be + updated. - o nh-add: It is defined to add a nexthop to a rib. A name of the - rib and a nexthop are passed as the input parameters. The network - node is required to allocate a nexthop identifier to the nexthop. - The outputs include the result of the nexthop add operation. + o nh-add: Add a nexthop to a rib. A name of the RIB and a nexthop + are passed as the input parameters. The network node is required + to allocate a nexthop identifier to the nexthop. The outputs + include the result of the nexthop add operation. * true - success; when success, a nexthop identifier will be returned to the i2rs client. * false - failed; when failed, the i2rs agent may return the specific reason that causes the failure. - o nh-delete: It is defined to delete a nexthop from a rib. A name - of a rib and a nexthop or nexthop identifier are passed as the - input parameters. The output is the result of the delete - operation: + o nh-delete: Delete a nexthop from a rib. A name of a RIB and a + nexthop or nexthop identifier are passed as the input parameters. + The output is the result of the delete operation: * true - success; * false - failed; when failed, the i2rs agent may return the specific reason that causes the failure. - The structure tree of rpcs is showing in following figure. + The structure tree of rpcs is shown in following figure. rpcs: +---x rib-add | +---w input | | +---w rib-name string - | | +---w rib-family rib-family-def + | | +---w address-family rib-family-def | | +---w ip-rpf-check? boolean | +--ro output | +--ro result uint32 | +--ro reason? string +---x rib-delete | +---w input | | +---w rib-name string | +--ro output | +--ro result uint32 | +--ro reason? string @@ -806,61 +806,61 @@ | ... +--ro output +--ro result uint32 +--ro reason? string Figure 6: RPCs Structure 2.6. Notifications Asynchronous notifications are sent by the RIB manager of a network device to an external entity when some event triggers on the network - device. A RIB data-model MUST support sending 2 kind of asynchronous - notifications. + device. An implementation of this RIB data model MUST support + sending two kinds of asynchronous notifications. 1. Route change notification: o Installed (Indicates whether the route got installed in the FIB) ; o Active (Indicates whether a route has at least one fully resolved nexthop and is therefore eligible for installation in the FIB) ; o Reason - E.g. Not authorized 2. Nexthop resolution status notification - Nexthops can be fully resolved nexthops or an unresolved nexthop. + Nexthops can be fully resolved or an unresolved. - A resolved nexthop has adequate level of information to send the + A resolved nexthop has an adequate level of information to send the outgoing packet towards the destination by forwarding it on an - interface of a directly connected neighbor. + interface to a directly connected neighbor. An unresolved nexthop is something that requires the RIB manager to - determine the final resolved nexthop. For example, in a case when a - nexthop could be an IP address. The RIB manager would resolve how to - reach that IP address, e.g. by checking if that particular IP is - address reachable by regular IP forwarding or by a MPLS tunnel or by - both. If the RIB manager cannot resolve the nexthop, then the - nexthop remains in an unresolved state and is NOT a suitable - candidate for installation in the FIB. + determine the final resolved nexthop. In one example, a nexthop + could be an IP address. The RIB manager would resolve how to reach + that IP address, e.g. by checking if that particular IP address is + reachable by regular IP forwarding or by a MPLS tunnel or by both. + If the RIB manager cannot resolve the nexthop, then the nexthop + remains in an unresolved state and is NOT a suitable candidate for + installation in the FIB. An implementation of this RIB data model MUST support sending route- change notifications whenever a route transitions between the following states: o from the active state to the inactive state o from the inactive state to the active state o from the installed state to the uninstalled state o from the uninstalled state to the installed state - A single notification MAY be used when a route transition from + A single notification MAY be used when a route transitions from inactive/uninstalled to active/installed or in the other direction. The structure tree of notifications is shown in the following figure. notifications: +---n nexthop-resolution-status-change | +--ro nexthop | | +--ro nexthop-id uint32 | | +--ro sharing-flag boolean | | +--ro (nexthop-type)? @@ -870,21 +870,21 @@ | | | ... | | +--:(nexthop-replicates) {nexthop-replicates}? | | | ... | | +--:(nexthop-protection) {nexthop-protection}? | | | ... | | +--:(nexthop-load-balance) {nexthop-load-balance}? | | ... | +--ro nexthop-state nexthop-state-def +---n route-change +--ro rib-name string - +--ro rib-family rib-family-def + +--ro address-family rib-family-def +--ro route-index uint64 +--ro match | +--ro (route-type)? | +--:(ipv4) | | ... | +--:(ipv6) | | ... | +--:(mpls-route) | | ... | +--:(mac-route) @@ -892,21 +892,21 @@ | +--:(interface-route) | ... +--ro route-installed-state route-installed-state-def +--ro route-state route-state-def +--ro route-change-reason route-change-reason-def Figure 7: Notifications Structure 3. YANG Modules - file "ietf-i2rs-rib@2016-03-17.yang" + file "ietf-i2rs-rib@2016-07-04.yang" module ietf-i2rs-rib { namespace "urn:ietf:params:xml:ns:yang:ietf-i2rs-rib"; // replace with iana namespace when assigned prefix "iir"; import ietf-inet-types { prefix inet; //rfc6991 } @@ -921,22 +921,22 @@ organization "IETF I2RS (Interface to Routing System) Working Group"; contact "WG Web: WG List: WG Chair: Susan Hares - WG Chair: Jeffrey Haas - + WG Chair: Russ White + Editor: Lixing Wang Editor: Hariharan Ananthakrishnan Editor: Mach(Guoyi) Chen @@ -945,106 +945,106 @@ Editor: Sriganesh Kini Editor: Nitin Bahadur "; description "This module defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model."; - revision "2016-03-17" { + revision "2016-07-04" { description "initial revision"; - reference "draft-ietf-i2rs-data-model-05"; + reference "draft-ietf-i2rs-data-model-06"; } //Features feature nexthop-tunnel { description - "This feature means that a node support + "This feature means that a node supports tunnel nexthop capability."; } feature nexthop-chain { description - "This feature means that a node support + "This feature means that a node supports chain nexthop capability."; } feature nexthop-protection { description - "This feature means that a node support + "This feature means that a node supports protection nexthop capability."; } feature nexthop-replicates { description - "This feature means that a node support - relicates nexthop capability."; + "This feature means that a node supports + replicates nexthop capability."; } feature nexthop-load-balance { description - "This feature means that a node support + "This feature means that a node supports load balance nexthop capability."; } feature ipv4-tunnel { description - "This feature means that a node support + "This feature means that a node supports IPv4 tunnel encapsulation capability."; } feature ipv6-tunnel { description - "This feature means that a node support + "This feature means that a node supports IPv6 tunnel encapsulation capability."; } feature mpls-tunnel { description - "This feature means that a node support + "This feature means that a node supports MPLS tunnel encapsulation capability."; } feature vxlan-tunnel { description - "This feature means that a node support + "This feature means that a node supports VxLAN tunnel encapsulation capability."; } feature gre-tunnel { description - "This feature means that a node support + "This feature means that a node supports GRE tunnel encapsulation capability."; } feature nvgre-tunnel { description - "This feature means that a node support + "This feature means that a node supports NvGRE tunnel encapsulation capability."; } feature route-vendor-attributes { description - "This feature means that a node support + "This feature means that a node supports route vendor attributes."; } //Identities and Type Definitions identity mpls-label-action { description - "Base identify from which all mpls label + "Base identity from which all MPLS label operations are derived. The MPLS label stack operations include: push - to add a new label to a label stack, pop - to pop the top label from a label stack, - swap - to change the top label of a label + swap - to exchange the top label of a label stack with new label."; } identity label-push { base "mpls-label-action"; description "MPLS label stack operation: push."; } identity label-pop { base "mpls-label-action"; @@ -1061,21 +1061,21 @@ typedef mpls-label-action-def { type identityref { base "mpls-label-action"; } description "MPLS label action def."; } identity tunnel-decap-action { description - "Base identify from which all tunnel decap + "Base identity from which all tunnel decap actions are derived. Tunnel decap actions include: ipv4-decap - to decap an IPv4 tunnel, ipv6-decap - to decap an IPv6 tunnel."; } identity ipv4-decap { base "tunnel-decap-action"; description "IPv4 tunnel decap."; @@ -1090,92 +1090,92 @@ typedef tunnel-decap-action-def { type identityref { base "tunnel-decap-action"; } description "Tunnel decap def."; } identity ttl-action { description - "Base identify from which all TTL + "Base identity from which all TTL actions are derived."; } identity no-action { base "ttl-action"; description "Do nothing regarding the TTL."; } identity copy-to-inner { base "ttl-action"; description "Copy the TTL of the outer header - to inner header."; + to the inner header."; } identity decrease-and-copy-to-inner { base "ttl-action"; description "Decrease TTL by one and copy the TTL - to inner header."; + to the inner header."; } identity decrease-and-copy-to-next { base "ttl-action"; description "Decrease TTL by one and copy the TTL to the next header.For example: when MPLS label swapping, decrease the TTL - of the in label and copy it to the out - label."; + of the inner label and copy it to the + outer label."; } typedef ttl-action-def { type identityref { base "ttl-action"; } description "TTL action def."; } identity hop-limit-action { description - "Base identify from which all hop limit + "Base identity from which all hop limit actions are derived."; } identity hop-limit-no-action { base "hop-limit-action"; description "Do nothing regarding the hop limit."; } identity hop-limit-copy-to-inner { base "hop-limit-action"; description "Copy the hop limit of the outer header - to inner header."; + to the inner header."; } typedef hop-limit-action-def { type identityref { base "hop-limit-action"; } description "IPv6 hop limit action def."; } identity special-nexthop { description - "Base identify from which all special + "Base identity from which all special nexthops are derived."; } identity discard { base "special-nexthop"; description "This indicates that the network device should drop the packet and increment a drop counter."; } @@ -1186,21 +1186,21 @@ "This indicates that the network device should drop the packet, increment a drop counter and send back an appropriate error message (like ICMP error)."; } identity receive { base "special-nexthop"; description - "This indicates that that the traffic is + "This indicates that the traffic is destined for the network device. For example, protocol packets or OAM packets. All locally destined traffic SHOULD be throttled to avoid a denial of service attack on the router's control plane. An optional rate-limiter can be specified to indicate how to throttle traffic destined for the control plane."; } @@ -1213,21 +1213,21 @@ typedef special-nexthop-def { type identityref { base "special-nexthop"; } description "Special nexthop def."; } identity ip-route-match-type { description - "Base identify from which all route + "Base identity from which all route match types are derived. Route match type could be: match source, or match destination, or match source and destination."; } identity match-ip-src { base "ip-route-match-type"; description @@ -1235,73 +1235,73 @@ } identity match-ip-dest { base "ip-route-match-type"; description "Destination route match type"; } identity match-ip-src-dest { base "ip-route-match-type"; description - "Src and Dest route match type"; + "Source and Destination route match type"; } typedef ip-route-match-type-def { type identityref { base "ip-route-match-type"; } description "IP route match type def."; } identity rib-family { description - "Base identify from which all rib + "Base identity from which all RIB address families are derived."; } identity ipv4-rib-family { base "rib-family"; description - "IPv4 rib address family."; + "IPv4 RIB address family."; } identity ipv6-rib-family { base "rib-family"; description - "IPv6 rib address family."; + "IPv6 RIB address family."; } identity mpls-rib-family { base "rib-family"; description - "MPLS rib address family."; + "MPLS RIB address family."; } identity ieee-mac-rib-family { base "rib-family"; description - "MAC rib address family."; + "MAC RIB address family."; } typedef rib-family-def { type identityref { base "rib-family"; } description "Rib address family def."; } identity route-type { description - "Base identify from which all route types + "Base identity from which all route types are derived."; } identity ipv4-route { base "route-type"; description "IPv4 route type."; } identity ipv6-route { @@ -1331,21 +1331,21 @@ typedef route-type-def { type identityref { base "route-type"; } description "Route type def."; } identity tunnel-type { description - "Base identify from which all tunnel + "Base identity from which all tunnel types are derived."; } identity ipv4-tunnel { base "tunnel-type"; description "IPv4 tunnel type"; } identity ipv6-tunnel { @@ -1380,21 +1380,21 @@ typedef tunnel-type-def { type identityref { base "tunnel-type"; } description "Tunnel type def."; } identity route-state { description - "Base identify from which all route + "Base identity from which all route states are derived."; } identity active { base "route-state"; description "Active state."; } identity inactive { @@ -1406,21 +1406,21 @@ typedef route-state-def { type identityref { base "route-state"; } description "Route state def."; } identity nexthop-state { description - "Base identify from which all nexthop + "Base identity from which all nexthop states are derived."; } identity resolved { base "nexthop-state"; description "Reolved nexthop state."; } identity unresolved { @@ -1432,21 +1432,21 @@ typedef nexthop-state-def { type identityref { base "nexthop-state"; } description "Nexthop state def."; } identity route-installed-state { description - "Base identify from which all route + "Base identity from which all route installed states are derived."; } identity uninstalled { base "route-installed-state"; description "Uninstalled state."; } identity installed { @@ -1460,38 +1460,38 @@ base "route-installed-state"; } description "Route installed state def."; } //Route change reason identities identity route-change-reason { description - "Base identify from which all route change + "Base identity from which all route change reasons are derived."; } identity lower-route-preference { base "route-change-reason"; description "This route was installed in the FIB because it had - a lower route preference value (and thus a higher - route preference) than the route it replaced."; + a lower route preference value (and thus was more + preferred) than the route it replaced."; } identity higher-route-preference { base "route-change-reason"; description "This route was uninstalled from the FIB because it had - a higher route preference value (and thus a lower - route preference) than the route that replaced it."; + a higher route preference value (and thus was less + preferred) than the route that replaced it."; } identity resolved-nexthop { base "route-change-reason"; description "This route was made active because at least one of its nexthops was resolved."; } identity unresolved-nexthop { @@ -1508,31 +1508,45 @@ description "Route change reason def."; } typedef nexthop-preference-def { type uint8 { range "1..99"; } description "Nexthop-preference is used for protection schemes. - It is an integer value between 1 and 99. A lower - value indicates higher preference. To download N + It is an integer value between 1 and 99. Lower + values are more preferred. To download N nexthops to the FIB, the N nexthops with the lowest - value are selected."; + value are selected. If there are more than N + nexthops that have the same preference, an + implementation of i2rs client should select N + nexthops and download them, as for how to select + the nexthops is left to the implementations."; } typedef nexthop-lb-weight-def { type uint8 { range "1..99"; } description - "Nhop-lb-weight is a number between 1 and 99."; + "Nexthop-lb-weight is used for load-balancing. + Each list member MUST be assigned a weight + between 1 and 99. The weight determines the + proportion of traffic to be sent over a nexthop + used for forwarding as a ratio of the weight of + this nexthop divided by the weights of all the + nexthops of this route that are used for forwarding. + To perform equal load-balancing, one MAY specify + a weight of 0 for all the member nexthops. The + value 0 is reserved for equal load-balancing + and if applied, MUST be applied to all member nexthops."; } typedef nexthop-ref { type leafref { path "/iir:routing-instance" + "/iir:rib-list" + "/iir:route-list" + "/iir:nexthop" + "/iir:nexthop-id"; } @@ -1689,69 +1702,70 @@ description "The interface used for matching."; } } } } } grouping route { description - "The common attributes used for all types of route."; + "The common attributes used for all types of routes."; uses route-prefix; container nexthop { description "The nexthop of the route."; uses nexthop; } - container route-statistic { + //In the information model, it is called route-statistic + container route-status { description - "The statistic information of the route."; + "The status information of the route."; leaf route-state { type route-state-def; config false; description "Indicate a route's state: Active or Inactive."; } leaf route-installed-state { type route-installed-state-def; config false; description "Indicate that a route's installed states: Installed or uninstalled."; } leaf route-reason { type route-change-reason-def; config false; description - "Indicate the route reason."; + "Indicate the reason that causes the route change."; } } container route-attributes { description "Route attributes."; uses route-attributes; } container route-vendor-attributes { description "Route vendor attributes."; uses route-vendor-attributes; } } grouping nexthop-list { description "A generic nexthop list."; list nexthop-list { key "nexthop-member-id"; description - "A list of nexthop."; + "A list of nexthops."; leaf nexthop-member-id { type uint32; mandatory true; description "A nexthop identifier that points to a nexthop list member. A nexthop list member is a nexthop."; } } } @@ -1769,25 +1783,25 @@ description "A nexthop identifier that points to a nexthop list member. A nexthop list member is a nexthop."; } leaf nexthop-preference { type nexthop-preference-def; mandatory true; description "Nexthop-preference is used for protection schemes. - It is an integer value between 1 and 99. A lower - value indicates higher preference. To download a + It is an integer value between 1 and 99. Lower + values are more preferred. To download a primary/standby/tertiary group to the FIB, the - nexthops that are resolved and have two highest - preferences are selected."; + nexthops that are resolved and are most preferred + are selected."; } } } grouping nexthop-list-w { description "A nexthop list with weight parameter."; list nexthop-list { key "nexthop-member-id"; description @@ -1856,21 +1871,21 @@ case nexthop-protection { if-feature nexthop-protection; container nexthop-protection { description "A protection nexthop."; uses nexthop-list-p; } } case nexthop-load-balance { if-feature nexthop-load-balance; - container nexthop-lbs { + container nexthop-lb { description "A load balance nexthop."; uses nexthop-list-w; } } } } grouping nexthop-base { description @@ -1918,63 +1933,64 @@ "Name of the outgoing interface."; } leaf ipv4-address { type inet:ipv4-address; mandatory true; description "The nexthop points to an interface with an IPv4 address."; } description - "The nexthop is an Egress-interface and an ip + "The nexthop is an egress-interface and an IP address.This can be used in cases e.g.where - the ip address is a link-local address."; + the IP address is a link-local address."; } } case egress-interface-ipv6-nexthop { container egress-interface-ipv6-address { leaf outgoing-interface { type if:interface-ref; mandatory true; description "Name of the outgoing interface."; + } leaf ipv6-address { type inet:ipv6-address; mandatory true; description "The nexthop points to an interface with an IPv6 address."; } description - "The nexthop is an Egress-interface and an ip + "The nexthop is an egress-interface and an IP address.This can be used in cases e.g.where - the ip address is a link-local address."; + the IP address is a link-local address."; } } case egress-interface-mac-nexthop { container egress-interface-mac-address { leaf outgoing-interface { type if:interface-ref; mandatory true; description "Name of the outgoing interface."; } leaf ieee-mac-address { type uint32; mandatory true; description "The nexthop points to an interface with a specific mac-address."; } description - "The egress interface must be an ethernet + "The egress interface must be an Ethernet interface. Address resolution is not required for this nexthop."; } } case tunnel-encap-nexthop { if-feature nexthop-tunnel; container tunnel-encap { uses tunnel-encap; description "This can be an encap representing an IP tunnel or @@ -1994,30 +2011,30 @@ description "This is to specify decapsulating a tunnel header."; } } case logical-tunnel-nexthop { if-feature nexthop-tunnel; container logical-tunnel { uses logical-tunnel; description "This can be a MPLS LSP or a GRE tunnel (or others - as defined in This document), that is represented + as defined in this document), that is represented by a unique identifier (e.g. name)."; } } case rib-name-nexthop { leaf rib-name { type string; description - "A nexthop pointing to a rib indicates that the - route lookup needs to continue in The specified + "A nexthop pointing to a RIB indicates that the + route lookup needs to continue in the specified rib. This is a way to perform chained lookups."; } } case nexthop-identifier { leaf nexthop-ref { type nexthop-ref; mandatory true; description "A nexthop reference that points to a nexthop."; } @@ -2048,27 +2065,27 @@ } } grouping ipv4-header { description "The IPv4 header encapsulation information."; leaf src-ipv4-address { type inet:ipv4-address; mandatory true; description - "The source ip address of the header."; + "The source IP address of the header."; } leaf dest-ipv4-address { type inet:ipv4-address; mandatory true; description - "The destination ip address of the header."; + "The destination IP address of the header."; } leaf protocol { type uint8; mandatory true; description "The protocol id of the header."; } leaf ttl { type uint8; description @@ -2073,35 +2090,34 @@ type uint8; description "The TTL of the header."; } leaf dscp { type uint8; description "The DSCP field of the header."; } } - grouping ipv6-header { description "The IPv6 header encapsulation information."; leaf src-ipv6-address { type inet:ipv6-address; mandatory true; description - "The source ip address of the header."; + "The source IP address of the header."; } leaf dest-ipv6-address { type inet:ipv6-address; mandatory true; description - "The destination ip address of the header."; + "The destination IP address of the header."; } leaf next-header { type uint8; mandatory true; description "The next header of the IPv6 header."; } leaf traffic-class { type uint8; description @@ -2138,26 +2154,27 @@ mandatory true; description "The subnet identifier of the NvGRE header."; } leaf flow-id { type uint16; description "The flow identifier of the NvGRE header."; } } + grouping vxlan-header { description "The VxLAN encapsulation header information."; choice vxlan-type { description - "NvGRE can use eigher IPv4 + "NvGRE can use either IPv4 or IPv6 header for encapsulation."; case ipv4 { uses ipv4-header; } case ipv6 { uses ipv6-header; } } leaf vxlan-identifier { type uint32; @@ -2171,29 +2188,29 @@ description "The GRE encapsulation header information."; choice dest-address-type { description "GRE options: IPv4 and IPv6"; case ipv4 { leaf ipv4-dest { type inet:ipv4-address; mandatory true; description - "The destination ip address of the GRE header."; + "The destination IP address of the GRE header."; } } case ipv6 { leaf ipv6-dest { type inet:ipv6-address; mandatory true; description - "The destination ip address of the GRE header."; + "The destination IP address of the GRE header."; } } } leaf protocol-type { type uint16; mandatory true; description "The protocol type of the GRE header."; } leaf key { @@ -2235,21 +2252,21 @@ "The s-bit of the label to be pushed. "; } leaf tc-value { type uint8; description "The traffic class value of the label to be pushed."; } leaf ttl-value { type uint8; description - "The TTL value of the label to to be pushed."; + "The TTL value of the label to be pushed."; } } } case label-swap { container label-swap { description "Label swap operation."; leaf in-label { type uint32; mandatory true; @@ -2265,38 +2282,38 @@ leaf ttl-action { type ttl-action-def; description "The label ttl actions: - No-action, or - Copy to inner label,or - Decrease (the in label) by 1 and copy to the out label."; } } + } } } } grouping tunnel-encap{ description - "Tunnel encapsulation inforamtion."; + "Tunnel encapsulation information."; choice tunnel-type { description "Tunnel options for next-hops."; case ipv4 { if-feature ipv4-tunnel; container ipv4-header { uses ipv4-header; description "IPv4 header."; - } } case ipv6 { if-feature ipv6-tunnel; container ipv6-header { uses ipv6-header; description "IPv6 header."; } } @@ -2330,22 +2347,21 @@ uses vxlan-header; description "VxLAN header."; } } } } grouping tunnel-decap { description - "Tunnel decapsulation inforamtion."; - + "Tunnel decapsulation information."; choice tunnel-type { description "Nexthop tunnel type options."; case ipv4 { if-feature ipv4-tunnel; container ipv4-decap { description "IPv4 decap."; leaf ipv4-decap { type tunnel-decap-action-def; @@ -2405,21 +2421,21 @@ description "Route attributes."; leaf route-preference { type uint32; mandatory true; description "ROUTE_PREFERENCE: This is a numerical value that allows for comparing routes from different protocols. Static configuration is also considered a protocol for the purpose of this - field. It iss also known as administrative-distance. + field. It is also known as administrative-distance. The lower the value, the higher the preference."; } leaf local-only { type boolean ; mandatory true; description "Indicate whether the attributes is local only."; } container address-family-route-attributes{ description @@ -2428,31 +2444,29 @@ description "Address family related route attributes."; case ip-route-attributes { } case mpls-route-attributes { } case ethernet-route-attributes { } } } - } container routing-instance { description "A routing instance, in the context of the RIB information model, is a collection of RIBs, interfaces, and routing parameters"; leaf name { type string; - mandatory true; description "The name of the routing instance.This MUST be unique across all routing instances in a given network device."; } list interface-list { key "name"; description "This represents the list of interfaces associated with this routing instance. The interface list helps @@ -2481,57 +2495,59 @@ key "name"; description "A list of RIBs that are associated with the routing instance."; leaf name { type string; mandatory true; description "A reference to the name of each rib."; } - leaf rib-family { + leaf address-family { type rib-family-def; mandatory true; description "The address family of a rib."; } leaf ip-rpf-check { type boolean; description "Each RIB can be optionally associated with a ENABLE_IP_RPF_CHECK attribute that enables Reverse path forwarding (RPF) checks on all IP routes in that RIB. Reverse path forwarding (RPF) check is used to prevent spoofing and limit malicious traffic."; } list route-list { key "route-index"; description "A list of routes of a rib."; uses route; } + // This is a list that maintains the nexthops added to the rib. + uses nexthop-list; } } - /*RPC Operations*/ + //RPC Operations rpc rib-add { description - "To add a rib to a instance"; + "To add a RIB to a instance"; input { - leaf rib-name { + leaf name { type string; mandatory true; description - "A reference to the name of the rib + "A reference to the name of the RIB that is to be added."; } - leaf rib-family { + leaf address-family { type rib-family-def; mandatory true; description "The address family of the rib."; } leaf ip-rpf-check { type boolean; description "Each RIB can be optionally associated with a ENABLE_IP_RPF_CHECK attribute that enables Reverse @@ -2552,29 +2568,30 @@ leaf reason { type string; description "The specific reason that causes the failure."; } } } rpc rib-delete { description - "To delete a rib from a routing instance. + "To delete a RIB from a routing instance. After deleting the rib, all routes installed - in the rib will be deleted as well."; + in the RIB will be deleted as well."; + input { - leaf rib-name { + leaf name { type string; mandatory true; description - "A reference to the name of the rib + "A reference to the name of the RIB that is to be deleted."; } } output { leaf result { type boolean; mandatory true; description "Return the result of the rib-delete operation. true - success; @@ -2737,30 +2756,31 @@ container updated-route-attr { uses route-attributes; description "The route attributes used for updating."; } } case update-route-vendor-attributes { container updated-route-vendor-attr { uses route-vendor-attributes; description - "The vender route attributes used for updating."; + "The vendor route attributes used for updating."; } } } } rpc route-update { description "To update a route or a list of route of a rib. The inputs: + 1. The match conditions, could be: a. route prefix, or b. route attributes, or c. nexthop; 2. The update parameters to be used: a. new nexthop; b. new route attributes;nexthop Actions: 1. update the nexthop 2. update the route attributes @@ -2862,26 +2882,25 @@ } } output { uses route-operation-state; } } rpc nh-add { description "To add a nexthop to a rib. - Inputs parameters: - 1. rib name + 1. RIB name 2. nexthop; Actions: - Add the nexthop to the rib + Add the nexthop to the RIB Outputs: 1.Operation result: true - success false - failed; 2. nexthop identifier."; input { leaf rib-name { type string; mandatory true; description @@ -2899,21 +2918,21 @@ false - failed;"; } leaf reason { type string; description "The specific reason that causes the failure."; } leaf nexthop-id { type uint32; description - "A nexthop identifer that is allocated to the nexthop."; + "A nexthop identifier that is allocated to the nexthop."; } } } rpc nh-delete { description "To delete a nexthop from a rib"; input { leaf rib-name { type string; @@ -2961,25 +2981,25 @@ notification route-change { description "Route change notification."; leaf rib-name { type string; mandatory true; description "A reference to the name of a rib."; } - leaf rib-family { + leaf address-family { type rib-family-def; mandatory true; description - "A reference to address family of a rib."; + "The address family of a rib."; } uses route-prefix; leaf route-installed-state { type route-installed-state-def; mandatory true; description "Indicates whether the route got installed in the FIB."; } leaf route-state { type route-state-def; @@ -3003,59 +3024,68 @@ "The reason that causes the route change."; } } } } 4. IANA Considerations - This document requests to register a URI in the "IETF XML registry" - [RFC3688]: + This document requests to register a URI in the "ns" registry with + the "IETF XML registry" [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib - Registrant Contact: The IESG.XML: - N/A, the requested URI is an XML namespace. + Registrant Contact: The IESG. + XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- This document requests to register a YANG module in the "YANG Module Names registry" [RFC6020]: -------------------------------------------------------------------- name: ietf-i2rs-rib namespace: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib prefix: iir reference: RFC XXXX -------------------------------------------------------------------- 5. Security Considerations - This document introduces no extra new security threat and SHOULD - follow the security requirements as stated in - [I-D.ietf-i2rs-architecture]. + I2RS protocol provides read and write access to the information and + state (e.g., RIB) within the routing process that exists inside the + routing elements. These information and state are normally + considered sensitive or vulnerable. Improper write operations to + these information and state can have negative effects on the network. + + The I2RS protocol will provide security mechanisms as required in + [I-D.ietf-i2rs-security-environment-reqs] and + [I-D.ietf-i2rs-protocol-security-requirements]. + + The YANG data model defined in this document itself will not + introduce extra security issues. 6. Contributors The following individuals also contribute to this document. o Zekun He, Tencent Holdings Ltd o Sujian Lu, Tencent Holdings Ltd o Jeffery Zhang, Juniper Networks 7. Acknowledgements - The authors would like to thank Chris Bowers for his review, - suggestion and comments to this document. + The authors would like to thank Chris Bowers and John Scudder for his + review, suggestion and comments to this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -3070,28 +3100,38 @@ [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . 8.2. Informative References [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing - System", draft-ietf-i2rs-architecture-13 (work in - progress), February 2016. + System", draft-ietf-i2rs-architecture-15 (work in + progress), April 2016. + + [I-D.ietf-i2rs-protocol-security-requirements] + Hares, S., Migault, D., and J. Halpern, "I2RS Security + Related Requirements", draft-ietf-i2rs-protocol-security- + requirements-06 (work in progress), May 2016. [I-D.ietf-i2rs-rib-info-model] Bahadur, N., Kini, S., and J. Medved, "Routing Information Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work in progress), October 2015. + [I-D.ietf-i2rs-security-environment-reqs] + Migault, D., Halpern, J., and S. Hares, "I2RS Environment + Security Requirements", draft-ietf-i2rs-security- + environment-reqs-01 (work in progress), April 2016. + [I-D.ietf-i2rs-usecase-reqs-summary] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", draft-ietf-i2rs-usecase-reqs-summary-02 (work in progress), March 2016. Authors' Addresses Lixing Wang Individual